Czy klient musi wiedzieć, czego chce?

Wspólną bolączką ludzi z branży IT jest fakt, że klient nie wie, czego chce. Przygotowujemy oprogramowanie zgodnie z jego wytycznymi, a on kręci nosem, zmienia zdanie, czasem tupie nogą i nie chce odebrać tego, co zamówił. Czy czasami nie oczekujemy od niego zbyt wiele?

Klient nie wie, czego chce

I nic dziwnego. Przychodzi mi na myśl cała litania trudności:

• Wymagania nieuświadomione (coś jest tak oczywiste, że nikomu nawet nie przyjdzie do głowy o tym wspominać)
• Wymagania nieodkryte (niektóre rzeczy „wie się” dopiero, kiedy zobaczy się prototyp – okazuje się, że coś nie pasuje)
• Wymagania niewyspecyfikowane (jak klient ma powiedzieć o czymś, co może mieć wpływ na kształt czy działanie systemu, skoro o systemach nie ma zielonego pojęcia i nie wie, co jest ważne?)
• Różne punkty widzenia (jeśli klient ma wielu reprezentantów, kogo nie zapytasz, może powiedzieć Ci cos innego. Dziwne? Każdy ma swoją rolę. Dla jednego coś jest ważne, dla drugiego mogłoby nie istnieć)

Czego właściwie oczekujemy od klienta? Że wspinając się na szczyty swoich zdolności zapytamy: „Co mamy dla Ciebie zrobić?” a on powie, co mamy dla niego zrobić?

A Ty jakim jesteś klientem?

Pomyśl o sobie jak czegoś szukasz, coś kupujesz, zamawiasz usługę. Zawsze wiesz, czego chcesz, patrząc z perspektywy dziedziny, do której ta rzecz należy, choć się na niej nie znasz? Idziesz do fryzjera i mówisz w jakim miejscu jak powinny być przycięte czy pomalowane włosy. Nie ma prawa nie podobać Ci się efekt?
Wyobraź sobie, że chcesz odnowić pokój. Zamawiasz ekipę do urządzania wnętrz. Co ona może dla Ciebie zrobić? Może na dwa sposoby. Podejście 1:
Ktoś pyta: „To, co Pan chce tutaj?”. Mówisz, że zielone zasłony, szeroką kanapę i mega telewizor. Ekipa dostarcza zielone zasłonki, szeroką (ich zdaniem) kanapę i mega telewizor. Choćby było paskudnie, a kanapa utrudniała wyjście z pokoju – nie masz się co oburzać – wszystkie Twoje wymagania zostały spełnione.
Ja wolałabym podejście 2:
Przychodzi specjalista od projektowania wnętrz. Zna się na rzeczy, ma swoje sprytne sztuczki i techniki projektowania. Wypytuje mnie, jakie przeznaczenie ma mieć ten pokój, co będę robić i kiedy (odpoczywać, bawić dzieci, grać w Kinecta), czy moi współlokatorzy nie cierpią na otyłość, jakie są moje ulubione kolory, co robię zaraz po przyjściu do domu, gdzie kładę klucze, czy lubię podpierać nogi oglądając TV, itp. Jeśli moje zielone zasłony w obliczu tych potrzeb nie mają racji bytu, a wielka kanapa odetnie dostęp światła i przeszkodzi w wykonywaniu moich rutynowych czynności, chcę, żeby mi o tym powiedział i zaproponował coś lepszego. Chcę, żeby miał wizję całości i stworzył dla mnie efekt bliższy moim potrzebom niż wyrażonym życzeniom. Chciałabym, żeby zaskoczył mnie tym, jak dobrze odkrył to, czego sama nie potrafiłam wyartykułować. Nie znam się na projektowaniu wnętrz, skąd mam wiedzieć co jest dobre?

Czy Klient musi wiedzieć, czego chce?

Czego się spodziewamy? Że klient odwali za nas całą robotę i podsunie pod nos gotową specyfikację z algorytmami i bazą danych?
Wystarczy dobra specyfikacja? Skąd klient ma wiedzieć jak przygotować specyfikację?
Wystarczy, żeby wiedział, czego chce i nie zmieniał zdania? Zazwyczaj system to złożona rzecz. Wymagamy od klienta, żeby patrząc na jedną funkcję, w głowie przeprowadził proces syntezy całego rozwiązania i widząc je w wielu wymiarach, dał nam odpowiedź – jakie pola będą potrzebne. W kontekście, o jakim teraz myśli może to być A, B i C, ale potem nagle pojawia się kolejny temat, który okazuje się mieć wpływ na poprzedni (w systemie!) i dodaje się pole D. Czy on to mógł przewidzieć? Czasem tak, czasem nie…
Problem w tym, że system jest abstrakcją rzeczywistości. Upraszczamy skomplikowany świat do prostych modeli, które mają mnóstwo ograniczeń. Budujemy ten model ze struktur oprogramowania. Czy to wina klienta, że pewne zmiany burzą nasze misterne struktury? To my wybraliśmy model, który opisze jego świat. Dlaczego wybraliśmy akurat taki? Moglibyśmy przygotować dla niego wszystko! Gdybyśmy tylko wiedzieli, co jest ważne.

Czy my mamy wiedzieć za Klienta, czego on chce?

Absurd. Jesteśmy inżynierami, a nie wróżką (czy wróżbitą Maciejem)! Przecież z takim to jak z babą! „A może tak… A może inaczej… A może lepiej tak…”. Wiemy tylko to, co nam powie…
Możemy pomóc jemu (i sobie!) odkryć jego potrzeby. Nie będziemy wiedzieli lepiej od niego jak działa jego biznes, ale wiemy lepiej jak działa oprogramowanie. I co z w związku z tym? Od dekad ludzie wytwarzają oprogramowanie i wszyscy (którzy tworzą na zlecenie zewnętrznego klienta) napotykają te same wyzwania. Powstało już tyle technik przekładania potrzeb na wymagania systemowe, że nic, tylko z nich korzystać (np. http://www.babokonline.org/)! Ale do tego potrzebujemy szacunku do siebie nawzajem (biznes vs IT), uznania potrzeb klienta za ważne (za drogę do naszego wspólnego celu) i właściwego podziału odpowiedzialności.

Dochodzimy do realnych oczekiwań

Czego nie możemy oczekiwać od klienta?

• Wyspecyfikuje system, który spełnia jego potrzeby (sam z siebie poda kompletny zestaw wymagań).
• Powie nam o wszystkim, co może mieć wpływ na kształt i działanie systemu.
• Nie będzie zgłaszał zmian.
• Będzie podejmował słuszne (dobre dla siebie i projektu) decyzje akceptując ustalenia przedstawione w sposób nie do końca dla siebie zrozumiały (uniemożliwiający podjęcie świadomej decyzji i wzięcie odpowiedzialności za jej konsekwencje)

Czego powinniśmy oczekiwać od klienta?

• Powie nam o swoich potrzebach (celach biznesowych, firmie, procesach, produkcie – w zależności od tego jakie ma być przeznaczenie oprogramowania; jeśli mamy go dobrze zrozumieć, musi być hojny w dzieleniu się informacjami)
• Będzie mówił prawdę J
• Będzie mówił o wszystkim, co uzna za ważne (co on uzna!)
• Wymieni wszystkie systemy, z jakich korzysta (musi być tego świadomy)
• Opowie o wszystkich szczególnych przypadkach, na których istnienie nie mamy szans wpaść
• Zaangażuje ludzi, na których pracę (cele) wpłynie system (tych, których on uzna za ważnych!)

Czego nie możemy oczekiwać od siebie?

• Oświeci nas i domyślimy się, czego potrzebuje klient
• Jeśli klient wprowadzi nas w błąd (akceptując prototyp czy specyfikację), będziemy mogli temu zaradzić

Czego powinniśmy oczekiwać od siebie?

• Zadając odpowiednie pytania i uzyskując prawdziwe odpowiedzi dojdziemy do tego, czego potrzebuje klient:
• Zapytamy o cele
• Zapytamy o to, jak działa biznes klienta i to dobrze zrozumiemy (utrwalimy ważne procesy, ważne artefakty) – jeśli to oprogramowanie ma zinformatyzować działanie organizacji
• Zapytamy o produkt, grupę docelową, konkurencję, cechy przewagi rynkowej i inne marketingowe rzeczy – jeśli to oprogramowanie będzie związane z produktem/wizerunkiem
• Weźmiemy pod uwagę wszystkie istotne punkty widzenia (klienta, użytkowników, wszystkie osoby, które mają istotny wpływ na system lub system będzie miał istotny wpływ na nich)
• Prześledzimy wszystkie przypadki szczególne i dopytamy co robić w takich sytuacjach
• Zastanowimy się nad każdym wymaganiem w kontekście naszej wiedzy o IT – czy ma sens i czy nie można tego rozwiązać inaczej, lepiej

Pamiętajmy o jednym:
To my jesteśmy specjalistami od IT. To my powinniśmy wiedzieć jak technologia może pomóc klientowi.

Gdzieś pomiędzy nami…

Gdzieś pomiędzy nami znajduje się tajemniczy obszar (jak w grze zaczernione na mapie tereny, których jeszcze nikt nie odkrył). Ten obszar to potrzeby klienta. Nie jego życzenia, ale to, czego naprawdę potrzebuje. Niestety nie widać ich gołym okiem. Przejścia bronią złośliwe trolle, złe czary i brakujące zasoby.

Mamy misję. Musimy odkryć niewidoczne. Tylko kto się tego podejmie?