Agenda spotkania kickoff projektu dla zespołów inżynierskich

Pytanie, które spotkania kickoff pomijają

Kickoff projektu, który idzie dobrze, zostawia zespół ustawiony w jednym rytmie co do tego, co zbudować, kto co robi i na kiedy. To ustawienie zwykle trzyma się przez jakieś trzy tygodnie. Potem zakres pełznie, interesariusz zmienia zdanie co do kluczowego założenia, zależność się ślizga, a zespół odkrywa, że nigdy nie uzgodnił, kto podejmuje decyzję, gdy dwie rozsądne osoby się nie zgadzają.

Pytanie, które większość agend kickoffu pomija, brzmi: jak ten zespół będzie podejmował decyzje, gdy coś pójdzie nie tak? Nie plan projektu — ramy podejmowania decyzji. Kto odpowiada za zakres, gdy trzeba wyciąć funkcję? Co robi zespół, gdy ograniczenie techniczne unieważnia wymaganie produktowe? Który interesariusz ma ostatnie słowo, gdy dwa działy chcą czegoś innego?

Na te pytania łatwo odpowiedzieć na kickoffie, bo nic jeszcze nie jest na szali. Dużo trudniej odpowiedzieć na nie w środku projektu, gdy każdy ma już swoje stanowisko. Poniższy szablon rezerwuje na nie czas, zanim zacznie się trudna część.

Agenda (do skopiowania)

Czas trwania: 60–90 minut w zależności od złożoności projektu
Format: prowadzony; wszyscy kluczowi interesariusze i wykonawcy obecni lub asynchronicznie zapoznani przed startem

Sekcja 1 — Cel i zakres projektu (20 min)

Sformułuj cel w jednym zdaniu: jak wygląda sukces, jeśli się da — mierzalnie
W zakresie: co projekt dostarczy, nazwane konkretnie
Poza zakresem: czego ten projekt jawnie nie zrobi — wypisz co najmniej trzy rzeczy
Kryteria sukcesu: skąd zespół będzie wiedział, że projekt jest ukończony?
Za tę sekcję odpowiada EM lub PM; inżynierowie oponują, jeśli podany zakres nie zgadza się z wykonalnością

Sekcja 2 — Role i odpowiedzialność (15 min)

Dla każdego strumienia pracy wskaż jednego właściciela — nie zespół, osobę
Kto podejmuje ostateczną decyzję w sprawie: zakresu produktu, architektury technicznej, komunikacji zewnętrznej?
Kto jest informowany, kto konsultowany, a kto decyzyjny przy każdym głównym typie decyzji?
Wskaż lidera projektu odpowiedzialnego, gdy nic innego nie jest jasne

Sekcja 3 — Ograniczenia i ryzyka (15 min)

Twarde ograniczenia: termin, budżet, zgodność, zależności od innych zespołów
Znane ryzyka: jakie są trzy główne rzeczy, które mogłyby wykoleić ten projekt?
Dla każdego ryzyka: prawdopodobieństwo, wpływ i właściciel działań łagodzących
Co spowodowałoby anulowanie projektu lub znaczące ograniczenie zakresu? Nazwij to teraz

Sekcja 4 — Plan komunikacji (10 min)

Jak często zespół będzie się synchronizował? W jakim formacie?
Kto dostaje aktualizację statusu i jak? Nie zakładaj, że interesariusze chcą tego samego kanału
Gdzie żyje dokumentacja projektu?
Jaka jest ścieżka eskalacji, gdy coś zablokuje projekt?

Sekcja 5 — Otwarte pytania (15 min)

Wypisz każde pytanie, na które zespół dziś nie potrafi odpowiedzieć
Dla każdego: przypisz właściciela i datę, do której odpowiedź jest potrzebna
Pytania bez daty i właściciela wciąż będą otwarte w połowie projektu

Sekcja 6 — Kolejne kroki (10 min)

Trzy rzeczy, które muszą się wydarzyć w ciągu najbliższych pięciu dni roboczych, żeby ruszyła prawdziwa praca
Każdy kolejny krok ma jednego właściciela
Potwierdź, jak podsumowanie kickoffu zostanie rozdystrybuowane i do kogo

Co popularne szablony kickoffu robią źle

Większość szablonów kickoffu jest skrupulatna co do planu projektu i cienka co do tego, co się dzieje, gdy plan nie wytrzyma. Wytwarzają czysty dokument zakresu i macierz RACI, co jest użyteczne. Nie wytwarzają wspólnej odpowiedzi na „co robimy, gdy dostawca bazy danych potroi cennik w środku projektu?" albo „co wycinamy, jeśli dobijemy do twardego terminu przy 80% gotowości funkcji?".

Brak zakresu-poza to druga stała luka. Podanie tego, co jest w zakresie, jest proste. Podanie tego, co jest jawnie poza — wypisanie trzech czy czterech konkretnych rzeczy, których projekt nie zrobi — wymusza tę samą rozmowę o oczekiwaniach interesariuszy, tylko z drugiej strony. Interesariusze, którzy mieli zakładać, że klient mobilny jest wliczony, dowiadują się o tym na kickoffie, a nie w szóstym tygodniu.

Trzecia luka to sekcja otwartych pytań. Zespoły nie chcą ujawniać, czego nie wiedzą, na kickoffie, bo sprawia to wrażenie przyznania się do braku gotowości. Ale nieznane odpowiedzi stają się blokerami w środku projektu, a blokery w środku projektu są drogie. Im wcześniej wiesz, że pytanie istnieje, tym wcześniej ktoś może wziąć odpowiedzialność za odpowiedź.

Jak te luki kumulują się w narzut na przestrzeni wielomiesięcznego projektu: Podatek od spotkań.

Dlaczego warto dobrze zrobić notatki z kickoffu

Dokument kickoffu to najczęściej przywoływany artefakt w dowolnym projekcie. To to, co ludzie sprawdzają, gdy zakres staje się sporny, gdy dołącza nowy członek zespołu, gdy interesariusz pyta „czy nie ustaliliśmy X na kickoffie?". Kickoff dobrze udokumentowany to projekt łatwiejszy do prowadzenia.

Pavleur przechwytuje pełny kickoff automatycznie: zakres w brzmieniu, jakie padło, role tak, jak je przypisano, ryzyka tak, jak je nazwano, otwarte pytania z właścicielami, kolejne kroki z właścicielami i datami. Jeśli ktoś udostępnił na ekranie brief projektu, diagram czy dokument wymagań w trakcie spotkania, materiał wizualny jest włączony do raportu obok dyskusji. Narzędzia oparte tylko na dźwięku dają ci, kto co powiedział; nie przechwytują diagramu architektury na ekranie, gdy tech lead opisywał zależność. Powstały raport służy jako dokument będący jedynym źródłem prawdy o projekcie od pierwszego dnia. Jak wypada to na tle tradycyjnych narzędzi do przechwytywania spotkań: Pavleur na tle alternatyw.

Uwaga o obecności

Każdy, od kogo oczekuje się decyzji w tym projekcie, powinien być na kickoffie albo przejrzeć pełne nagranie i pisemne podsumowanie przed startem prac. Interesariusz, który przegapi kickoff i pozna zakres nieformalnie dwa tygodnie później, to czekający na swoją godzinę spór o zakres w środku projektu. Zadaniem kickoffu jest zbudowanie wspólnego kontekstu, a wspólny kontekst istnieje tylko wtedy, gdy właściwe osoby są w pokoju.