Você pode usar o ClickUp Docs para comunicar os requisitos do produto com sua equipe de engenharia e partes interessadas.
Continue lendo para descobrir como Sam resolveu um grande problema de comunicação para sua equipe Ágil!
Conheça o Sam
Sam é gerente de produto em uma empresa de software baseada na nuvem. Eles estão trabalhando em um recurso específico do produto com uma equipe dedicada, incluindo:
-
Um designer
-
Dois desenvolvedores
-
Um engenheiro de qualidade
O desafio
A equipe se dá bem, mas Sam percebe que a equipe passa a maior parte das reuniões diárias de recapitulação fazendo perguntas a Sam sobre o recurso e como ele deve funcionar.
Sam decide orientar a equipe fora das reuniões rápidas usando Documentos do ClickUp.
A solução
Sam decide que cada recurso deve ter seu próprio documento. Quando a equipe está trabalhando em um recurso, todas as informações relevantes devem estar em um único lugar.
Usar páginas dentro de um Documento permite que a equipe encontre respostas relevantes rapidamente sem procurar e pesquisar em Documentos separados.
Sam cria algumas páginas dentro do documento para estruturar o briefing do produto com base no que a equipe precisa saber e pode estar procurando.
-
Carta da equipe de recursos
-
Requisitos de design
-
Requisitos funcionais
-
Requisitos de UX
Dica: Procure por páginas específicas ou conteúdo dentro de um Doc usando a função de Busca!
Sam adiciona títulos e outros elementos de formatação a cada página para comunicar sua visão para o recurso.
Sam compartilha o documento com a equipe de recursos. Eles trabalham juntos para redigir e concordar com o estatuto.
Sam convida a equipe a fazer perguntas adicionando comentários no documento para que todos possam ver as perguntas e respostas.
Retrospectiva
Alguns Sprints passam voando, e a equipe agradece pelo documento que os ajudou a se orientar. As reuniões de recapitulação agora são muito mais eficientes e eficazes.
Uma melhoria de recurso foi enviada e adicionada ao produto. Infelizmente, isso causa um novo erro em outra parte do recurso que não estava sendo atualizado no lançamento.
Os desenvolvedores corrigiram rapidamente o erro e, na próxima retrospectiva, a equipe de recursos discutiu como isso poderia ter sido evitado.
Um engenheiro de QA sugere algum tipo de critério de aceitação para que nenhuma alteração seja enviada para produção a menos que todos os critérios de teste sejam cumpridos.
A equipe concorda! Sam adiciona uma nova página ao documento do briefing de recursos para documentar os critérios de aceitação do recurso.
Sam utiliza Blocos de Código ( /co ) para formatar os requisitos de critérios de aceitação, já que a equipe já está familiarizada com Gherkin, e o ClickUp oferece suporte para isso em blocos de código!
O resultado
À medida que a equipe de recursos implementa mais melhorias e corrige erros, os clientes estão adotando cada vez mais o recurso. A equipe de recursos cresce para incluir mais dois desenvolvedores e outro engenheiro de QA.
Os novos membros da equipe se adaptam rapidamente e começam a contribuir com a ajuda do documento de briefing de recursos do Sam!
Sam também compartilha o modelo de documento de resumo de recursos com outros gerentes de produto para que eles possam adaptá-lo para suas equipes baseadas em recursos.
É uma grande vitória para a equipe de Sam e para outras também!