Documentar: o bem necessário de Produtos — Parte 2

Ana "aninha" Pimentel
Produtei
Published in
6 min readJul 14, 2021

--

Se você leu o texto anterior já sabe a importância da documentação de um produto. Mas não custa nada recapitular:

  1. Documentar traz clareza
  2. Documentar é democratizar o conhecimento
  3. Documentar é deixar legado

Mas e aí? Qual a melhor forma de escrever uma documentação? Não queremos escrever meia dúzia de linhas, mas também não podemos cair no erro de redigir um roteiro de cinema. O próprio manifesto ágil diz:

“Software em funcionamento mais do documentação abrangente”

O que seria suficiente então? Nada tão longo que não possa ser lido, nem tão curto que não possa ser entendido! Você só saberá a dose certa ao tentar. Por isso, quando fizer seu primeiro documento, saiba que ele não estará bom o bastante. É o primeiro! MELHORIA CONSTANTE, LEMBRA?

Nessa segunda parte da nossa série sobre a importância da documentação, quero te ajudar com algumas dicas sobre o que fazer (ou não) na hora de abrir uma página em branco.

Linguagem Acessível

“Alô, alô, Marciano! Aqui quem fala é da terra.”

Elis Regina em: “A glamorização da linguagem em Produtos”. OPS! “Alô, alô, Marciano”… O que não muda muito dependendo do ponto de vista kkkk.

É assim que muitas pessoas se sentem quando começam a ler documentações de Produtos. Já comentei em algum momento sobre cada área ter um vocabulário em particular. Quando você entrou para Produtos, quantas palavras novas te impactaram? Se você está começando aqui neste universo, com certeza ainda estranha a linguagem que utilizamos. É uma mistura de português com inglês e verbalizações que não existem como Deployar (kkk).

A documentação do produto não é para você! Ela pode sim servir inicialmente para te dar clareza, mas você não é o público alvo. Por isso, antes de começar a recitar um festival de palavras estranhas, pense nas pessoas que o lerão. Eles são de marketing? É o time de suporte? É alguém do comercial? É um gestor que não faz ideia do que está acontecendo? É uma pessoa nova que acabou de chegar na empresa? Então, fale de maneira clara e acessível!

PS: Caso tenha que usar uma palavra muito própria, coloque o significado.

Estrutura

Documentar um produto não é abrir um DOC e começar a escrever sobre como ele funciona. Você precisa estruturar os seus pensamentos e organizar as informações de forma que elas façam sentido. Aqui está o pulo do gato!

Vou citar alguns itens que podem compor a sua documentação e deixá-la mais rica. Porém, já aviso, veja o que faz sentido para o seu produto. Para não cansar a sua mente com muita informação, vou dividir esses pontos em duas partes:

Parte 1 — Contextualização do produto

  • Objetivo
  • Quem são os Stakeholders?
  • O que é este produto?
  • O que não é este produto?
  • Por que estamos fazendo ele?
  • Para a empresa
  • Para o usuário
  • Como ele funciona?

Parte 2 — Detalhamento do desenvolvimento e acompanhamento do produto

  • O que é sucesso?
  • Requisitos
  • Release
  • Telas
  • Métricas desejadas
  • Go to market
  • Riscos — Valor
  • Riscos — Viabilidade de Negócio
  • Riscos — Usabilidade
  • Riscos — Viabilidade Técnica
  • Versionamento

Achou muita coisa? Calma! Essa é apenas a estrutura e você não precisa escrever textão em cada parte. Seja clara e objetiva. Lembra que acabamos de falar da clareza? É hora de usá-la. Não floreie nem fique rodeando os assuntos.

Vamos lá?

Objetivo

Qual é o objetivo desse documento? É possível adicionar comentários? O produto está acabado? Exponha isso aqui. Um exemplo que posso deixar para facilitar é:

“Com o produto X ainda em construção, este documento servirá de base para o desenvolvimento e acompanhamento. Além disso, queremos compartilhar com outras áreas para que elas possam deixar seus comentários e manter o alinhamento sobre o que será feito e o que não será”.

Ou o objetivo possa ser contar como o produto funciona, caso ele esteja em produção.

Quem são os Stakeholders

Nem todos os produtos precisam das mesmas pessoas. Aqui, você pode colocar o nome e a área de atuação de cada um dos stakeholders que serão envolvidos na construção deste produto.

Se você ainda não sabe quem são seus stakeholders, sugiro a leitura deste texto aqui do Product Guru’s.

Exemplo:

  • Fulana — Suporte
  • Beltrana — Marketing
  • Ciclana — Desenvolvimento
  • Etc.

O que é este produto

Seja claro e sucinto sobre o que é o produto que você está desenvolvendo. “Este produto é um novo menu no aplicativo que permite o cliente fazer empréstimo pessoal”. Se você conseguir escrever de forma resumida será mais fácil das pessoas entenderem e “decorarem” o seu produto.

O que não é este produto

As pessoas costumam sempre pressupor algo sobre o que estamos fazendo. Quantas vezes você estava desenvolvendo um produto X e te perguntaram depois do lançamento: “Mas ele não faz tal coisa?”. Você com cara de ué, pensa: “Eu nunca disse que ele fazia isso!”. Pois bem, falar o que o produto não é ajuda muito a manter claro o que você está fazendo.

Se no exemplo acima falamos de um menu novo para empréstimo, podemos dizer que “Este produto não é uma forma de fazer negociações de empréstimos já realizados, nem possui inteligência para ofertar empréstimo de acordo com o comportamento do cliente”.

Se você está desenvolvendo apenas um simulador de empréstimo que leva o cliente para o site ao invés de concluir alí mesmo a transação, deixe explícito. Se você não fala o que o seu produto é e não é, não queira que as pessoas adivinhem, por mais óbvio que pareça.

Dica avulsa: nunca trabalhe com o óbvio.

Por que estamos fazendo ele?

Se a decisão veio de cima de forma estratégica (famoso top down), você pode colocar aqui. É importante que as pessoas saibam o motivo das coisas. Obviamente você não escreverá isso na força do ódio, já que muitas pessoas de Produtos costumam detestar Top down. Pense que para tudo existe um motivo e se no momento em que recebeu a demanda não perguntou o porquê, volte lá na sua gestão e pergunte.

O interessante aqui é que a pergunta precisa ser respondida de dois ângulos: empresa e cliente. É neste momento que você deixa claro se o produto traz benefícios somente para a empresa. Todo produto precisa ser igualmente bom para ambos, caso contrário, não haverá adesão nem de fora nem de dentro.

Para a empresa:

“Queremos ter mais um canal de conversão para empréstimos pessoais, porque faz parte da nossa meta como empresa aumentar a receita que vem desse produto.”

Para o cliente:

“Tendo a contratação do empréstimo pessoa pelo aplicativo facilitamos o acesso ao produto para o cliente tirando a necessidade de ligações na central de relacionamento”

Como ele funciona

Chegou a hora do textão. As famosas regras de negócio que a turma tanto ama mora aqui nesse pedacinho do documento. Eu comecei meu exemplo com um novo menu no APP que possibilitará a contratação do empréstimo pessoal certo? Como então todo esse processo funcionará:

  • O aplicativo deverá ter uma tela de simulação.
  • A simulação acontecerá somente quando o cliente for pré-aprovado, caso contrário exibir uma mensagem de “você não possui crédito aprovado”.
  • O cliente poderá ter apenas um empréstimo ativo.
  • O APP não trará a possibilidade de negociação, mas trará o contato para que o cliente ligue e negocie.
  • Após X dias de atraso o APP enviará uma mensagem avisando da negativação do nome.

Esses são apenas alguns exemplos do que você pode escrever sobre o funcionamento de um APP. Pense nas regras de negócio que deseja implementar na primeira versão. Adicione tudo o que faz sentido para o seu produto, pois essa é, com certeza, a parte mais preciosa do seu documento.

Bom, apresentei a você a primeira parte do documento. Respondendo a esses pontos acima você já terá praticamente um manual do Produto. Nesse primeiro pedaço do DOC as pessoas já sabem o que esperar e como esperar. No próximo artigo continuaremos com detalhamentos mais específicos de negócio e técnicos.

Até a próxima!

--

--