A implementação de software sempre ensina alguma coisa. Sistemas reais revelam casos de borda. Usuários reais se comportam de maneira diferente das premissas de um workshop. Características de desempenho passam a ser mensuráveis. Integrações expõem restrições que a documentação não deixava claras.
O erro não é aprender durante a implementação.
O erro é usar a implementação como o primeiro lugar para descobrir fatos básicos sobre o produto.
Quando times começam a construir antes de entender o problema, os atores, os conceitos de domínio, as restrições, os fluxos e as capacidades necessárias, o código se torna um instrumento de descoberta. E um instrumento muito caro.
Nem toda incerteza é igual
Todo produto começa com incertezas, mas os times frequentemente tratam todas elas como se exigissem a mesma resposta.
Algumas perguntas são baratas de responder:
- Quem executa esta ação?
- De quais informações essa pessoa precisa?
- Qual sistema é a fonte de autoridade?
- O que acontece quando uma solicitação é rejeitada?
- Uma criança pode executar a mesma ação que seu responsável?
- Um registro representa o estado atual ou o histórico?
Outras perguntas realmente exigem implementação:
- Este algoritmo consegue atender à meta de latência com uma carga real?
- A API de um fornecedor se comportará de forma confiável sob a concorrência de produção?
- O modelo de armazenamento escolhido continua economicamente viável em escala?
- Quais modos de falha aparecem apenas na execução distribuída?
O primeiro grupo raramente deveria exigir código de produção. O segundo frequentemente exige.
Uma boa formação de produto reduz a primeira categoria antes de começarem os compromissos caros de engenharia.
O código cristaliza premissas
É barato mudar uma premissa em um documento.
Não é barato mudar uma premissa incorporada ao código.
Quando uma ideia se transforma em esquema de banco de dados, lógica de autorização, contratos de API, formatos de eventos, pipelines de análise, testes e fluxos de interface, mudar a ideia significa mudar um sistema.
Considere um erro simples de modelagem:
Um aluno pertence a uma escola.
Essa afirmação pode parecer inofensiva no início da implementação. Depois, o time descobre que alunos mudam de escola, podem estar ligados a instituições anteriores, podem participar de atividades independentemente de uma escola ou precisam de registros que sobrevivam à matrícula atual.
A premissa deixou de ser uma frase. Ela pode estar em chaves estrangeiras, consultas, regras de acesso, lógica de relatórios e fluxos de usuário.
O custo de corrigir o modelo de produto se transformou em trabalho de arquitetura.
Backlogs prematuros criam uma falsa certeza
Uma falha comum é converter uma ideia inicial diretamente em um backlog.
O backlog ganha detalhes suficientes para parecer executável:
Épico
→ Funcionalidade
→ História
→ Critérios de aceitação
Mas detalhe não é compreensão.
Um backlog pode conter centenas de afirmações precisas construídas sobre o modelo de domínio errado. Pode criar na organização a impressão de que a descoberta terminou porque já existem tarefas de implementação.
Isso é perigoso porque os times passam a se apegar ao artefato. Perguntas que deveriam mudar o modelo são reinterpretadas como “mudanças de escopo”. A evidência vira uma interrupção da entrega, em vez de ser o propósito do trabalho inicial de produto.
Uma sequência melhor se aproxima de:
Problema
↓
Atores e contexto
↓
Domínio e restrições
↓
Capacidades
↓
Fluxos críticos
↓
Riscos e premissas
↓
Evidências
↓
Implicações arquiteturais
↓
Incrementos de entrega
O backlog chega depois, quando pode representar um produto suficientemente compreendido para ser construído.
Descoberta é redução de risco
Às vezes, a descoberta de produto é reduzida a entrevistas com usuários ou testes de experiência de uso. Essas atividades são importantes, mas o propósito mais profundo é reduzir as incertezas relevantes antes de assumir o custo integral da entrega.
O SVPG estrutura a descoberta de produto em torno dos riscos de valor, usabilidade, viabilidade técnica e viabilidade de negócio. A utilidade desse modelo não está na taxonomia em si. Está na disciplina de perguntar o que poderia fazer a ideia fracassar antes de investir muito em implementação.
A necessidade de evidências depende do risco.
Uma alteração reversível em um fluxo interno pode justificar um teste barato e uma implementação rápida. Um novo modelo de identidade, um fluxo de dados regulados ou um contrato visível externamente merece evidências mais fortes porque sua reversão é cara.
O objetivo não é eliminar a incerteza. Isso é impossível.
O objetivo é evitar gastar esforço de engenharia para responder a perguntas que poderiam ter sido respondidas de forma mais barata.
Protótipos e código de produção atendem a objetivos diferentes de aprendizado
Protótipos são úteis porque permitem que os times sejam intencionalmente incompletos.
Um protótipo pode testar se um fluxo faz sentido sem implementar todo o modelo de autorização. Pode testar a compreensão do usuário sem observabilidade de nível de produção. Pode validar uma integração com um adaptador descartável antes que a interface se torne uma fronteira permanente.
A implementação de produção tem outras obrigações:
- segurança;
- facilidade de manutenção;
- observabilidade;
- tratamento de falhas;
- desempenho;
- capacidade de suporte;
- integridade de dados;
- migração;
- responsabilidade operacional.
Usar código de produção para o aprendizado inicial de um conceito significa pagar por essas obrigações antes que a ideia justifique o investimento.
É por isso que técnicas rápidas de descoberta são economicamente importantes. Elas produzem evidências sem criar prematuramente um estado de sistema de longa duração.
A descoberta do domínio costuma ser a camada que falta
Times podem fazer um bom trabalho de descoberta de experiência de uso e ainda assim entender mal o produto, porque o domínio por trás da interface não está claro.
Imagine um fluxo de compras que parece simples na interface:
- criar uma solicitação;
- convidar fornecedores;
- receber propostas;
- escolher um vencedor.
Por trás desse fluxo existem perguntas de domínio:
- Os fornecedores podem oferecer quantidades parciais?
- O preço pode variar conforme a data de entrega?
- O frete é separado?
- O comprador pode dividir a contratação entre fornecedores?
- O que acontece quando um fornecedor revisa uma proposta antes do prazo?
- A “melhor” oferta é a de menor preço ou a de menor custo total de aquisição e entrega?
- Quais condições são comparáveis e quais exigem julgamento?
- O que se torna contratualmente vinculante?
Uma tela bem-acabada pode esconder essas perguntas. A implementação acaba expondo-as, normalmente depois que escolhas de dados e fluxos já foram feitas.
É por isso que Capacidades antes de telas importa. A interface deve expressar um modelo de domínio e de capacidades, não substituí-lo.
A dívida arquitetural pode começar como incerteza de produto
A dívida técnica costuma ser descrita como uma consequência da engenharia. Parte dela começa muito antes.
Quando o produto não está claro, a engenharia precisa inventar as regras que faltam.
Desenvolvedores escolhem um modelo de dados porque ninguém definiu o comportamento histórico. Tornam uma integração síncrona porque a semântica de falha é desconhecida. Concedem permissões amplas a um perfil porque as fronteiras de autorização não foram exploradas. Codificam transições de estado diretamente na lógica da interface porque o fluxo não foi modelado.
O código funciona, mas a arquitetura agora carrega perguntas de produto não resolvidas.
Isso cria uma forma sutil de dívida: uma estrutura técnica construída em torno de premissas que nunca foram escolhidas conscientemente.
Mais tarde, os times chamam esse trabalho de “refatoração”. Na realidade, parte dele é formação de produto adiada.
O aprendizado da implementação continua sendo essencial
O argumento a favor de uma descoberta mais sólida pode ser mal utilizado.
Times podem passar meses modelando um domínio que usuários reais invalidariam em dias. Podem criar uma documentação de produto elaborada que adia o contato com evidências. Podem confundir completude conceitual com confiança real.
A implementação deve começar quando as incertezas mais importantes tiverem sido reduzidas o suficiente para que construir seja o próximo experimento racional.
A expressão central é “reduzidas o suficiente”.
Esse limiar depende de reversibilidade, risco e custo.
Um modelo útil é:
| Situação | Resposta mais adequada |
|---|---|
| Reversão barata, baixo risco | Implementar e observar |
| Grande incerteza sobre experiência de uso | Prototipar e testar |
| Grande incerteza de domínio | Modelar atores, regras e estados |
| Grande incerteza de viabilidade técnica | Investigação técnica curta ou prova de conceito |
| Alto risco em contratos externos | Validar o contrato e a semântica de falha |
| Grande impacto regulatório ou de segurança | Pesquisar e revisar antes de assumir o compromisso |
| Modelo de dados difícil de reverter | Dedicar mais tempo a invariantes e histórico |
Descoberta e entrega não são departamentos sequenciais. São modos diferentes de aprender, com estruturas de custo diferentes.
Decisões reversíveis e irreversíveis precisam de tratamentos diferentes
Alguns times tentam resolver a implementação prematura adicionando mais governança a toda decisão. Isso cria outro problema.
Nem toda decisão merece um workshop.
O objetivo é identificar quais escolhas ficam caras depois de codificadas.
Uma paleta de cores é reversível. Um modelo de isolamento de clientes no banco de dados pode não ser.
O nome de uma rota interna é reversível. Uma API pública consumida por clientes pode não ser.
Os dados fictícios de um protótipo são reversíveis. O modelo canônico de identidade de um sistema em produção pode não ser.
Quanto mais irreversível for a decisão, mais útil será antecipar o aprendizado.
A arquitetura é, portanto, parte da descoberta de produto, e não algo que começa depois dela. Arquitetura é uma decisão de produto, não um detalhe técnico para depois desenvolve essa relação com mais detalhes.
A descoberta deve reduzir o custo de estar errado
Um bom processo de descoberta não prova que um produto terá sucesso.
Ele permite que a organização erre mais barato.
Isso pode significar aprender que o problema não é importante o suficiente. Pode significar descobrir uma fronteira de papéis ou permissões que muda o fluxo. Pode revelar que a integração com um fornecedor não oferece uma garantia necessária. Pode mostrar que o produto tem valor, mas é economicamente inviável no modelo atual.
Esses são resultados positivos da descoberta porque evitam compromissos maiores baseados em premissas frágeis.
Uma medida útil da qualidade da descoberta não é quantos artefatos ela produziu. É se decisões importantes ficaram mais bem fundamentadas antes de se tornarem caras de reverter.
Entender antes de implementar não é voltar ao modelo em cascata
“Entender antes de construir” pode parecer uma volta às grandes especificações antecipadas. Não deveria ser.
O objetivo não é definir completamente o sistema futuro. É tomar o próximo conjunto de decisões com compreensão suficiente para justificar seu custo.
Um ciclo saudável é:
Entender
↓
Formular uma hipótese
↓
Escolher o teste útil mais barato
↓
Aprender
↓
Decidir
↓
Construir o próximo incremento significativo
↓
Observar o comportamento real
↓
Atualizar a compreensão
A implementação continua fazendo parte do sistema de aprendizado. Ela apenas deixa de carregar perguntas que métodos mais baratos poderiam ter respondido antes.
As organizações de produto mais fortes não escolhem entre descoberta e entrega. Elas entendem a economia de ambas.
Código de produção é excelente para descobrir a realidade da produção.
É uma forma desnecessariamente cara de descobrir o que o produto deveria ser.
Referências
- Marty Cagan. The Four Big Risks. Silicon Valley Product Group, 2017. https://www.svpg.com/four-big-risks/
- Marty Cagan. Discovery, Judgement. Silicon Valley Product Group, 2020. https://www.svpg.com/discovery-judgement/
- Silicon Valley Product Group. Product Success. https://www.svpg.com/product-success/
- Silicon Valley Product Group. Product Discovery: Pitfalls and Anti-Patterns. https://www.svpg.com/product-discovery-anti-patterns/