Treze anos de auditoria de projetos de software levam a uma conclusão clara: os projetos não falham por azar, mas sim por causa de treze erros que são
São problemas recorrentes. Quatro estão relacionados ao planejamento (escopo aberto, equipe errada, prazo impossível, orçamento baseado na fé). Quatro estão relacionados à execução.
(Sem testes, sem documentação, dívida técnica desde o primeiro dia, decisões por consenso). Cinco são problemas de governança (sem responsável definido, comitês).
(Falta de tomada de decisão, métricas vagas, ausência de critérios de aceitação, mudanças constantes sem priorização). A detecção desses problemas nas duas primeiras semanas evita o código tributário espanhol 90%.
do custo.
A literatura sobre gestão de projetos de software está saturada de boas práticas. O que falta é honestidade sobre os erros. Após treze anos auditando projetos paralisados ou fracassados, identificamos treze erros que se repetem em quase todos os casos. Conhecê-los pelo nome nos permite detectá-los nas duas primeiras semanas, quando ainda podem ser corrigidos a um custo razoável. Detectá-los no sexto mês custa de 5 a 20 vezes mais.
Nós os agrupamos em três categorias: erros de planejamento, erros de execução e erros de governança.
Erro 1 · Escopo aberto assinado como fechado. O contrato menciona "implementação de CRM", mas não especifica quais módulos, integrações ou nível de personalização. Cada parte acredita ter assinado um escopo diferente. A discussão sobre o que está incluído e o que não está começa no terceiro mês e nunca termina. Solução: assinar o escopo por módulo, com entregáveis explícitos.
Erro 2 · Equipamento incorreto para o tipo de projeto. Contrate Grandes
Quatro pessoas para um MVP rápido é ineficiente. Contratar um freelancer para um
Um sistema crítico regulamentado é arriscado. Contratar um escritório boutique sênior para um
Serviços pequenos são caros. A escolha do fornecedor determina o resultado.
do que qualquer outra metodologia.
Erro 3 · Prazo impossível assinado devido à pressão comercial. O cliente precisa
“"Para junho", porque ele tem um anúncio confirmado. O fornecedor.
Ele assina sabendo que é impossível porque precisa do contrato. O projeto
O lançamento estava previsto para setembro, o anúncio foi cancelado e todos começaram a culpar uns aos outros.
Solução: faça estimativas honestas e rejeite o impossível.
Erro 4 · Orçamento baseado na fé. Estimativas de “mais ou menos”
Isto sem um detalhamento de marcos, sem plano de contingência e sem critérios para mudança.
Quando o projeto sofre uma alteração de 30% no segundo mês, não há como...
Para determinar se é razoável ou catastrófico. Solução: estimativa detalhada por
módulo com buffer assinado.
Erro 9 · Não há um responsável claro pelo projeto no cliente. Projetos
onde “o projeto envolve tecnologia, mas também operações, também
"De marketing e também de vendas." Quando todos são donos,
Ninguém está. As decisões são adiadas, as entregas são atrasadas.
Eles permanecem sem validação e o projeto fica mais lento. Solução: um único
Responsável e com autoridade real desde o primeiro dia.
Erro 10 · Comissões sem poder de decisão. Reuniões quinzenais
com quinze pessoas onde ninguém tem o poder de tomar decisões que
Elas são importantes. Servem para informar, não para decidir. Solução: reuniões de
Decisões separadas das reuniões informativas, com procuração assinada.
Erro 11 · Métricas vagas ou ausentes. “O fato de funcionar bem e os usuários estarem satisfeitos” não é uma métrica. Sem métricas objetivas, a decisão de
“"Está terminado" depende do humor de quem lê. Solução: métricas declaradas antes do primeiro commit, medidas semanalmente.
Erro 12 · Nenhum critério de aceitação assinado. O projeto entra em fase de testes sem uma definição consensual de "aceito".
Discussões intermináveis sobre se o bug X é ou não um impedimento. Solução: critérios de aceitação assinados no início do módulo, antes de iniciá-lo.
Erro 13 · Mudança constante sem priorização. A cada semana, o cliente adiciona novos requisitos sem remover nenhum da lista de pendências. O projeto cresce sem parar.
Nem o cronograma nem o orçamento devem aumentar. Isso acabará por gerar um aumento exorbitante. Solução: uma política de alterações assinada, onde adicionar é possível, mas exige remover algo.
ou prorrogar o prazo e o orçamento.
As duas primeiras semanas de um projeto são as mais importantes. Se três ou mais dos treze erros forem detectados durante esse período, o projeto estará em risco.
em risco, e precisamos parar antes de prosseguir. Cinco perguntas que você pode fazer em uma reunião de 60 minutos:
Se a resposta para três ou mais perguntas for “não” ou “de jeito nenhum”, você precisa parar e
Resolva isso antes de prosseguir.
Não, mas o custo é significativamente reduzido quando os problemas são identificados precocemente. Um projeto perfeito não existe. Um projeto bem gerenciado é aquele que detecta erros em semanas, não em meses.
Em nossa experiência, o erro 1 (escopo aberto) e o erro 9 (sem proprietário definido) são os mais dispendiosos, pois amplificam todos os outros.
Não por si só. Uma implementação ágil inadequada pode se tornar "Scrum sem disciplina" e reproduzir os mesmos erros sob um nome diferente. Disciplina importa mais do que metodologia.
Existem ferramentas (SonarQube, CodeClimate) que fornecem métricas objetivas. O importante é medir desde o primeiro dia, e não descobrir o problema no sexto mês.
Quando o custo estimado para a conclusão do projeto excede o valor esperado dos resultados, a decisão é desconfortável, mas às vezes necessária. Recomendamos isso aos clientes que nos contrataram para auditorias.
Sim, essa é exatamente a função. Uma auditoria de 10 dias com a TCG abrange os treze erros e entrega um relatório conciso destacando os mais críticos para o projeto específico.
Um diagnóstico honesto: o que pode ser aproveitado, o que precisa ser reescrito, o que precisa ser interrompido. Às vezes, seguir em frente com esforço extra custa mais caro do que refazer parte do trabalho.
A decisão depende do caso específico e deve ser tomada com uma perspectiva externa.
Os projetos de software não falham por causa da tecnologia escolhida ou por azar. Eles falham devido a uma combinação previsível de erros.
Planejamento, execução e governança. Conhecer os treze erros pelo nome permite detectá-los a tempo e corrigi-los enquanto ainda estão presentes.
É possível. Se o seu projeto identificar três ou mais problemas, recomenda-se uma auditoria externa antes de investir mais recursos.
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
