Playbook de teste técnico de 7 dias para escolher fornecedor: roteiro, entregáveis e scorecard prático

O teste técnico de 7 dias para escolher fornecedor resolve um problema que aparece em quase toda compra de tecnologia: a proposta parece boa, o discurso é convincente, mas a entrega real só aparece depois do contrato assinado. Quando a decisão envolve software sob medida, IA, integração com SAP, Power BI, cloud ou uma squad alocada, a diferença entre slides e execução costuma custar caro. Em vez de apostar em reputação, você cria um ambiente pequeno, controlado e comparável para ver como o time pensa, se comunica e entrega. Na prática, o teste não serve para “fazer uma mini fase grátis”. Ele existe para responder três perguntas objetivas: o fornecedor entende o problema? Consegue decompor o trabalho com clareza? Entrega algo que ajuda seu time a decidir? É por isso que a OrbeSoft usa um formato de shootout em processos concorrenciais, com briefing de discovery resumido antes do código, entregáveis concretos e avaliação por scorecard. A lógica é simples: validar capacidade de execução, não apenas a capacidade de impressionar. Esse tipo de teste faz ainda mais sentido quando o seu contexto é sensível, como MVP com prazo curto, backlog travado, migração de stack, produto regulado, piloto corporativo ou projeto financiado por FAPESC, FINEP e BNDES. Nesses casos, contratar errado não significa só perder dinheiro. Significa atrasar roadmap, comprometer captação, aumentar risco de operação e deixar a empresa presa a um fornecedor que fala bonito, mas não reduz incerteza.

O erro mais comum é pedir “uma POC” sem definir o que, exatamente, precisa ser provado. POC, spike e protótipo não são a mesma coisa. A POC valida viabilidade, o spike reduz incerteza técnica específica e o protótipo simula experiência ou fluxo para validar entendimento com usuário. Se você misturar tudo, o fornecedor entrega algo bonito demais para o técnico e superficial demais para o negócio. Para um processo sério de contratação, o mínimo recomendável é exigir quatro entregáveis. Primeiro, uma síntese do problema com hipótese de valor e hipótese de usuário. Segundo, um protótipo de baixa fidelidade que mostre o fluxo principal ou a lógica da solução. Terceiro, um PoC técnico mínimo, suficiente para comprovar que a abordagem é viável. Quarto, uma nota executiva com riscos, dependências, estimativa de esforço e recomendações. Em projetos mais sensíveis, inclua também evidências de teste, como registro de feedback de usuários, decisões de arquitetura e observações sobre segurança, compliance e escalabilidade. Isso é especialmente útil em saúde, fintech e govtech, onde um fornecedor bom precisa entender restrições regulatórias desde o início. Se o seu caso envolve IA, use também critérios de rastreabilidade, qualidade de dados e governança, como discutimos no guia prático de observabilidade para produtos digitais com IA e no framework prático para integrar IA em produtos digitais. Uma boa régua é esta: se o entregável não ajuda um decisor a responder “vale continuar?” ou “precisamos mudar a abordagem?”, ele ainda não está pronto. O teste técnico de 7 dias não é um concurso de slides. É um instrumento de decisão.

Teste técnico sério tem custo, e isso precisa estar explícito desde o início. Quando o fornecedor investe tempo de arquiteto, UX, engenharia e validação com usuário, o processo deixa de ser uma amostra informal e vira trabalho de diagnóstico com entregáveis. A melhor prática é tratar o teste como uma etapa paga, com escopo fechado, critério de aceite claro e prazo curto. Isso reduz atrito, qualifica a relação e atrai fornecedores que realmente têm senioridade. Quanto ao pagamento, há três modelos comuns. O primeiro é valor fixo pelo teste, bom para escopos pequenos e bem definidos. O segundo é um modelo híbrido, com valor inicial e complemento se o teste avançar para implantação. O terceiro é o pagamento por marco, com liberação após cada entregável principal. Para processos comparativos, o modelo fixo costuma facilitar a leitura entre propostas. A aceitação deve ser objetiva. Defina antes do início o que conta como concluído, quais arquivos, links, demos ou documentos precisam ser entregues e o que invalida o teste. Se o seu time já sofreu com fornecedor que promete muito e entrega pouco, use um critério de aceite baseado em evidência: artefato funcional, explicação das decisões e feedback de três usuários decisores. Para alinhar esse tipo de negociação com squads externos, vale cruzar o teste com o conteúdo de como alinhar CEO e CTO ao contratar um squad externo e com o checklist de 30 perguntas para avaliar propostas de alocação de equipe.

O primeiro erro é transformar o teste em competição de apresentação. Se você premia slides mais bonitos, o processo seleciona marketing, não execução. O segundo erro é pedir escopo demais para poucos dias. Quando o teste cresce além do razoável, ele deixa de comparar capacidade e passa a medir resistência a caos. Outro problema recorrente é não envolver decisores reais. Se a avaliação fica só com um gestor intermediário, você corre o risco de contratar uma solução que ninguém lá na frente vai usar. Também é comum esquecer de testar comunicação, documentação e postura em relação a tradeoffs, embora esses fatores influenciem muito mais o sucesso do projeto do que a estética de uma demo. Por fim, muita empresa compara fornecedor sem considerar estágio. Uma startup em captação, uma empresa de software em escala e uma operação regulada não precisam do mesmo tipo de parceiro. Se o seu caso envolve roadmap travado, dívida técnica ou pressão de mercado, o teste precisa revelar quem consegue discutir arquitetura, priorização e go-to-market, não apenas quem consegue escrever código rápido. Nesse ponto, a leitura de escala sem quebrar, do MVP ao produto 1.0 e de arquitetura modular para reduzir time-to-market ajuda a calibrar o critério técnico.