Decyzja projektowa jest kompletna dopiero wtedy, gdy można odtworzyć jej treść, powód, właściciela i skutki. Sam wpis „ustalono na spotkaniu” nie wystarcza: po miesiącu uczestnicy mogą inaczej pamiętać warunki, a nowa osoba nie będzie wiedziała, dlaczego odrzucono pozornie lepszy wariant.
Rejestr decyzji nie musi być ciężkim procesem. Jedna krótka karta powiązana z wymaganiami jest bardziej użyteczna niż wielostronicowy protokół, w którym wybór ginie między wypowiedziami uczestników.
Co warto uznać za decyzję
- wybór wariantu procesu, rozwiązania lub integracji;
- akceptację wyjątku, ryzyka albo długu;
- ustalenie definicji biznesowej lub źródła danych;
- zmianę zakresu, priorytetu czy kryterium odbioru;
- świadome odłożenie funkcji albo rezygnację z niej;
- zatwierdzenie założenia, które wpływa na koszt lub zachowanie produktu.
Nie każda informacja jest decyzją. Pytanie otwarte, hipoteza i działanie powinny mieć odrębne typy. W przeciwnym razie zdanie „sprawdzić możliwość logowania SSO” może zostać błędnie odczytane jako zatwierdzenie SSO.
Minimalny wzór karty decyzji
| Pole | Co zapisać |
|---|---|
| ID i tytuł | Stały identyfikator oraz jednoznaczna nazwa wyboru |
| Status | Proponowana, zatwierdzona, zastąpiona albo wycofana |
| Kontekst | Problem, ograniczenia i moment, w którym potrzebna była decyzja |
| Decyzja | Jedno zdanie opisujące przyjęty wariant i warunki |
| Rozważane warianty | Najważniejsze alternatywy, także „nie zmieniać” |
| Uzasadnienie | Kryteria, dane, kompromisy i zaakceptowane ryzyka |
| Właściciel i data | Osoba z mandatem oraz data zatwierdzenia |
| Wpływ | Procesy, wymagania, komponenty, testy i komunikacja do aktualizacji |
Przykład: źródło adresu klienta
DEC-017 — adres do wysyłki umowy. Status: zatwierdzona 14.06 przez właścicielkę procesu obsługi klienta. Kontekst: CRM i system zamówień przechowują różne adresy, a integracja wymaga jednego źródła. Decyzja: dla nowej umowy używamy adresu wskazanego i potwierdzonego w zamówieniu; adres z CRM służy wyłącznie jako podpowiedź. Warianty: zawsze CRM, zawsze zamówienie, blokada przy rozbieżności. Uzasadnienie: klient może legalnie wskazać inny adres, a blokada opóźniałaby 18% spraw. Ryzyko: literówka w ręcznie wpisanym adresie; ograniczamy je walidacją kodu i ekranem potwierdzenia. Wpływ: REQ-42, model danych zamówienia, API wysyłki, scenariusze akceptacji AC-42.3–42.6.
Taki zapis wyjaśnia programiście źródło wartości, testerowi przypadek rozbieżności, a przyszłemu właścicielowi produktu — dlaczego system nie blokuje procesu. Nie trzeba odtwarzać całej historii mailowej.
Gdzie przechowywać rejestr
Najlepsze miejsce to takie, które jest dostępne dla zespołu, wersjonowane i możliwe do powiązania z backlogiem lub dokumentacją. Może to być tabela na stronie projektowej, osobny typ zgłoszenia albo pliki ADR dla decyzji architektonicznych. Narzędzie ma mniejsze znaczenie niż jedno źródło prawdy i stałe identyfikatory.
Nie kopiuj pełnej decyzji do kilku dokumentów. W wymaganiu umieść odnośnik do DEC-017, a w rejestrze listę elementów objętych wpływem. Kopie szybko się rozchodzą i ponownie tworzą problem, który rejestr miał rozwiązać.
Zmiana decyzji bez przepisywania historii
Decyzje mogą się zdezaktualizować po zmianie prawa, danych albo architektury. Nie usuwaj starej karty. Oznacz ją jako zastąpioną, utwórz nową i dodaj wzajemne odnośniki. Dzięki temu wiadomo, jakie założenie obowiązywało przy wcześniejszych wymaganiach i dlaczego później je zmieniono.
Zmiana powinna uruchomić analizę wpływu. Sprawdź procesy, wymagania, interfejsy, testy, instrukcje oraz dane już przetworzone według starej reguły. Samo zakomunikowanie nowego wyboru na czacie nie aktualizuje produktu.
Antywzorce dokumentowania
- Protokół bez konkluzji: zapisuje przebieg rozmowy, ale nie wiadomo, co zatwierdzono.
- Anonimowe „biznes zdecydował”: brakuje osoby z mandatem i możliwości potwierdzenia.
- Decyzja bez kontekstu: po zmianie warunków nikt nie wie, czy nadal obowiązuje.
- Uzasadnienie „bo tak ustaliliśmy”: uniemożliwia ocenę kompromisu.
- Nadpisywanie historii: ukrywa wpływ zmiany na wykonane już prace.
- Rejestr bez aktualizacji: daje fałszywe poczucie pewności.
Poziomy decyzji i adekwatna forma zatwierdzenia
Decyzja o kolorze pomocniczego komunikatu nie wymaga tego samego procesu co wybór źródła danych finansowych. Warto sklasyfikować wpływ. Decyzje lokalne i łatwo odwracalne może zatwierdzać zespół w backlogu. Decyzje przekrojowe, kosztowne albo regulacyjne powinny mieć formalnie wskazanego właściciela, analizę wariantów oraz zapis zaakceptowanego ryzyka.
Przydatne jest pole „data ponownego przeglądu”. Stosuj je, gdy wybór zależy od czasowego ograniczenia, prognozy wolumenu albo eksperymentu. Przykładowo zespół może świadomie przyjąć ręczną obsługę do 500 spraw miesięcznie, pod warunkiem ponownej oceny po przekroczeniu 400.
Rejestr może również wskazywać delegację: kto rekomenduje, kto konsultuje, a kto zatwierdza. Zapobiega to zarówno blokowaniu drobnych spraw przez komitet, jak i zatwierdzaniu istotnego ryzyka przez osobę bez mandatu. Zakres uprawnień warto uzgodnić na początku projektu.
Checklista dobrej decyzji projektowej
- Treść jest jednym jednoznacznym zdaniem.
- Kontekst opisuje problem i obowiązujące ograniczenia.
- Wskazano realnie rozważane warianty.
- Uzasadnienie pokazuje dane, kryteria i kompromisy.
- Właściciel ma mandat do zatwierdzenia wyboru.
- Status i data są aktualne.
- Wpływ prowadzi do konkretnych wymagań, procesów i testów.
- Zmiana decyzji zachowuje historię i uruchamia analizę wpływu.
Ustal również oczekiwany czas zapisu. Decyzję o dużym wpływie najlepiej zarejestrować tego samego dnia i potwierdzić przed rozpoczęciem zależnej pracy. Starsze ustalenia odtworzone wyłącznie z pamięci warto oznaczyć jako rekonstrukcję i ponownie zweryfikować z właścicielem, zamiast nadawać im pozorną pewność. Pozwala to odróżnić wiarygodny ślad od późniejszej interpretacji.
Decyzje powstające podczas spotkania warto rozdzielić od pytań i działań zgodnie z poradnikiem jak prowadzić ustalenia po warsztacie. Jeśli wybór dotyczy rozwiązania, najpierw upewnij się, że zespół oddzielił je od potrzeby biznesowej.
