A resposta curta
Discovery de produto é a fase de descoberta que vem antes do desenvolvimento: entender o problema onde ele acontece, ouvir quem usa e quem decide, testar a ideia com um protótipo e sair com um escopo validado. O objetivo é reduzir o risco de construir a coisa errada, que é o erro mais caro de um projeto.
Na DevPlans, essa fase se chama validação e estudo de produto e é a primeira das seis etapas do nosso ciclo. Ela não é burocracia antes do trabalho de verdade. É a parte do trabalho em que mudar de ideia ainda custa uma conversa, e não uma reescrita de código.
Para que serve a fase de descoberta de um software
Quem pede um sistema geralmente já tem uma ideia de solução. A discovery serve para conferir se a solução imaginada resolve o problema real e se existe um caminho menor que resolva o mesmo problema.
- Entender o problema antes da solução. O pedido "precisamos de um aplicativo" às vezes esconde um problema de processo, de integração ou de dado que um aplicativo não resolve.
- Achar o menor escopo que resolve. Separar o essencial do desejável, para que a primeira versão entre em uso mais cedo.
- Descobrir os riscos cedo. Uma integração que não existe, uma regra que ninguém sabe explicar, um dado que não é confiável. Tudo isso sai mais barato descoberto agora.
- Alinhar quem decide e quem opera. Gestão e equipe costumam descrever a mesma rotina de jeitos diferentes. A discovery põe as duas versões na mesa.
- Dar base para a estimativa. Prazo e investimento estimados sem estudo são palpite. Com o estudo, viram uma estimativa por fase.
O que se faz durante a discovery
As atividades variam com o projeto, mas estas aparecem em quase todos.
- Entrevistas e imersão na operação. Conversamos com quem usa e com quem decide e, sempre que possível, acompanhamos a rotina no lugar onde ela acontece. Quem executa o processo todo dia conhece as exceções que nenhum documento registra.
- Mapa do processo atual. Desenhamos como o trabalho acontece hoje, passo a passo, com os gargalos, o retrabalho e os controles paralelos em planilha. Muitas vezes esse mapa é a primeira vez que todos veem o processo inteiro da mesma forma.
- Análise do que já existe. Levantamos os sistemas, os dados e as integrações em uso, e o que cada sistema permite. Daqui sai boa parte da decisão entre software pronto ou sob medida.
- Protótipo. Um protótipo rápido, às vezes só algumas telas navegáveis, mostra a ideia a quem vai usar. A reação a uma tela concreta revela muito mais do que a resposta a uma pergunta abstrata.
- Validação. Definimos hipóteses e indicadores de sucesso e testamos o protótipo com quem vai usar o sistema. O que não se sustenta sai do escopo ou muda de forma antes de virar código.
A inteligência artificial ajuda nessa fase, sintetizando entrevistas e documentos e propondo uma primeira versão das histórias de usuário. A revisão e a decisão continuam com o nosso time e com você, como descrevemos em como trabalhamos.
O que sai da discovery: os entregáveis
Uma discovery bem feita termina com documentos que alguém consegue usar para decidir. Estes são os principais:
| Entregável | O que contém | Para que serve |
|---|---|---|
| Diagnóstico da operação | Processo atual, gargalos, retrabalho e sistemas em uso | Mostrar onde está o problema e o que já funciona |
| Protótipo validado | Telas navegáveis testadas com quem vai usar | Confirmar a solução antes de virar código |
| Escopo validado | Objetivo, perfis, rotinas, regras, integrações e exclusões | Fixar o que será construído e o que fica de fora |
| Backlog priorizado | Itens em ordem de prioridade, com critério de aceite | Organizar a primeira versão e as sprints |
| Estimativa por fase | Prazo e investimento de cada etapa | Decidir se e como seguir, com a informação em mãos |
| Registro de decisões e riscos | Premissas, escolhas e riscos, com responsável | Guardar o porquê de cada decisão ao longo do projeto |
No nosso ciclo, o escopo é aprovado formalmente antes de o design começar. Com esses entregáveis, você decide se segue, como e em que ordem, e isso vale mesmo que a decisão seja não construir. O que um escopo precisa conter está em como definir o escopo de um software.
Quanto a discovery pesa no projeto
Não existe uma proporção fixa, e vale desconfiar de quem dá uma antes de conhecer o caso. O peso da discovery depende de quanto do problema já está claro. Quando a operação sabe o que precisa mudar e o processo é conhecido, o estudo é curto. Quando o problema ainda está emaranhado, com várias áreas envolvidas, regras não escritas e integrações incertas, a validação leva mais tempo.
Esse tempo não é perdido. Corrigir um fluxo no protótipo custa bem menos do que corrigir no sistema pronto, e descobrir no estudo que uma integração não existe custa bem menos do que descobrir no meio do desenvolvimento. Também não é preciso esgotar tudo antes de começar: o estudo detalha a primeira versão e deixa o restante num nível que permite priorizar, e as etapas seguintes se sobrepõem a partir das primeiras sprints.
O que a discovery pede do seu lado é tempo de pessoas: alguém com autonomia para decidir pelo projeto e quem executa o processo no dia a dia, por algumas horas em entrevistas e validações. A participação de quem vai usar o sistema é o que mais reduz retrabalho depois.
Quando dá para pular a discovery
Dá para encurtar bastante, e em alguns casos pular, quando:
- O problema e a solução já foram validados. Por exemplo, quando já existe um protótipo testado ou uma versão em uso e o projeto é evoluir o que funciona.
- O escopo é pequeno e conhecido. Uma integração pontual entre dois sistemas ou a automação de uma tarefa bem definida pedem um levantamento curto, não uma fase inteira.
- Há documentação confiável. Um termo de referência bem escrito, um processo mapeado e regras documentadas já cumprem parte do papel.
Mesmo nesses casos, algum estudo acontece: confirmar o que o outro sistema permite, quem aprova cada entrega e qual é o critério de aceite. Num projeto com muitas incertezas, pular a discovery não economiza tempo, só adia o momento de descobrir.
Se a sua ideia ainda está na fase de testar se vale a pena, a discovery e o MVP andam juntos: a primeira descobre o que construir, o segundo prova com uso real. É assim que começa todo projeto de desenvolvimento de software sob medida que fazemos.