Bezpańskie wymagania

Pamiętam pierwszą zaskakującą lekcję o wymaganiach.

Wyciągnęłam pieczołowicie przygotowaną moją pierwszą specyfikację wymagań. Zebraliśmy wymagania przez wywiad z klientem – inicjatorem projektu stworzenia nowego systemu zarządzania siecią w akademikach. A teraz byliśmy tu – na konsultacjach w gabinecie profesora wykładającego inżynierię wymagań na Politechnice Gdańskiej, aby wydał werdykt.

Z zapałem pokazywałam efekt naszej pracy. Ukradkiem rozejrzałam się po pokoju tego szanowanego człowieka. Zobaczyłam wiele książek, dokumentów i zdjęcie 4-letniej pewnie wnuczki w stroju motyla.

Nieco rozluźniło to atmosferę. Jednak nadal z napięciem wyczekiwałam na ocenę naszej pracy. I wtedy, 11 lat temu, profesor powiedział coś, na co niemal spadłam z krzesła:

– Ja nie wiem czy to są dobre wymagania.

Jak to możliwe, że profesor nie wie? Jakim cudem? Po co w takim razie te konsultacje?

– Tylko klient może Wam powiedzieć czy to dobre wymagania. Ja tylko mogę sprawdzić czy przygotowaliście je w odpowiedniej formie.

Zgłupiałam. Łomot burzonego poczucia pewności. 

Jak to profesor nie może powiedzieć? Przychodzę na konsultacje do najbardziej szanowanego człowieka na katedrze, profesora inżynierii oprogramowania i on nie wie czy mam dobre wymagania?

I to była najmądrzejsza rzecz, która wryła mi się w mózg. Nie jesteś właścicielem swoich wymagań. Nie możesz powiedzieć czy one są dobre. Twój kolega z zespołu też nie może. Ani manager. Ani profesor.

Tylko właściciel, źródło wymagania wie, czy wymaganie jest dobre. 

W procesie inżynierii wymagań mamy weryfikację wymagań, czyli sprawdzenie, czy są one poprawnie napisane, zgodne ze standardami, zrozumiałe dla wykonawców, jednoznaczne, kompletne dla testerów, itd.

Inną rzeczą jest walidacja wymagań. Odpowiada ona na pytanie, czy wymaganie jest właściwe, czy odpowiada na potrzebę, czy jeśli dostarczymy rozwiązanie spełniające to wymaganie, to rozwiążemy problem. Tego nie wie profesor. To wie właściciel wymagania.

Wszędzie widzę jak w IT próbujemy sami sobie napisać wymagania, sami siebie poklepać po plecach, sami sobie odebrać rozwiązanie. I myślimy, że tak jest OK.

Manager wymyśla wymagania. Product owner wymyśla wymagania niepoparte potrzebą klienta, regulacjami, ani strategią. Zespół wymyśla wymagania, choć odbiorca, beneficjent, klient nie został w to włączony.

Czasem klient wewnętrzny jest 2 minuty od Twojego biurka albo w odległości 2 maili czy 2 minut rozmowy na komunikatorze.

Bez punktu odniesienia – potrzeby klienta, celu biznesowego, problemu, jaki rozwiązujesz, Twoje wymagania są nic niewarte. Są przypadkowe. Wymyślone. 

To nie jest inżynieria. To chaos. Niedbałość. Niekompetencja. To robienie na odwal czegoś, za co pobierasz pieniądze.

Kiedy jesteś już na tym etapie, że prosisz klienta o walidację wymagań, objawia się szereg innych problemów. Ktoś się zgadza, ale nie wie, co mówi. Każdy człowiek mówi coś innego. Ludzie mówią swoje, a regulacje swoje. Ale to już inna historia.