EVM para Projetos de TI e Software
Aplicar o Gerenciamento de Valor Agregado a projetos de TI e software é mais desafiador e tem mais nuances do que aplicá-lo à construção civil. O trabalho de software é abstrato, os requisitos podem mudar no meio do projeto e medir o "percentual de conclusão" de uma funcionalidade é inerentemente subjetivo. No entanto, com as adaptações corretas, o EVM oferece um valor tremendo para o gerenciamento de programas de TI e para comunicar o status do orçamento e do cronograma para partes interessadas não técnicas.
O Desafio Central: Medir o Valor Agregado no Software
Na construção, você pode medir o progresso físico (metros cúbicos concretados, metros instalados). No software, você está medindo um trabalho invisível. As três abordagens mais comuns são:
1. Story Points (EVM Ágil)
Em ambientes Scrum ou Kanban, as equipes estimam o trabalho em pontos de história (story points). Você pode construir o EVM sobre isso:
- BAC = Total de story points × custo médio por story point
- PV = Story points planejados para conclusão até este sprint
- EV = Story points efetivamente concluídos × custo médio por story point
- AC = Custos reais da equipe (salários, infraestrutura, licenças) no período
Esta abordagem só credita as histórias como "concluídas" quando elas atendem à Definição de Pronto (Definition of Done) da equipe — prevenindo a armadilha do "90% concluído".
2. EVM Baseado em Marcos (Cascata)
Para projetos em cascata ou baseados em fases (phase-gate), atribua pesos orçamentários aos marcos (ex: Requisitos = 15%, Design = 20%, Desenvolvimento = 40%, Testes = 20%, Implantação = 5%). O Valor Agregado é creditado apenas quando cada marco é totalmente concluído e aceito.
3. Pacotes de Trabalho Ponderados
Divida o software em módulos funcionais (autenticação, relatórios, API, UI). Estime o custo e a duração para cada um. Monitore a conclusão no nível do módulo. Esta é a abordagem EVM mais tradicional, adequada para contratos de TI de preço fixo.
Exemplo Prático: Projeto de Desenvolvimento de Software
Um projeto de desenvolvimento de CRM customizado: BAC = $400.000, 8 sprints (16 semanas). No sprint 4 (semana 8):
- Total de story points: 800. Custo médio por story point: $500.
- Story points planejados até o sprint 4: 400. PV = 400 × $500 = $200.000
- Story points efetivamente concluídos: 320. EV = 320 × $500 = $160.000
- Custo real (salários da equipe + infraestrutura): AC = $195.000
SPI = EV ÷ PV = 160.000 ÷ 200.000 = 0,800 (atraso de 20%)
EAC = BAC ÷ CPI = 400.000 ÷ 0,821 = $487.211
VAC = 400.000 − 487.211 = −$87.211
EVM e Agile: Objeções Comuns
| Objeção | Resposta |
|---|---|
| "Agile não tem escopo fixo" | O EVM funciona com um backlog priorizado — o BAC representa o escopo acordado da release, não todo o backlog do produto. |
| "Os requisitos mudam a cada sprint" | Use um processo de controle de mudanças. Mudanças de escopo aprovadas atualizam o BAC. Mudanças não planejadas são variações a investigar. |
| "O velocity de story points é mais útil" | Velocity é ótimo para a equipe; o EVM fornece a visão financeira necessária pelos patrocinadores e executivos. |
| "Nós não estimamos com antecedência" | O EVM requer uma linha de base. Mesmo histórias dimensionadas de forma relativa podem formar uma base se dimensionadas consistentemente. |
Dicas Práticas para Gerentes de Projetos de TI
- Defina seu BAC antes do sprint, não depois: A linha de base deve ser estável para que o EVM tenha sentido.
- Conte apenas 0% ou 100% para histórias em andamento: Evite crédito parcial; isso infla o EV e mascara o risco do cronograma.
- Monitore as tendências do CPI semanalmente: Projetos de software avançam rápido. Relatórios mensais de EVM podem detectar problemas tarde demais.
- Separe o BAC para infraestrutura/operações vs desenvolvimento: Os custos de infraestrutura têm diferentes direcionadores e devem ser monitorados separadamente.
- Use EVM no nível do programa: Se você tiver várias equipes Agile, agregue os dados EV/AC delas no nível do programa para relatórios executivos.