Post-mortem prático para pilotos que falharam: transforme lições em roadmap e contrato renovado

Um post-mortem de piloto falho não é uma reunião para encontrar culpados. É um processo de investigação que transforma evidências de produto, tecnologia, operação e compra em uma decisão executiva: corrigir a solução, mudar a hipótese, renegociar o escopo ou encerrar com segurança.

Em projetos B2B, a falha raramente aparece em uma única dimensão. O usuário pode aprovar a proposta, mas não conseguir acessar os dados. O modelo de IA pode atingir a precisão esperada, mas o gestor não confiar na recomendação. A integração pode funcionar em ambiente de testes, mas não atender às regras de segurança do cliente.

Considere um piloto de automação para uma operação industrial. A equipe entregou a funcionalidade principal, porém a adesão ficou abaixo do esperado porque os operadores precisavam consultar três sistemas diferentes antes de concluir a tarefa. O problema não era apenas de interface. Havia uma hipótese operacional incompleta e uma dependência de integração que não foi tratada no início.

Uma análise conduzida pela OrbeSoft em projetos de recuperação começa com uma pergunta simples: qual decisão o piloto deveria tornar possível? Se o objetivo era provar redução de tempo, a avaliação precisa mostrar o tempo antes e depois. Se era validar compra, deve investigar orçamento, patrocinador, risco percebido e processo de contratação.

A prática de documentar aprendizados sem atribuir culpa também é usada em operações de alta confiabilidade. O guia de cultura de post-mortem do Google SRE recomenda registros factuais, foco em causas sistêmicas e ações corretivas acompanhadas até a conclusão. Para um piloto, isso significa trocar opiniões soltas por uma cadeia de evidências.

A pergunta “o piloto funcionou?” é ampla demais. Substitua-a por quatro perguntas: a solução foi usada, produziu o resultado esperado, foi adotada pelo processo do cliente e existe uma rota de compra? Cada resposta aponta para uma causa diferente e exige uma correção específica.

Um problema técnico costuma deixar sinais observáveis: falhas reproduzíveis, latência acima do limite, dados incompletos, indisponibilidade, erros de integração ou baixa precisão em determinados grupos. Já um problema comercial aparece quando o valor não é percebido, o patrocinador não tem orçamento, o usuário não tem incentivo ou a decisão depende de uma área que nunca participou do piloto.

A matriz abaixo ajuda a organizar a investigação:

| Sinal observado | Hipótese provável | Evidência a coletar | Ação inicial | |---|---|---|---| | Usuários tentam usar, mas abandonam | Fricção de jornada ou desempenho | Funil, entrevistas e logs | Corrigir fluxo crítico e repetir teste | | Resultado técnico é bom, mas ninguém compra | Valor econômico ou processo de compra mal definido | Entrevistas com decisores e compras | Recalcular caso de negócio | | Cliente não libera dados ou acessos | Governança e segurança subestimadas | Registro de bloqueios e requisitos | Criar plano de acesso e ambiente controlado | | Patrocinador desaparece após a demonstração | Baixo compromisso executivo | Agenda, decisões e responsáveis | Exigir patrocinador e marco de decisão | | Escopo cresce a cada sprint | Hipótese substituída por customização | Histórico de solicitações | Congelar escopo e negociar mudança |

O guia de validação de requisitos não funcionais para MVPs B2B é útil quando a falha envolve segurança, desempenho ou disponibilidade. Em muitos casos, o piloto não fracassou por falta de funcionalidade, mas porque requisitos não funcionais foram deixados para depois.

Para pilotos com dados pessoais, registre também base legal, finalidade, minimização, retenção e responsáveis pelo tratamento. A orientação da ANPD sobre agentes de tratamento e encarregado oferece referências oficiais para organizar esses papéis. O diagnóstico não substitui aconselhamento jurídico, mas evita renegociar um piloto sem tratar riscos de privacidade.

O roadmap de recuperação não deve ser uma lista completa de tudo que o cliente pediu. Ele precisa conectar cada iniciativa a uma hipótese e a uma decisão. Um bom item responde: qual risco reduzimos, qual evidência esperamos, quem precisa participar e qual será o próximo passo se o resultado for negativo?

Uma estrutura prática usa quatro trilhas. A primeira trata do produto, com ajustes de jornada, proposta de valor e funcionalidades indispensáveis. A segunda trata da tecnologia, incluindo integração, dados, desempenho, segurança e observabilidade. A terceira trata da adoção, com treinamento, comunicação, suporte e definição de usuários. A quarta trata da compra, com patrocinador, orçamento, jurídico e critérios de contratação.

Imagine um piloto de IA para classificar solicitações de atendimento. A primeira versão apresentou boa precisão em dados históricos, mas os analistas não confiaram nas respostas. O roadmap de recuperação deve incluir explicação da recomendação, fila de revisão humana, medição de falsos positivos e teste com um grupo controlado. Apenas aumentar o tamanho do modelo não resolve a barreira de adoção.

Para cada item, use um cartão com cinco campos: hipótese, evidência atual, experimento, métrica de sucesso e decisão associada. “Melhorar a interface” é vago. “Reduzir de cinco para três passos o cadastro e elevar a conclusão de 40% para 65% em 30 sessões observadas” é testável, desde que a linha de base seja confiável.

O workshop para transformar backlog técnico em roadmap orientado por valor ajuda a organizar essa passagem. A prioridade deve considerar risco e aprendizado, não apenas esforço ou pressão da área que fez o pedido.

Se o post-mortem revelar que o MVP não deve seguir para escala, não force uma arquitetura de produto 1.0. Um protótipo, uma operação assistida ou uma integração limitada podem ser suficientes para testar a próxima hipótese. O guia sobre quando pausar, pivotar ou avançar com um MVP complementa essa decisão com critérios de continuidade.