„Skończone” jest w projekcie najbardziej zdradliwym słowem, jakie znam.

Nie dlatego, że ktoś kłamie. Prawie nigdy nie kłamie.

Dlatego, że każdy rozumie je inaczej, a nikt tego nie sprawdza, dopóki nie zrobi się za późno.

Jak to wygląda w praktyce

Wyobraź sobie zadanie, które w piątek zostaje zgłoszone jako gotowe.

Developer ma na myśli: kod napisany, działa u mnie, wypchnięty. I to jest uczciwa odpowiedź, bo w jego świecie to jest cała robota.

Tester ma na myśli coś innego: przetestowane, defekty zamknięte, potwierdzone na środowisku, które przypomina produkcję.

Klient ma na myśli jeszcze coś innego: mogę tego użyć w poniedziałek rano.

Trzy różne rzeczy, jedno słowo. Nikt nie skłamał ani razu.

A Ty na statusie zapisujesz „gotowe”, bo dostałeś dokładnie tę odpowiedź, o którą pytałeś.

Dlaczego to się pogłębia, zamiast samo naprawiać

Tu jest część, która mnie kiedyś zaskoczyła.

Można by pomyśleć, że po pierwszej takiej wpadce zespół dogaduje się raz na zawsze i temat znika. W praktyce dzieje się odwrotnie: granica tego, co uznajemy za skończone, przesuwa się w dół, i przesuwa się cicho.

Mechanizm jest prosty i całkowicie ludzki. Termin naciska, więc raz odpuszczamy testy wydajnościowe, bo „to i tak przejdzie”. Potem raz odpuszczamy dokumentację, bo „dopiszemy po odbiorze”. Potem raz oddajemy funkcję bez obsługi błędów, bo „to przypadek brzegowy”.

Każde z tych odstępstw z osobna jest rozsądne. Każde ma dobre uzasadnienie w tym konkretnym tygodniu.

Po kwartale „skończone” znaczy coś zupełnie innego niż na początku, a nikt nie pamięta momentu, w którym to się zmieniło, bo nie było takiego momentu. Były trzy rozsądne wyjątki.

I wiesz co? To jest ten sam dług, o którym mówi się przy kodzie, tylko zaciągnięty na definicji, a nie na architekturze. Też trzeba go będzie któregoś dnia spłacić, tylko spłaca się go zwykle w tygodniu przed odbiorem.

Definition of Done istnieje, tylko nie tam, gdzie trzeba

Zanim ktoś napisze mi w komentarzu, że przecież mamy Definition of Done: mamy.

Scrum Guide opisuje ją jako formalny opis stanu, w którym przyrost spełnia wymaganą jakość, i jako coś, co ma tworzyć wspólne rozumienie tego, jaka praca została ukończona. To jest dobre narzędzie i nie zamierzam go podważać.

Problem jest gdzie indziej i widzę go w każdym projekcie, który przejmuję po kimś.

Definition of Done zwykle istnieje na poziomie zespołu, a decyzje o odpuszczaniu zapadają na poziomie pojedynczego zadania. Wisi na Confluence, spisana pół roku temu, ogólna i słuszna. A rozmowa, w której naprawdę zapada „to wystarczy”, brzmi tak: „słuchaj, oddajmy to bez tego raportu, dopiszemy w przyszłym sprincie”.

Nikt w tej rozmowie nie otwiera Confluence.

Druga rzecz, mniej oczywista: definicja jest napisana z perspektywy tego, kto robi, a nie tego, kto odbiera. „Kod przeszedł review” jest zdaniem o naszym procesie. „Klient może wystawić fakturę w poniedziałek” jest zdaniem o rzeczywistości.

Tylko drugie z nich da się zweryfikować bez wiary.

Co robię zamiast tego

Jedna rzecz, nudna, zajmuje mniej niż pięć minut.

Przy każdym większym elemencie zakresu piszę jedno zdanie: co konkretnie będzie prawdą, kiedy to będzie skończone. Jedno zdanie, w czasie przyszłym dokonanym, opisujące świat, a nie naszą robotę.

Nie „zrobimy integrację z magazynem”, tylko „magazynier zobaczy stan po zamknięciu dnia bez wchodzenia do drugiego systemu”.

Nie „przygotujemy raport”, tylko „dyrektor otworzy raport w poniedziałek rano i zobaczy w nim dane z piątku”.

To zdanie idzie tam, gdzie żyje zadanie, a nie na osobną stronę z definicjami. Ma być widoczne w tym samym miejscu, w którym ktoś klika „gotowe”.

Dwie rzeczy, które to zdanie robi od razu:

Po pierwsze, rozmowa o odpuszczaniu przestaje być bezkosztowa. Trudno powiedzieć „oddajmy bez raportu”, kiedy obok stoi zdanie „dyrektor otworzy raport w poniedziałek”. Nadal można tak zdecydować, tylko teraz to jest decyzja, a nie przeoczenie.

Po drugie, wychodzą braki, o których nikt nie wiedział. Zdanie o magazynierze bardzo szybko prowadzi do pytania, czy on w ogóle ma do czego się zalogować, a to jest pytanie, które zwykle zadajemy w ostatnim tygodniu.

Jak zapytać, żeby dostać prawdziwą odpowiedź

Przestałem pytać „czy skończone”.

Pytam: „czego jeszcze brakuje, żeby ktoś mógł tego użyć?”.

Różnica jest większa, niż wygląda, i działa dokładnie dlatego, że nie wymaga od nikogo przyznania się do niczego. Pierwsze pytanie każe człowiekowi ocenić samego siebie i domyślną odpowiedzią jest „tak, skończone”. Drugie pytanie zakłada, że coś jeszcze zostało, więc odpowiedź „nic” jest mocnym zdaniem, które trzeba świadomie wypowiedzieć.

Ludzie mówią wtedy rzeczy, których wcześniej nie mówili. Nie dlatego, że je ukrywali, tylko dlatego, że nikt nie stworzył miejsca, w którym pasowały do pytania.

Po czym poznasz, że działa

Po jednej rzeczy i przychodzi ona po kilku tygodniach.

Zaczynasz słyszeć „prawie” zamiast „tak”. „Prawie, brakuje jeszcze eksportu”. To jest zdrowy projekt: ktoś oddaje Ci różnicę między stanem faktycznym a docelowym, zamiast oddawać Ci samopoczucie.

Zły sygnał jest równie wyraźny. Wszystko jest na zielono do tygodnia przed terminem, a potem w ciągu trzech dni czerwienieje połowa. To nie jest awaria z tamtego tygodnia, tylko rachunek za kwartał drobnych odpuszczeń.

Jedna uczciwa uwaga na koniec

To nie jest technika, która naprawia projekt bez terminu, bez ludzi i bez decyzji.

Jest natomiast tania i można ją wprowadzić w środku trwającego projektu, bez zgody kogokolwiek i bez zmiany procesu. Jedno zdanie przy każdym większym elemencie zakresu, w miejscu, w którym ludzie i tak pracują.

Sprawdź to na najbliższym zadaniu, które ktoś zgłosi jako gotowe. Zapytaj, czego brakuje, żeby ktoś mógł tego użyć.

Jest spora szansa, że usłyszysz coś, czego nie było w statusie.

Zebrałem takie ruchy w PM Crisis Toolkit: dwanaście gotowców dla project managera, który wszedł w projekt na późnym etapie albo dostał go po kimś. Bez metodyki, bez wdrożenia, do użycia w tym tygodniu.

A Ty jak wyłapujesz różnicę między „skończone” a „skończone”? Ciekawi mnie zwłaszcza, czy robisz to na spotkaniu, czy pisemnie.

Wszystkie sytuacje opisane w tym tekście są oparte na autentycznych zdarzeniach, ale nie zawierają nazw firm, nazwisk ani danych konkretnych projektów.