Gestão de projetos para empresas de software: Kanban, Gantt, EVM e como montar um PMO que funciona

O paradoxo das empresas de software: constroem sistemas de gestão, mas não gerenciam seus próprios projetos

Software houses vivem de entregar projetos. Mas a maioria delas gerencia suas entregas com uma combinação precária de Jira mal configurado, planilhas de horas duvidosas e reuniões de status que não resolvem nada. O resultado é previsível: atraso crônico, escopo que cresce sem controle e margem que evapora.

O problema não é falta de ferramenta. É falta de método — saber qual abordagem usar para cada tipo de projeto, como medir progresso real (não % de conclusão inventada) e como escalar a gestão quando a empresa cresce de 3 para 30 projetos simultâneos.

Este guia cobre as metodologias, métricas e estruturas que funcionam para empresas de tecnologia que querem sair do modo "apagar incêndio" e entrar no modo "gestão previsível".

Kanban, Scrum, Waterfall: quando usar cada um

Não existe metodologia universal. Cada tipo de projeto pede uma abordagem diferente, e a empresa madura é aquela que sabe combinar métodos.

Kanban: fluxo contínuo para operação e suporte

Kanban funciona quando o trabalho chega de forma contínua e imprevisível. Times de suporte, manutenção evolutiva e DevOps se beneficiam porque:

• Não há sprints artificiais — o trabalho flui
• O WIP (Work in Progress) é limitado — evita sobrecarga
• O foco é em lead time (tempo da entrada à entrega) e throughput (quantidade entregue por período)

Quando usar: manutenção de sistemas, suporte N2/N3, bug fixing, operações de infraestrutura.

Quando não usar: projetos com escopo definido, prazo fixo e entregáveis claros.

Quadro Kanban mínimo para time de software:

Backlog → Refinamento → Desenvolvimento → Code Review → QA → Deploy → Done

Regras essenciais:

• WIP limit por coluna: máximo 3 itens em "Desenvolvimento" por desenvolvedor
• Puxar, não empurrar: o desenvolvedor puxa o próximo item quando termina o atual
• Classes de serviço: urgente (bypass do WIP), padrão, data fixa, intangível (dívida técnica)
• Reunião diária de fluxo: 10 minutos olhando para o quadro, focando em itens bloqueados

Scrum: iterações para desenvolvimento de produto

Scrum funciona quando há um produto a ser construído com requisitos que evoluem. A estrutura de sprints cria cadência e previsibilidade.

Quando usar: desenvolvimento de produto novo, MVP, evolução de produto com roadmap definido.

Quando não usar: projetos com escopo fixo e contrato fechado (o cliente não aceita "vamos descobrir na sprint"), operações de suporte contínuo.

Métricas Scrum que importam:

• Velocity: story points entregues por sprint (média das últimas 3-5 sprints)
• Sprint burndown: acompanhamento diário do trabalho restante
• Sprint goal achievement: % de sprints que atingem o objetivo declarado

Waterfall / Cascata: projetos com escopo e prazo rígidos

Sim, waterfall ainda tem seu lugar. Projetos com contrato de escopo fechado, licitações públicas, integrações com prazo regulatório — todos se beneficiam de um planejamento sequencial com marcos claros.

Quando usar: projetos com escopo 100% definido antes do início, contratos de preço fixo, projetos regulatórios, integrações com sistemas de terceiros.

Quando não usar: desenvolvimento de produto com requisitos voláteis, projetos de inovação.

A realidade: abordagem híbrida

Na prática, a maioria dos projetos de software usa uma abordagem híbrida:

• Planejamento macro em cascata: marcos do projeto, entregas principais, dependências entre equipes
• Execução em sprints: dentro de cada fase, o time trabalha em sprints de 2 semanas
• Operação em Kanban: manutenção e suporte pós-entrega fluem em Kanban

No sistema de gestão de projetos da Bradata, esses três modos coexistem no mesmo projeto — permitindo visões diferentes para públicos diferentes (Gantt para o stakeholder, Kanban para o time, burndown para o scrum master).

WBS: a fundação que todo projeto precisa

WBS (Work Breakdown Structure) é a decomposição hierárquica do escopo do projeto em pacotes de trabalho gerenciáveis. É a base para estimativa, cronograma, alocação de recursos e controle de custos.

Como construir uma WBS para projeto de software

Nível 1: Projeto Nível 2: Fases ou módulos Nível 3: Entregas Nível 4: Pacotes de trabalho (atividades estimáveis)

Exemplo para um projeto de e-commerce:

1. Plataforma E-commerce
   1.1 Arquitetura e Infraestrutura
       1.1.1 Definição de arquitetura
       1.1.2 Setup do ambiente de desenvolvimento
       1.1.3 Setup do ambiente de staging
       1.1.4 Setup do ambiente de produção
   1.2 Catálogo de Produtos
       1.2.1 Modelagem de dados
       1.2.2 API de produtos
       1.2.3 Importação em massa
       1.2.4 Interface administrativa
       1.2.5 Busca e filtros
   1.3 Carrinho e Checkout
       1.3.1 Carrinho persistente
       1.3.2 Cálculo de frete
       1.3.3 Integração com gateway de pagamento
       1.3.4 Checkout em uma página
   1.4 Gestão de Pedidos
       1.4.1 Workflow de status
       1.4.2 Integração com ERP
       1.4.3 Painel administrativo
       1.4.4 Notificações ao cliente
   1.5 Testes e Homologação
   1.6 Go-live e Estabilização

Regra dos 8/80

Cada pacote de trabalho no nível mais baixo da WBS deve ter entre 8 e 80 horas de esforço. Menor que 8 horas é microgerenciamento. Maior que 80 horas é um pacote que precisa ser decomposto mais.

Gantt: o cronograma que o stakeholder entende

O gráfico de Gantt é a representação visual do cronograma do projeto. Apesar das críticas que recebe da comunidade ágil, continua sendo a melhor ferramenta para comunicar timeline para stakeholders.

Elementos de um Gantt útil

• Atividades com início e fim: derivadas da WBS
• Dependências: finish-to-start (a mais comum), start-to-start, finish-to-finish
• Caminho crítico: a sequência mais longa de atividades dependentes — determina a duração mínima do projeto
• Marcos (milestones): pontos de controle com data fixa
• Folga (slack): diferença entre o prazo da atividade e o prazo máximo sem atrasar o projeto
• Linha de base: o cronograma original aprovado, para comparação com o realizado

Caminho crítico na prática

Se um projeto de 6 meses tem 3 caminhos paralelos de trabalho:

Caminho A: Infra → Backend → Integração → Testes    = 120 dias
Caminho B: UX → Frontend → Testes                    = 90 dias
Caminho C: Documentação → Treinamento                = 40 dias

O caminho crítico é o A (120 dias). Qualquer atraso nas atividades de A atrasa o projeto inteiro. Atividades de B e C têm folga — podem atrasar até 30 e 80 dias respectivamente sem impactar a data final.

O gerente de projeto inteligente coloca seus melhores recursos no caminho crítico e monitora essas atividades com maior frequência.

EVM: medir progresso real em vez de % inventada

Earned Value Management é a técnica que responde as duas perguntas que todo patrocinador faz: "Estamos no prazo?" e "Estamos no orçamento?"

As três variáveis do EVM

• PV (Planned Value): quanto deveria estar feito até agora, em valor planejado
• EV (Earned Value): quanto realmente foi feito, medido pelo valor planejado das atividades concluídas
• AC (Actual Cost): quanto efetivamente custou o que foi feito

Indicadores derivados

Indicador	Fórmula	Interpretação
SV (Schedule Variance)	EV - PV	Positivo = adiantado, Negativo = atrasado
CV (Cost Variance)	EV - AC	Positivo = abaixo do orçamento, Negativo = acima
SPI (Schedule Performance Index)	EV / PV	> 1 = adiantado, < 1 = atrasado
CPI (Cost Performance Index)	EV / AC	> 1 = econômico, < 1 = gastando demais
EAC (Estimate at Completion)	BAC / CPI	Projeção do custo total
ETC (Estimate to Complete)	EAC - AC	Quanto ainda vai custar

Exemplo prático

Um projeto de R$ 500.000 planejado para 6 meses. Ao final do mês 3:

• PV = R$ 250.000 (deveria ter 50% feito)
• EV = R$ 200.000 (na verdade tem 40% feito)
• AC = R$ 230.000 (gastou R$ 230k para fazer 40%)

Indicadores:

• SV = 200k - 250k = -R$ 50.000 (atrasado)
• CV = 200k - 230k = -R$ 30.000 (acima do orçamento)
• SPI = 200k / 250k = 0,80 (entregando 80% do planejado)
• CPI = 200k / 230k = 0,87 (cada R$ 1 gasto produz R$ 0,87 de valor)
• EAC = 500k / 0,87 = R$ 574.712 (se continuar nesse ritmo, vai custar R$ 575k)

Esses números contam uma história muito mais honesta do que "o projeto está 40% concluído". O projeto está atrasado e acima do orçamento, e se nada mudar, vai estourar em R$ 75k.

No módulo de gestão de projetos da Bradata, o EVM é calculado automaticamente a partir das atividades concluídas e horas registradas, gerando alertas quando SPI ou CPI caem abaixo de 0,9.

Capacity Planning: saber quantos projetos cabem no time

Capacity planning é a disciplina de alinhar a demanda de projetos com a capacidade real do time. Sem isso, a empresa aceita mais projetos do que consegue entregar — e todos atrasam.

Calculando capacidade disponível

Capacidade bruta = Nº de pessoas × Horas de trabalho por dia × Dias úteis no mês

Para um time de 10 desenvolvedores em um mês com 22 dias úteis:

• Capacidade bruta = 10 × 8h × 22 = 1.760 horas

Mas a capacidade real é menor:

• Reuniões e cerimônias: -15%
• Férias e ausências: -8%
• Suporte e manutenção: -10%
• Slack time (buffer): -10%

Capacidade líquida = 1.760 × 0,57 = 1.003 horas

Ou seja, dos 10 desenvolvedores, a capacidade real de entrega é equivalente a 5,7 desenvolvedores em tempo integral. Alocar como se fossem 10 é a receita para atraso.

Alocação por projeto

Com a capacidade líquida calculada, o PMO distribui entre projetos:

Projeto	Alocação	Horas/mês	Pessoas equivalentes
Projeto Alpha	40%	401h	2,3
Projeto Beta	30%	301h	1,7
Manutenção Product X	15%	150h	0,9
Projetos internos	15%	150h	0,9
Total	100%	1.003h	5,7

Se chegar um novo projeto pedindo 3 pessoas, a conta não fecha. O PMO precisa dizer não, renegociar prazos de projetos existentes ou contratar.

Como montar um PMO que funciona

PMO (Project Management Office) é a estrutura organizacional que governa a gestão de projetos. Em empresas de software, o PMO geralmente se justifica quando há 5+ projetos simultâneos com times compartilhados.

Níveis de maturidade do PMO

Nível 1 — PMO de suporte (Mês 1-3)

• Padroniza templates (plano de projeto, status report, ata de reunião)
• Centraliza informações de projeto em um único lugar
• Apoia gerentes de projeto com ferramentas e métodos
• Gera relatório consolidado de portfólio semanal

Nível 2 — PMO de controle (Mês 4-8)

• Define e monitora metodologia padrão
• Acompanha KPIs de projeto (SPI, CPI, SLA de entregas)
• Gerencia capacity planning
• Faz gestão de riscos consolidada
• Participa de decisões de priorização

Nível 3 — PMO estratégico (Mês 9+)

• Prioriza portfólio com base em critérios estratégicos
• Gestão de dependências entre projetos
• Análise de ROI por projeto
• Previsão de demanda e planejamento de contratação
• Melhoria contínua de processos com base em dados

Estrutura mínima

Para uma empresa com 10-30 projetos ativos:

• 1 head de PMO: governa processo, reporta para diretoria
• 1 analista de PMO: coleta dados, gera relatórios, mantém ferramentas
• Gerentes de projeto: cada GP gerencia 3-5 projetos (podem ser técnicos com função acumulada)

Gestão de riscos: prever antes de sofrer

Todo projeto tem riscos. A diferença entre gestão amadora e profissional é tratar riscos antes que virem problemas.

Matriz de riscos para projetos de software

Risco	Probabilidade	Impacto	Score	Mitigação
Turnover de desenvolvedor-chave	Alta	Alto	Crítico	Documentação, pair programming, bus factor > 1
Escopo creep (aumento não controlado)	Alta	Alto	Crítico	Change request formal, backlog congelado por sprint
Integração com sistema legado falha	Média	Alto	Alto	POC de integração na fase inicial
Requisitos mal definidos	Alta	Médio	Alto	Sprint 0 de discovery, protótipo
Atraso de aprovação do cliente	Média	Médio	Médio	SLA de aprovação no contrato, escalation path
Dependência de API de terceiro	Média	Médio	Médio	Mock da API, contrato de SLA com fornecedor

Reunião de riscos

Frequência: quinzenal ou a cada sprint. Duração: 30 minutos. Participantes: GP, tech lead, PO.

Agenda:

1. Revisar riscos existentes (mudou probabilidade/impacto?)
2. Identificar novos riscos
3. Verificar ações de mitigação em andamento
4. Atualizar o registro de riscos

Status report: a comunicação que o stakeholder precisa

O status report é o mecanismo de comunicação entre o projeto e os stakeholders. Precisa ser conciso, honesto e acionável.

Template de status report semanal

Projeto: [Nome]
Período: [Data início] a [Data fim]
Status geral: 🟢 Verde / 🟡 Amarelo / 🔴 Vermelho

Progresso:
- Sprint X concluída: [entregas realizadas]
- Sprint X+1 em andamento: [objetivo da sprint]
- % de conclusão geral: XX% (EV/BAC)

Indicadores:
- SPI: X.XX | CPI: X.XX
- Horas consumidas: XXXh de YYYh planejadas

Riscos e impedimentos:
- [Risco/impedimento 1]: [ação e responsável]
- [Risco/impedimento 2]: [ação e responsável]

Decisões necessárias:
- [Decisão pendente]: [impacto se não decidir até data X]

Próximas entregas:
- [Entrega 1]: [data prevista]
- [Entrega 2]: [data prevista]

Ferramentas não resolvem processo quebrado

A tentação de toda empresa é comprar uma ferramenta e esperar que ela resolva a gestão de projetos. Ferramentas são amplificadoras: amplificam o bom processo e amplificam o processo ruim.

O caminho que funciona, e que aplicamos nos projetos que desenvolvemos na Bradata, é:

1. Definir o processo primeiro: como os projetos são aprovados, planejados, executados e encerrados
2. Padronizar o mínimo: templates, métricas, cadência de reuniões
3. Escolher ferramenta que se adapte: não o contrário
4. Medir e ajustar: usar dados reais para melhorar o processo continuamente

A plataforma de PMO da Bradata foi construída justamente com essa filosofia — o sistema se adapta ao processo da empresa, oferecendo visões de Kanban, Gantt e EVM no mesmo projeto, capacity planning integrado e relatórios automáticos para stakeholders. Porque aprendemos que a melhor ferramenta de gestão de projetos é aquela que o time realmente usa.