Como entregamos um projeto completo para cliente pela primeira vez
Primeiro projeto do zero ao deploy com cliente real na POA Software. O que funcionou, o que não funcionou, e o que aprendi que nenhum tutorial de programação ensina.
Primeiro projeto completo do zero ao deploy na POA Software.
Cliente de médio porte. Sistema de gestão de leads com integração ao CRM deles. Prazo de 6 semanas. Time de 3 pessoas.
Entreguei. Mas não foi tranquilo. E o que aprendi sobre entrega de software real não estava em nenhum livro de programação que eu tinha lido.
Na semana 3, o cliente pediu "uma coisa pequena": adicionar um relatório de conversão por vendedor. Parecia simples. Não era. Exigia query nova, nova tela, exportação para Excel, e integração com o sistema de metas que ninguém tinha mencionado antes.
Aprendi o conceito de scope creep na prática, não na teoria. "Uma coisa pequena" raramente é. O que fizemos: documentamos o pedido, estimamos o impacto no prazo, apresentamos ao cliente. Ele escolheu: "entra no projeto com prazo estendido" ou "vai para a próxima fase". Escolheu a próxima fase.
Esse processo — documentar, estimar, apresentar opções — foi a primeira vez que vi gestão de escopo funcionando de forma concreta. Antes eu achava que era burocracia. Depois entendi que é proteção para o time e transparência para o cliente.
Na semana 5, demo para o cliente. Tudo funcionando em desenvolvimento. Em produção: erro na importação de dados. O servidor de produção tinha versão diferente do Python. Uma dependência que assumíamos como disponível não estava.
O ambiente de desenvolvimento nunca é igual ao de produção. Isso é uma verdade da engenharia de software que você aprende várias vezes, de formas diferentes, ao longo da carreira. O que aprendi: ambiente de produção precisa ser documentado explicitamente. Não "Python 3.x" — "Python 3.7.2 com as seguintes dependências". E o processo de deploy precisa ser testado em ambiente igual ao de produção antes da entrega.
Na semana 2, tomamos uma decisão técnica: mudar a estrutura de como leads eram agrupados para resolver um problema de performance. Não comunicamos ao cliente.
Semana 6, demo final: "isso não é como discutimos que funcionaria."
Tecnicamente estava correto e melhor. Para o cliente, era diferente do que esperavam. Tivemos que explicar a decisão retrospectivamente, o que é sempre mais difícil do que comunicar na hora. Regra que adotei depois: qualquer decisão que muda comportamento visível para o usuário — mesmo que seja melhoria técnica — precisa ser comunicada antes de implementada.
Estimei que a integração SAML levaria 3 dias. Levou 7. Não porque eu era lento — porque eu nunca tinha feito integração SAML antes. Não sabia o que não sabia.
Estimativa para tarefa nova é quase sempre errada. A questão é se você erra para o lado seguro ou para o otimista. Fórmula que aprendi depois: estimativa base × 2 para tarefa que você já fez, × 3 para tarefa nova em área conhecida, × 4+ para tarefa nova em área desconhecida. O cliente que recebe o sistema 2 dias antes do prazo fica mais feliz do que o que esperava 2 dias menos.
O cliente não lembra dos bugs que você corrigiu. Não lembra das decisões técnicas. Não lembra das noites depurando.
Lembra de como foi trabalhar com você. Na entrega final, ele disse: "foi um prazer trabalhar com vocês. A comunicação de vocês foi excelente." Não falou do código. Falou da experiência de trabalhar com o time.
Essa semana: pensa no seu projeto atual. Tem alguma decisão técnica que você tomou mas não comunicou para o cliente ou stakeholder? Vale uma mensagem proativa agora, antes que vire surpresa depois.