Cel nauki: odróżnić warunkową akceptację kierunku architektonicznego od zgody na uruchomienie usługi oraz zamienić każdy warunek w sprawdzalne zobowiązanie: właściciel, dowód, weryfikator i bramka decyzyjna.

Fikcyjny scenariusz edukacyjny. Zespół przeglądowy akceptuje projekt pod dwoma warunkami: trzeba wykazać skuteczne odebranie dostępu użytkownikowi i odtworzyć kompletną ścieżkę usługi po awarii. Protokół kończy się zdaniem „dział IT potwierdzi spełnienie warunków”. Zespół wdrożeniowy traktuje to jako zielone światło. Nikt nie uzgodnił, kto przeprowadzi próby, kto oceni wyniki i co stanie się, jeśli test się nie powiedzie. To przykład modelowy, nie opis zdarzenia w konkretnej organizacji.

Trzy warianty, trzy różne konsekwencje

WariantCo zyskujemyCo ryzykujemy
A. Akceptujemy bez zastrzeżeń, a warunki wpisujemy do listy zadań.Szybki start.Nie ma punktu, w którym brak dowodu zatrzyma wdrożenie; zadanie może zostać uznane za wykonane na podstawie deklaracji.
B. Wstrzymujemy każdą pracę do zamknięcia obu prób.Nie pomylimy niepewności z potwierdzeniem.Blokujemy także prace niezależne od testów; rośnie koszt oczekiwania.
C. Akceptujemy warunkowo określony zakres, ale nie zwalniamy bramki uruchomieniowej bez dowodów.Można prowadzić odwracalne prace równolegle, zachowując kontrolę ryzyka.Trzeba utrzymywać rejestr warunków i jasno wskazać osobę uprawnioną do decyzji o przejściu bramki.

W tym scenariuszu wybieramy C, o ile brakujące dowody nie podważają samej wykonalności architektury. Akceptacja kierunku, dopuszczenie do realizacji i dopuszczenie do uruchomienia mogą być trzema różnymi decyzjami. Nie należy ich zastępować jednym statusem „zatwierdzone”.

Warunek musi mieć kontrakt wykonania

Przy każdym warunku zapisz sześć pól: co ma być prawdą, kto odpowiada za spełnienie, jaki artefakt jest dowodem, kto sprawdza i akceptuje dowód, przed jaką bramką oraz co robimy przy wyniku negatywnym. Termin i identyfikator decyzji pomagają w śledzeniu, ale nie zastępują kryterium akceptacji.

Warunek i kryteriumWłaściciel wykonaniaDowód i weryfikatorBramka
Odebranie dostępu: po unieważnieniu uprawnień nie można wykonać chronionej operacji także przy aktywnej wcześniej sesji.Właściciel mechanizmu tożsamości.Protokół próby pozytywnej i negatywnej; weryfikuje osoba odpowiedzialna za kontrolę bezpieczeństwa.Przed dopuszczeniem użytkowników.
Odtworzenie usługi: po kontrolowanej awarii da się wykonać uzgodnioną ścieżkę użytkownika, a nie tylko uruchomić bazę.Właściciel ciągłości usługi.Raport ćwiczenia z wynikiem, ograniczeniami i odstępstwami; weryfikuje odpowiedzialny za gotowość operacyjną.Przed uruchomieniem produkcyjnym.

To przykładowy podział ról, a nie uniwersalny regulamin. Koordynator przeglądu pilnuje spójności decyzji i eskalacji, ale nie staje się automatycznie właścicielem mechanizmu, wykonawcą testu ani osobą przyjmującą ryzyko. Ostatnia decyzja należy do roli wskazanej przez rzeczywisty ład organizacji.

Jak zapisać decyzję, żeby dało się ją wykonać?

Przykładowy zapis decyzji: „Akceptujemy kierunek architektury do prac odwracalnych. Nie upoważnia to do uruchomienia usługi. Przed bramką uruchomieniową właściciele dwóch kontroli dostarczą uzgodnione wyniki prób; wyznaczeni weryfikatorzy potwierdzą zgodność z kryteriami. Brak dowodu lub wynik negatywny oznacza status warunek otwarty i powrót do osoby uprawnionej do decyzji: poprawa projektu, ponowienie próby albo jawna decyzja o zmianie zakresu. Nie ma milczącej akceptacji”.

Minimalny przebieg to propozycja → akceptacja warunkowa → dowód i weryfikacja → decyzja o przejściu bramki. W rejestrze zachowaj wersję decyzji, datę, otwarte warunki i odnośniki do artefaktów. Nie zmieniaj statusu na „zamknięty” tylko dlatego, że minął termin albo wykonawca oznaczył zadanie jako ukończone.

Kiedy C nie jest dobrym wyborem?

Jeżeli nie wiadomo, czy kluczowy mechanizm jest w ogóle możliwy, warunek może unieważnić cały projekt. Wtedy nie zatwierdzaj nawet kierunku, którego sens zależy od wyniku: zleć eksperyment lub dowód wykonalności i wróć do wariantów. Z kolei drobne usprawnienie nie powinno automatycznie blokować uruchomienia; oznacz je jako pracę następczą z właścicielem i terminem. Granicę wyznacza skutek niespełnienia warunku, a nie siła sformułowania w protokole.

Twoja decyzja — dwie minuty

Właściciel dostarczył zrzut ekranu „test zakończony”, lecz nie ma opisu scenariusza negatywnego. Termin uruchomienia przypada jutro. Czy koordynator może zamknąć warunek? Nie na podstawie samego zrzutu. Najpierw trzeba porównać dowód z kryterium, uzyskać ocenę wyznaczonego weryfikatora i pozostawić bramkę zamkniętą albo skierować odstępstwo do osoby uprawnionej do przyjęcia ryzyka. Sam koordynator nie powinien zastępować tej decyzji.

Powiązania: ADR — zapis decyzji i konsekwencji; Scenariusz jakościowy — kryterium sprawdzalne; Practice — granice odpowiedzialności; Antywzorzec — rozwiązanie tymczasowe bez decyzji wyjścia. Ostatnie dwa materiały dotyczą innych sytuacji, ale ćwiczą pokrewne rozróżnienie odpowiedzialności i warunków.

Źródła pierwotne (sprawdzone 13.10.2026): Oficjalny przewodnik po procesie ADR — kontekst, decyzja, konsekwencje, status i właściciel; FAQ procesu ADR — odpowiedzialność za utrzymanie decyzji; Publiczna metodyka oceny kontroli bezpieczeństwa i prywatności — planowanie i ocena dowodów kontroli. Sześciopolowy kontrakt warunku, warianty A–C i przykłady są autorską syntezą edukacyjną; źródła nie ustanawiają obowiązkowego procesu zatwierdzania architektury dla każdej organizacji.