Gotowość to decyzja, nie dokument
Zespoły często pytają, czy brief jest kompletny albo backlog w pełni dopracowany. To pomocne sygnały, ale nie one rozstrzygają o starcie.
Właściwe pytanie brzmi: czy możemy już robić sensowny postęp bez opierania pierwszej pracy na założeniach, które mogą ją unieważnić?
Checklista gotowości projektu porządkuje dowody. Poniższy framework pomaga zamienić je w jedną z trzech decyzji.
Start
Startuj, gdy pierwszy fragment pracy jest jasny i wykonalny.
Powinny być znane:
- rezultat pierwszego etapu,
- osoby podejmujące i zatwierdzające decyzje,
- dostępy potrzebne do pierwszych zadań,
- zależności oraz ich właściciele,
- sposób review i odbioru pracy.
Część późniejszych wymagań może pozostać otwarta, jeśli nie zmienia fundamentów pracy, która właśnie rusza.
Start z ostrożnością
Wybierz tę opcję, gdy zespół może zacząć, ale jeden lub kilka warunków mogą wpłynąć na zakres, kolejność albo termin.
Przykład: przegląd API zaplanowany na przyszły tydzień, treści potrzebne dopiero przed integracją albo decyzja interesariusza wymagana przed drugim etapem.
Samo zapisanie ryzyka nie wystarczy. Nadaj mu właściciela, termin i moment ponownej oceny. Jeśli warunek nie zostanie spełniony, zespół powinien wiedzieć, która praca się zatrzymuje.
Jeszcze nie startuj
Zatrzymaj projekt, gdy pierwsza sensowna praca zależy od czegoś niedostępnego albo nierozstrzygniętego.
Typowe sygnały:
- nikt nie może zatwierdzić oczekiwanego zachowania,
- brakuje repozytorium lub środowiska,
- dwa wymagania są ze sobą sprzeczne,
- krytyczna integracja nie ma właściciela,
- nie da się nazwać pierwszego rezultatu,
- odbiór zależy od nieustalonych kryteriów.
Koszt czekania powinien być widoczny. Tak samo jak koszt rozpoczęcia pracy, którą prawdopodobnie trzeba będzie wyrzucić.
Niewiadoma, ryzyko, zależność czy bloker?
Niewiadoma to brak informacji. Staje się istotna, gdy odpowiedź może zmienić podejście.
Ryzyko to możliwe zdarzenie o opisanym wpływie. Wymaga monitorowania lub ograniczenia, ale nie zawsze zatrzymania.
Zależność to wejście albo działanie poza bieżącym zadaniem lub zespołem. Potrzebuje właściciela i terminu.
Bloker to aktualny warunek, który uniemożliwia pracę lub konieczną decyzję. Trzeba go usunąć, obejść albo jawnie zaakceptować.
Lista blokerów przed developmentem pomaga ocenić szare strefy. Nie nazywaj blokerem każdej niewiadomej, bo prawdziwe blokery przestaną być widoczne.
Przetestuj pierwszy tydzień
Wyobraź sobie start w poniedziałek. Co zespół zrobi najpierw? Jakich kont, danych i decyzji będzie potrzebował do środy? Kto odpowie, gdy pierwsze założenie okaże się błędne?
Jeśli odpowiedzi są konkretne, projekt prawdopodobnie jest gotowy. Jeśli plan zaczyna się od „ustalimy, co właściwie budujemy”, jeszcze nie jest.
Po pozytywnej decyzji ustal sposób pracy i kolejne działania z checklistą kickoffu projektu. Jeżeli zespół ma już estymację, przelicz ją na realistyczny termin przed przedstawieniem planu jako zobowiązania.