Agenda della riunione di kickoff di progetto per team di ingegneria

La domanda che le riunioni di kickoff saltano

Un kickoff di progetto che va bene lascia il team allineato su cosa costruire, chi fa cosa e quando le cose sono dovute. Quell'allineamento di solito regge per circa tre settimane. Poi lo scope si dilata, uno stakeholder cambia idea su un'ipotesi centrale, una dipendenza slitta, e il team scopre di non aver mai concordato chi prende la decisione quando due persone ragionevoli non sono d'accordo.

La domanda che la maggior parte delle agende di kickoff salta è: come prenderà le decisioni questo team quando qualcosa va storto? Non il piano di progetto — il framework decisionale. Chi è responsabile dello scope quando una funzionalità va tagliata? Cosa fa il team quando un vincolo tecnico invalida un requisito di prodotto? Quale stakeholder ha l'ultima parola quando due reparti vogliono cose diverse?

Queste domande sono facili da rispondere al kickoff perché non c'è ancora nulla in gioco. Sono molto più difficili da rispondere a metà progetto, quando ognuno ha una posizione. Il modello qui sotto riserva tempo per esse prima che inizi la parte difficile.

L'agenda (da copiare e incollare)

Durata: 60-90 minuti a seconda della complessità del progetto
Formato: Facilitata; tutti gli stakeholder chiave e i contributori presenti o consultati in modo asincrono prima di iniziare

Sezione 1 — Obiettivo e scope del progetto (20 min)

Enuncia l'obiettivo in una frase: che aspetto ha il successo, misurabile se possibile
In-scope: cosa consegnerà il progetto, nominato in modo specifico
Fuori scope: cosa questo progetto esplicitamente non farà — elenca almeno tre cose
Criteri di successo: come farà il team a sapere che il progetto è concluso?
L'EM o il PM è responsabile di questa sezione; gli ingegneri obiettano se lo scope dichiarato non corrisponde alla fattibilità

Sezione 2 — Ruoli e responsabilità (15 min)

Per ciascun flusso di lavoro, nomina un responsabile — non un team, una persona
Chi prende la decisione finale su: scope di prodotto, architettura tecnica, comunicazioni esterne?
Chi è informato vs. consultato vs. decisore per ciascun tipo di decisione importante?
Nomina il project lead che è responsabile se nient'altro è chiaro

Sezione 3 — Vincoli e rischi (15 min)

Vincoli rigidi: scadenza, budget, compliance, dipendenze da altri team
Rischi noti: quali sono le prime tre cose che potrebbero far deragliare questo progetto?
Per ciascun rischio: probabilità, impatto e responsabile della mitigazione
Cosa causerebbe l'annullamento o un significativo ridimensionamento del progetto? Nominalo ora

Sezione 4 — Piano di comunicazione (10 min)

Ogni quanto il team farà sincronizzazione? In che formato?
Chi riceve un aggiornamento di stato, e come? Non dare per scontato che gli stakeholder vogliano lo stesso canale
Dove risiede la documentazione di progetto?
Qual è il percorso di escalation se qualcosa blocca il progetto?

Sezione 5 — Domande aperte (15 min)

Elenca ogni domanda a cui il team non sa rispondere oggi
Per ciascuna: assegna un responsabile e una data entro cui serve la risposta
Le domande senza una data e un responsabile saranno ancora aperte a metà percorso

Sezione 6 — Prossimi passi (10 min)

Le tre cose che devono accadere nei prossimi cinque giorni lavorativi per iniziare il lavoro vero
Ogni prossimo passo ha un unico responsabile
Conferma come sarà distribuito il riepilogo del kickoff e a chi

Cosa sbagliano i modelli di kickoff più diffusi

La maggior parte dei modelli di kickoff è accurata sul piano di progetto e scarna su cosa accade quando il piano non regge. Producono un documento di scope pulito e una matrice RACI, il che è utile. Non producono una risposta condivisa a «cosa facciamo quando il fornitore del database triplica i prezzi a metà progetto?» o «cosa viene tagliato se raggiungiamo la scadenza rigida all'80% di completamento delle funzionalità?»

L'assenza dello scope-out è l'altra lacuna costante. Dichiarare cosa è in scope è semplice. Dichiarare cosa è esplicitamente fuori — elencando tre o quattro cose specifiche che il progetto non farà — forza la stessa conversazione sulle aspettative degli stakeholder, ma dalla direzione opposta. Gli stakeholder che stavano per dare per scontato che il client mobile fosse incluso lo scoprono al kickoff anziché nella sesta settimana.

La terza lacuna è la sezione delle domande aperte. I team non vogliono far emergere ciò che non sanno al kickoff perché sembra ammettere impreparazione. Ma le risposte sconosciute diventano blocchi a metà progetto, e i blocchi a metà progetto sono costosi. Prima sai che la domanda esiste, prima qualcuno può prendersi la responsabilità della risposta.

Per capire come queste lacune si accumulano in oneri nell'arco di un progetto di più mesi: La tassa delle riunioni.

Perché vale la pena curare le note del kickoff

Il documento di kickoff è l'artefatto a cui si fa più frequentemente riferimento in qualsiasi progetto. È ciò che le persone controllano quando lo scope viene contestato, quando un nuovo membro del team si unisce, quando uno stakeholder chiede «non avevamo deciso X al kickoff?» Un kickoff ben documentato è un progetto più facile da gestire.

Pavleur cattura automaticamente l'intero kickoff: lo scope così come dichiarato, i ruoli così come assegnati, i rischi così come nominati, le domande aperte con i responsabili, i prossimi passi con responsabili e date. Se qualcuno ha condiviso a schermo il brief di progetto, un diagramma o un documento di requisiti durante la riunione, l'elemento visivo è incluso nel report accanto alla discussione. Gli strumenti solo-audio ti danno chi ha detto cosa; non catturano il diagramma di architettura a schermo quando il tech lead ha descritto la dipendenza. Il report risultante funge da documento di riferimento del progetto fin dal primo giorno. Per capire come tutto questo si confronta con gli strumenti tradizionali di cattura delle riunioni: Pavleur vs. alternative.

Una nota sulla partecipazione

Chiunque ci si aspetti prenda una decisione su questo progetto dovrebbe partecipare al kickoff, oppure rivedere una registrazione completa e un riepilogo scritto prima che il lavoro inizi. Uno stakeholder che salta il kickoff e apprende lo scope in modo informale due settimane dopo è una disputa sullo scope a metà progetto in attesa di accadere. Il compito del kickoff è costruire un contesto condiviso, e il contesto condiviso esiste solo se le persone giuste sono nella stanza.