A Subestimada Arte de Nomear Épicos, Releases, Funcionalidades e Histórias de Usuários.

Como a habilidade de nomear os itens do seu roadmap pode fazer com que você se destaque como uma Product Manager.

Este artigo possui uma versão em inglês: https://medium.com/@jess.esquenazi/the-undervalued-art-of-naming-epics-releases-features-and-user-stories-343a5e444074

Se você está no processo de criar, refinar ou mesmo revisar sua estratégia de produto, então definitivamente esse artigo é para você. Eu não somente vivi isso, como vi grandes product managers falhar na hora de engajar e animar a liderança com sua estratégia de produto por não saber dar bons nomes aos itens do roadmap.

Quando isso acontece, uma reunião de estratégia que era pra ser um momento de animação se torna uma sessão de tradução, na qual a product manager perde tempo valioso com a liderança explicando o que cada item do roadmap significa na prática.

Como foi destacado no próprio título desta publicação, nomear itens de roadmap é uma arte. Não no sentido de romantizar o trabalho, mas no sentido de que não existe uma resposta exata como na matemática para qual é o nome certo de se dar a cada item de roadmap. Além disso, cada product manager vai acabar construindo seu próprio estilo de nomear épicos, releases, funcionalidades e histórias de usuários.

Espero que com esse artigo eu seja capaz de ajudar product managers que ainda estão construindo seus primeiros roadmaps de produto a entender os princípios e melhores práticas a ser aplicadas nesse processo para que sua estratégia e implementação sejam tão animadoras para os stakeholders e desenvolvedores quanto são para você.

Nos próximos parágrafos serão apresentadas definições claras do são épicos, releases, funcionalidades e histórias de usuários, para quem cada um é destinado e algumas dicas e boas práticas de como nomeá-los. Espero que as definições abaixo proporcionem clara e ajudem outras product managers a organizar e comunicar melhor seus roadmaps.

Antes de começarmos, gostaria de levantar um ponto a ser levado em consideração durante a leitura:

Existem um montão de diferentes terminologias na comunidade de produto quando o assunto é itens de roadmap. Em muitos lugares, o que eu vou definir como épico abaixo, pode ser chamado de iniciativa, tema, escopo, ou algum outro termo. O mesmo serve para releases, funcionalidades e histórias de usuário. Isso fica mais complicado ainda quando estamos trabalhando numa empresa brasileira, que vai traduzir alguns termos, e manter outros no inglês.

Esse artigo foi escrito com o propósito de compor um treinamento de fundamentos de produto para novos membros do time de produto da Powertofly. Por esse motivo a terminologia do artigo será a mesma utilizada pela empresa. Conforme você se deparar com as definições a seguir, tente refletir sobre qual a terminologia que é usada na sua empresa e não se prender tanto à terminologia que estou usando, mas sim a descrição de cada termo, já que os nomes realmente podem varias dependendo de onde você trabalha.

Épicos

Para descrever o objetivo estratégico de um produto, muitas vezes é preciso mais de uma funcionalidade e/ou história de usuário. Na verdade, é preciso um grupo de funcionalidades e histórias para contemplar o objetivo do produto. — Product School Glossary

• Compõe: Iniciativa geral da empresa.
• É composto de: Releases e funcionalidades.
• Destinado para: Áreas de negócios (liderança e stakeholders).
• Janela de tempo: Pode durar até mais de um quarter (unidade para medir um quarto de ano. Algumas empresas trabalham com outras medidas, como trimestres).

Todas as estratégias de produto devem estar ligadas a uma iniciativa maior da empresa. Um épico representa justamente qual grupo de funcionalidades ou até mesmo novos sub-produtos serão lançados ao longo do roadmap estratégico para colaborar com os objetivos de negócio que muitas vezes vão além do produto em si.

Em algumas empresas os épicos podem ser compostos de funcionalidades e/ou histórias de usuários. Em outros, podem ser compostos apenas de histórias de usuários, ou, como demonstrarei em meu exemplo, de apenas funcionalidades, que por sua vez são compostas de histórias de usuários.

Dito isso, um épico não é nada mais que uma iniciativa de produto ligada a um objetivo geral da empresa e composta por um grupo de funcionalidades que podem ser lançadas e iteradas de forma independente.

Um bom nome de épico dará a você e a todos os stakeholders um entendimento claro do seu valor para o usuário e animação para sua concretização. Também irá facilitar seu trabalho na hora de definir e quebrar as funcionalidades que compõe o épico, além de conceber novas ideias.

Aqui estão alguns pontos chaves sobre os quais se deve refletir ao nomear épicos:

• Preste atenção para garantir que o nome do épico contém a essência do que será desenvolvido e/ou a razão pela qual o item será desenvolvido.
• Use uma linguagem simples e evite jargões/vocabulário técnico.
• Se o épico oferece um valor claro para o usuário, o mesmo deve ser contemplado no nome do épico.
• Épicos podem (e devem) se abrangentes sem ser vagos. Dessa forma, os épicos deixam o time de negócios curiosos sobre as funcionalidades que compõe o épico, sem precisar que o product manager traduza o épico ou descreva as funcionalidades para que o mesmo tenha valor ao ler o roadmap.
• O nome deve ser curto o suficiente para caber sem maiores problemas em gráficos e roadmaps.

Exemplos de bons nomes de épicos:

Nota: para todos os exemplos de nomes, usarei uma plataforma fictícia que ajuda pessoas comuns a perder peso.

• Criar espaço para nutricionistas na plataforma
• Adicionar missões para engajar os pacientes

Example of bad epic names are:

• Criação de plano de dieta
• Estratégia de gamificação

Releases

Um release de produto é o processo de entregar uma nova experiência aos consumidores. — Aha!

• Compõe: Épico e iniciativa geral da empresa.
• É composto de: Funcionalidades.
• Destinado para: Áreas de negócios (liderança e stakeholders).
• Janela de tempo: é entregue durante um quarter.

Como product managers, nos buscamos entregar valor constante aos nossos usuários. Mesmo se estivermos subindo histórias de usuário para o ambiente de produção toda sprint, ainda assim precisaremos comunicar os marcos de um épico aos stakeholders e usuários finais.

As releases devem ser a matéria prima usada pelos Product Marketing Managers para promover nosso produto. Estamos nomeando nossas releases e itens de roadmap com o objetivo de engajar nossa liderança e stakeholders com nossa estratégia de produto. Por esse motivo, eu recomendo deixar o time de marketing se preocupar depois com qual nome será dado para a release publicamente para usuários finais, e focar agora em dar o nome que vai permitir que o time de negócios obtenha maior clareza sobre o marco que foi alcançado.

Aqui vão alguns pontos a se considerar para nomear releases:

• Assim como épicos, devem ser abrangentes o suficiente para contemplar todas as funcionalidades que a compõem.
• O nome deve deixar claro quem se beneficia de cada release e o principal valor sendo entregue. Em alguns, quando a empresa inteira atende a somente um usuário, não será preciso mencioná-lo em cada item do roadmap, mas em empresas ou times que trabalham com mais de um usuário, esquecer de mencionar que se beneficia da release/funcionalidade/história de usuário pode causar confusão.
• O nome deve ser simples o suficiente para que o time de negócios e o time de marketing consigam entender e trabalhar na melhor estratégia de comunicação.
• Preset atenção e assegure que está usando a mesma terminologia que foi usada no épico. Por exemplo, no épico usei o termo "espaço para nutricionistas", então, no nome da release, vou usar "espaço" também, ao invés de "conta" ou "experiência".

Exemplos de bons nomes para releases:

• Espaço para nutricionistas MVP
• Iterações na gamificação para pacientes
• Melhorias na velocidade do site dos pacientes

Exemplos de nomes ruins para releases:

• Versão 2.4.3.1
• Android 2.5
• Release segundo trimestre

Funcionalidades

Um aspecto do seu produto que entrega valor ao atender a um requerimento do seu consumidor — como realizar uma função que ajuda a solucionar um problema de seu cliente ou o deixa mais próximo de alcançar um resultado desejado — Product School Glossary

• Compõe: Épico.
• É composto de: Histórias de usuários.
• Audiência: Áreas de negócios e desenvolvedores.
• Janela de tempo: São entregues em poucas sprints. Um quarter deve ter múltiplas funcionalidades entregues.

Em uma estratégia de produto, a funcionalidade nos ajuda a entender qual o valor diferenciado que está sendo criado para o consumidor a fim de que o épico atinja com sucesso os objetivos de negócio.

Isso significa que a funcionalidade é simplesmente uma coleção de funções que devemos fornecer ao usuário para considerar um épico completo.

Aqui estão algumas coisas para se ter em mente ao nomear funcionalidades:

• O nome deve conter o que a funcionalidade faz.
• Use a simplicidade e foque em termos que tanto a área de negócios como s desenvolvedores podem entender. Para isso, evite termos técnicos e de negócio.
• Uma dica que recebi da Amber Brown — Diretora de Produto na Powertofly — , e gostaria de compartilhar com vocês é de sempre checar com alguns desenvolvedores e representantes das áreas de negócios se o nome está claro e fazendo sentido antes de apresentar o roadmap formalmente. Para o time de negócios o nome fará muita diferença em como vão preparar as estratégias de comunicação e go-to-market. Já para os desenvolvedores, não irá somente ajudar a quebrar as tarefas, como o nome pode ser usado dentro do código.
• Nesse momento, não se preocupe com qual será o nome da release para o usuário final. Deixe esta missão para sua Product Marketing Manager ou, caso você mesma seja responsável pelo go-to-market, escolha o momento cero para se preocupara com que nome você usará para os consumidores. Essa nomeação para o roadmap é apenas para o time de negócios e para os desenvolvedores.
• Tome cuidado para que o nome da funcionalidade seja suficientemente diferente dos nomes de outras funcionalidades do mesmo épico. Pode parecer bobo mencionar isso, mas as vezes os stakeholders desenvolvedores do nosso produto sofrem para distinguir funcionalidades com nomes parecidos e acabam precisando ler a descrição ou perguntar ao product manager para saber qual é qual.
• Use a mesma terminologia usada nos itens outros itens do roadmap.
• Mais uma dica do nosso time, dessa vez da Melissa Cox — Product Manager at Powertofly: ao nomear uma funcionalidade, se pergunte "para quem é e o que faz?".

Exemplos de bons nomes para funcionalidades:

• Nutricionistas podem criar planos de dietas
• Nutricionistas podem adicionar consultas no calendário
• Permitir aos pacientes escolher missões para participar
• Criar dashboard para pacientes acompanharem missões

Exemplos de nomes ruins:

• Criador de plano de dieta
• Integração com calendário
• Lista de missões
• Dashboard de missões

Histórias de usuários

Uma história de usuário é a menor unidade de trabalho da metodologia ágil. É um objetivo final, não uma funcionalidade, expressado pela perspectiva do usuário do software. — Atlassian.

• Compõe: Funcionalidade.
• É composta de: Sub-tarefas.
• Audiência: Desenvolvedores.
• Janela de tempo: São entregues dentro de uma sprint.

A história de usuário será sua principal forma de comunicação com os desenvolvedores a respeito do que precisa ser construído.

Aqui estão algumas dicas para a hora de nomear as histórias de usuário:

• Elas são direcionadas aos desenvolvedores, mas precisam ser compreensíveis por qualquer um que se depare com elas. Sempre alinhe com os desenvolvedores se os nomes estão claros para eles, uma vez que se o nome for muito orientado ao negócio pode ser pouco claro para o time de desenvolvimento.
• Tome cuidado ao nomear histórias de usuário dentro de uma mesma funcionalidade. Torne os nomes diferentes o suficiente para que os desenvolvedores consigam lembrar os detalhes da história sem precisa abrir e ler detalhes para diferenciá-la de outras.
• Preste atenção para garantir que o nome da história contempla o valor que traz para o usuário.
• Use a mesma terminologia que foi usada até então nos outros itens do mesmo roadmap.

Exemplos de bons nomes para histórias de usuário:

• Criar formulário para nutricionistas salvarem os planos de dieta.
• Permitir que nutricionistas criem rascunhos e publiquem planos.
• Enviar notificações ao paciente quando plano é criado.

Exemplos de nomes ruins para histórias de usuários:

• Interface plano e dieta
• Plano de dieta público/rascunho
• Notificação do plano de dieta

Em conclusão, cada product manager terá seu próprio estilo de nomeação, mas todos precisam se certificar em seguir alguns "faça" e "não faça" que podem ajudar muito a destacar sua estratégia para os stakeholders, além de ajudar a quebrar o roadmap em itens menores.

Segue abaixo um guia rápido que pode ser aplicado em diferentes itens de um roadmap:

FAÇA

• Use palavras simples e evite jargões.
• Deixe claro quem é o usuário final.
• Deixe claro qual o valor que está sendo criado.
• Lembre-se de quem será a principal audiência do item.

NÃO FAÇA

• Usar abreviações para diminuir o tamanho do nome.
• Usar diferentes palavras /terminologia para a mesma coisa em itens de um mesmo roadmap.
• Escrever itens que podem se confundir com outros/possivelmente parecer a mesma coisa para quem está lendo.
• Dar nomes extremamente vagos.