Agenda úvodní schůzky projektu pro vývojářské týmy

Otázka, kterou úvodní schůzky přeskakují

Úvodní schůzka projektu, která proběhne dobře, zanechá tým sladěný na tom, co stavět, kdo co dělá a kdy jsou věci hotové. Toto sladění obvykle vydrží asi tři týdny. Pak se rozroste rozsah, stakeholder změní názor na klíčový předpoklad, uklouzne závislost a tým zjistí, že se nikdy nedohodl, kdo rozhoduje, když se dva rozumní lidé neshodnou.

Otázka, kterou většina agend kickoffu přeskakuje, zní: jak bude tento tým rozhodovat, když se něco pokazí? Ne plán projektu — rozhodovací rámec. Kdo vlastní rozsah, když je potřeba nějakou funkci vyříznout? Co tým dělá, když technické omezení zneplatní produktový požadavek? Který stakeholder má poslední slovo, když dvě oddělení chtějí různé věci?

Tyto otázky se na kickoffu zodpovídají snadno, protože ještě nejde o nic. Mnohem hůř se zodpovídají uprostřed projektu, když každý zaujal postoj. Šablona níže na ně vyhrazuje čas, než začne ta těžká část.

Agenda (zkopírujte a vložte)

Trvání: 60–90 minut podle složitosti projektu
Formát: moderované; všichni klíčoví stakeholdeři a přispěvatelé přítomni nebo asynchronně seznámeni před startem

Sekce 1 — Cíl a rozsah projektu (20 min)

Vyslovte cíl v jedné větě: jak vypadá úspěch jako výsledek, pokud možno měřitelně
V rozsahu: co projekt dodá, konkrétně jmenováno
Mimo rozsah: co tento projekt výslovně nebude dělat — vyjmenujte alespoň tři věci
Kritéria úspěchu: jak tým pozná, že je projekt hotový?
Tuto sekci vlastní EM nebo PM; inženýři oponují, pokud uvedený rozsah neodpovídá proveditelnosti

Sekce 2 — Role a vlastnictví (15 min)

Za každý pracovní proud pojmenujte jednoho vlastníka — ne tým, člověka
Kdo má poslední slovo v: rozsahu produktu, technické architektuře, externí komunikaci?
Kdo je informován vs. konzultován vs. osoba s rozhodovací pravomocí u každého hlavního typu rozhodnutí?
Pojmenujte vedoucího projektu, který je zodpovědný, pokud nic jiného není jasné

Sekce 3 — Omezení a rizika (15 min)

Pevná omezení: termín, rozpočet, compliance, závislosti na jiných týmech
Známá rizika: jaké jsou tři hlavní věci, které by mohly tento projekt vykolejit?
U každého rizika: pravděpodobnost, dopad a vlastník opatření
Co by způsobilo zrušení nebo výrazné zúžení projektu? Pojmenujte to hned

Sekce 4 — Komunikační plán (10 min)

Jak často se bude tým synchronizovat? V jakém formátu?
Kdo dostává aktualizaci stavu a jak? Nepředpokládejte, že stakeholdeři chtějí stejný kanál
Kde žije dokumentace projektu?
Jaká je eskalační cesta, pokud něco projekt zablokuje?

Sekce 5 — Otevřené otázky (15 min)

Vypište každou otázku, kterou tým dnes neumí zodpovědět
U každé: přiřaďte vlastníka a datum, do kdy je odpověď potřeba
Otázky bez data a vlastníka budou v polovině projektu stále otevřené

Sekce 6 — Další kroky (10 min)

Tři věci, které se musí stát v příštích pěti pracovních dnech, aby začala skutečná práce
Každý další krok má jediného vlastníka
Potvrďte, jak a komu bude shrnutí z kickoffu rozesláno

Co dělají populární šablony kickoffu špatně

Většina šablon kickoffu je důkladná ohledně plánu projektu a chudá na to, co se stane, když plán nevydrží. Vyprodukují čistý dokument s rozsahem a RACI matici, což je užitečné. Nevyprodukují sdílenou odpověď na „co uděláme, když dodavatel databáze uprostřed projektu ztrojnásobí ceny?“ nebo „co se vyřízne, pokud narazíme na pevný termín při 80% dokončenosti funkcí?“.

Absence rozsahu-mimo je další konzistentní mezera. Uvést, co je v rozsahu, je přímočaré. Uvést, co je výslovně mimo — vyjmenovat tři nebo čtyři konkrétní věci, které projekt nebude dělat — vynutí stejnou konverzaci o očekáváních stakeholderů, ale z druhé strany. Stakeholdeři, kteří se chystali předpokládat, že mobilní klient je součástí, to zjistí na kickoffu, a ne v šestém týdnu.

Třetí mezerou je sekce otevřených otázek. Týmy nechtějí na kickoffu vynášet na povrch, co nevědí, protože to působí jako přiznání nepřipravenosti. Ale neznámé odpovědi se stávají blokátory uprostřed projektu a blokátory uprostřed projektu jsou drahé. Čím dřív víte, že otázka existuje, tím dřív může někdo odpověď vzít na sebe.

O tom, jak se tyto mezery nabalují do režie během několikaměsíčního projektu: Daň za schůzky.

Proč se vyplatí udělat poznámky z kickoffu pořádně

Dokument z kickoffu je nejčastěji odkazovaným artefaktem v jakémkoli projektu. Je to to, co lidé kontrolují, když se zpochybní rozsah, když se přidá nový člen týmu, když se stakeholder zeptá „nerozhodli jsme na kickoffu X?“. Dobře zdokumentovaný kickoff je projekt, který se snáze řídí.

Pavleur zachytí celý kickoff automaticky: rozsah tak, jak byl vysloven, role tak, jak byly přiděleny, rizika tak, jak byla pojmenována, otevřené otázky s vlastníky, další kroky s vlastníky a daty. Pokud někdo uprostřed schůzky sdílel obrazovku se zadáním projektu, diagramem nebo dokumentem s požadavky, je ten vizuál v reportu zahrnut vedle diskuse. Nástroje jen na zvuk vám dají, kdo co řekl; nezachytí architektonický diagram na obrazovce ve chvíli, kdy tech lead popisoval závislost. Výsledný report slouží jako dokument se zdrojem pravdy pro projekt už od prvního dne. O tom, jak se to srovnává s tradičními nástroji na záznam schůzek: Pavleur vs. alternativy.

Poznámka k účasti

Každý, od koho se očekává rozhodnutí na tomto projektu, by měl být na kickoffu přítomen, nebo si před začátkem práce projít úplnou nahrávku a písemné shrnutí. Stakeholder, který kickoff zmešká a o rozsahu se dozví neformálně o dva týdny později, je spor o rozsah uprostřed projektu čekající, až se stane. Úkolem kickoffu je vybudovat sdílený kontext a sdílený kontext existuje jen tehdy, když jsou relevantní lidé v místnosti.