Projekt B2B umiera na UAT

Co naprawdę testuje UAT

Formalnie UAT sprawdza, czy oprogramowanie spełnia wymagania. Realnie sprawdza coś zupełnie innego: czy model danych, który zbudowaliście, opisuje firmę klienta.

Przez trzy miesiące zespół pracował na wyobrażeniu tej firmy - zbudowanym z warsztatów, dokumentów i zdań typu „mamy standardowe cenniki". W UAT do systemu wchodzi zaopatrzeniowiec ze swoim prawdziwym zamówieniem i okazuje się, że cennik nie jest standardowy, bo dla trzech kontrahentów obowiązuje umowa ramowa z zeszłego roku, której nikt nie wspomniał, bo „to oczywiste".

To nie jest testowanie. To jest konfrontacja modelu z rzeczywistością - i pierwszy moment, kiedy w ogóle jest ona możliwa.

Dlaczego dwa tygodnie to fikcja

Dwa tygodnie wystarczą na znalezienie literówek. Nie wystarczą na to, co się faktycznie dzieje.

Bo zgłoszenia z UAT dzielą się na te, które da się naprawić w dzień, i te, które oznaczają zmianę modelu. Te drugie nie mieszczą się w harmonogramie z definicji - jeśli okazuje się, że jeden kontrahent może mieć dwa różne cenniki zależnie od oddziału, to nie jest poprawka. To jest przeprojektowanie relacji w modelu danych, migracja tego, co już wgrane, i retest wszystkiego.

I jeszcze jedno: klient w UAT uczy się systemu i formułuje wymagania jednocześnie. Człowiek, który pierwszy raz widzi swój proces w oprogramowaniu, dopiero wtedy zauważa, że jego proces wygląda inaczej, niż go opisał. To nie jest zła wola. To jest normalne i przewidywalne - i dlatego powinno być w harmonogramie.

Trzy typy zgłoszeń i tylko jeden jest bugiem

Rozdzielenie tych trzech kategorii w pierwszym tygodniu UAT ratuje projekt. Wrzucenie ich do jednego backlogu go zabija.

Bug. Miało działać, nie działa. Naprawiasz, idziesz dalej. To zwykle mniejszość zgłoszeń, mimo że wszyscy nazywają tak wszystko.

Luka w modelu. Miało działać inaczej, bo rzeczywistość jest inna niż założenie. To jest zmiana zakresu, nawet jeśli klient zgłasza to jako bug - i to jest uczciwa rozmowa do odbycia od razu, a nie w trzecim tygodniu poślizgu.

Życzenie. „A dałoby się jeszcze...". Zawsze się pojawia, bo system nagle stał się realny. Odkładasz do rejestru zmian i wracasz po starcie.

Konflikt, który zabija projekty, bierze się stąd, że klient nazywa wszystkie trzy „błędami", a zespół wszystkie trzy „zmianami zakresu". Prawda leży pomiędzy i trzeba ją rozstrzygać zgłoszenie po zgłoszeniu, w tygodniu pierwszym, a nie w atmosferze sporu o termin.

Jak przesunąć ten ból wcześniej

Nie da się uniknąć konfrontacji modelu z rzeczywistością. Da się ją przesunąć na moment, w którym jest tania.

Prawdziwe dane od pierwszego sprintu. Nie dziesięć produktów testowych - realny wycinek katalogu i realni kontrahenci z ich prawdziwymi cennikami. Większość luk w modelu widać już przy trzeciej kartotece, a nie przy trzytysięcznej.

Dziesięciu najtrudniejszych klientów jako kryterium projektowe. Jeśli model obsługuje tych dziesięciu, obsłuży resztę. Jeśli projektujesz pod „typowego" klienta, UAT znajdzie ci wszystkie nietypowe naraz.

Mapowanie danych jako osobny etap z własnym terminem, a nie zadanie w tle. Rozbieram to w tekście o mapowaniu danych.

I rzecz najprostsza, a najrzadziej robiona: zaproś do UAT tego zaopatrzeniowca, który będzie z tego korzystał codziennie, a nie kierownika, który podpisze protokół. Kierownik zaakceptuje. Zaopatrzeniowiec powie, dlaczego to nie zadziała - i to jest jedyna informacja, po którą tam przyszliście.

Jak spiąć to z terminem startu, opisałem w planie cutover.

Co dalej

• Mapowanie jako osobny etap: Mapowanie danych
• Jak spiąć to z terminem startu: Plan cutover
• Model, który UAT weryfikuje: Cenniki kontraktowe