Tutoriais9 min de leitura

De um pedido vago de funcionalidade a um plano de entrega claro

Acompanhe um exemplo de onboarding desde uma pergunta em aberto até uma melhoria pequena e testável, com um mapa mental que cresce à medida que as decisões ficam mais claras.

Alguém diz: “Precisamos facilitar o onboarding”.

Todo mundo concorda. Então começam as sugestões: adicionar uma lista de tarefas, encurtar o fluxo de configuração, escrever instruções melhores, enviar um e-mail de boas-vindas.

Em pouco tempo, já há ideias suficientes para preencher uma sprint. O que não está tão claro é qual problema a equipe está tentando resolver.

Esse é um bom momento para criar um mapa mental. Ele oferece à equipe um espaço para explorar a solicitação, conectar ideias e manter visíveis as perguntas sem resposta antes de decidir o que desenvolver.

Neste guia, vamos acompanhar uma equipe fictícia que trabalha em um produto com espaços de trabalho compartilhados. Novos clientes criam uma conta, configuram um espaço de trabalho e convidam seus colegas. A equipe recebeu a tarefa de melhorar essa experiência.

Vamos levar a solicitação de uma discussão aberta até uma pequena tarefa claramente descrita no Jira. Você pode seguir o mesmo processo com qualquer ferramenta de mapas mentais.

1. Comece pela solicitação, sem tratá-la como a resposta

“Facilitar o onboarding” expressa uma intenção. Ainda não diz onde as pessoas encontram dificuldades nem o que deveria mudar.

A equipe coloca Melhorar o onboarding no centro do mapa e adiciona quatro ramificações:

  • Criar uma conta
  • Configurar um espaço de trabalho
  • Convidar colegas
  • Realizar juntos a primeira ação útil

Isso dá estrutura à conversa. Em vez de discutir o “onboarding” como um único grande problema, as pessoas podem apontar para uma parte específica da experiência.

A equipe adiciona o que sabe no momento ao lado das ramificações relevantes. No nosso exemplo fictício, o suporte recebeu perguntas sobre onde convidar colegas. Durante uma sessão de observação, uma pessoa que acabou de criar seu espaço de trabalho procura uma opção de convite na tela inicial do espaço. A opção existe, mas fica dentro das configurações do espaço de trabalho.

Essas observações indicam um ponto a investigar. Elas não provam que todo o fluxo de onboarding precisa ser reconstruído.

A equipe mantém as outras ramificações no mapa e volta sua atenção para Convidar colegas.

2. Separe o que você sabe do que você supõe

É fácil uma explicação começar a parecer um fato quando alguém a apresenta com confiança.

“As pessoas não estão convidando os colegas porque o processo de convite é complicado demais.”

Talvez. Mas elas têm dificuldade para encontrar o formulário de convite, preenchê-lo ou entender por que deveriam convidar alguém naquele momento? Esses são problemas diferentes.

Na ramificação de convites, a equipe cria três grupos.

Observado

  • O suporte recebeu perguntas sobre onde convidar colegas.
  • Um proprietário de espaço de trabalho procurou os convites na tela inicial.
  • A opção de convite atual fica dentro das configurações do espaço de trabalho.

Suposto

  • Um ponto de acesso mais visível ajudaria as pessoas a encontrá-la.
  • Alguns proprietários talvez não percebam que convidar colegas é um próximo passo útil.

Ainda não está claro

  • Os proprietários conseguem preencher o formulário existente depois de encontrá-lo?
  • As pessoas que recebem um convite entendem o que fazer em seguida?

Os rótulos importam mais do que o estilo visual. Qualquer pessoa que olhe o mapa deve conseguir distinguir uma observação de uma possível explicação.

Antes de escolher uma solução, a equipe pede a alguns novos proprietários de espaços de trabalho que tentem convidar um colega. Ela observa onde eles procuram e pergunta o que esperam que aconteça, sem mostrar primeiro a opção de convite.

Neste exemplo, as sessões sugerem que encontrar o formulário é o obstáculo imediato. Depois que o ponto de acesso é mostrado, os proprietários conseguem preenchê-lo. A experiência de quem recebe o convite ainda precisa de uma análise separada.

Agora a equipe pode descrever um problema mais específico:

“Novos proprietários de espaços de trabalho não encontram facilmente onde convidar seus colegas.”

Isso é específico o suficiente para orientar a próxima discussão. Também é algo que a equipe pode reavaliar depois de fazer uma alteração.

Comece separando o que você observou do que ainda precisa descobrir.

3. Explore algumas respostas para o mesmo problema

Com o problema mais claro, a equipe volta às possíveis melhorias. Ela adiciona três opções ao mapa:

  • Colocar uma ação Convidar colegas na tela inicial do espaço de trabalho.
  • Adicionar uma etapa de convite ao fluxo de configuração inicial.
  • Enviar um e-mail de acompanhamento explicando como convidar colegas.

Cada opção pode ajudar, mas cada uma chega ao proprietário em um momento diferente.

A ação na tela inicial estaria disponível quando alguém voltasse ao seu espaço de trabalho. Uma etapa na configuração apresentaria os convites logo no início, mas alguns proprietários talvez ainda não estivessem prontos para convidar outras pessoas. Um e-mail poderia servir de lembrete, embora o proprietário ainda precisasse voltar ao produto.

A equipe escreve uma breve nota ao lado de cada opção explicando o que ela pretende facilitar. Isso mantém a discussão ligada ao problema, em vez de transformá-la em uma votação sobre a funcionalidade favorita de cada pessoa.

Não é necessário mapear todas as soluções imagináveis. Comece com algumas respostas plausíveis e pergunte:

  • Isso resolve a dificuldade que observamos?
  • Vai ajudar no momento em que o proprietário precisar?
  • O que precisaríamos descobrir ou mudar para fazer isso funcionar?

Um mapa útil facilita a discussão dessas escolhas. Ter mais ramificações não o torna automaticamente melhor.

Compare algumas respostas para o mesmo problema antes de escolher uma.

4. Escolha um primeiro passo útil

A equipe escolhe testar uma ação de convite visível na tela inicial do espaço de trabalho.

Por que essa opção? Ela responde diretamente ao lugar onde os proprietários estavam procurando, e a equipe pode usar o formulário de convite existente. Além disso, a ação continua disponível para os proprietários que decidirem convidar colegas mais tarde.

Esse é um ponto de partida, não uma afirmação de que todos os problemas de onboarding foram resolvidos.

A equipe expande a ramificação selecionada com o escopo acordado e registra, ao lado do plano, as ideias adiadas e a investigação ainda em aberto:

Nesta melhoria

  • Adicionar uma ação de convite com um rótulo claro à tela inicial do espaço de trabalho.
  • Abrir o formulário de convite existente a partir dessa ação.
  • Manter as permissões de convite e o comportamento de envio existentes.

Mais tarde

  • Avaliar se uma etapa de convite deve fazer parte da configuração inicial.
  • Avaliar se um lembrete posterior seria útil.

Precisa de investigação

  • Verificar a experiência de receber e aceitar um convite.

Manter esses grupos visíveis ajuda a evitar que a discussão reabra repetidamente as mesmas decisões. A ideia do e-mail não desapareceu. A experiência de quem recebe o convite não foi esquecida. Elas apenas não fazem parte desta primeira melhoria.

Nesse momento, a equipe também consulta as pessoas que vão implementar a alteração. Reutilizar um formulário existente parece simples, mas pode haver restrições que afetem a abordagem. É melhor descobri-las antes de considerar o escopo definido.

Desenvolva a melhoria escolhida até chegar a um escopo pequeno e explícito.

5. Descreva o que uma pessoa deve conseguir fazer

“Adicionar um botão de convite” descreve uma alteração na interface. Diz menos sobre a experiência que a equipe quer criar.

Uma pergunta mais útil é:

“O que um proprietário de espaço de trabalho deve conseguir fazer quando essa melhoria estiver concluída?”

A equipe concorda com uma lista curta de verificações:

  • Um proprietário com permissão para convidar colegas consegue encontrar uma ação Convidar colegas na tela inicial do espaço de trabalho.
  • Ao selecioná-la, o formulário de convite existente é aberto para o espaço de trabalho atual.
  • O proprietário consegue concluir o convite usando o fluxo existente.
  • Uma pessoa sem permissão para convidar não ganha acesso por meio da nova ação.
  • A ação pode ser usada nos tamanhos de tela compatíveis com o produto e pode ser acessada pelo teclado.

Esses são critérios de aceitação: condições observáveis que a equipe pode usar para verificar seu trabalho. Eles não precisam parecer uma especificação técnica.

Também há duas perguntas diferentes que devem ficar separadas. Entregamos a alteração acordada? A resposta vem da verificação dessas condições. A alteração tornou os convites mais fáceis de encontrar? Isso exige observar como as pessoas a utilizam.

Um botão pode funcionar exatamente como especificado e ainda assim passar despercebido.

6. Leve o trabalho acordado para o Jira

O mapa ajudou a equipe a explorar a solicitação e tomar uma decisão. Agora a melhoria selecionada está pronta para se tornar um trabalho que alguém pode assumir.

A equipe cria um ticket no Jira para o resultado acordado. Ela não cria um ticket para cada ramificação do mapa.

Veja o que esse ticket poderia conter:

Título: Tornar os convites para colegas acessíveis pela tela inicial do espaço de trabalho

Por que isso importa: Novos proprietários de espaços de trabalho tiveram dificuldade para encontrar a opção de convite nas configurações. Queremos que consigam iniciar um convite pela tela inicial, onde já procuram por essa opção.

Escopo: Adicionar uma ação Convidar colegas que abra o formulário de convite existente para o espaço de trabalho atual. Preservar as regras de permissão e o comportamento dos convites existentes.

Não incluído: Um novo fluxo de configuração, e-mails de lembrete ou alterações na experiência de aceitar um convite.

Critérios de aceitação: Incluir as verificações acordadas na seção anterior.

Contexto do planejamento: Adicionar um link para o mapa para que qualquer pessoa que trabalhe no ticket possa ver as observações, as alternativas e a decisão sobre o escopo.

Dependendo de como a equipe trabalha, design e implementação podem se tornar tarefas separadas. Divida o trabalho quando isso deixar as responsabilidades ou a entrega mais claras, em vez de copiar automaticamente a estrutura do mapa para o Jira.

Uma ramificação organiza o raciocínio. Um ticket descreve um trabalho. Eles não precisam ter uma relação de um para um.

Se sua ferramenta de mapas mentais se conecta ao Jira, talvez você possa criar o ticket a partir do nó selecionado e manter a conexão visível no mapa. Caso contrário, você pode criar o ticket separadamente e adicionar um link. Em qualquer caso, revise o ticket antes de passá-lo adiante: o rótulo curto de um nó raramente contém todo o contexto de que alguém precisa.

Quando a execução começar, mantenha o status e as responsabilidades no Jira. Use o mapa para o problema mais amplo, o raciocínio por trás da decisão e as perguntas que continuam em aberto. Isso dá a cada espaço um propósito claro e reduz a tentação de manter duas listas de tarefas separadas.

Selecione a melhoria acordada, revise seu resumo e seus critérios de aceitação e, em seguida, crie o ticket. Esta captura de tela mostra a seleção antes da criação.

7. Verifique se o problema original diminuiu

Depois que a alteração é lançada, a equipe volta à frase que escreveu antes:

“Novos proprietários de espaços de trabalho não encontram facilmente onde convidar seus colegas.”

Os novos proprietários agora conseguem encontrar a ação de convite sem que alguém mostre onde ela está? Conseguem continuar pelo formulário existente? As conversas com o suporte sugerem que a mesma confusão continua acontecendo?

Se a equipe tiver métricas de produto adequadas, também pode observar quantos novos proprietários de espaços de trabalho iniciam e concluem um convite. Esses números precisam de contexto: alguns proprietários podem escolher trabalhar sozinhos, e outras alterações podem afetar os resultados.

Para esta história fictícia, não precisamos inventar um resultado de sucesso. O próximo passo útil é observar o que acontece e adicionar esse aprendizado ao mapa.

Se os proprietários encontram a ação, mas ficam travados mais adiante, a equipe tem um problema mais específico para explorar. Se a alteração ajuda, ela pode decidir se vale a pena buscar outra melhoria.

A solicitação original era ampla. O plano resultante é focado: um problema claro, uma resposta escolhida, um escopo administrável e uma forma de verificar se a melhoria ajudou.

É isso que torna o mapa útil. Ele leva a conversa de “deveríamos melhorar isso” a um próximo passo acordado, mantendo o raciocínio e as perguntas pendentes à vista.

#MindMapping#ProductManagement#Jira#ProductDiscovery

Artigos relacionados

Vamos Conversar

Tem dúvidas sobre este artigo? Vamos conversar sobre seus objetivos técnicos.

Seus Dados