Jak wymusić dowody i zakończyć dyskusję „wydaje mi się”?
W releasie nie chodzi o to, żeby “nie było błędów”. Chodzi o to, żeby decyzja o wdrożeniu była świadoma: wiesz, co jest bezpieczne, co jest ryzykiem, czego nie sprawdziliście i co zrobicie, jeśli coś pójdzie źle. Bez tego release to nie decyzja tylko zakład.
W tym artykule pokażę Ci prostą bramkę GO/NO-GO do skopiowania. Jest krótka celowo. Ma działać w firmie, która nie ma czasu na rozbudowane procesy, a mimo to chce przestać wypuszczać wersje myśląc, że wszystko działa, a później być rozczarowanym.
Problem
Decyzja release’owa w wielu firmach wygląda najczęściej tak:
- software house albo zespół mówi „przetestowaliśmy, działa”,
- ktoś z biznesu “przeklikał” najważniejsze ekrany mówi „działa”,
- a potem pada: „wdrażamy, bo musimy, nie mamy czasu”.
W praktyce to nie jest proces decyzyjny. To jest negocjacja pod presją terminu, w której wygrywa ten, kto mówi pewniej albo ma większą siłę przebicia.
Efekt jest przewidywalny:
- ryzyka nie są spisane,
- brak “not tested” jest ukryty (albo nikt go nie zna),
- a po releasie zaczyna się gaszenie pożaru i pytanie “czemu nikt nie zauważył”.
Koszt i ryzyko – co realnie tracisz
Zły release (albo release w złym momencie) kosztuje w pieniądzach, nawet jeśli nie masz łatwo policzalnej “sprzedaży”:
- Utracony przychód lub utracona konwersja
Gdy pada krytyczna ścieżka (logowanie, zapis formularza, publikacja, rezerwacja, zakup), tracisz użytkowników i to od razu, nikt nie lubi korzystać z czegoś co mu nie działa. - Koszt reakcji i przestój zespołu
Tryb awaryjny pożera czas developerów, producta, supportu i często osób decyzyjnych. - Koszty obsługi klienta i reputacji
Zgłoszenia, frustracja, odpływ użytkowników, negatywne opinie. - Ryzyko danych i zgodności
Błędy uprawnień, zgód i danych potrafią mieć konsekwencje większe niż “zwykły bug”. - Dług jakościowy
Jeżeli raz “przepchniesz” release bez dowodów, łatwo wejść w kulturę: “naprawimy po wdrożeniu”. To jest prosta droga do rosnących kosztów utrzymania.
Mini-model kosztu (wzór do podstawienia)
Koszt złego GO = (czas zespołu × stawki) + utracony przychód + koszt supportu + koszt komunikacji + koszt opóźnionych prac
Dlaczego to się dzieje
- Brak standardu dowodów
„Przetestowane” nie znaczy nic, jeśli nie wiadomo: co, jak, gdzie i czego nie. - Brak jawnego “not tested”
W każdym releasie coś jest odpuszczone. Problemem nie jest odpuszczenie. Problemem jest brak jawności. - Brak właścicieli ryzyk
Jeśli ryzyko nie ma ownera, to nikt nie będzie nim zarządzał. Będzie “czyjś problem” po releasie.
Rozwiązanie – 15 minut, 5 dowodów, jedna decyzja
To nie jest “proces QA”. To jest prosty mechanizm zarządczy.
Minimalny zestaw dowodów
- Krytyczne ścieżki + status (PASS/FAIL/NOT TESTED)
- Zakres testów (w punktach, bez wodolejstwa)
- Lista “NOT TESTED” (co świadomie odpuszczono)
- Top ryzyka (max 5, z ownerami)
- Minimalny plan awaryjny (kto/co/kiedy po wdrożeniu)
Jeśli te elementy nie istnieją, to nie masz podstaw do świadomego wdrożenia.
Jak to zweryfikować
(dowody, nie deklaracje)
Zamiast pytać “czy testowaliście?”, pytaj o konkret i oczekuj konkretnych artefaktów.
- Jakie są krytyczne ścieżki w tej wersji?
Dowód: lista 5–10 ścieżek + status. - Co dokładnie przetestowaliście?
Dowód: zakres w 5–10 punktach. - Co nie zostało przetestowane i dlaczego?
Dowód: lista NOT TESTED + powody. - Jakie są top ryzyka?
Dowód: tabela ryzyk + ownerzy. - Co robimy, jeśli po wdrożeniu wyjdzie błąd krytyczny?
Dowód: 1 strona minimalnego planu awaryjnego.
Jeśli nie da się tego zebrać w 24–48 godzin przed releasem, to sygnał, że release jest prowadzony “na wiarę”, a nie “na dowody”.
Do skopiowania
GO/NO-GO (15 minut)
Użyj przed każdym releasem.
A) Dowody (muszą istnieć)
- Krytyczne ścieżki spisane i mają status: TAK / NIE
- Zakres testów opisany (5–10 punktów): TAK / NIE
- Lista NOT TESTED jest jawna i zaakceptowana: TAK / NIE
- Top 5 ryzyk spisane i mają ownerów: TAK / NIE
- Minimalny plan awaryjny po wdrożeniu istnieje: TAK / NIE
Jeśli w A masz choć jedno “NIE”, decyzja domyślna to NO-GO, dopóki brak nie zostanie uzupełniony albo świadomie zaakceptowany jako ryzyko (z ownerem).
B) Krytyczne ścieżki (5–10)
- ____________________ PASS / FAIL / NOT TESTED
- ____________________ PASS / FAIL / NOT TESTED
- ____________________ PASS / FAIL / NOT TESTED
- ____________________ PASS / FAIL / NOT TESTED
- ____________________ PASS / FAIL / NOT TESTED
- ____________________ PASS / FAIL / NOT TESTED
- ____________________ PASS / FAIL / NOT TESTED
- ____________________ PASS / FAIL / NOT TESTED
C) Ryzyka (max 5)
| Ryzyko (konkretnie) | Wpływ (N/S/W) | Prawdopodobieństwo (N/S/W) | Co robimy teraz (mitigacja) | Owner |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 |
D) NOT TESTED (jawnie)
| Co nie było testowane | Dlaczego | Jakie ryzyko bierzemy | Owner ryzyka |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 |
E) Decyzja
- Decyzja: GO / NO-GO
- Jeśli GO: jakie warunki/bramki po wdrożeniu (np. monitoring, szybki rollback, gotowość zespołu)
- Jeśli NO-GO: co musi się wydarzyć, żeby zmienić decyzję
- Osoba odpowiedzialna za decyzję: ____________________
- Data/godzina: ____________________
Kopiuj-wklej: Mail do wykonawcy (dowody przed releasem)
Temat: Gotowości do releasu – {wersja/data}
Cześć,
zanim podejmiemy decyzję o wdrożeniu {wersja/data}, proszę o krótkie podsumowanie (max 1 strona):
- Lista krytycznych ścieżek dla tej wersji + status (PASS/FAIL/NOT TESTED)
- Zakres wykonanych testów (w punktach)
- Lista “NOT TESTED” – co nie było sprawdzane i dlaczego
- Top 5 ryzyk tej wersji + propozycja mitigacji + ownerzy
- Minimalny plan awaryjny na wypadek błędu krytycznego po wdrożeniu (kto/co/kiedy)
Chcemy mieć pewność, że jesteśmy gotowi wyjść z tym na świat, w tym celu potrzebne nam są ww. informacje. Dzięki.
Co zrobić jutro (plan na 60–90 minut)
- Skopiuj bramkę do dokumentu i nazwij ją “GO/NO-GO – szablon release”.
Rezultat: gotowy standard. - Zdefiniuj listę 5–10 krytycznych ścieżek produktu (uniwersalnych) i trzymaj ją jako bazę.
Rezultat: stała lista do aktualizacji per release. - Ustal zasadę: bez listy NOT TESTED nie ma “przetestowane”.
Rezultat: koniec ukrytych braków. - Ustal, kto jest ownerem ryzyk (nie “zespół”, tylko konkretna rola/osoba).
Rezultat: odpowiedzialność zamiast rozmycia. - Wyślij mail do wykonawcy z prośbą o 1 stronę dowodów.
Rezultat: dowody przed releasem. - Ustal minimalny plan awaryjny: kto reaguje po wdrożeniu i w jakiej kolejności.
Rezultat: mniejsze straty, gdy coś pójdzie źle. - Zrób pierwszą bramkę jeszcze przed najbliższym releasem nawet “na sucho”.
Rezultat: zespół nabiera nawyku i skracacie czas spotkania.
Sygnały ostrzegawcze
- „Nie mamy listy tego, co nie było testowane.”
- „Zrobiliśmy testy, ale nie mamy podsumowania.”
- „Krytyczne ścieżki? Wszystko jest krytyczne.”
- „Nie ma czasu na formalności.”
- „To mały change, nie ma sensu tego spisywać.”
- „Plan awaryjny? Jak coś wyjdzie, to poprawimy.”
To nie są złe intencje. To są sygnały braku kontroli.
Decyzja: GO / NO-GO
GO, jeśli:
- Krytyczne ścieżki mają status PASS (a wyjątki są jawne i świadomie zaakceptowane).
- Istnieje lista NOT TESTED oraz top ryzyka z ownerami.
- Jest minimalny plan awaryjny i wiadomo, kto reaguje po wdrożeniu.
NO-GO, jeśli:
- Zmiana dotyczy krytycznej ścieżki, a ta ma status FAIL albo NOT TESTED.
- Nie da się zebrać 1 strony dowodów (zakres + not tested + ryzyka).
- Ryzyka nie mają ownerów i nie ma planu awaryjnego (czyli nikt nie “trzyma” skutków).
Podsumowanie
Ten sposób nie da Ci dać gwarancji “będzie idealnie”. Ma Ci dać kontrolę: wiesz, co jest sprawdzone, co nie, jakie ryzyka bierzemy i kto je prowadzi. To jest różnica między releasem zarządzanym, a releasem na wiarę.
Źródła i dalsza lektura
- ISTQB – terminologia i fundamenty testowania
- ISO/IEC/IEEE 29119 – standard procesu testowania
- ISO/IEC 25010 – model jakości produktu
- DORA – metryki stabilnego dostarczania zmian
- Google SRE – incident management i reliability
- ITIL – change management i incident management