Ser “de fora para dentro”, “baseado em resultados” ou “orientado pelo negócio” é particularmente importante para a criação de produtos de sucesso. O problema é que somente dizer essas palavras não é suficiente para ajudar alguém a mudar suas opiniões. Para aqueles que já pensam dessa maneira, as expressões se tornam critérios. Para aqueles que ainda não pensam assim, elas podem parecer triviais ou palavras vazias. Conheço muitas pessoas que querem mudar seus papéis de “faça isso” para “resolva esses problemas”. Elas precisam mudar suas organizações. Esse exemplo pode ajudar a explicar isso.

Gerente de contatos

Eu estava conversando via mensagens de texto no mês passado com outras 3 pessoas (um grupo de MMS). Em vez de ver 3 nomes, eu via 2 nomes e 1 número de telefone – não é uma boa maneira de identificar os participantes. Como eu tinha ajudado a criar um aplicativo de mensagens antes, acabei tendo uma ideia de como o aplicativo deveria funcionar. Quando o aplicativo recebe uma mensagem, ele recebe uma “carga” de informações que combina a mensagem com outras informações sobre a mensagem (dados e metadados). Essa carga inclui as mensagens e outros números de telefone identificando os participantes da conversa. Então o aplicativo verifica a lista de contatos do meu telefone e, para cada número que ele encontra, substitui o número de telefone pelo nome do meu contato. Os que não foram encontrados ficam como “desconhecido”.

Estou contando como o aplicativo funciona por dentro, pois essa é uma situação que encara as pessoas que possuem uma perspectiva “de fora para dentro”. Especialmente porque elas sabem como as coisas funcionam – elas formam discussões sobre como mudar o que um produto faz mudando a maneira como ele faz. A maldição do conhecimento mina o mercado.

Eu consegui identificar o participante desconhecido devido ao contexto da conversa. Eu comecei o processo de adicionar aquela pessoa à minha lista de contatos. Eu coloquei o nome da pessoa e o aplicativo pré-preencheu o número do telefone para mim. Muito conveniente. Meu cérebro mudou para o modo de “gerenciamento de requisitos” por um tempo, e me imaginei escrevendo uma User Story.

A principal peça que falta na User Story acima é a intenção. Como uma pessoa, eu quero fazer alguma atividade (com mais frequência), para então eu perceber algum benefício. À primeira vista, parece que existe intenção – “Adicionar…” mas essa não é a intenção, é somente a atividade.

Um erro comum seria escrever:

Como um participante de uma conversa por SMS, eu quero poder adicionar pessoas desconhecidas à minha lista de contatos.

Essa história tem o “sentimento” do programador que está escrevendo o código primeiro, para documentar o design mais tarde. Intuitivamente, você quer poder mudar o contexto do que você está fazendo (participando da conversa) para fazer alguma correção (adicionar alguém à sua lista de contatos). As pessoas gostam de organizar as coisas. Especialmente programadores.

Isso não parece totalmente certo – a intenção parece errada. Parece que alguém já decidiu que essa funcionalidade é um requisito, e como parte de trabalhar sua lista das funcionalidades desejadas está forçando seu desejo “de dentro para fora” em uma sintaxe de história escrita para comunicar a intenção do cliente que foi descoberta.

Um erro menos comum seria escrever:

Como um participante de uma conversa por SMS, eu quero poder adicionar contatos desconhecidos à minha lista de contatos para mantê-la atualizada.

Novamente, isso parece uma história “de dentro para fora”. Imagine que um usuário te disse que é isso que ele quer. Isso ainda seria um exemplo de foco na manifestação do problema (uma lista de contatos incompleta ou desatualizada) em vez do problema – identificar pessoas. Os usuários quase sempre se fixam nas manifestações dos problemas, em vez de determinarem os problemas.

• Falta essa pessoa na minha lista de contatos x Eu preciso saber a identidade dessa pessoa
• Meu telefone não toca alto o suficiente x Não estou notando as chamadas recebidas
• Preciso de um cavalo mais rápido x Preciso chegar ao meu destino mais rápido.

Determinando a intenção

Determinar a intenção do seu usuário (ou patrocinador) é o requisito. Quando você expressa os requisitos de dentro para fora (com uma abordagem de design presumido), você perde oportunidades de criar um produto notavelmente melhor. Como você articula os requisitos inequivocamente dá base e restringe o espaço da solução na qual sua equipe vai resolver os problemas determinados. Considere nosso exemplo, de não conseguir identificar todos os participantes da conversa.

Quando você passa à sua equipe “Como um participante em uma conversa por SMS, eu quero poder adicionar pessoas desconhecidas à minha lista de contatos”, eles vão criar uma solução para fazer isso. Eles poderiam criar um workflow elegante no qual o usuário clica e segura sobre o número de telefone desconhecido, e o telefone apresenta uma interação que cause o mínimo de incômodo – talvez adicionando apenas o nome e sobrenome – então volta à conversa. O telefone pode até criar uma notificação pop-up que, após 5 minutos de inatividade, indique que a conversa foi completada – encorajando o usuário a passar mais informações. Parece ótimo, certo?

Aqui está o problema. O usuário não quer atualizar sua lista de contatos. O usuário não se importa em ter uma lista de contatos. O usuário quer saber quem está na conversa. Vamos reescrever a user story assim:

Como um participante em uma conversa de SMS, quero saber quem são todos os participantes.

Agora sua equipe pode desenvolver alguma coisa como a seguinte solução para o problema apontado. Se existe uma lista de contatos, e o telefone identifica o número de telefone, ele utiliza o nome do contato. Se não, atualiza a lista de contatos quando o nome do contato desconhecido for descoberto. Tente deduzir o nome do participante pelo contexto da conversa e outras conversas que incluam o mesmo número, mesmo que de outros usuários. Talvez a plataforma ofereça opções de backup e restore, incluindo mensagens – esses dados podem ser minerados atrás da identidade da pessoa associada ao número de telefone. Talvez seu aplicativo de mensagem seja parte, ou pertença, a uma rede social ou outro produto ou serviço que tenha indexação das identidades referentes aos números de telefone – agora você pode olhar para ele diretamente. Dê um passo a frente – não deduza somente o nome, encontre a foto de perfil associada ao participante, encontre o avatar do participante.

Então, automaticamente atualize o aplicativo de mensagens para substituir o número de telefone pelo avatar ou nome do participante. Utilize qualquer técnica que seja mais “elegante” para lembrar identidades no futuro.

Talvez “saber quem alguém é” requeira mais do que somente um nome; talvez requeira “Nome – você falou com ela sobre tecnologia wearable no evento de tecnologia no evento do Hotel Citadela no sábado à noite”. Tenha uma maneira elegante para a aplicação informar de qual contato é a mensagem e como vocês se conectaram.

Essas são maneiras criativas de resolver um problema que sua equipe não esteja disposta a explorar quando você os diz que quer “atualizar a lista de contatos”. Você perde uma oportunidade de inovar – de investir em algo valioso – por focar em uma perspectiva de dentro para fora da manifestação do seu problema.

Conclusão

Focar na criação do seu produto ou na resolução do seu problema é sutilmente, mas poderosamente, diferente de focar na criação de funcionalidades.

Sua equipe consegue fazer somente o que você peça que façam e depois lhes diga como fazer.

Sua equipe consegue fazer coisas realmente ótimas, quando você os conta o motivo.

***

Scott Sehlhorst faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://tynerblain.com/blog/2016/10/06/outside-in-user-story/.