Prova de conceito (PoC) em TI: como avaliar uma solucao antes de comprar

O que é uma PoC e por que ela existe

Prova de conceito (PoC) é um teste controlado, com escopo curto e critério de aceite definido, cuja única função é responder se determinada tecnologia resolve um problema específico no ambiente real da empresa. Não é demonstração de vendedor, não é treinamento de equipe e não é implantação antecipada. É experimento com hipótese declarada antes de começar.

A confusão mais comum no mercado de TI brasileiro é tratar PoC como sinônimo de piloto. São coisas diferentes. A PoC pergunta "isso funciona para o nosso caso?" e dura semanas. O piloto pergunta "isso opera em escala, com nossos processos e nossa equipe?" e dura meses. Quem pula da demonstração direto para o piloto compra um problema caro: passa a operar uma ferramenta que nunca foi validada tecnicamente, e sair dela depois exige justificar o investimento já feito.

Existe também o custo silencioso de não fazer PoC nenhuma. Decisões de compra baseadas em apresentação comercial, quadrante de analista ou indicação de terceiros ignoram a variável que mais importa: a particularidade do seu ambiente. Firewall específico, aplicação legada, latência do link, versão de sistema operacional em produção, integração com Active Directory antigo. Nenhum fornecedor conhece essas restrições melhor que a sua equipe, e nenhuma demonstração acontece dentro delas.

Hipótese, métrica e prazo: os três elementos obrigatórios

Uma PoC sem hipótese escrita vira passeio pela interface do produto. A hipótese precisa ser uma frase falsificável, ou seja, uma afirmação que pode ser provada errada. "Queremos avaliar a solução X" não é hipótese. "A solução X reduz o tempo de restauração de um servidor de arquivos de 6 horas para menos de 1 hora, usando nosso link atual de 200 Mbps" é hipótese. A segunda versão determina o que testar, o que medir e quando parar.

A métrica precisa existir antes do teste e ter valor de referência atual. Sem baseline, qualquer resultado parece bom. Se você não sabe quantos chamados de senha sua equipe atende por mês, não tem como afirmar que a ferramenta de autoatendimento reduziu esse volume. Meça o estado atual primeiro, mesmo que a medição seja tosca — uma contagem manual de duas semanas vale mais que uma estimativa de memória.

O prazo é a proteção contra o piloto eterno. Defina data de encerramento no dia zero e trate como compromisso, não como sugestão. Prazos típicos:

• 2 a 3 semanas — ferramentas pontuais: antivírus, gestão de senhas, monitoramento, ferramenta de acesso remoto.
• 4 a 6 semanas — soluções com integração: backup, firewall, EDR, virtualização de desktop.
• 6 a 8 semanas — plataformas que tocam vários sistemas: ERP satélite, plataforma de identidade, migração de e-mail corporativo.

Acima de 8 semanas, o que existe já não é PoC. É implantação sem contrato, e normalmente sem responsável formal pelo resultado.

Como desenhar o escopo sem virar projeto

Escopo de PoC se define por subtração. Comece pela lista completa de tudo que a solução promete fazer e corte tudo que não responde à hipótese. Se a hipótese é sobre tempo de restauração de backup, a PoC não precisa validar relatórios executivos, integração com o service desk nem política de retenção de sete anos. Essas coisas importam na decisão de compra, mas se resolvem em análise documental — não consomem semanas de laboratório.

Escolha um recorte representativo do ambiente, não o mais fácil. Testar backup só na VM de homologação, que tem 20 GB e nenhuma aplicação ativa, não prova nada sobre o servidor de banco de dados de 800 GB com transações abertas. O recorte precisa conter pelo menos um caso difícil real: o servidor legado, o sistema que ninguém quer mexer, o setor com o link mais fraco. É ali que a solução vai falhar, e é melhor descobrir agora.

Defina também os papéis por escrito. Quem opera a PoC internamente, quem é o contato técnico do fornecedor, quem decide ao final e em qual data essa decisão acontece. PoC sem decisor nomeado tende a terminar em silêncio: o prazo vence, ninguém convoca a reunião de fechamento, e a ferramenta fica rodando "por enquanto" até virar dependência.

Regra prática: se a PoC exige mudança em produção que seria difícil reverter, o escopo está errado. Redesenhe antes de começar, não durante.

Critérios de aceite e o que fazer com o resultado

Critério de aceite é o número que separa aprovado de reprovado, definido antes de ver o resultado. Escrever depois é enviesar: a equipe que investiu três semanas tende a ajustar a régua para justificar o esforço. Formalize em uma tabela simples, com métrica, valor mínimo aceitável e valor desejável.

1. Critérios funcionais — a solução faz o que precisa fazer no cenário difícil escolhido? Passa ou não passa, sem meio-termo.
2. Critérios de desempenho — tempo, throughput, latência, consumo de recurso. Sempre com número e comparação com o baseline.
3. Critérios operacionais — a equipe atual consegue operar sem depender do fornecedor? Quantas horas de treinamento? Quantos passos manuais por semana?
4. Critérios de suporte — abra um chamado real durante a PoC, de propósito. O tempo de resposta que você receber como prospect é o melhor cenário possível; como cliente, tende a piorar.

Resultado negativo é resultado válido e barato. Uma PoC que reprova uma solução em quatro semanas economiza um contrato de 36 meses, a migração de dados, o treinamento de equipe e o custo de saída. Trate a reprovação como entrega, não como fracasso do time. Documente o motivo técnico específico — "não atingiu RTO de 1 hora, ficou em 4h20 por limitação de throughput do link" — porque essa documentação serve para reavaliar a mesma solução daqui a dois anos, quando o cenário mudar.

Se o resultado for positivo, registre também o que não foi testado. Essa lista vira o escopo do piloto ou do plano de implantação, e evita que a organização assuma que "a PoC validou tudo". Validou a hipótese declarada, dentro do recorte escolhido, no período definido. Nada além disso.

Erros que transformam PoC em piloto eterno

O primeiro é a ausência de data de fim. Sem encerramento formal, a ferramenta migra silenciosamente para produção: alguém aponta um servidor real, outro setor pede acesso, e em seis meses existe dependência operacional sem contrato, sem SLA e sem suporte garantido. Quando o fornecedor cobra, a negociação acontece na pior posição possível — com a empresa já refém.

O segundo é a expansão de escopo durante o teste. Começa com backup de dois servidores, o fornecedor sugere testar também replicação, alguém lembra do site remoto, e o prazo dobra. Toda sugestão nova durante a PoC deve ir para uma lista de "avaliar depois", não para o escopo corrente. A disciplina aqui é o que separa PoC de projeto informal.

O terceiro é deixar o fornecedor operar a PoC sozinho. Um engenheiro de pré-vendas configurando tudo produz resultado excelente e irreal — a empresa não terá esse profissional no dia a dia. Quem opera a PoC deve ser a mesma equipe que vai operar em produção, mesmo que isso torne o teste mais lento. A curva de aprendizado observada durante a PoC é dado, não ruído.

O quarto é comparar soluções em condições diferentes. Se a solução A foi testada em janeiro no ambiente antigo e a B em maio depois da troca de link, a comparação não vale. Quando houver mais de um candidato, rode em paralelo ou em janelas próximas, com o mesmo recorte, o mesmo baseline e os mesmos critérios de aceite.

Sinal de alerta: quando a resposta para "por que ainda estamos testando?" é "porque está funcionando bem", a PoC morreu e virou produção não declarada.

Como a Duk conduz PoCs com clientes

Na Duk Informática & Cloud, prova de conceito faz parte do processo de recomendação técnica, não da etapa comercial. Antes de propor qualquer plataforma de backup, segurança, virtualização ou nuvem, o time levanta o baseline do ambiente do cliente — tempos atuais, volumes reais, restrições de link e dependências legadas — e escreve a hipótese junto com o responsável de TI da empresa. Sem esse número inicial, não existe forma honesta de dizer que houve melhoria.

São mais de 18 anos de operação e mais de 550 empresas atendidas, o que produz um repertório útil na hora de desenhar o recorte: já sabemos quais cenários costumam quebrar uma solução em ambiente brasileiro de médio porte — link assimétrico, servidor legado sem janela de parada, aplicação que não tolera snapshot, integração com Active Directory herdado de outra gestão. Esses casos entram na PoC de propósito, logo no começo, em vez de aparecerem como surpresa três meses após a assinatura.

Como Microsoft Gold Partner, a Duk também tem acesso a licenciamento de avaliação e a canais técnicos de escalação que encurtam o ciclo de teste em soluções Microsoft 365, Azure e infraestrutura híbrida — o que na prática significa PoC mais curta e com dado mais confiável. E, quando o resultado é negativo, o relatório de reprovação é entregue com a mesma clareza do positivo: qual métrica falhou, por qual limitação técnica e o que precisaria mudar no ambiente para reavaliar no futuro. Recomendar a não-compra faz parte do trabalho de um parceiro de TI.