Dica 5 — Como documentamos discoveries na Conta Azul
Quem vai dar a letra hoje é o nosso product designer Rodrigo Gardim. Ele tem 32 anos, é paulistano e formado em Administração de Empresas pelo Mackenzie.
Gardim começou a trabalhar com Design motivado pela parte criativa da coisa: ele gostava de fazer grafite na adolescência. A partir daí, passou a utilizar ferramentas como o Photoshop e fazer jobs para agências de São Paulo. Desde então, já empreendeu — teve a própria startup de Tecnologia — e atuou como designer em grandes empresas como Cielo e Centauro.
A dica do Gardim hoje é sobre documentação de discoveries:
“Aqui na Conta Azul decidimos usar o Confluence para documentar nossas discoveries (etapa da descoberta e de construção de uma solução). Antes não usávamos uma ferramenta de documentação específica, compilávamos tudo no Drive, do Google. O problema é que o Drive não é tão eficiente do ponto de vista de encontrabilidade das informações e de padronização.
Uma vantagem interessante é que o Confluence conversa com o Jira, uma ferramenta de gerenciamento de projetos que também utilizamos aqui, o que ajuda bastante no dia a dia. Mas algumas outras boas alternativas de ferramentas para documentação seriam: Notion, Basecamp, Dropbox Paper e Airtable.
Antes de falar sobre como documentamos discoveries, no entanto, é necessário explicar por que fazer isso.
A documentação é importante em função da gestão do conhecimento. Todos os dias pessoas entram e saem de empresas, tiram férias, licenças, então quem chega precisa ter um ramp up e acesso facilitado às informações. Não podemos ficar reféns do conhecimento tácito, que é o que está somente na cabeça de cada um.
Questionamentos pré-discovery
Ao iniciar uma discovery, é importante responder algumas perguntas. A primeira delas é: qual problema estamos tentando resolver naquela etapa?
A segunda, é o que determina o sucesso da nossa solução e o que seria um indicador de fracasso? Além de que forma poderemos acompanhar isso — via dados, utilizando quais indicadores.
Precisamos — designer e product owner (PO) — definir sucesso e fracasso para que o time de Desenvolvimento saiba o que será necessário trackear. E, também, para conseguirmos verificar se uma versão proposta será suficiente, se precisaremos de um plano de contenção, etc.
Outro questionamento é: Por que estamos fazendo determinada coisa agora? Ou seja, porque resolvemos priorizar isso? Normalmente, ligaremos essa escolha a métricas da empresa e verificaremos o que entregaremos de valor para o usuário no curto e no médio prazos.
Feito isso, podemos iniciar a discovery e começar a pensar também em documentação. Em relação a documentação, devemos determinar:
O que documentar?
Acredito que tudo o que for possível. Todos os insumos colhidos podem ser úteis para o desenvolvimento e para atualizações futuras do produto.
Como documentar?
Uma estrutura de tópicos que costumamos usar na Conta Azul é:
- Pessoas envolvidas (imagem 1);
- Objetivo da discovery;
- Planejamento da discovery (imagem 2);
- Execução da discovery — e neste ponto gostamos de agrupar pelos momentos do Diamante duplo:
- Descoberta;
- Definição;
- Desenvolvimento;
- Entrega;
- Entregáveis;
- Encerramento da discovery.
Lembrando que tudo é contextual, então funcionalidades e momentos específicos podem não passar por todos estes tópicos ou serem inseridos novos.
Quanto mais detalhes uma documentação tiver, mais rica será para quem a consultar na sequência. Por isso, acrescentamos à documentação benchmarkings realizados junto a outras empresas, fluxos de navegação, protótipos, formulários de pesquisa, artefatos de testes e entrevistas.
Essa riqueza de informações ajuda quem lê a documentação a entender porque algumas decisões foram tomadas. E dá a essa pessoa sugestões de coisas para revisitar, repensar ou evoluir depois.
Outro ponto é aproveitar o que as ferramentas de documentação oferecem. O Confluence, por exemplo, permite a criação de templates, aí criamos um específico para discoveries, que é utilizado por todos os times. Então, o mais importante na ferramenta escolhida — independente de qual for — é que ela forneça a assistência que o seu contexto necessita.
A padronização também deve ser considerada. Quanto mais próximos os times estiverem do mesmo padrão, mais fácil será para entender e para encontrar as coisas depois.
Também é importante contar a história da discovery de maneira simples, evitando termos muito técnicos, e tentar deixar tudo bem visual (usar imagens, fluxos).
Isso porque a documentação servirá para apoiar diversos times, entre eles: Desenvolvimento, Atendimento, Marketing, que têm diferentes níveis de maturidade e de conhecimento sobre o produto.
Para facilitar, uma coisa que eu sempre faço é colocar, já no início da documentação, uma tabela com uma espécie de status daquela entrega. Esse resumão permite a qualquer pessoa descontextualizada entender, rapidamente, o andamento do projeto.
Quando documentar?
Cada um tem um timing. Para mim, funciona bem documentar em tempo real. Acho mais fácil do que começar do zero, só após a conclusão da discovery. Depois a gente acaba não lembrando de tudo, perde detalhes. Mas, claro, veja o que é melhor para você e no seu contexto.”
Por hoje é só isso tuuuudo! E você, como documenta discoveries na sua empresa? Conta para a gente nos comentários! Gostou desta dica? Não esquece de 👏.
