Trzeci raz w tym samym miejscu. Warsztat o zakresie, druga godzina, i ktoś z biznesu rzuca: "a dlaczego właściwie zamówienia od partnerów idą osobnym procesem?". Cisza. Kierownik projektu pamięta, że to było ustalone. Architekt pamięta, że sam się przy tym upierał. Nikt nie pamięta dlaczego. Więc dyskusja rusza od zera, z tymi samymi argumentami co dwa miesiące wcześniej, tylko z innym składem na sali i z mniejszą cierpliwością.
Znam tę scenę z wielu projektów i za każdym razem kosztuje to samo: godzinę ludzi, którzy mogliby robić coś innego, plus ryzyko, że tym razem decyzja wyjdzie inna, bo argumenty z pierwszej rundy zostały w głowie kogoś, kto akurat jest na urlopie. Lekarstwo jest nudne i tanie. Rejestr decyzji projektowych. Jedna tabela, prowadzona konsekwentnie, która zamienia "wydaje mi się, że ustaliliśmy" na "ustaliliśmy, oto zapis".
Pokażę Ci, czym ten rejestr jest, a czym nie jest, jak wygląda minimalny szablon, który da się utrzymać, i jak go prowadzić, żeby zadziałał w sporze, nie dopiero w audycie.
Czym jest rejestr decyzji, a czym nie jest
Rejestr decyzji (decision log) to lista rozstrzygnięć, które zmieniają kształt projektu: co wchodzi w zakres, jak rozumiemy pojęcie, którą z opcji wybieramy i na jakich warunkach. Każdy wpis odpowiada na cztery pytania: co postanowiliśmy, dlaczego, kto to postanowił i co z tego wynika dla reszty roboty.
Łatwiej zrozumieć go przez to, czym nie jest, bo najczęściej myli się go z czterema innymi artefaktami.
Nie jest protokołem ze spotkania. Protokół opisuje przebieg: kto był, o czym mówiono, jakie padły zadania. Decyzja bywa w nim jednym zdaniem w trzecim akapicie i ginie po tygodniu. Rejestr wyciąga ją z protokołu i daje jej własne miejsce.
Nie jest backlogiem. Backlog mówi, co mamy zrobić. Rejestr mówi, dlaczego robimy to tak, a nie inaczej. Historyjka "obsłuż zamówienia partnerskie osobnym procesem" to element backlogu. Wpis "zamówienia partnerskie idą osobnym procesem, bo mają inny cykl rozliczeń; rozważaliśmy wspólny proces z flagą kanału i odrzuciliśmy go" to element rejestru.
Nie jest rejestrem ryzyk. Ryzyko to coś, co może się wydarzyć. Decyzja to coś, co już postanowiliśmy. Łączą się: decyzja bywa odpowiedzią na ryzyko, a ryzyko bywa skutkiem decyzji. Ale trzymanie ich w jednej tabeli kończy się tym, że nikt nie wie, co jest faktem, a co obawą.
Nie jest wnioskiem o zmianę wymagań. Zmiana zakresu to osobny proces z własną ścieżką oceny i akceptacji, opisałem go we wpisie o zarządzaniu zmianą wymagań. Rejestr decyzji jest dla niej pamięcią: zatwierdzona zmiana kończy się wpisem, a odrzucona też, bo "nie" jest równie ważną decyzją jak "tak".
Dlaczego decyzje giną
Nie giną dlatego, że ludzie są niedbali. Giną dlatego, że zapadają w miejscach, które nie są stworzone do ich przechowywania.
Pierwsze takie miejsce to głowa. Decyzja zapada w rozmowie przy kawie albo w kuluarach po warsztacie, dwie osoby się zgadzają, obie wracają do biurek. Po miesiącu jedna z nich odchodzi z projektu i decyzja idzie razem z nią.
Drugie to wątek na komunikatorze. Ktoś zadaje pytanie, po czterdziestu wiadomościach pada "ok, róbmy tak". Za trzy tygodnie nikt nie znajdzie tego "ok", bo wyszukiwarka czatu nie rozumie, że to była decyzja, a nie jedna z czterdziestu opinii.
Trzecie to notatka ze spotkania, której nikt nie czyta. Formalnie wszystko jest udokumentowane, tylko że dokumentacja, do której nikt nie wraca, działa jak dokumentacja, której nie ma.
I czwarte, najbardziej podstępne: decyzja zapadła, ale każdy zapamiętał ją trochę inaczej. Biznes pamięta "zgodziliśmy się na osobny proces", IT pamięta "zgodziliśmy się sprawdzić, czy osobny proces ma sens". Spór wraca z naddatkiem, bo tym razem każdy czuje, że druga strona łamie ustalenie.
Rejestr załatwia wszystkie cztery przypadki tym samym ruchem: decyzja dostaje jedno miejsce i jedno brzmienie, z konkretną osobą przy nim.
Minimalny szablon, który da się utrzymać
Widziałem rejestry na dwadzieścia kolumn. Nikt ich nie prowadził dłużej niż miesiąc. Poniżej zestaw pól, bez których wpis nie działa, i ani jednego więcej.
| Pole | Po co jest |
|---|---|
| Identyfikator | Żeby móc powiedzieć "patrz D-14" w rozmowie, w historyjce i w słowniku |
| Data | Kiedy decyzja zapadła (nie kiedy ją wpisano) |
| Decyzja | Jedno, dwa zdania w trybie oznajmującym. "Robimy X", nie "rozważamy X" |
| Kontekst / problem | Jakie pytanie trzeba było rozstrzygnąć i dlaczego akurat teraz |
| Rozważane opcje i co odrzucono | Minimum dwie opcje. Przy każdej odrzuconej: dlaczego odpadła |
| Uzasadnienie | Dlaczego wybrana opcja wygrała. To pole czyta się w sporze najczęściej |
| Kto zdecydował | Konkretna osoba albo rola z mandatem, nie "zespół" |
| Konsekwencje / wpływ na wymagania | Które wymagania, procesy albo pojęcia się zmieniają |
| Status | Obowiązuje / uchylona / zastąpiona przez D-nn |
| Link do artefaktów | Notatka, model procesu, historyjka, hasło w słowniku |
Trzy uwagi do tej tabeli.
Pole "co odrzucono" jest ważniejsze, niż wygląda. Gdy spór wraca, wraca zwykle w postaci "a może jednak zrobić to inaczej". Jeśli w rejestrze stoi, że "inaczej" było rozważane i dlaczego odpadło, dyskusja skraca się do jednego pytania: czy coś się od tamtej pory zmieniło.
Pole "kto zdecydował" musi wskazywać kogoś z mandatem. Decyzja podjęta przez "zespół analityczny" w sprawie, która należy do właściciela procesu, nie jest decyzją. Jest propozycją, która przy pierwszym konflikcie zostanie zakwestionowana. Kto ma mandat do czego, ustala się wcześniej, na poziomie governance wymagań.
Status "zastąpiona" jest lepszy niż kasowanie. Stary wpis zostaje, dostaje odnośnik do nowego i po roku wciąż widać, jak projekt zmieniał zdanie i dlaczego.
Jak to prowadzić na co dzień
Szablon to połowa. Druga połowa to procedura i to ona zwykle pada.
Kiedy powstaje wpis. W ciągu jednego dnia roboczego od decyzji, nie na koniec sprintu. Wpis po tygodniu jest już rekonstrukcją, a nie zapisem. Jeśli prowadzisz warsztat, wpisy szkicuj w jego trakcie, na oczach uczestników. Wtedy sala widzi brzmienie decyzji i ma szansę zaprotestować, zanim rozejdzie się do domu z własną interpretacją.
Kto pisze. Analityk, bo i tak stoi najbliżej wymagań i najszybciej zobaczy, które z nich decyzja zmienia. W zespołach bez analityka rolę bierze osoba prowadząca spotkanie, byle była jedna.
Jak potwierdzić z decydentem. Wpis szkicujesz Ty, ale słowa mają być jego. Wysyłasz brzmienie decyzji i uzasadnienie do osoby z pola "kto zdecydował" z jednym pytaniem: czy tak to rozumiesz. Odpowiedź "tak" zamyka wpis. Odpowiedź "prawie, ale..." jest najcenniejszą rzeczą, jaką rejestr daje, bo wyłapuje rozjazd interpretacji dzień po decyzji, a nie miesiąc po niej.
Jak wiązać z wymaganiami. Każdy wpis, który zmienia wymaganie, zostawia ślad w obie strony: w rejestrze jest identyfikator wymagania, w wymaganiu jest identyfikator decyzji. Jeśli prowadzisz macierz śledzenia wymagań, decyzje są w niej naturalnym elementem, bo odpowiadają na pytanie "skąd to wymaganie w ogóle się wzięło".
Jak wiązać ze słownikiem. Zaskakująco wiele decyzji to decyzje o znaczeniu słów: kogo liczymy jako "aktywnego klienta", kiedy zamówienie jest "zrealizowane". Taka decyzja zmienia hasło w słowniku, a hasło dostaje odnośnik do wpisu. Jak zbudować słownik pojęć w projekcie, opisałem osobno; tu wystarczy zasada: definicja bez decyzji za sobą jest opinią.
Przegląd przy zmianie zakresu. Każdy wniosek o zmianę zaczyna się od przejrzenia rejestru: które decyzje ta zmiana narusza? Ta lista jest połową analizy wpływu. Druga połowa to wymagania i procesy, ale bez pierwszej łatwo uchwalić zmianę, która po cichu odwraca coś, o co dwa miesiące wcześniej toczył się ciężki bój.
Trzy wpisy z typowego projektu
Wyobraź sobie typowy projekt: firma handlowa wdraża nowy system obsługi zamówień, a sprzedaż detaliczna i sprzedaż przez partnerów mają dziś osobne procesy. Tak mogłyby wyglądać trzy wpisy z jej rejestru.
D-07 Decyzja: zamówienia od partnerów są obsługiwane osobnym procesem, z własnym statusem rozliczenia. Kontekst: pierwotny model zakładał jeden proces dla wszystkich kanałów. W warsztacie z działem rozliczeń wyszło, że partnerzy rozliczają się zbiorczo raz w miesiącu, a klienci detaliczni od razu. Opcje: (a) jeden proces z flagą kanału, odrzucona, bo status "opłacone" znaczyłby co innego dla każdego kanału; (b) osobny proces, wybrana. Uzasadnienie: jedno pojęcie, jedno znaczenie. Kosztem są dwa procesy do utrzymania, ale to mniej niż koszt niejednoznacznego statusu w raportach. Zdecydował: właściciel procesu sprzedaży partnerskiej. Wpływ: wymagania W-31 do W-36 rozdzielone na dwa zbiory; hasło "zamówienie opłacone" w słowniku dostało dwa warianty. Status: obowiązuje.
D-12 Decyzja: "aktywny klient" oznacza klienta z co najmniej jednym zrealizowanym zamówieniem w ostatnich dwunastu miesiącach. Kontekst: marketing i sprzedaż liczyli aktywnych klientów inaczej i raporty się nie zgadzały. Opcje: sześć miesięcy (propozycja marketingu), dwanaście (propozycja sprzedaży), dowolne zamówienie bez ograniczenia czasu (odrzucone od razu przez obie strony). Uzasadnienie: dwanaście miesięcy pokrywa sezonowość branży; sześć wycinało klientów, którzy kupują raz w roku. Zdecydował: dyrektor sprzedaży, po konsultacji z marketingiem. Wpływ: definicja w słowniku, raport R-04, warunek segmentacji w wysyłkach. Status: obowiązuje.
D-19 Decyzja: rezygnujemy z automatycznego anulowania zamówień nieopłaconych po dwóch dobach. Kontekst: D-09 wprowadziła automatyczne anulowanie. Po analizie procesu partnerskiego (D-07) wyszło, że partnerzy z natury płacą później. Opcje: (a) wyjątek dla partnerów, odrzucona, bo komplikuje proces, który celowo trzymaliśmy prostym; (b) wydłużenie terminu dla wszystkich, odrzucona, bo w detalu automat traci sens; (c) rezygnacja z automatu na rzecz przypomnienia, wybrana. Zdecydował: sponsor projektu. Wpływ: W-42 usunięte, W-43 zmienione na przypomnienie o płatności. Status: obowiązuje; zastępuje D-09 (D-09 dostaje status "zastąpiona przez D-19").
Zwróć uwagę na D-19. To ten moment, w którym rejestr zarabia na siebie: widać, że decyzja zapadła po wcześniejszych, widać, co odrzucono i dlaczego, i nikt za pół roku nie zapyta "a czemu właściwie zrezygnowaliśmy z anulowania".
Typowe błędy
Rejestr jako sąd nad ludźmi. Jeśli pole "kto zdecydował" zaczyna służyć do wskazywania winnych, ludzie przestaną podejmować decyzje albo zaczną je podejmować "zespołowo", czyli anonimowo. Rejestr ma odpowiadać na pytanie "dlaczego tak", nie "przez kogo źle". Kiedy decyzja okazała się zła, wpisujesz nową, ze statusem "zastępuje", i tyle.
Wpisy po fakcie. Rejestr uzupełniany przed audytem albo pod koniec fazy to fikcja. Daty zgadzają się z kalendarzem, uzasadnienia są dopisane z pamięci i wygładzone, odrzuconych opcji brak, bo nikt ich nie pamięta. Taki rejestr wygląda dobrze i nie działa.
Brak odrzuconych opcji. Wpis "wybraliśmy X" bez "rozważaliśmy też Y i Z" to najczęstszy sposób, w jaki spór wraca. Bo za trzy miesiące ktoś zaproponuje Y i będzie to brzmiało jak świeży pomysł.
Decyzja bez właściciela. "Ustalono na spotkaniu" nie jest właścicielem. Przy pierwszym konflikcie ktoś powie "ja się na to nie zgadzałem" i będzie miał rację, bo nikt nie wie, kto się zgadzał.
Rejestr wszystkiego. Jeśli wpisujesz kolor przycisku, rejestr rozrasta się do rozmiarów, przy których nikt go nie czyta. Kryterium wejścia: decyzja zmienia zakres, znaczenie pojęcia, sposób realizacji wymagania albo została podjęta wbrew czyimś oczekiwaniom. Reszta idzie do backlogu albo do notatki.
A co z ADR w zespołach technicznych
Jeśli pracujesz blisko deweloperów, pewnie spotkałeś Architecture Decision Records. To ten sam pomysł zastosowany do decyzji architektonicznych: krótki dokument na jedną decyzję, z kontekstem, opcjami i konsekwencjami, trzymany w repozytorium obok kodu. Rejestr trzyma decyzje biznesowe i zakresowe, ADR trzyma decyzje o tym, jak je technicznie zrealizować, a wpis w jednym linkuje do drugiego. Nie próbuj sklejać ich w jeden dokument, bo mają innych czytelników i inny rytm zmian.
Rejestr w sporze: trzeci raz w tym samym miejscu
Wróćmy do sceny z początku. Warsztat, druga godzina, pytanie o osobny proces dla partnerów. Tym razem na stole leży rejestr.
Nie mówisz "to już było ustalone", bo to zdanie zamyka rozmowę i otwiera urazę. Mówisz: "Wracamy do tego trzeci raz. Mam zapis D-07: osobny proces, bo rozliczenie zbiorcze raz w miesiącu, opcja z flagą odrzucona z takiego a takiego powodu, zdecydował właściciel procesu. Pytanie na dziś: co zmieniło się od tamtej pory?".
I wtedy dzieje się jedna z dwóch rzeczy. Albo nic się nie zmieniło i dyskusja kończy się w trzy minuty, bo argumenty leżą na stole, a nie w czyjejś pamięci. Albo coś się zmieniło: partnerzy przeszli na rozliczenia bieżące i założenie z uzasadnienia przestało być prawdziwe. Wtedy spór jest zasadny i kończy się nową decyzją, D-27, z odnośnikiem do D-07 i statusem "zastępuje".
W obu przypadkach rozmowa toczy się o faktach, a nie o tym, kto co pamięta, a spór o sprzeczne oczekiwania dwóch stron, jeśli w ogóle się zaczyna, startuje od zapisanego stanu wyjściowego. Jak rozstrzygać takie spory na poziomie kryteriów, a nie hierarchii, rozpisałem we wpisie o sprzecznych wymaganiach. Rejestr jest tym, co sprawia, że rozstrzygnięcie nie wraca za miesiąc.
Zacznij od jednego projektu i pięciu wpisów z decyzji, które już zapadły i które pamiętasz najlepiej. Potwierdź je z decydentami. Jeśli choć jedna osoba odpisze "prawie, ale...", rejestr właśnie zapobiegł sporowi, którego jeszcze nie było.
Decyzje to jedno ogniwo w cyklu życia wymagania, od źródła po wdrożenie. Jeśli chcesz sprawdzić, jak dobrze widzisz cały ten łańcuch, zrób test z cyklu życia wymagań i traceability. Jest publiczny i nie wymaga zakładania konta.