Por que projetos fracassam mesmo com profissionais competentes

Projeto de software não morre de incompetência técnica. Morre de desalinhamento entre o que cada parte da mesa entende por sucesso — e o profissional mais competente do mundo não resolve isso sozinho, porque o problema não é saber fazer; é saber combinar.

Assino aqui o argumento: Roberto Brandini, escrevo há duas décadas sistemas comerciais e ERPs, desde os anos de Clipper em 1996 até a migração atual de WebForms para .NET 10 com Angular. E continuo vendo o mesmo padrão se repetir: a equipe é competente, o código sobe, a arquitetura é sólida. O projeto morre de outra coisa — de gestão, não de técnica. Da diferença entre alguém que sabe executar e alguém que sabe combinar execução com propósito, prazo, escopo e risco na mesma mesa.

Este é o segundo artigo da série PMBOK sem Burocracia. No primeiro, mostrei que o PMBOK é vocabulário comum, não manual de gestão. Agora quero responder a pergunta que aparece em toda roda de conversa sobre software: se a equipe é boa, por que o projeto fracassou? A resposta curta está no subtítulo. A longa vem a seguir.

Leitura: ~7 minutos

🎧 Ouvir resumo (53s) — voz gerada por IA, narração dos pontos principais do post.

O ERP que subiu perfeito e foi rejeitado

Atendi uma distribuidora de cosméticos há alguns anos. O sistema anterior tinha três anos de uso, rodava em Clipper, dava pane toda vez que abria o caixa depois do meio-dia e travava na rotina de fechamento mensal. A diretoria decidiu trocar. Chamou uma equipe nova. O orçamento foi aprovado, o cronograma assinado, o fornecedor escolhido por indicação.

Oito meses depois o sistema novo estava no ar. Banco de dados migrado, rotinas fiscais integradas, emissor de NF-e conversando com a SEFAZ, módulo de compras conectado ao fornecedor de matéria-prima, fluxo de aprovação de pedido funcionando. Tecnicamente, era um trabalho competente — eu mesmo examinei o código em algumas visitas e era bem escrito.

A rejeição veio no terceiro mês de uso. A diretoria alegou que o sistema “não atendia”. Não o que estava em tela, não o que estava em relatório, não o cálculo fiscal. A alegação era mais difusa: o sistema não atendia o negócio. Traduzindo o que a diretoria verbalizou em seis reuniões, o que faltava era combinação entre o que cada área fazia com o sistema. O comercial interpretava “pedido aprovado” de um jeito, o depósito de outro, o fiscal de um terceiro. O sistema atendia cada interpretação em separado, mas não atendia a empresa — porque a empresa não era a soma dessas três interpretações, era o fluxo entre elas.

O fornecedor da implantação alegou, com razão parcial, que seguiu o escopo contratado. A diretoria alegou, com razão parcial, que esperava outra coisa. Os dois estavam certos dentro da definição de cada um. E foi exatamente isso que matou o projeto: não bug, não incompetência, não corrupção. Definições diferentes para as mesmas palavras, sem ninguém com a função de alinhar antes de começar.

Domínio técnico não é gerenciamento (e a confusão entre os dois é o erro)

No jargão do PMBOK, a competência de escrever software é trabalho do projeto: o que se produz, o que se entrega, o que se mede. A competência de combinar expectativas, prazos, custos e riscos entre pessoas diferentes é gerenciamento de projeto: a função de manter o trabalho alinhado com o propósito que motivou o trabalho.

Essas duas competências se sobrepõem em alguns pontos, mas não são a mesma coisa. Um programador sênior sabe transformar requisito em código com qualidade. Um gerente de projeto sabe transformar requisito em acordo entre pessoas que não se entendem. São ofícios diferentes. Profissionais competentes em cada ofício são comuns. Profissionais competentes nos dois simultaneamente, com a profundidade necessária para projetos não-triviais, são raros. E aqui está o ponto que ninguém fala em roda de bar: a maioria esmagadora dos projetos de software não conta com a segunda competência — porque a primeira é cara, e ninguém quer pagar pelas duas.

O sintoma que aparece com mais frequência em duas décadas de ERP: o profissional mais competente do time, quando promove a “gerente” sem mudar a função, vira o ponto de estrangulamento. Ele é promovido porque conhece o código; ele fracassa como gerente porque gerenciar pessoas, expectativa e prazo é trabalho diferente de conhecer o código. Quando a empresa percebe a falha, geralmente já entregou metade do projeto com escopo debatido a cada reunião.

O que o gerente de projeto faz (na prática, não no organograma)

A definição mais honesta que eu já li sobre a função: o gerente de projeto é a pessoa que responde, em qualquer momento do projeto, sobre três perguntas — estamos dentro do escopo? estamos dentro do prazo? estamos dentro do custo? — e que tem a autoridade (formal ou negociada) para chamar atenção quando a resposta começa a divergir.

A definição parece simples. A prática é diferente. O gerente de projeto passa a maior parte do tempo traduzindo. Traduzindo o que o cliente quis dizer em requisito verificável. Traduzindo o que o programador construiu em valor que o cliente entende. Traduzindo o que o cronograma diz em decisão que o diretor pode tomar. Traduzindo o que o risco identificado significa em ação concreta que alguém tem que executar. A função do gerente é servir de ponte entre vocabulários que, sem a ponte, não se conversam.

Quando a ponte não existe, o projeto não para. Ele continua, mas cada parte da mesa faz sua própria tradução. E o resultado do trabalho é a média das traduções — não o que foi pedido, não o que foi combinado, mas a média do que cada lado entendeu sozinho. Em projetos longos, essa média costuma ser diferente o suficiente do objetivo original para que, na entrega, o cliente receba um sistema que tecnicamente está pronto, mas operacionalmente não atende.

Caso ERP: três áreas, três leituras, um sistema

Volto ao exemplo do começo, porque ele é típico. Em uma implantação de ERP, a palavra “integração” é usada em pelo menos três sentidos diferentes sem que ninguém perceba:

• O comercial entende integração como “o celular dele abre o pedido de venda em qualquer lugar”. Conectividade, disponibilidade, usabilidade mobile.
• O fiscal entende integração como “a NF-e sai com CFOP, CST e tributação corretos conforme a operação”. Conformidade legal, apuração de impostos, sped.
• O TI entende integração como “as rotinas conversam com o banco de dados, com o web service da SEFAZ e com a API do fornecedor”. Conectividade técnica, latência, versionamento.

Nenhuma das três definições está errada. Cada uma corresponde a um uso legítimo da palavra em seu contexto. O problema é que, no início do projeto, os três sentam na mesma mesa e concordam que “o sistema precisa estar integrado”. A frase fecha. A pergunta que vem depois — integrado como? — só aparece quando a primeira entrega cai.

O que o gerente de projeto deveria ter feito antes de qualquer codificação: sentado com as três áreas, escrito em uma página o que cada uma entende por integração, e confrontado as três definições até virarem uma só — ou até virar explícito que a integração da área A é diferente da integração da área B, e que ambas precisam ser entregues. Sem essa página validada, o sistema que sobe ao fim do projeto é o que o time de TI entendeu por integração, e as outras duas áreas só vão perceber que faltou no primeiro fechamento mensal — quando o retrabalho já está contratado.

A regra geral que eu aplico em qualquer projeto de implantação: se duas áreas usam a mesma palavra, escreva a definição de cada uma lado a lado e peça para cada área validar a definição da outra. Se uma das duas discordar da definição da outra, a palavra ainda não está alinhada — e nenhum código que dependa daquela palavra deveria ser escrito antes do alinhamento.

Por que o erro se repete mesmo conhecendo a solução

Sendo essa solução visível, por que ela se repete? Três motivos que eu já vi no meu próprio comportamento e no de colegas:

1. Achar que alinhamento é perda de tempo. O programador olha para a semana de reunião de alinhamento e compara com a semana que ele poderia estar escrevendo código. Em projetos curtos, parece que dá pra pular. Em projetos longos, o alinhamento economiza as três semanas de retrabalho do fim. A comparação troca certo por imediato, e a empresa só percebe meses depois. 2. Confundir formalidade com efetividade. Muitos gerentes preenchem ata de reunião, planilha de risco e matriz RACI sem nunca confrontar a definição das palavras. A documentação serve de cenário, não de processo. O alinhamento é verbal, presencial, com o conflito exposto — não está em template nenhum. 3. Tratar o gerente de projeto como cargo, não como função. Em muitas empresas, o “gerente de projeto” é o programador mais antigo que ganhou a função por tempo de casa. Sem treinamento, sem tempo dedicado, sem autoridade para parar uma linha de código que está construindo a coisa errada. A função existe no organograma, mas não existe no projeto.

Erros frequentes ao gerenciar projeto de software

Quatro padrões que eu já vi e que se repetem, listados sem ordem de importância:

1. Aceitar escopo por abraço. “Coloca isso também que a gente vê depois” é a frase que mata o cronograma. Toda adição verbal deveria virar item de lista e voltar à mesa de decisão antes de ser implementada. Se a equipe implementa sem voltar, a culpa é da equipe — mas a omissão que permitiu a aceitação foi gerencial. 2. Não registrar mudança de prazo. Mudou o prazo por qualquer motivo, e o time continua trabalhando no plano antigo. O plano antigo e a nova realidade passam a conviver em silêncio, e a primeira pessoa a descobrir a discrepância é quem recebe a entrega fora do prazo esperado. Toda mudança de prazo deveria ser documentada com o motivo — e o motivo deveria ser comunicado a todos. 3. Misturar urgência de operação com prazo de projeto. A operação (suporte, correção de bug crítico, atendimento a cliente) tem urgência por impacto, não por data. O projeto (release, implantação, migração) tem prazo por data. Quando a urgência da operação vira prazo do projeto, o projeto herda a ansiedade do dia a dia e ninguém lembra mais o que era o objetivo. A frase que denuncia a confusão: “isso é para ontem”. Resposta correta: “ontem é operação; projeto tem data, vamos negociar.” 4. Esconder risco até virar problema. O gerente que só noticia risco quando ele se materializou está transferindo para o cliente a função de decidir sobre algo que o gerente já sabia ser possível. Risco identificado é risco documentado, com probabilidade, impacto e ação. Risco não documentado vira surpresa — e surpresa é o oposto de gerenciamento.

Reflexão final e próxima ação

Em duas décadas de ERP, eu vi projeto morrer de três formas: código ruim, gestão ruim e desalinhamento entre quem pede e quem faz. Código ruim se corrige com tempo. Gestão ruim se corrige com processo. Desalinhamento é o único dos três que não aparece em nenhuma linha do cronograma, e por isso é o que mais mata projeto sem que ninguém perceba até a entrega.

A diferença entre o profissional competente que faz o sistema funcionar e o gerente de projeto competente que faz o projeto funcionar é a pergunta que cada um faz. O primeiro pergunta “como faço?”. O segundo pergunta “como combinamos o que vamos fazer antes de eu começar?”. As duas perguntas são legítimas e complementares. Quando o mesmo profissional precisa responder as duas com profundidade, ele cobra por isso. Quando a empresa acha que dá pra ter as duas no mesmo salário, o projeto herda a diferença.

Minha próxima ação para você levar daqui: antes de iniciar o próximo projeto de software, reúna as áreas envolvidas por uma hora. Em uma página, escreva para cada área: o que ela entende por “entrega concluída”, o que ela entende por “escopo”, o que é projeto e o que é operação. Coloque as definições lado a lado. Peça para cada área ler a definição da outra e discordar verbalmente do que não concordar. O que sobreviver a essa validação coletiva é o vocabulário comum do projeto. O que não sobreviver é o retrabalho evitado.

Esse é o tipo de trabalho invisível que o PMBOK descreve sem romantizar: alinhar antes de fazer, perguntar antes de assumir, documentar antes de mudar. Não é glamour, não é velocidade, não é entregável visível no status report. Mas é o trabalho que separa o projeto que sobe em produção e roda por anos do projeto que sobe em produção e é rejeitado em três meses.

Leitura relacionada

• O que é PMBOK e por que todo profissional deveria conhecê-lo — o primeiro artigo da série, com o vocabulário fundamental (projeto, operação, programa, portfólio) e a justificativa para quem constrói software se importar com o guia.
• PMBOK sem burocracia: 40 artigos sobre gestão de projetos para quem constrói software — o índice da série inteira, com o mapa dos 40 artigos, a ordem planejada e o caso de origem.
• Escopo, prazo e custo: mudou um, você precisa conversar novamente sobre os outros — a regra do triângulo em ação, escrita para o caso clássico de mudança de escopo sem renegociação das outras duas pontas.