Uma tarefa do projeto é um trabalho a executar. Um marco é um evento ou uma conquista importante usada para indicar progresso. “Executar os testes de aceitação” é uma tarefa; “aceitação operacional confirmada” é um marco. Essa distinção ajuda a equipe a ver se as atividades concluídas produziram a prontidão ou a decisão necessária.
Um prazo é diferente: é uma data obrigatória. Um marco pode ter um prazo, mas chegar à data não comprova que ele aconteceu. Registrar essa diferença com honestidade é essencial quando as partes interessadas dependem do plano.
O Guia de Avaliação de Cronogramas do GAO distingue marcos de atividades nos cronogramas de projetos. Os exemplos aqui aplicam essa distinção de planejamento às revisões de equipes e às transferências; são hipotéticos, não relatos de projetos de clientes.
Compare uma tarefa, um marco, um prazo e uma entrega
| Item | O que representa | Exemplo | Evidência de conclusão |
|---|---|---|---|
| Tarefa | Trabalho que exige esforço e tempo | Ensaiar a migração | Ensaio realizado e observações registradas |
| Entrega | Item ou capacidade produzida | Manual de execução da migração | Conteúdo acordado e critérios de qualidade atendidos |
| Marco | Evento significativo ou estado aceito | Operações aceita a responsabilidade | Aceitação autorizada registrada, com quaisquer condições |
| Prazo | Data obrigatória | A transição deve terminar antes do fim do contrato | Comparar a data real ou prevista do marco com a data exigida |
Convencionalmente, um marco é modelado como um ponto de duração zero no cronograma. Isso não significa que o trabalho necessário para alcançá-lo seja instantâneo. Vincule as atividades reais de preparação, revisão e aceitação em vez de escondê-las dentro de um losango chamado “pronto”.
Uma atividade-resumo pode abranger muitas tarefas. Ela não é automaticamente um marco. Chamar uma fase de seis semanas de marco pode ocultar se a equipe quer dizer o trabalho da fase, a data de término ou uma decisão em seu limite.
Nomeie os marcos de modo que alguém possa verificá-los
Prefira um estado ou evento com um destinatário identificável: “Piloto aceito pelo responsável pelo serviço”, “Acesso necessário aprovado” ou “Primeiro grupo completo de resultados revisado”. Evite rótulos como “fase dois” e “quase pronto”, que exigem explicação do planejador original.
Para cada marco, registre:
- O evento ou estado aceito que ele representa.
- As evidências necessárias para confirmá-lo.
- A pessoa ou função autorizada a confirmá-lo.
- O trabalho predecessor e as dependências externas necessários.
- A restrição de data, se houver.
- Como serão tratadas condições, exceções ou aceitação parcial.
Isso não exige um documento extenso para cada evento pequeno. Uma frase de aceitação clara pode evitar um mal-entendido caro. O detalhe deve ser proporcional à consequência de declarar o marco concluído por engano.
Se for possível “aceitar com condições”, defina as condições e quem será responsável pelo trabalho restante. Não transforme trabalho pendente em uma nota de rodapé invisível apenas para preservar o status verde.
Exemplo: treinamento concluído não significa serviço pronto
Uma equipe hipotética está transferindo um serviço de relatórios para operações. O plano do projeto contém um marco chamado “treinamento concluído”. Três sessões de treinamento acontecem no prazo, e o projeto marca a transição como pronta.
Então a equipe que recebe o serviço descobre que não consegue restaurar um relatório agendado que falhou. As sessões cobriram a operação normal, mas as instruções de acesso e recuperação ainda estavam incompletas.
O problema da equipe não era que o treinamento não tivesse valor. O marco representava a contagem de uma atividade, enquanto as partes interessadas acreditavam que ele representava uma decisão de prontidão.
No plano revisado, “operações aceita a responsabilidade pelo suporte” passa a ser o marco de transição. Suas evidências incluem uma apresentação acordada do tratamento rotineiro, um exercício adequado de recuperação, acesso confirmado e uma lista de limitações pendentes aceita explicitamente. O treinamento continua sendo um conjunto de tarefas que contribuem para a prontidão.
Esses critérios são ilustrativos e precisam ser adaptados ao risco e às exigências operacionais do serviço. Não são um padrão universal de aceitação operacional.
O projeto também acrescenta uma tarefa separada para a própria revisão de aceitação. Quem recebe não pode revisar evidências sem custo só porque o cronograma representa o marco final como um ponto no tempo.
Escolha marcos suficientes para orientar decisões
Um cronograma com apenas “início” e “fim” pode deixar as partes interessadas sem visibilidade dos riscos intermediários. Um cronograma com um marco para cada pequena ação torna os eventos importantes difíceis de perceber.
Escolha marcos em torno de mudanças relevantes: autorização para prosseguir, premissas de design aceitas, uma capacidade utilizável, prontidão para um teste ou transferência de responsabilidade. Pergunte: “Que decisão será possível quando esse evento for confirmado?”
Em trabalho exploratório, um marco significativo pode ser a revisão de evidências, e não uma prova de que a ideia preferida deu certo. “Decisão sobre o piloto com base em evidências acordadas” pode ser mais honesto que “sucesso do piloto” quando o experimento foi criado para descobrir se uma abordagem funciona.
Mantenha o acompanhamento da entrega detalhado o bastante para mostrar como chegar ao marco. Uma visão de alto nível é útil para as partes interessadas, mas não deve desconectar o evento prometido do trabalho e das dependências que o sustentam.
Revise um marco ameaçado antes do prazo
Quando a previsão escorregar, investigue a cadeia de pré-requisitos. A entrega está incompleta, o revisor está indisponível, o critério de aceitação é ambíguo ou uma dependência ainda não foi confirmada? Esses problemas exigem respostas diferentes.
Uma pergunta útil para a revisão é: “Qual é a última data em que ainda podemos tomar outra decisão?” Ela pode ser anterior ao prazo do marco. Se um fornecedor precisa ser escolhido duas semanas antes dos testes, um aviso no dia dos testes já chega tarde.
Não mude a data de linha de base do marco apenas para coincidir com a previsão atual. Preserve o compromisso de referência e registre as mudanças autorizadas. O guia de linha de base de Gantt explica essa comparação com mais detalhes.
Se o marco for alcançado mais tarde que o planejado, registre a data real e a razão sustentada por evidências. Esse histórico pode melhorar o planejamento futuro sem reduzir a conversa a culpabilização.
Inclua alguns marcos na retrospectiva
Uma retrospectiva não precisa repetir todas as atualizações de status do projeto. Escolha um marco em que a equipe tenha aprendido algo sobre seu modo de trabalhar: uma aceitação tardia, uma dependência inesperada ou uma premissa de prontidão que falhou.
Pergunte no que a equipe acreditava durante o planejamento, que evidência desafiou essa crença depois e que pequena mudança melhoraria a próxima decisão. Por exemplo, teste os critérios de aceitação com o responsável que receberá o serviço antes de iniciar o próximo pacote de trabalho.
Use uma retrospectiva de equipe para examinar o padrão e o guia de itens de ação para acompanhar as ações. O NextRetro pode conduzir a conversa; o cronograma aprovado continua no sistema de planejamento do projeto.
Perguntas frequentes
Um marco pode ter duração?
Na programação convencional, um marco é um ponto no tempo com duração zero. A preparação, a inspeção e a decisão ao seu redor levam tempo e devem aparecer como atividades. Confira o comportamento da sua ferramenta se ela permitir outras representações.
Concluir uma entrega é sempre um marco?
Não. Uma entrega é um item ou uma capacidade produzida. Sua conclusão ou aceitação pode ser um marco quando representa um evento significativo, mas nem toda pequena entrega precisa desse nível de acompanhamento.
O que devemos fazer quando um marco está apenas parcialmente concluído?
Descreva o estado real e as condições pendentes. Use uma regra definida de aceitação condicional se o projeto tiver uma. Caso contrário, mantenha o marco como não alcançado em vez de usar uma porcentagem para sugerir uma aceitação que ainda não aconteceu.