Muitos artigos e livros sobre o trabalho do gerente de produto consideram questões de pensamento estratégico e inovação. Claro, essa é a base. Eu gosto de prestar atenção às tarefas diárias de rotina. Um desses trabalhos é com solicitações de usuários e requisitos de produtos.
O axioma é que os pedidos de funcionalidade dos usuários não são requisitos do produto. Uma solicitação pode ser facilmente dividida em vários requisitos e vice-versa, um requisito consiste em várias solicitações dos usuários.
Vejamos um exemplo simples - o aplicativo Calculadora. Você recebeu uma solicitação: adicione suporte para o sistema de números binários. Pode dar origem a vários requisitos de produtos.
- Suporte para operações aritméticas.
- Suporte de conversão. Aliás, isso afetará o sistema decimal existente. Será necessário, no mínimo, criar botões na interface.
- Suporte para operações lógicas.
Como você pode ver, inicialmente o usuário não pediu para suportar, por exemplo, apenas operações lógicas. A solicitação para o sistema numérico como um todo, mas contém vários requisitos.
Talvez tudo isso seja óbvio. Mas o processo de trabalhar com solicitações, se você não atribuir importância a ela, pode adicionar problemas. A primeira armadilha é manter registros no rastreador.
Obviamente, ter um sistema único para solicitações de usuários e requisitos de produtos é melhor que dois. Bem, pelo menos você terá apenas uma janela aberta. É importante ter diferentes tipos de objetos para registros. Um exemplo da minha experiência. Eu chego a uma média de duas a quatro solicitações de usuário todos os dias úteis. Você pode imaginar o volume. A lista no backlog do produto é simplesmente enorme. Ter dois tipos de entradas "requisito" e "solicitação de funcionalidade" permite configurar filtros, coletar uma lista de pendências de uma versão específica e fazer links entre requisitos e solicitações para rastrear o histórico. Além disso, após considerar a solicitação, ela pode ser fechada com as notas “planejadas para liberação” ou “não serão implementadas”.
O segundo aspecto do trabalho é coletar diretamente os requisitos. Uma maneira é obtê-los através do suporte técnico. Esse é um bom processo, como resultado do qual você recebe uma solicitação filtrada contendo a essência. Por outro lado, é opaco para seus usuários. Muitos podem não perceber que tal solicitação foi e são acessados repetidamente.
Portanto, os fornecedores, especialmente aqueles que desenvolvem soluções em nuvem, podem usar portais para receber feedback.
Fórum de feedback do ZendeskEste método melhora a visibilidade. Separa solicitações de requisitos, pois os sistemas são diferentes. No entanto, agora seu trabalho dobrou. Você precisa visualizar rapidamente novas postagens, comentar, responder perguntas. O silêncio, especialmente na comunicação pública, é inaceitável.
Mas o mais difícil é que agora você precisa rastrear e marcar solicitações de alguma maneira para marcar aquelas que estão planejadas para implementação ou vice-versa. Voltando ao exemplo com uma calculadora. Como no portal, é necessário marcar a solicitação de suporte binário, se você planeja implementar apenas operações aritméticas e conversão, sem operações lógicas.
Cada gerente de produto escolhe sua própria solução. Não existe uma abordagem universal. No entanto, você deve sempre lembrar que mesmo um processo tão pequeno como a coleta e o processamento de solicitações de usuários pode conter muitos tópicos ocultos e é fácil duplicar o trabalho.