Você sempre pode contar com as habilidades estratégicas do gerente de produto, como pensamento inovador, abordagem do oceano azul e outras. Porém, diariamente, usamos ferramentas e abordagens mais práticas. Este artigo é sobre como trabalhar com solicitações de recursos e requisitos de produtos.
O principal axioma do gerenciamento de solicitações é que solicitações de recursos de clientes, parceiros e equipes internas não são requisitos para o produto. Isso ocorre porque cada solicitação pode ser dividida em vários requisitos ou, caso contrário, várias solicitações podem ser combinadas em um único requisito.
Vamos usar um exemplo - um aplicativo de calculadora. Você recebeu uma solicitação para adicionar um sistema numérico binário ao aplicativo. Esse recurso único específico gera os seguintes tópicos, cada um deles pode ser convertido em requisito.
- Suporte a operações aritméticas.
- Suporte à conversão de / para. Isso afetará a funcionalidade do sistema decimal. Por exemplo, você precisa oferecer suporte à conversão de decimal.
- Suporte a operações lógicas.
Você vê que ninguém solicita operações lógicas para binário se você não tiver suporte para esse sistema. A solicitação de recurso é sobre um sistema numérico específico, mas possui vários requisitos subjacentes.
Provavelmente isso é tão óbvio. Existem algumas armadilhas escondidas. O primeiro deles é gerenciar solicitações de recursos e requisitos de produtos em um rastreador.
Definitivamente, ter um sistema único de rastreamento e planejamento é melhor do que ter dois. Pelo menos você precisa apenas de uma guia ou janela do aplicativo aberta. Considere o uso de tipos separados de registros para gerenciar solicitações e requisitos, em vez de um único. Um exemplo da minha experiência. Estou recebendo de duas a quatro solicitações de novos recursos todos os dias úteis, enviadas pela equipe de suporte. Você pode imaginar facilmente um número de itens registrados. A lista de projetos do produto parece uma lista extremamente longa. Ter um tipo de registro de "requisito" e "solicitação de recurso" facilita a revisão e o planejamento. Se várias solicitações são a origem de um único requisito, eu faço um link de referência. Depois de revisar, posso fechar a solicitação de recurso com os rótulos "planejado" ou "rejeitado"
A segunda armadilha pode estar na coleta de solicitações. Uma maneira é obtê-los através do canal de suporte. É uma boa maneira de receber itens filtrados e limpos. Por outro lado, este não é um processo visível para seus clientes.
Portanto, fornecedores, especialmente para software em nuvem, podem usar portais para obter feedback.
Portal de comentários do ZendeskEste método adiciona visibilidade, separa solicitações de requisitos. Agora seu trabalho está dobrado, no entanto. Você precisa revisá-los e comentá-los rapidamente - os clientes não gostam de silêncio e você está se comunicando publicamente.
E o pior é rastrear e marcar itens na lista como planejados, não planejados, concluídos. Lembre-se de que solicitações de recursos não são requisitos que você deve ter em mente dependências. Voltando a um caso de suporte binário no aplicativo de calculadora. Como você deve rastrear essa solicitação no portal público, se você implementar apenas aritmética e conversão sem operações lógicas.
Todo gerente de produto escolhe uma solução própria, não existe uma abordagem universal. No entanto, devemos sempre lembrar que muitos detalhes importantes podem estar ocultos em um tópico simples.