O czym rozstrzyga go/no-go
Go/no-go to moment, w którym biznes mówi: ta wersja CRM może trafić na produkcję w tym dniu. Albo mówi: jeszcze nie. To nie jest formalność na koniec testu. To powód, dla którego test został przeprowadzony.
Dobre go/no-go składa się z trzech części:
- Fakty. Co przetestowano, co przeszło, co jest nadal otwarte. Na podstawie wyników testów, a nie z pamięci.
- Ocena. Właściciele procesów mówią, czy mogą wykonywać swoją pracę w tej wersji i na jakich warunkach.
- Decyzja. Komitet sterujący waży fakty i oceny względem daty go-live i podejmuje decyzję.
Większości nieudanych spotkań go/no-go brakuje pierwszej części. Ludzie spierają się, jak poważne jest zgłoszenie albo czy proces w ogóle przetestowano, bo nikt nie ma liczb. Reszta tego poradnika dotyczy tego, jak zadbać o to, by fakty były na stole, zanim spotkanie się zacznie.
Kryteria wyjścia: uzgodnić je przed pierwszym dniem testowym
Kryteria wyjścia mówią, kiedy test jest wystarczająco dobry, by przejść do go-live. Należy je uzgodnić z komitetem sterującym przed pierwszym dniem testowym. Na końcu emocje są silne, a terminy bliskie. To zły moment, by decydować, co się liczy.
Kryteria, które sprawdzają się przy większości go-live CRM:
- Żadne zgłoszenie Critical nie jest otwarte.
- Każdy przypadek testowy Must zakończył się wynikiem pozytywnym.
- Każde otwarte zgłoszenie High ma obejście lub termin poprawki zaakceptowany przez biznes.
- Każdy przypadek testowy w zakresie ma wynik.
- Właściciel każdego procesu dał sign-off.
Uzgodnić znaczenie słów
Kryteria działają tylko wtedy, gdy wszyscy posługują się tą samą skalą. Należy zapisać, co oznacza każda waga, i udostępnić to zarówno testerom, jak i komitetowi sterującemu:
| Waga | Co oznacza |
|---|---|
| Critical | Kluczowy proces nie działa i nie da się go obejść albo dane są tracone lub błędne. Blokuje go-live. |
| High | Kluczowy proces działa tylko z obejściem albo zawodzi ważna funkcja. |
| Medium | Funkcja nie działa tak, jak powinna, ale istnieje rozsądne obejście. |
| Low | Kosmetyczne: tekst, układ, drobna niedogodność. |
To samo dotyczy priorytetu. Przypadek testowy oznaczony jako Must obejmuje to, co musi działać od pierwszego dnia, np. utworzenie oferty lub przekierowanie sprawy. Jeśli przypadek testowy Must nie przejdzie, go-live jest zagrożony. Jak ustalać priorytety, opisuje poradnik Przypadki testowe zrozumiałe dla testerów biznesowych.
Zapisać, czego się nie testuje
Każdy UAT coś pomija: kraj, który uruchamia system później, raport, który nie jest gotowy, integrację testowaną tylko w teście systemowym. Należy to spisać przed testem. Wtedy nikt na go/no-go nie powie, że zakładał, iż to zostało przetestowane.
Kto decyduje
Udział biorą dwie grupy osób, w różnych rolach.
Właściciele procesów dają sign-off
Dla każdego procesu lub grupy w teście sign-off daje jedna osoba z biznesu: dyrektor sprzedaży dla procesu od leada do płatności, kierownik obsługi klienta dla obsługi spraw, kierownik finansów dla fakturowania. Wiedzą, czego potrzebują ich zespoły, i to oni będą żyć z rezultatem. Ich sign-off oznacza: moi ludzie mogą wykonywać swoją pracę w tej wersji.
Należy ich wyznaczyć na początku projektu, a nie w ostatnim tygodniu. Właściciel procesu, który pierwszy raz widzi test na spotkaniu go/no-go, albo podpisze bez czytania, albo poprosi o kolejny tydzień.
Komitet sterujący decyduje
Komitet sterujący podejmuje decyzję dla całego go-live. Zwykle zasiadają w nim sponsor z biznesu, kierownik projektu, lider z IT oraz, przy partnerze wdrożeniowym, ktoś od partnera. Komitet waży to, czego pojedynczy właściciel procesu nie widzi: kończącą się umowę na stary CRM, plan szkoleń, weekend migracji, inne projekty w tym samym terminie.
Kierownik testów przygotowuje, ale nie decyduje
Kierownik testów przedstawia fakty i rekomendację. Kierownik testów nie daje sign-offu za biznes i nie podejmuje decyzji. Rozdzielenie tych ról sprawia, że decyzja się obroni, gdy po go-live coś pójdzie nie tak.
Raport: co powinien zawierać
Raport go/no-go jest dla osób, które nie uczestniczyły w teście. Powinien być krótki: jedna strona, ze szczegółami dla tych, którzy ich potrzebują.
- Rekomendacja. Go, go z warunkami lub no-go, z uzasadnieniem w jednym lub dwóch zdaniach.
- Zakres. Które procesy i user stories były objęte testem, a czego nie testowano.
- Co przetestowano. Środowisko, wydanie i build. Wynik dotyczy jednej wersji systemu.
- Liczby. Przypadki testowe zaliczone, niezaliczone, zablokowane i niedokończone.
- Dla każdej grupy lub procesu. Te same liczby, z sign-offem każdej grupy.
- Według priorytetu. Ile przypadków testowych Must, Should i Could przeszło i które przypadki testowe Must nie przeszły.
- Zgłoszenia według wagi. Ile jest otwartych, gotowych do ponownego testu i zamkniętych, z otwartymi zgłoszeniami Critical i High wymienionymi z nazwy.
- Sign-offy. Kto podpisał, kiedy, z jaką decyzją i z jakimi warunkami.
- Znane ryzyka. Obejścia, z których biznes będzie korzystał w pierwszych tygodniach, i kto je wspiera.
Raport należy wysłać dzień przed spotkaniem. Osoby, które przeczytają go w domu, zadają lepsze pytania.
W UAT StudioGo/no-go report na dashboardzie zawiera wskazanie (GO, GO with conditions lub NO-GO, z uzasadnieniem), liczby, postęp dzień po dniu, wyniki dla każdej grupy, epiki i priorytetu, zgłoszenia według wagi, otwarte zgłoszenia Critical i High z nazwy oraz każdy sign-off rundy. Wskazanie wynika ze stałych reguł i jest rekomendacją: decyduje komitet sterujący. Raport można udostępnić jako PDF lub pobrać jako slajdy do prezentacji dla komitetu sterującego.
Co zrobić z otwartymi zgłoszeniami
Na koniec UAT zawsze są otwarte zgłoszenia. Pytanie nie brzmi, czy jakieś są, ale czy każde z nich ma decyzję. Należy je przejrzeć przed spotkaniem, z biznesem i zespołem programistów, tak jak podczas codziennego triażu.
| Waga | Czego biznes potrzebuje przed go-live |
|---|---|
| Critical | Poprawione i ponownie przetestowane. Jeśli nie da się tego poprawić na czas, odpowiedź brzmi no-go albo proces wypada z go-live. |
| High | Poprawione albo obejście zaakceptowane przez właściciela procesu, z terminem poprawki. |
| Medium | Termin poprawki albo decyzja, by na razie z tym żyć. |
| Low | W backlogu. Nie jest powodem do czekania. |
Ostrożnie ze zmianą klasyfikacji
W ostatnich dniach pojawia się presja, by przenieść zgłoszenie Critical na High. Czasem to słuszne: znajduje się obejście albo okazuje się, że proces występuje rzadko. Należy to robić otwarcie, na triażu, z właścicielem procesu, i zapisać dlaczego. Nigdy po cichu, żeby liczby lepiej wyglądały. Właśnie tak go-live upada w pierwszym tygodniu.
Życzenia to nie defekty
Testerzy znajdują rzeczy, które chcieliby mieć inaczej. Jeśli system działa zgodnie z projektem, jest to wniosek o zmianę: trafia do backlogu, a nie do tego wydania, i nie liczy się przeciwko go-live.
W UAT StudioTriaż nadaje każdemu zgłoszeniu wagę, priorytet, osobę odpowiedzialną i decyzję: Fix, Reject lub Change request. Z modułem AI test design przycisk Summarize with AI na karcie Issues pisze krótkie podsumowanie otwartych zgłoszeń na spotkanie go/no-go: pogrupowane według tematu, z tym, co blokuje go-live. Bez modułu Summarize with your own AI daje prompt do wklejenia w firmowe AI.
Warunkowe go
Wiele go-live CRM dostaje go z warunkami. System jest wystarczająco dobry, pod warunkiem że coś zostanie zrobione przed go-live lub tuż po nim. To uczciwa decyzja, o ile warunki są prawdziwe.
Dobry warunek jest:
- Konkretny. Zatwierdzanie rabatu dla zamówień powyżej 50 000 jest poprawione i ponownie przetestowane, a nie zatwierdzenia działają.
- Przypisany. Odpowiada za niego jedna osoba, z imienia i nazwiska.
- Z terminem. Przed go-live albo z datą w pierwszych tygodniach po nim.
- Sprawdzony. Ktoś potwierdza, że został spełniony, a komitet sterujący się o tym dowiaduje.
Warto pilnować liczby warunków. Dwa lub trzy to norma. Piętnaście oznacza, że test nie jest skończony. Warunkowe go nie jest sposobem na uniknięcie no-go.
Go-live w częściach
Czasem jeden proces nie jest gotowy, a reszta tak. Można wtedy uruchomić system bez tego procesu albo z jednym krajem lub zespołem później. Należy to wyraźnie postanowić, zapisać nowy termin dla części, która czeka, i zaplanować dla niej osobną rundę UAT i sign-off.
Sign-off dla każdej grupy
Należy prosić o sign-off dla każdego procesu lub grupy, a nie o jeden podpis pod wszystkim. Dyrektor sprzedaży nie oceni obsługi spraw i nie powinien musieć. Każdy właściciel wybiera jedną z trzech odpowiedzi:
- Accepted: moi ludzie mogą wykonywać swoją pracę w tej wersji.
- Accepted with conditions: pod warunkiem spełnienia warunków. Każdy z nich należy zapisać, z tym, kto go realizuje i do kiedy.
- Rejected: nie jest wystarczająco dobre, by przejść do go-live. Warto zapytać, co zmieniłoby odpowiedź.
Sign-offy należy zebrać przed spotkaniem, aby komitet sterujący decydował na podstawie pełnego obrazu. Sign-off dotyczy jednej wersji: gdy pojawia się nowy build lub nowa runda testów, sign-off trzeba dać ponownie.
W UAT StudioKarta Sign-off na dashboardzie ma wiersz dla całego projektu i po jednym dla każdej grupy, z Accepted, Accepted with conditions lub Rejected. Zapisywane są data, godzina i liczba otwartych zgłoszeń Critical. Domyślnie nikt nie może zaakceptować, dopóki jest otwarte zgłoszenie Critical; przy zaznaczonej opcji No sign-off while Must test cases have not passed akceptacja czeka też, aż przejdzie każdy przypadek testowy Must. Odrzucić można zawsze. Sign-off dotyczy bieżącej rundy.
Prowadzenie spotkania go/no-go
Spotkanie należy zaplanować razem z dniami testowymi, z terminem w kalendarzu komitetu sterującego. Warto zarezerwować godzinę. Typowy przebieg:
- Kierownik testów pokazuje raport: zakres, liczby, otwarte zgłoszenia, sign-offy. Dziesięć minut, z liczbami na ekranie.
- Każdy właściciel procesu mówi w jednym lub dwóch zdaniach, dlaczego podpisał tak, a nie inaczej, i jakie ma warunki.
- Pytania o otwarte zgłoszenia Critical i High: czy jest poprawka, obejście, termin?
- Pytania wykraczające poza test: szkolenia, migracja danych, wsparcie w pierwszych tygodniach, plan wycofania.
- Decyzja: go, go z warunkami lub no-go. Odczytana na głos, z warunkami, osobami odpowiedzialnymi i terminami.
Jeśli decyzja brzmi no-go, spotkanie należy zakończyć planem: co musi się zmienić, nowa runda testów i termin kolejnego go/no-go. No-go z planem to zwykła decyzja projektowa. No-go bez planu odbierane jest jak porażka.
Rejestr decyzji
Decyzję należy zapisać tego samego dnia. Kilka miesięcy później, po incydencie lub podczas audytu, ktoś zapyta, kto zdecydował o go-live z tym otwartym zgłoszeniem. Znalezienie odpowiedzi powinno zająć minutę.
Rejestr decyzji zawiera dla każdego go/no-go:
- Datę i uczestników spotkania.
- Decyzję: go, go z warunkami lub no-go.
- Każdy warunek, z osobą odpowiedzialną, terminem i, później, datą realizacji.
- Otwarte zgłoszenia zaakceptowane przez biznes, z uzasadnieniem.
- Raport, na podstawie którego podjęto decyzję, w postaci z tamtego momentu.
Rejestr należy przechowywać z dokumentacją projektu, a warunki monitorować w pierwszych tygodniach po go-live, aż każdy zostanie spełniony.
W UAT StudioSave snapshot w raporcie go/no-go zachowuje raport w postaci z chwili podjęcia decyzji; nie zmienia się on już, a Show otwiera go ponownie później. Każdy sign-off pozostaje w historii, także te zastąpione lub wycofane. Dla audytora administratorzy pobierają Evidence pack: raport, przypadki testowe, wyniki i zgłoszenia, historię każdego zgłoszenia, każdy sign-off i dziennik audytu, z sumą kontrolną każdego pliku.
Do bezpłatnego użytku
Kryteria wyjścia, sign-off i raport są też w checkliście UAT na go-live CRM, jako bezpłatny plik Excel. Cały test opisują poradniki do UAT Salesforce i UAT Dynamics 365.