Często do projektów wkrada się stwierdzenie, że coś jest oczywiste, przez co wymagania klienta przyjmują postać niepełną, opartą o założenia czy to programisty, czy analityka, czy projektanta. W projekcie nie ma miejsca na założenia odnośnie wymagań. One muszą istnieć, muszą przybrać najdokładniejszą w miarę możliwości postać i co więcej muszą zostać zatwierdzone przez Klienta.
W metodyce Prince2 zaleca się tworzenie dla każdego produktu jego opisu. Opis Produktu, bo tak nazywa się ten dokument, definiuje przeznaczenie produktu, jego wygląd, kryteria jakości i inne. Za to jak opisany jest produkt odpowiada Główny Użytkownik (jedna z ról Komitetu Sterującego, Główny Użytkownik jest wskazany przez środowisko Klienta). Dokument powstaje w procesie Zarządzania Zakresem Etapu, czyli przed tym, jak rozpocznie się wytwarzanie produktu. Dokument ten jest bardzo istotny, ponieważ na jego podstawie zespół produkt tworzy, tester testuje i weryfikuje zgodność jego wykonania z opisem znajdującym się w dokumencie a Klient na jego podstawie produkt odbiera.
Ok. wszystko wydaje się jasne. Tylko co robić w przypadku, kiedy klient płaci i wymaga, ale nie za bardzo wie czego?
Jeśli Klient nie zdefiniuje jakby chciał, żeby produkt końcowy działał i wyglądał szanse, że trafimy w jego gusta są prawie zerowe. Czerwona lampka powinna zapalić się zawsze kochany Kierowniku Projektu, kiedy przychodzi do Ciebie programista i pyta, wskazując palcem na monitor "jak to ma wyglądać". Analityk u klienta co prawda był, udało mu się wyciągnąć "jakieś" informacje, więcej nie wyciągnie, a te są tak ogólne... No cóż, musimy zgadywać... Stop ! Nigdy nie zgaduj. Wyślij znowu analityka do Klienta, niech pyta i drąży, bo nikt inny, tylko Klient może nam na to pytanie odpowiedzieć. Niech podsunie mu przykładowe rozwiązania, służy pomocą i dobrą radą, pokaże przykłady, prototypy, ale pamiętaj: niech nie podejmuje za niego decyzji, tylko Klient ma prawo do zdefiniowania Opisu Produktu.
Najlepiej już na początku projektu uświadomić odbiorcy, że to on jest odpowiedzialny za zdefiniowanie Opisu Produktu. Nie jest to proste zadanie, bo wiąże się z przekazaniem odpowiedzialności, a każdy ma opory przez braniem jej na siebie.
Co się dzieje gdy nie ma wymagań ? Ostatnio oddawaliśmy etap projektu, do którego mieliśmy tylko wymagania ogólne i dostaliśmy jasną informację od Odbiorcy, że niestety, ale bardziej szczegółowo nie jest w stanie opisać, co by chciał. Podjęliśmy decyzję, że będziemy jako zespół brać udział w spotkaniach projektowych, w których będziemy podejmować wspólnie decyzję odnośnie tego, jak rezultat ma wyglądać. Na spotkaniach nie było Odbiorcy.
Podczas oddawania etapu Klient zaczął posługiwać się zdaniami : "to jest źle", "kto to zaakceptował?", "ja takiego produktu nie odbiorę", "czy w ogóle przemyśleliście to?", "wasz produkt" itd. Pomijając fakt, że takie sformułowania są zabójcą motywacji w zespole i wpływają bardzo negatywnie na morale, na nasze pytania "to jak ma być?" padała odpowiedz "nie wiem, wy coś wymyślcie".
Jakie z tego wynikły problemy:
- Nadal nie wiedzieliśmy, jak funkcjonalności mają działać / wyglądać
- Zostaliśmy obciążeni brakiem zdecydowania Klienta
- Zespół był zły, bo został skrytykowany bezpodstawnie
- Straciliśmy czas, bo to co zostało zrobione okazało się nie tym, co chciał Klient
- Klient nadal nie rozumiał, że problem nie tkwi w ludziach, ale w tym, że nie ma wymagań i tylko on je może opisać, bez tego będziemy tak zgadywać w nieskończoność
Wtedy ostatecznie i bezwzględnie zdecydowaliśmy, że Klient musi wyznaczyć osobę odpowiedzialną za definiowanie wymagań a przede wszystkim musi zrozumieć, że nikt nie umie czytać w myślach i tylko on może produkt opisać. Nie było łatwo, ciągle pojawiały się sformułowania typu: "nie ma takiej abstrakcyjnej osoby", "nie wiem" i inne. Ostatecznie stanęło na tym, że będziemy do każdej funkcjonalności po uprzednim spotkaniu uzgadniającym jej zakres przygotowywać dokument do akceptacji Klienta, przy czym pomożemy Klientowi w uzgodnieniu tego zakresu poprzez prototypowanie i przykłady. Zaakceptowany dokument nie może być zmieniany, wszelkie zmiany zakresu przez niego opisanego muszą przejść przez procedurę zarządzania zmianą.
Klient na prawo wymagać, my mamy prawo wiedzieć czego wymaga.
