Discovery técnico antes do código: roteiro prático para evitar erros caros

Discovery técnico antes do código é o processo de investigar problema, demanda, usuários, restrições operacionais e viabilidade tecnológica antes de transformar uma ideia em backlog de desenvolvimento. Ele não é uma reunião para levantar requisitos nem um documento extenso produzido para justificar uma decisão já tomada. É uma etapa de aprendizado que ajuda CTOs, founders e líderes de produto a decidir se devem construir, ajustar, pausar ou abandonar uma hipótese. O erro mais caro costuma acontecer antes do primeiro commit. Uma empresa pode investir meses em uma plataforma tecnicamente bem executada e descobrir depois que o comprador não tem orçamento, que o usuário não muda seu processo, que a integração depende de dados inacessíveis ou que a proposta resolve um problema secundário. O código apenas torna mais caro continuar na direção errada. Em um MVP B2B, por exemplo, a hipótese não é apenas “profissionais precisam de um painel”. É preciso entender quem compra, quem usa, qual decisão será melhorada, qual sistema já contém os dados, quanto tempo o cliente tolera para obter valor e qual evidência justificaria um contrato. Para produtos com IA, IoT, AR ou VR, a investigação também precisa avaliar qualidade dos dados, dispositivos, conectividade, privacidade, segurança e operação em campo. A validação deve combinar evidências de mercado e evidências técnicas. Entrevistas mostram como o problema é percebido, mas não provam sozinhas disposição de compra. Um protótipo navegável revela compreensão e usabilidade, mas não garante que a integração será possível. Um pequeno teste técnico pode confirmar viabilidade, porém não substitui a conversa com compradores. O discovery eficaz conecta essas camadas antes que elas virem custos de desenvolvimento.

Um discovery técnico eficaz não precisa produzir dezenas de documentos. Precisa deixar rastreável por que uma hipótese foi priorizada, qual evidência a sustenta e quais riscos ainda permanecem. O conjunto mínimo recomendado é um mapa de hipóteses, um resumo das entrevistas, um mapa do processo atual, um protótipo de baixa fidelidade, uma matriz de riscos e um backlog inicial ligado a resultados. O mapa de hipóteses pode usar uma tabela simples com cinco colunas: hipótese, evidência necessária, método de teste, resultado e decisão. Uma hipótese como “o gestor pagará para reduzir o tempo de conferência” deve ser testada com entrevistas sobre o processo atual, medição do tempo gasto e uma conversa comercial concreta. “Gostei da ideia” é um sinal fraco; compromisso de testar, fornecer dados ou discutir orçamento é uma evidência mais útil. As entrevistas devem gerar observações acionáveis, não apenas transcrições. Registre frases do usuário, comportamento observado, frequência do problema, impacto operacional e solução alternativa. Depois, converta os achados em requisitos testáveis, como “o operador consegue concluir a conferência em até três passos” ou “o sistema importa dados do ERP sem exigir digitação duplicada”. O artigo sobre como transformar entrevistas com clientes em um backlog técnico priorizado aprofunda essa passagem entre pesquisa e execução. O protótipo de baixa fidelidade deve representar estados importantes, inclusive erro, ausência de dados e falta de permissão. Em um produto para indústria, vale simular o cenário de baixa conectividade. Em uma solução para saúde ou governo, vale testar consentimento, perfis de acesso e necessidade de auditoria. Quando dados pessoais estiverem envolvidos, o discovery deve considerar desde cedo os princípios e as bases legais previstos na Lei Geral de Proteção de Dados, disponível no portal oficial do Planalto.

A decisão de encerramento do discovery precisa ser baseada em critérios definidos antes de analisar os resultados. Um scorecard simples pode atribuir notas de zero a três para intensidade do problema, frequência, acesso ao comprador, disposição para testar, diferenciação, viabilidade técnica, risco regulatório e capacidade de operação. A pontuação não substitui julgamento, mas torna visíveis as premissas que normalmente ficam escondidas em apresentações otimistas. Considere construir quando existe um problema recorrente, um público acessível, uma jornada mínima compreendida e nenhum risco técnico capaz de invalidar a proposta. O primeiro backlog deve conter apenas o necessário para testar a hipótese principal. Funcionalidades que não mudam a decisão sobre valor podem esperar, mesmo que sejam desejáveis para uma versão futura. Pivotar faz sentido quando há evidência de dor, mas o comprador, o processo ou a proposta de valor não são os inicialmente imaginados. Uma solução criada para automatizar relatórios pode encontrar maior valor em alertas operacionais. Um produto de IA pensado para substituir uma análise humana pode ser mais aceito como ferramenta de revisão e rastreabilidade. O pivot deve preservar o aprendizado útil e mudar a hipótese que falhou. Pausar não é fracassar. É uma decisão racional quando o problema existe, mas o acesso aos dados, o canal comercial, a regulação ou a capacidade operacional tornam o momento inadequado. O registro deve indicar quais condições precisam mudar para retomar a iniciativa. Para organizar essa escolha, use também o guia decisório sobre quando pausar, pivotar ou avançar com um MVP. Um bom comitê de decisão reúne CEO, CTO, produto e comercial, mas não transforma consenso em requisito. Se cada área tiver poder de veto sem apresentar evidência, o projeto tende a avançar por política interna. A pergunta correta não é “todos gostaram?”, e sim “qual hipótese foi comprovada, qual foi enfraquecida e qual risco estamos conscientemente aceitando?”.

Na OrbeSoft, o discovery começa pela compreensão do mercado e do processo do cliente, não pela escolha da tecnologia. A equipe combina entrevistas com potenciais compradores, análise de concorrentes, mapeamento da jornada e prototipação de baixa fidelidade antes de recomendar o primeiro sprint. Quando existe um risco técnico específico, a investigação é desenhada para respondê-lo, sem transformar a prova em um produto paralelo. O resultado esperado é um pacote de decisão: hipóteses priorizadas, evidências de demanda, fluxos validados, riscos técnicos, premissas de operação, backlog inicial e recomendação de construir, pivotar ou pausar. Em uma solução com IA, isso pode incluir análise de disponibilidade e qualidade dos dados, critérios de avaliação e estratégia para começar com uma API de modelo ou evoluir para uma abordagem própria. Em IoT, pode incluir conectividade, sensores, edge, nuvem e processo de suporte. Em AR e VR, inclui dispositivo, ambiente, interação e condições reais de uso. Essa abordagem foi consolidada em mais de 300 projetos desenvolvidos na América Latina, nos Estados Unidos e na Europa, incluindo produtos para setores como indústria, energia, agronegócio, governo e SaaS B2B. A experiência com projetos de inovação apoiados por editais, incluindo mais de 17 projetos FAPESC e três projetos FINEP, reforça uma lição prática: entregar código não basta quando o recurso precisa se converter em evidência, produto e resultado operacional. Depois da decisão, a OrbeSoft pode seguir com um projeto fechado de ponta a ponta ou estruturar uma equipe sênior dedicada integrada ao cliente. O modelo não muda o princípio: a equipe deve questionar escopo, explicitar riscos e transferir conhecimento ao time interno. Para entender como escolher o formato de execução depois da validação, consulte a matriz prática entre alocação de equipe e projeto fechado por estágio do produto.