Todo Product Owner é um redator (mesmo que ele ou ela não saiba disso)

A comunicação escrita é um atributo essencial para POs, e precisa ser abordada com a devida importância.

Visualize essa cena comigo: você acabou de assumir o papel como Product Owner de uma empresa, e já conta com uma fila gigantesca de histórias em backlog, que você sabe que acabara afetando o capacity de seu squad. Para completar, novas histórias (geralmente incidentes) estão sendo solicitadas com uma frequência altíssima.

A cereja do bolo é que grande parte dessas histórias constam apenas com um título auto descritivo, sem critérios de aceite ou qualquer outro detalhe que possa servir de insumo relevante para os desenvolveres do squad, e como consequência sua agenda agora está tomada por alinhamentos com eles e diversos outros stakeholders com o objetivo de detalhar cada uma das demandas.

Pode ser estranho para alguns dos leitores a situação acima descrita, mas para outros acredito que alguma situação semelhante já deve ter sido presenciada ao assumir uma nova equipe, ou ao ser contratado em uma nova empresa.

Como evitar situações acima descritas? Não existe receita de bolo, mas um ponto a ser detalhado é justamente o das histórias de usuário (ou User Stories), que podem parecer um aspecto extremamente simples para o dia a dia de uma empresa, mas são extremamente importantes para manutenção da organização de todos os envolvidos nas tarefas atribuídas a eles.

Origem: de onde vem as User Stories?

A User Story apareceu pela primeira vez em 1998 com o eXtreme Programming (XP), um framework da cultura Agile. Em sua primeira definição, as User Stories apenas afirmam que os clientes definem o escopo do projeto “com histórias de usuários, que são como casos de uso”.

No entanto, a maior parte da literatura que veio depois argumentou que as User Stories são diferentes dos casos de uso.

Em uma definição mais atual, as histórias de usuário podem ser interpretadas como a definição dos requisitos de um desenvolvimento específico, orientando o time de desenvolvimento com informações pertinentes (contexto, restrições, exemplos de aplicação, objetivo entre diversos outros.

E, novamente, vale reforçar: as histórias são apenas uma (importante) parte para o desenvolvimento organizado e produtivo: existem documentações, por exemplo, que ajudam de forma considerável os desenvolvedores visando manter a escalabilidade e boa qualidade de código.

A necessidade de aprimoramento x tempo gasto

É indiscutível a necessidade de um nível de detalhamento mínimo para a construção de histórias eficientes. E essa eficiência vem em mais de um sentido: não só pelo nível de dados presentes que deverão suprir todas as principais dúvidas dos desenvolvedores e stakeholders que tiverem acesso a ela, mas também a questão do tempo dedicado para escrevê-las.

Tive a chance de conversar com o Luiz Wienc, GPM do Itaú, sobre o tema, e ele trouxe um exemplo prático da empresa: imagine que os squads sob sua responsabilidade possuem aproximadamente 5 pessoas por time e a média por sprint dure 15 dias.

Minimamente, cada PO tem como meta a necessidade de escrever 15 histórias por sprint (3 histórias por pessoa, considerando 1 história por semana/pessoa).

Se esse PO fizer algo simples, precisará fazer uma ou mais sessões de refinamento (reunião para explicar do que a história se trata exatamente) com o Techlead do squad.

Isso porque, em uma história mais complexa, ficará faltando contexto do produto, regras básicas, cenários para tratar minimamente do que está sendo falado, desenho de jornada etc.

O que acontece? Não é o Techlead que desenvolve, e sim diretamente o desenvolver. Ou seja, o Techlead deverá fazer o mesmo processo junto ao desenvolvedor em questão.

E caso esse desenvolvedor não possa atuar no momento (por estar doente, por exemplo), é mais um período dedicado a repassar ao novo desenvolvedor responsável o contexto necessário para que a história seja executada.

Isso sem contar na contextualização com outros membros do time, como QA, UX e diversos stakeholders que precisarão ficar à par.

Economia eficaz do tempo

Ao invés do PO gastar apenas 5 minutos  escrevendo uma história no tradicional padrão “Como, Quero e Para”, ao preencher mais algumas informações adicionais, seguindo o "User History Review", por exemplo, esse tempo irá subir para 15, 20 ou até mesmo 30 minutos.

A princípio parece bastante tempo, e “dedicar mais tempo na atividade de escrita das histórias vai contra todos os princípios ágeis conhecidos até então”.

Talvez esse tenha sido seu primeiro pensamento, mas a percepção de Luiz se traduz em uma provocação extremamente pertinente: este tempo dedicado mitiga a necessidade de alinhamentos entre Techlead, Dev 1, Dev 2, CX, QA etc conforme citado no exemplo anterior.

Mais do que isso: esse esforço inicial ajuda na documentação futura, e faz da história uma espécie de hub de informações sempre que for necessário consultar alguma. É um investimento de tempo inteligente, uma vez que o PO poderá dedicar esforços em outras atividades de aqui em diante.

O grande desafio então é como Hackear o cérebro do PO para que ele preencha informações adicionais, com o objetivo que ele mesmo se faça algumas perguntas para ter certeza de que a história em questão faz sentido?

O conceito

Seguindo uma das premissas da cultura Agil, as histórias devem ser “puxadas” com facilidade para sua execução: existe um desenvolver livre? Ele deverá puxar a próxima história em DoR (Definition of Ready – pronta para execução).

O problema aqui é a necessidade de realização de refinamentos constantes, ou algumas vezes nem isso: o contexto de determinada história permanece na própria cabeça do próprio PO.

Por mais que na planning sejam realizadas revisões das histórias que serão abordadas em determinada sprint de forma mais abrangente, ainda serão necessários detalhes cruciais para que todos os envolvidos possam ter assertividade em suas funções referentes a ela.

Uma história consciente com todas as informações e dados ajuda na desconstrução da interdependência entre a equipe.

E aqui isso é fundamental: para que exista mais agilidade na execução das respectivas funções, é importante promover a autonomia de todos os envolvidos, e isso só é possível ao darmos os insumos necessários a cada um de modo assíncrono.

Anti-heroísmo

Uma boa organização ajuda a evitar a dependência de determinados profissionais, e isso (apesar do título no parágrafo) é algo positivo. Quando nenhum membro do squad precisa “salvar o dia”,- e ser o grande responsável por um entregável, a carga, responsabilidade (e consequentemente reconhecimento) ficam distribuídos entre todos os membros.

Na prática, isso também pode ser reflexo da escrita planejada de histórias por meio da mitigação de cenários não mapeados (imprevistos, turnovers, etc).

Deixar todos a par do que precisa ser feito por meio de histórias completas ajuda na organização da equipe, o que faz que ninguém tenha que “se sacrificar” para que determinados entregáveis sejam concluídos.

Perfil ideal para um bom contador de histórias

No já longínquo episódio #27 do Product Guru’s com o título “Como desenvolver times de alta performance”, a convidada Annelise Gripp traz uma visão detalhada em relação as atribuições de um Product Owner, e deixa uma característica clara:

“Um PO não pode ser uma pessoa que não goste de se comunicar: o que ele mais gosta de fazer é isso”.
- Annelise Gripp, Owner e Mentora na LACE Consultoria LTDA.

E é de se entender: a figura de um PO é alguém que precisa se relacionar com stakeholders o tempo inteiro, seja para mediar conflitos ou estruturar parcerias com squads parceiros. Dentre suas atribuições, o relacionamento é a palavra-chave para conseguir exercer sua profissão com êxito.

E isso inclui a comunicação escrita. Ou seja, o perfil comunicativo de um PO já não é segredo a ninguém a algum tempo: mas a visão dessa característica aplicada a escrita muitas vezes não é levada em consideração.

Ainda no tema original do episódio #27, um artigo escrito por Annelise reforça a necessidade de comunicação entre funcionários, que é extremamente importante para diminuir o máximo de ruídos possíveis ao apresentar um novo mapa de trabalho para os líderes, envolvendo-os desde a concepção.

E o PO que não tem esse perfil: como lidar?

Uma das alternativas levantadas por Luiz ao se deparar com situação semelhante foi a rotação de pessoas: colocar o PO com falta de skills de relacionamento em um time mais autocontido.

Outro ponto fundamental foi o de realização de feedbacks para aprimoramento da visão de stakeholders em um squad que tinha como necessidade isso do papel: estimular a interação e navegação por outros squads e diferentes áreas.

Existe também a possibilidade de investimento em cursos de oratória e de superapresentações (esse último consiste, basicamente, na explicação por meio do formato de apresentação sem ter nada anotado: como apresentar uma imagem ao público em poucos segundos?)

Ainda segundo as observações de Luiz, gestores com falta de preparo poderiam despachar uma pessoa com perfil semelhante automaticamente, quando, na verdade, existem diversas dinâmicas possíveis para tratar de uma situação semelhante.

Vale ressaltar os custos para a própria organização, inclusive, no desligamento de um profissional.

Como desenvolver a redação dos POs especificamente?

Essa é uma pergunta um tanto quanto complexa, uma vez que os profissionais tem os mais diversos perfis dentro de uma mesma organização.

Compartilhando uma experiência pessoal (com quem muitas pessoas podem se relacionar), Luiz confessou que sempre teve um perfil para matérias exatas na época escolar, e não humanas. Ao mesmo tempo, ele sempre foi bem visual.

Por exemplo, durante uma prova de história, ele tinha o costume de escrever todo o conteúdo que se recordava em uma única folha, e depois usá-la como base para as perguntas da prova em si.

Esse comportamento trouxe um importante insight: Não adianta utilizar só bullets points e frases objetivas, já que nem todas as pessoas têm a mesma familiaridade com informações nessa configuração.

Sendo assim, o melhor raciocínio é a explicação tim-tim por tim-tim. O detalhamento de forma bem elaborada seguindo algumas premissas ressaltadas por Luiz em seus mais de 18 anos de carreira no Itaú:

• Leitura dinâmica: ler apenas alguns pontos, o que chama mais atenção na história, é melhor ter mais conteúdos, mas orientar pontos de destaque do que ser raso no conteúdo.

• Escrever com calma: quando alguém fala de forma descompassada, ágil e sem pausas, é difícil entender exatamente o que ela quer dizer, certo? O mesmo acontece com a escrita.

  Garanta parágrafos dedicados a cada tema, leve tempo na pontuação empregada e em todos os detalhes de forma geral. Redigir uma boa história já é metade do caminho para uma execução eficiente.

• Tangibilize exemplos: como alguém que não lida com esse assunto do dia a dia pode entender a história em questão? Aqui pode ser interessante considerar o ponto de vista de um Desenvolvedor Jr, que não tem tanta familiaridade com fluxos e processos e precisa de um grande nível de detalhamento.

  É importante, inclusive, trazer imagens, vídeos, fluxogramas e outras formas de conteúdo para facilitar a interpretação de quem a lê.

• Evite a síndrome de Jean Grey: nem todos trabalham com leitura de mentes, e por isso é importante tirar coisas da cabeça e colocar no papel (informações consideradas básicas, por exemplo, precisam constar).

• Estimular questionamentos e perguntas por parte dos desenvolvedores e outras pessoas que leem as histórias é fundamental. Pergunte aos seus leitores mais assíduos como eles acreditam que as histórias podem ser aprimoradas. Convide-os para o jogo para que eles efetivamente façam parte do processo, e não se considerem responsáveis apenas por uma parte do mesmo.

• Repertório: a importância de ler livros para ampliar os processos de construção de textos e linhas de raciocínio é fundamental. Quanto mais o tempo dedicado a leitura, mas facilmente você conseguirá estruturar sua escrita de forma lógica e eficiente.

Além das histórias: o que mais o PO pode fazer para facilitar o trabalho da equipe de desenvolvimento?

Já pudemos explorar diferentes aspectos em relação a criação das histórias, entretanto existem questões complementares que podem ajudar o time de desenvolvimento de um squad a darem vazão aos to dos já mapeadas pela equipe.

O primeiro deles é a necessidade de alinhamento entre a tríade (PO;TechLead;SM ou PD depende da confuguração da liderança do squad): dessa forma ela estará blindada em prol da organização e desenvolvimento. E esse aspecto é extremamente importante quando propomos a criação de histórias mais elaboradas, uma vez que os próprios desenvolvedores e outros leitores podem não enxergar o valor intrínseco a uma história bem consolidada.

Um ponto sugerido nesse caso seria o de realização de reuniões periódicas entre a tríade justamente para que todos possam já estar devidamente alinhados entre si antes de levar questões polêmicas ao restante do squad.

Outro ponto positivo a partir dessa união entre a tríade é o de reforçar que a função do PO, que não deve ser idealmente a de “contador de histórias”: Ou seja, ele não deve contar a mesma história para várias pessoas.

A ideia é que o PO possa focar no negócio propriamente dito, por meio de uma comunicação já clara e assertiva com os demais membros da equipe.

Outro ganho de uma unidade entre a tríade é também a de dar uma devolutiva estruturada ao time quando caso surja alguma reclamação referente ao aumento no nível de detalhamento das histórias, levam mais tempo para serem lidas.

Entretanto essa possível dor percebida pode ser consideravelmente menor do que a gerada com a necessidade de refazer algo. E aqui entra o aspecto da documentação: em muitos alinhamentos, quem não presta atenção em um determinado ponto pode ficar perdido.

Já com uma formalização por meio de uma história bem detalhada, é possível consultá-la a qualquer momento.

“Durante meu tempo como PO, o alinhamento do que é prioridade era feito durante o alinhamento entre a tríade: estar em harmonia com a liderança do squad é o ponto fundamental para garantir que todos estão indo na mesma direção.”
– Luiz Wienc, GPM do Itaú

Metrificando o processo de aprimoramento de histórias

Considerando um case real de vivência do Luiz, existe um progresso relevante a partir do maior nível de detalhamento de histórias:

• Antes: tempo médio por história era de 60 dias (praticamente uma release). Basicamente, parava e voltava para alinhamento, ou para aguardar desenvolvimento etc.

• Depois: 20 dias (praticamente uma sprint).

• Atualmente: entre 5 e 7 dias (pensando que a história é de um 1 a 2 dias para que possa ser implementada com agilidade. Algumas histórias ainda levam mais tempo, mas não por falta de conteúdo e sim nível de complexidade técnica, com muitos cenários de testes, dependência de outras etc.

Existem diferentes indicadores levados em consideração para checar o sucesso da novas formas de escrita de histórias, e algumas delas usadas pelo próprio Luiz são:

• Leadtime: da priorização para o desenvolvimento

• Bug report: Em quantas dessas histórias tinha refatoração/bug/débito técnico?

Outro indicador: Entrega de valor

Quanto tempo, em média, uma entrega de valor ocorre? Não pode ser leadtime puro porque muitas entregas podem ser enablers (como criação de banco de dados que dependem infra e outros), mas considerando histórias que são realmente vitais para o KPI da organização, por exemplo.

Um time maduro tem 1 entrega de valor diária, enquanto um time ainda em desenvolvimento tem em média de 2 a 3 dias de entrega de valor.

Considerando um exemplo genérico de uma nova funcionalidade, por exemplo:

• Antes: 200 dias

• Depois: 60 dias (praticamente uma sprint).

• Atualmente: 20 dias. Uma redução de basicamente 10x o tempo originalmente requisitado.

As métricas ajudam como balizadores para busca de investimento e capital interno para novos produtos, dentro da categoria grandes entregas de valor.

Para um squad ser saudável, ela precisa estar viva e perene de 1 ano e meio a 2.

O futuro da redação de histórias

Durante nosso papo, o Luiz ressaltou que acredita no futuro apoiado pelo uso da IAs. Mas para poder utilizar essa tecnologia de modo inteligente, precisamos saber fazer minimamente as perguntas a essa nova tecnologia, indo além de prompts distribuídos livremente pelas redes sociais.

É necessário ler a fundo sobre o tema e escopo pelo qual o PO é o responsável, complementar perguntas e manter uma base contínua de trocas com a tecnologia de inteligência artificial em questão, criando um histórico com repertório que poderá ser consultado futuramente para questões semelhantes.

O PO que está se preparando para criar prompts corretos e bem embasados em relação ao mercado e registros anteriores para a IA sairá na frente.

Pensando em papéis, o PO precisa focar no delivery, enquanto o PM precisa estar de cabeça na estratégia de negócios.

O PM e PO precisam mapear como gastar o menor tempo possível com as atividades operacionais, e a escrita de histórias é justamente uma delas: Como criar prompts assertivos e completos dentro desse cenário?

Conforme já citado, é importante manter o detalhamento com prompts que serão obtidos depois de algumas versões: funcionará melhor quanto mais informação for incluída lá.

Outro ponto que precisa ser reforçado é o da manutenção de uma opinião questionadora para entender se atende as necessidades de negócios ou não, sem preciosismos em relação a atual escopo de trabalho.

E existem desdobramentos à partir daí: os próprios desenvolvedores poderão usar da IA lendo essa história para construir uma estrutura básica para iniciar o desenho técnico em si.

O nível de detalhamento de histórias nunca foi tão importante no objetivo de alcançar a eficiência, mas as formas para chegar até esse resultado devem ser inteligentes para que POs e PMs possam concentrar esforços em tarefas do cotidiano que exigem cabeças pensantes, e não apenas uma escrita assertiva e automatizada.

Mas, para se chegar a esse cenário ideal, é importante começarmos o quanto antes.

---

A nossa newsletter é gratuita e o que nos motiva escrever é ajudar com conteúdo como este, as pessoas. Se gostou, compartilhe com seus amigos e na sua rede social.

Se quiser compartilhar via WhatsApp, clique no botão abaixo…