Ogólnym podejściem wskazywanym przy wdrażaniu czy przepisywaniu systemów jest:
- Najpierw określ stan AS IS (jak jest teraz)
- Potem określ stan TO BE (jak ma być)
- A potem przygotuj plan przejścia z AS IS do TO BE
W dzisiejszym odcinku chciałbym skupić się na owym AS IS. Zdefiniowanie stanu/procesu AS IS wydaje się oczywiste - ot, wystarczy zapytać klienta jak jest - to jednak sprawia więcej trudności, niż można by przypuszczać.
Klient i tak powie to, co chce
Zanim klient podjął decyzję, żeby Ciebie albo firmę, w której pracujesz wynająć, musiało się wydarzyć sporo rzeczy. Jego obecna sytuacja tzn. oprogramowanie, z którego korzysta, aby prowadzić swoją działalność, sprawiło mu sporo problemów. Jest tym zirytowany, podobnie jak zirytowani są jego współpracownicy. Z drugiej strony może być również mocno nakręcony nowymi możliwościami, które widzi na rynku.
Wszystko powyższe sprawa, że Twoi rozmówcy chętniej będą mówili o tym, "jak ma być", niż o tym "jak jest". Całą tajemnicę skutecznego zadawania pytań można zamknąć w jednym zdaniu: Ludzie nie odpowiadają na pytania, lecz mówią to, co chcą powiedzieć. Pamiętaj o tym, a nie zgubisz się w żadnej rozmowie. Zatem:
- co jakiś czas pytaj rozmówcę Czy mówisz teraz o tym jak jest, czy jak ma być?
- zadawaj powyższe pytanie zwłaszcza, gdy pojawiają się tzw. "wodotryski" ???? tzn. klient nagle zaczyna generować kolejne pomysły;
- staraj się zachować elegancką równowagę w rozmowie - z jednej strony pozwól rozmówcy nieco się "wygadać", z drugiej strony nieustannie wracaj do raz zadanego pytania, aby w końcu uzyskać na nie odpowiedź;
- używaj fizycznych rzeczy do skupienia uwagi np. karteczek, na których zapisywane są kolejne informacje, wirtualnej tablicy, na której wszyscy pracujecie, dokumentu, który wspólnie edytujecie, diagramów i modeli, ale tylko wtedy, gdy rozmówcy potrafią je czytać.
Myślicie inaczej
Każdy myśli inaczej - wiadomo. Jednak moja obserwacja jest następująca: klient - zwłaszcza ten nietechniczny - gdy opowiada o swoich oczekiwaniach, wyświetla w swojej głowie coś jakby pokaz slajdów. Przynajmniej ja w ten sposób wyobrażam sobie proces myślowy takiego klienta. Ty natomiast zaczynasz budować w swojej głowie rozwiązanie. Zaczynasz zastanawiać się nad konkretnymi komponentami, obmyślasz interfejsy, itd.
W pewnym momencie nagle Twój rozmówca wyrzuca jeden slajd ze swojego mentalnego slide decka, a potem równie nagle zmienia kolejność innych slajdów. Twoje rozwiązanie się wtedy rozsypuje. Wyobrażenie rozwiązania, które pieczołowicie zbudowałeś/aś w swojej głowie, jest już nieaktualne, ponieważ rozmówca zmienił swoje "slajdy".
Gdy definiujesz stan AS IS, to ma być AS IS. Jeśli zaczynasz - nawet tylko w swojej głowie - kombinować nad rozwiązaniem, to już jest stan TO BE. Źle! Najpierw określ: jak jest - AS IS.
[mailerlite_form form_id=1]
Wstydliwe tematy
W każdej firmie istnieją tematy wstydliwe. Aby funkcjonować Twój klient używa różnego rodzaju oprogramowania. Przeważnie jest to kilka, kilkanaście systemów wpiętych w różne etapy procesów biznesowych klienta. Bywa, że czasem te procesy trzeba popchnąć ręcznie :) To są właśnie wstydliwe tematy - wszystko to, co dzieje poza oficjalnie zdefiniowanymi procesami. Dla zilustrowania zjawiska podam Ci klika przykładów owych tematów wstydliwych:
- wykonywanie przelewów unit testami;
- drukowanie raportu z jednego systemu po to, aby wprowadzić go ręcznie w innym;
- ręczne resetowanie serwera guzikiem, aby przyśpieszyć jego działanie;
- robienie w Excelu tego, co mógłby robić istniejący system, ale liczba licencji jest ograniczona i trzeba czekać, aż ktoś jakąś zwolni.
Słowem: życie. Prawie napewno pozbycie się wstydliwych tematów będzie jednym z istotnych celów Twojej pracy. Zatem musisz je zidentyfikować i opisać. Żeby jednak na poźniejszych etapach opracować rozwiązanie, najpierw musisz opisać te wstydliwe tematy takimi, jakie są obecnie - AS IS.
Tematy klamkowe
W rozmowach z klientem istnieje jedno zjawisko, które przyprawia o łzy każdego wykonawcę. Są to "tematy klamkowe". Wygląda to tak, że kilkugodzinny warsztat właśnie się zakończył, wszyscy się zbierają i wychodzą. Klient również wychodzi i gdy łapie za klamkę, nagle coś mu się przypomina, odwraca się i mówi: *Panie Michale czy moglibyśmy jeszcze...". W miejscu kropek pojawia się wtedy nowe oczekiwanie, które wywraca do góry nogami ustalenia z zakończonego właśnie spotkania. Jak nic "temat klamkowy".
Chcę przez to powiedzieć, że w trakcie określania stanu AS IS nie ma sensu zastanawiać się nad rozwiązaniami, bo oczekiwania klienta odnośnie do rozwiązań niejednokrotnie się jeszcze zmienią. Tematów klamkowych będzie więcej. Na tym etapie skup się przede wszystkim na tym, aby precyzyjnie zdefiniować jak jest - AS IS.
Na kiedy i za ile?
Niewypowiedziane oczekiwanie klienta, które może Cię wybijać ze stanu wewnętrznego spokoju brzmi: na kiedy to zrobicie i za ile?. Będziesz starać się uwzględnić to oczekiwanie i prawie na pewno skłoni Cię to do myślenia o rozwiązaniach od najwcześniejszych etapów rozmowy. Żeby uniknąć tego dylematu, już na wstępie uprzedź rozmówców, że oszacowania odnośnie do czasu i ceny podasz po wykonaniu analizy. Teraz natomiast zaczynamy jej pierwszy etap - określenie stanu obecnego, AS IS.
Nie zmuszaj do abstrahowania
Jeśli Twoi rozmówcy potrafią odpowiedzieć na pytanie: Jakie są kolejne roki procesu w waszej organizacji?, to wiedz, że spotkałeś/aś idealnego klienta. Czym prędzej zrób mu zdjęcie i powieś sobie nad biurkiem. W trakcie rozmowy klient zapewne określi te kroki, potem poda możliwe wejścia do procesu, potem możliwe wyjścia i sprawa załatwiona!
Odpowiedź na wspomniane pytania wiąże się z umiejętnością abstrahowania, czyli budowania ogólnego obrazu z przypadków szczególnych. Umiejętność abstrahowania nie jest moim zdaniem powszechna. Trzeba jej oczekiwać od wykonawcy, lecz klienta zostawiłbym w spokoju.
Klient - zwłaszcza użytkownik - bez problemu opowie o poszczególnych przypadkach działania procesu, np. "w przypadku faktury papierowej robimy to tak..., w przypadku elektronicznej tak..., w przypadku rachunku tak...". Być może po kilku takich przypadkach dostrzeżesz już jakąś powtarzalność i schemat. Dostrzeż to dlatego, że posłużysz się swoją umiejętnością abstrahowania. STOP! Nie rób tego.
Nie abstrahuj, nie definiuj szablonów, nie łącz poszczególnych przypadków w jeden ogólny. Żeby zbudować rozwiązanie problemu ogólnego, najpierw trzeba zbudować rozwiązania problemów szczegółowych, a dopiero potem je abstrahować. Zatem w pierwszej kolejności musisz zrozumieć, jakie są te problemy szczegółowe. Musisz zrozumieć jak jest - AS IS.
Porada Feynmana
Richard Feynman napisał kiedyś: Nigdy nie zabieraj się do obliczeń, dopóki nie znasz odpowiedzi. Mogę tutaj ukuć podobne stwierdzenie: Nigdy nie zabieraj się za przygotowanie rozwiązania, dopóki nie rozumiesz jak jest - AS IS.
