Pauta de Reunião de Kickoff de Projeto para Equipas de Engenharia

A pergunta que as reuniões de kickoff saltam

Um kickoff de projeto que corre bem deixa a equipa alinhada no que construir, quem faz o quê e quando as coisas devem estar prontas. Esse alinhamento geralmente dura cerca de três semanas. Depois o âmbito cresce, um stakeholder muda de ideias sobre um pressuposto central, uma dependência atrasa-se, e a equipa descobre que nunca chegou a acordo sobre quem toma a decisão quando duas pessoas razoáveis discordam.

A pergunta que a maioria das pautas de kickoff salta é: como irá esta equipa tomar decisões quando algo correr mal? Não o plano do projeto — o enquadramento de tomada de decisão. Quem é responsável pelo âmbito quando uma funcionalidade precisa de ser cortada? O que faz a equipa quando um constrangimento técnico invalida um requisito de produto? Qual stakeholder tem a palavra final quando dois departamentos querem coisas diferentes?

Estas perguntas são fáceis de responder no kickoff porque ainda não há nada em jogo. São muito mais difíceis de responder a meio do projeto quando todos têm uma posição. O modelo abaixo reserva tempo para elas antes de a parte difícil começar.

A pauta (copiar e colar)

Duração: 60 a 90 minutos dependendo da complexidade do projeto
Formato: Facilitado; todos os stakeholders e colaboradores chave presentes ou com revisão assíncrona antes do início

Secção 1 — Objetivo e âmbito do projeto (20 min)

Declare o objetivo numa frase: que resultado parece sucesso, mensurável se possível
Dentro do âmbito: o que o projeto vai entregar, especificado concretamente
Fora do âmbito: o que este projeto explicitamente não vai fazer — liste pelo menos três coisas
Critérios de sucesso: como saberá a equipa que o projeto está concluído?
O EM ou PM é responsável por esta secção; os engenheiros contestam se o âmbito declarado não corresponde à viabilidade

Secção 2 — Papéis e responsabilidades (15 min)

Para cada linha de trabalho, nomeie um responsável — não uma equipa, uma pessoa
Quem toma a decisão final sobre: âmbito de produto, arquitetura técnica, comunicações externas?
Quem é informado vs. consultado vs. decisor em cada tipo de decisão relevante?
Nomeie o líder de projeto que é responsável quando mais nada está claro

Secção 3 — Constrangimentos e riscos (15 min)

Constrangimentos rígidos: prazo, orçamento, compliance, dependências de outras equipas
Riscos conhecidos: quais são as três principais coisas que poderiam descarrilar este projeto?
Para cada risco: probabilidade, impacto e responsável pela mitigação
O que faria com que o projeto fosse cancelado ou significativamente reduzido de âmbito? Nomeie-o agora

Secção 4 — Plano de comunicação (10 min)

Com que frequência vai a equipa sincronizar? Em que formato?
Quem recebe uma atualização de status, e como? Não assuma que os stakeholders querem o mesmo canal
Onde fica a documentação do projeto?
Qual é o caminho de escalada se algo bloquear o projeto?

Secção 5 — Questões em aberto (15 min)

Liste cada questão que a equipa não consegue responder hoje
Para cada uma: atribua um responsável e uma data até à qual a resposta é necessária
Questões sem data e responsável ainda estarão em aberto a meio do projeto

Secção 6 — Próximos passos (10 min)

As três coisas que devem acontecer nos próximos cinco dias úteis para começar o trabalho real
Cada próximo passo tem um único responsável
Confirme como o recap do kickoff será distribuído e a quem

O que os modelos populares de kickoff fazem mal

A maioria dos modelos de kickoff é minuciosa sobre o plano do projeto e escassa sobre o que acontece quando o plano não se sustenta. Produzem um documento de âmbito limpo e uma matriz RACI, o que é útil. Não produzem uma resposta partilhada a "o que fazemos quando o fornecedor de base de dados triplicar o preço a meio do projeto?" ou "o que é cortado se atingirmos o prazo rígido com 80% das funcionalidades concluídas?"

A ausência de âmbito excluído é a outra lacuna consistente. Declarar o que está dentro do âmbito é simples. Declarar o que está explicitamente fora — listar três ou quatro coisas específicas que o projeto não vai fazer — força a mesma conversa sobre as expectativas dos stakeholders mas a partir da direção oposta. Os stakeholders que assumiriam que o cliente móvel estava incluído ficam a saber no kickoff em vez de na semana seis.

A terceira lacuna é a secção de questões em aberto. As equipas não querem expor o que não sabem no kickoff porque parece admitir falta de preparação. Mas respostas desconhecidas tornam-se bloqueios a meio do projeto, e os bloqueios a meio do projeto são caros. Quanto mais cedo souber que a questão existe, mais cedo alguém pode ser responsável pela resposta.

Para saber como estas lacunas se acumulam em overhead ao longo de um projeto de vários meses: O imposto das reuniões.

Por que as notas de kickoff valem a pena ser bem feitas

O documento de kickoff é o artefacto mais frequentemente referenciado em qualquer projeto. É o que as pessoas verificam quando o âmbito é contestado, quando um novo membro se junta à equipa, quando um stakeholder pergunta "não decidimos X no kickoff?" Um kickoff bem documentado é um projeto mais fácil de gerir.

O Pavleur captura o kickoff completo automaticamente: âmbito conforme declarado, papéis conforme atribuídos, riscos conforme nomeados, questões em aberto com responsáveis, próximos passos com responsáveis e datas. Se alguém partilhou o ecrã com o briefing do projeto, um diagrama ou um documento de requisitos a meio da reunião, o visual está incluído no relatório juntamente com a discussão. As ferramentas apenas de áudio dão-lhe quem disse o quê; não capturam o diagrama de arquitetura no ecrã quando o tech lead descreveu a dependência. O relatório resultante serve como documento de verdade do projeto desde o primeiro dia. Para saber como isto se compara com ferramentas tradicionais de captura de reuniões: Pavleur vs. alternativas.

Uma nota sobre presença

Todos os que se espera que tomem uma decisão neste projeto devem assistir ao kickoff, ou rever uma gravação completa e um resumo escrito antes do início do trabalho. Um stakeholder que falta ao kickoff e fica a saber do âmbito informalmente duas semanas depois é uma disputa de âmbito a meio do projeto à espera de acontecer. O trabalho do kickoff é construir contexto partilhado, e o contexto partilhado só existe se as pessoas relevantes estiverem na sala.