Mina 02 - On-Site Customer albo Whole Team

Kolejną znaną praktyką, która dla mnie była źródłem wielu niespodzianek to było bezpośrednie zaangażowanie klienta w proces wytwórczy oraz transparencja tego procesu. Generalnie chodzi o to by klient był zaangażowany osobiście w projekt. Dotyczy to zarówno procesu analizy jak i spotkań statusowych, projektowych i innych.
Założenie jest takie, że jeśli klient będzie zaangażowany w aktywności niekoniecznie związane z jego odpowiedzialnością to i tak może mieć to dobry skutek, a jeśli do tego będzie uczestniczył w pracach jako żywa dokumentacja (patrz Mina 01) to będzie jeszcze lepiej, bo wtedy my będziemy mieli pewną i rzetelną wiedzę dostępną na zawołanie, a dodatkowo klient będzie się bardziej identyfikował z wytwarzanym produktem (jak to mój prezes dziś podsumował w postaci metafory zamku z piasku: "ta wieżyczka rzeczywiście jest krzywa, ale od tej fosy to Ty się odczep, bo ona jest moja"). Zespół i klient stanowią jedną zgraną i szczęśliwą rodzinę, żyją długo i mają dużo dzieci.
Ponadto według tej praktyki klient obecny na projekcie potrafi podjąć wiążące i ostateczne decyzje do co kształtu, zakresu i szczegółów funkcjonalności, które maja zostać wytworzone. A jeśli jest więcej niż jedna osoba jako "klient" to obowiązuje ich reguła, że przemawiają wspólnym głosem, tzn jeden nie zaprzecza drugiemu.

Tiaaa .... jassssne .. ;)

Zawsze przed dopuszczeniem klienta do tak bliskiej współpracy zadaje sobie pytania - wykrywacze min:

Czy ten klient nie wykorzysta informacji, które zdobędzie na temat zespołu, stylu pracy, efektywności i innych operacyjnych szczegółów firmy przeciw nam w przyszłości?
Call me paranoid, ale zdarzyło mi się, że klient podczas następnych negocjacji zaczął wyciągać na stół dane z których sobie wynioskował, że wcale tyle nie będzie nas to kosztować, bo zespół zrobi to tak i tak i cena ta jest zawyżona, bla bla bla, no i ręce nam opadły, a racji nie miał. No i teraz udowadniaj, że nie jesteś wielbłądem.


Czy klient posiada całą wiedzę jakiej zespół potrzebuje?
Po pierwsze bardzo często osobą najlepiej obeznaną w zawiłych procesach biznesowych, które ma wspierać tworzony system jest jakaś strasznie ważna dla klienta osoba, która oprócz tego projektu ma jeszcze 7 innych obowiązków od których zależy ciągłość biznesu klienta. Siłą rzeczy nie będziemy tej osoby mieli na każdy gwizdek w naszym pokoju, a o zafundowaniu jej biurka i przykuciu jej łańcuchem do niego to możemy sobie pomarzyć.

Z drugiej strony, jeśli dostaniemy inną osobę (mniej ważną), która będzie dla nas miała czas, to czy będzie ona miała całą potrzebną wiedzę? Wątpliwe, ale nawet jeśli tak, to czy będzie ta osoba odpowiednio decyzyjna w sprawach dwuznacznych, by móc na bieżąco podejmować decyzje projektowe, czy będzie musiała z każdą rzeczą latać wyżej albo chwytać za telefon do przyjaciela? Bo w tym przypadku historia informatyki pokazuje, że granie ciągle 50/50 nie sprawdza się zbyt dobrze...

Inaczej zadane pytanie może być tak: czy projekt ten dla klienta jest na tyle istotny by dedykował on do niego odpowiednio dużo (tzn tyle ile my potrzebujemy) czasu swoich kluczowych pracowników? Czy zdaje on sobie sprawę ze skutków tego, że nie będziemy mieli dostępu do takich osób?

Czy klient mówi jednym głosem?
W moim przypadku często było tak, że domena projektu była na tyle obszerna, że nasz klient był co najmniej 2-osobowy, czasem 3-5-osobowy. W takim przypadku kluczowe jest by klient wypowiadał się jednym spójnym głosem komunikując co jest do zrobienia i jak ma działać. Jakie było moje zdziwienie, gdy na jednym ze spotkań wieloosobowy klient zaczął się autentycznie kłócić ze sobą, popatrzeliśmy po sobie, czy przerwiemy im poczekamy ... poczekaliśmy kwadrans i skończyło się na tym, że daną kwestię wyjaśnią na następnym spotkaniu. Nie powiem, by to przyczyniało się do powodzenia projektu ...

W problemie przedstawionym powyżej klient sam się zaangażował w sprzeczkę i postanowił ją rozwiązać. Drugi problem, który spotkałem związany z "jednym głosem" jest podobny do poprzedniego, ale wg mnie znacznie gorszy. Zdarzało mi się lawirować pomiędzy nie rozmawiającymi ze sobą elementami "klienta" i otrzymywać od nich sprzeczne informacje na temat wymagań do konkretnej funkcji. I to często na zasadzie: nie obchodzi mnie co inni chcą, ale mój dział X jest krytyczny i to musi działać tak jak my tego potrzebujemy. I gdzie tu jest One Voice? One Noise jeśli już. I kto mi teraz powie, że informatyka to ścisła dyscyplina inżynieryjna... Nie wiem jak dla innych, ale dla mnie rozwiązywanie problemów klienta na takim poziomie jest dość angażujące i wyczerpujące, potrafi to skonsumować sporo energii i czasu, które mogłyby być skanalizowane o wiele bardziej produktywnie. Jest to klasyczny waste. Poza tym co ja jestem psychoterapeuta czy informatyk?

A może prawda jest taka, że każdy dobry informatyk powinien mieć też składaną (albo dmuchaną) leżankę na którą w odpowiedniej chwili zapraszałby klienta i pytał łagodnym tonem: opowiedz mi o swoich problemach..... Nie żebym strasznie się z tym czuł, ale nie pamiętam tego z rozmowy kwalifikacyjnej, ani też wielkim specjalistą w dziedzinie sie raczej nie czuje... ale może czas zrobić sobie wizytówkę Wojciech Biela - informatyk/psychoterapeuta


Podsumowując nie mówię, że jeśli na któreś z tych pytań nie potrafię odpowiedzieć, lub odpowiedź jest negatywna to nie zapraszam klienta "do środka", albo jak już jest to czymprędzej go wyganiam. Raczej jestem wtedy bardziej czujny, lub stosuję jakieś elementy minimalizujące dane ryzyko. Innymi słowy wchodzę na minę, ale wiedząc że po niej stąpam kroki stawiam ostrożnie i mam na sobie 50kg kevlaru i pełną zbroję płytową ...