Abra um plano de projeto que não foi você quem escreveu e vá procurar os marcos. Muitas vezes você vai encontrar algo como “Fase 2 concluída” — uma barra que se estende por duas semanas do calendário, sem dono, sem nenhuma definição escrita do que “concluída” realmente significa.
Isso não é um marco. É uma tarefa fantasiada, e ela nunca vai avisar você de nada.
Os marcos são o sistema de alerta precoce mais barato da gestão de projetos. Nenhuma ferramenta extra, nenhuma reunião extra, talvez vinte minutos de configuração. Mas eles só funcionam se forem construídos de um jeito específico, e a maioria dos planos não faz isso. Veja como é a versão que funciona.
Um marco é um momento, não um trecho de trabalho
O Guia PMBOK define marco como um ponto ou evento significativo num projeto, programa ou portfólio. A palavra-chave é ponto. Um marco tem duração zero: não consome tempo, nem orçamento, nem pessoas.
Esse zero não é um detalhe técnico. É todo o mecanismo.
Uma tarefa pode estar 60% concluída. Um marco, não. Ou ele é atingido numa data específica, ou não é, e é esse caráter binário que o torna útil como ponto de controle. No momento em que você dá a um marco uma data de início e uma data de término, entrega à sua equipe espaço para reportá-lo como “quase lá” — e “quase lá” é como quatro semanas de atraso ficam invisíveis até a semana anterior ao lançamento.
O teste das quatro perguntas
Antes de adicionar um marco a um plano, passe-o por estas perguntas:
- Ele é binário? Se alguém puder responder “em parte” de forma razoável, você está diante de uma tarefa.
- Algo muda depois dele? Um marco de verdade libera trabalho, libera dinheiro ou transfere responsabilidade. Se nada se comporta de outro jeito no dia seguinte, é enfeite.
- Alguém de fora da equipe de entrega se importaria? Os marcos são tanto um instrumento de comunicação quanto de cronograma. Um ponto de controle que só a sua equipe entende pertence à sua lista de tarefas, não à linha de marcos.
- Dá para escrever os critérios de aceitação dele numa frase? Se não der, ninguém vai concordar sobre se ele foi atingido.
Essa última pergunta é a que mais trabalha. “Testes” não é um marco. “Testes concluídos, zero defeitos críticos em aberto” é. O segundo não pode ser declarado verdadeiro enquanto três bugs críticos estiverem abertos, e é exatamente essa a ideia: critérios de aceitação precisos são a cura para a síndrome dos 99% concluído, em que um ponto de controle é marcado como concluído e duas semanas de arremates continuam, em silêncio, por trás dele.
Depois, atribua um dono. Não a pessoa que faz o trabalho que alimenta o marco — a única pessoa que declara se ele foi cumprido ou não com base naqueles critérios. Um ponto de controle que pertence “à equipe” é um ponto de controle que ninguém precisa defender.
Quantos marcos é o número certo?
Há dois modos de falhar. Três marcos num programa de nove meses não servem para nada — o primeiro sinal honesto só chega no quarto mês. Quarenta marcos num projeto de doze semanas são igualmente inúteis, porque, quando tudo é ponto de controle, nada é.
Uma regra prática: espace-os de modo que nenhum trecho do projeto passe mais de duas a quatro semanas sem um marco, e mantenha o total pequeno o bastante para caber num único slide de status. Na maioria dos projetos, isso dá entre cinco e doze.
Um conjunto padrão que serve para quase qualquer área:
- Plano aprovado e linha de base definida
- Escopo congelado
- Design ou especificação aprovados
- Construção concluída / congelamento de funcionalidades
- Entrega ao cliente, ao usuário final ou ao QA
- Go-live
Marcos precisam de predecessoras, não só de datas
Este é o erro estrutural que desativa silenciosamente todo o sistema: estacionar um marco numa data sem nenhuma dependência que o alimente.
Um marco sem predecessoras é uma afirmação. Ele fica em 14 de novembro porque alguém digitou 14 de novembro. As tarefas atrasam ao redor dele, o losango não se mexe, e o seu plano continua divulgando uma data que deixou de ser verdadeira há três semanas.
Um marco com predecessoras é um cálculo. Ligue cada tarefa que precisa terminar antes que o ponto de controle possa ser declarado — término para início, entrando no losango — e o marco passa a ser a mais tardia dessas datas de término. Basta uma predecessora atrasar para o marco se mover no mesmo dia, no gráfico, sem que ninguém precise perceber.
Duas consequências que vale a pena considerar no planejamento. Primeiro, um marco com muitas ligações de entrada é um ponto de convergência, e pontos de convergência concentram risco: seis predecessoras significam seis chances independentes de atraso, todas caindo numa mesma data. Segundo, os marcos herdam folga como qualquer outro nó da rede. Um marco com folga zero está no caminho crítico, o que significa que não é um ponto de controle que você possa perder sem ninguém notar.
Como acompanhá-los: análise de tendência de marcos
Depois que os marcos estão devidamente ligados ao cronograma, você desbloqueia o gráfico mais informativo e menos usado da gestão de projetos.
A análise de tendência de marcos é simples. A cada ciclo de reporte, registre a data prevista de hoje para cada marco — e guarde o histórico em vez de sobrescrevê-lo. Coloque a data do reporte no eixo horizontal e a data prevista do marco no eixo vertical.
Acompanhar semanalmente um marco de go-live poderia produzir isto:
| Data da revisão | Go-live previsto |
|---|---|
| Semana 1 | 14 nov |
| Semana 2 | 14 nov |
| Semana 3 | 19 nov |
| Semana 4 | 26 nov |
| Semana 5 | 3 dez |
Uma linha plana significa que a previsão está estável. Uma linha subindo significa que o marco está fugindo de você, e a inclinação é o sinal de verdade. A partir da semana 3, este projeto perde sete dias por semana, o que significa que a data de go-live está recuando exatamente na mesma velocidade em que o calendário avança. Esse não é um projeto que se recupera na segunda metade. É um projeto cujo plano e cuja realidade se separaram — e o gráfico mostrou isso três semanas antes de a data ser formalmente perdida.
Uma disciplina faz isso funcionar, e ela é contraintuitiva: registre o atraso em vez de editar a data original para bater com a realidade. Toda vez que alguém arrasta discretamente um marco para onde ele está agora, um dado é destruído e a tendência se achata numa mentira confortável.
Como isso funciona no LoopGantt
No LoopGantt, um marco é uma tarefa com duração zero, e cada visualização o exibe de um jeito diferente, de propósito.
- No gráfico de Gantt, ele aparece como um losango, e não como uma barra, para que os pontos de controle do plano sejam lidos num relance; e o destaque do caminho crítico mostra de imediato quais deles já não têm folga.
- Na visualização de tabela, as datas de início e término são idênticas e a coluna Dias fica em branco. Isso torna rápida a auditoria do plano de outra pessoa: qualquer coisa chamada de marco que mostre uma duração não é um marco.
- Na visualização de calendário, o losango fica no seu único dia, em vez de ocupar várias células, ao lado das tarefas que se estendem por elas.
- Na árvore EAP, os marcos aparecem como nós em forma de losango entre os nós circulares das tarefas, para você ver se cada fase realmente termina num ponto de controle.
O painel é onde os marcos mostram o seu valor. Ele traz um painel dedicado, Marcos, que lista cada um com a sua data e o seu status, e uma seção Verificações do cronograma que sinaliza os que a rede indica estarem em apuros — por exemplo, Marco em risco: “Início do Projeto” — adicione uma margem de tempo antes deste marco ou reduza o escopo das tarefas predecessoras. Essas verificações são calculadas diretamente a partir do grafo de dependências e da folga, então aparecem na hora e não consomem cota de IA.
Para a análise de tendência acima, as linhas de base guardam as datas planejadas, para você comparar as datas planejadas com as datas atuais dos marcos em vez de depender da memória ou de capturas de tela antigas. Gráficos de Gantt, dependências, marcos e análise do caminho crítico estão todos disponíveis no plano gratuito; as linhas de base e o acompanhamento de desvios vêm com o Pro, e o plano Teams é cobrado por membro. Os preços atuais estão aqui.
Quatro erros que vale a pena evitar
- Dar duração a um marco. Ele passa a poder ser reportado como parcialmente concluído, que é justamente a única coisa que um ponto de controle nunca pode ser.
- Deixá-lo sem ligações. Um marco sem ligações não pode atrasar, então não pode avisar você. Ele vai manter a data até o dia em que for perdido.
- Não escrever os critérios de aceitação. Sem eles, “concluído” é negociado na reunião de status por quem estiver mais confiante.
- Editar a data em vez de registrar o atraso. Parece boa higiene e destrói o único conjunto de dados que teria mostrado a tendência a você.
Conclusão
Um marco útil tem cinco propriedades: duração zero, um resultado binário, um dono com nome, critérios de aceitação escritos e predecessoras reais que o alimentam. Acerte isso e o seu plano começa a reportar problemas semanas antes de eles chegarem. Erre e você terá losangos decorativos.
Se o seu plano atual já tem marcos, faça uma auditoria esta semana. Abra cada um e confira o que está ligado a ele. Os que não têm nada antes deles são os que estão mentindo para você.