Niektórzy twierdzą, że największym problemem w projekcie jest Klient. Wielu z nas narzeka na pracę z klientem ponieważ nie zawsze mówi nam o wszystkich swoich potrzebach. Spotkania z nim to niekończąca się lista życzeń, a I do dokumentu czasem ma uwagi.
Jak poradzić sobie w tych sytuacjach, czyli słów kilka o największych koszmarach analityka.
Problem #1: Niechęć klienta do dzielenia się informacjami
Wyobraź sobie taką sytuację: jesteś na spotkaniu, Klient bez większego problemu opowiada Tobie o swoim biznesie. Bez Twoich dodatkowych pytań mówi o tym co chce osiągnąć, jak będzie działał jego biznes po wdrożeniu zmian. Rozrysował nawet za Ciebie proces, przygotował listę wymagań biznesowych. Przy każdym z nich dopisał mierzalny cel biznesowy. Brzmi jak marzenie każdego analityka 🙂
Sytuacje, w których klient nie opowiada o wszystkich swoich wymaganiach to normalność w każdym projekcie. Musimy w pierwszej kolejności zrozumieć powody, dla których użytkownicy niechętnie nam o wszystkim mówią. Ale mieć na uwadze również fakt, że klient nie zawsze zdaje sobie sprawę z tego, że taka informacja może być dla nas ważna.
Sprawdź czy interesariusz:
- jest przyzwyczajony do określonego sposobu pracy I dlatego jest odporny na zmiany.
- wie jakie czynności wykonywane są w omawianym procesie biznesowym
- posiada informacje kto wykonuje te czynności, a kto nie powinien mieć do nich dostępu.
- rozumie co za pomocą danej funkcjonalności chce osiągnąć
Pamiętaj, aby w pierwszej kolejności zapytać klienta o tym CO funkcja ma robić, a dopiero w drugiej kolejności JAK ma działać. Nie myśl od razu o rozwiązaniu, lecz o tym w jaki sposób interesariusz będzie z niej korzystał. Pomocny w tym przypadku będzie rozrysowany proces biznesowy.
Dzięki niemu łatwiej będzie Tobie zadać pytania, np:
- Czy wykonanie tego zadania wymaga decyzji innych osób?
- Z jakich danych musisz skorzystać, aby wykonać swoje zadanie?
- Kto je przygotowuje?
- Na którym etapie powstają te dane?
- Komu musisz wysłać wynik swojej pracy?
- Czy kolejność wykonywanych działań ma znaczenie?
- Jak system powinien się zachować w określonej sytuacji?
- Co musi się stać, aby wykonanie tej operacji nie było możliwe?
- Czy ktoś spoza działu ma mieć dostęp do tej operacji?
Problem #2: Niezrozumiały dokument
Tester, programista, klient- żadna ze stron nie rozumie tego co zostało zapisane w dokumencie. Twoje zdziwienie jest tym większe, jeśli sam jesteś zadowolony z tego “dzieła”. W końcu poświęciłaś na stworzenie tego dokumentu wiele tygodni.
W innym przypadku masz wrażenie, że klient opowiada to samo co już opisałeś tylko innymi słowami, a Ty nie wiesz co zrobić?
Musisz zrozumieć, że dokumentu nie tworzysz dla siebie. Zatem to czy według Ciebie dokument jest dobry czy nie, nie ma większego znaczenia. Tworzysz go dla klienta, programisty, testera. Dlaczego więc nie pytasz tych interesariuszy projektu czego oczekują od Twojego opisu w tym projekcie? Na co szczególnie powinieneś zwrócić uwagę?
Oczekiwaniem klienta jest sprawdzenie czy dobrze została jego potrzeba. Nie interesuje go rozwiązanie, chyba, że jest to wymaganie względem systemu wynikające np. z zapisów w Księdze Identyfikacji Wizualnej Firmy. Klienta interesuje opis, w ramach którego będzie wiedział co funkcja robi, jakie są jej ograniczenia oraz czy będzie mógł jej użyć w osiągnięciu celu biznesowego.
Takim przykładem może być: “ Umożliwienie Klientowi dodawania książki do koszyka zamówień”. Klienta nie interesuje w pierwszym momencie jak będzie wyglądał mechanizm dodawania. W pierwszej kolejności jako Klient muszę znać odpowiedzi na pytania:
- Czy po dodaniu książki mogę ją usunąć z koszyka? Na którym etapie tego procesu usunięcie nie będzie możliwe?
- Czy po dodaniu książki mogę modyfikować zamówienie, np. Dodać liczbę sztuk książki?
- Czy po dodaniu książki będę widzieć, że została dodana?
Powyższe pytania są skontruowane według skrótu: C,R,U,D ( C- create, R- read, U-update, D-delete).
Pamiętaj, że Klient testuje biznesowo, zatem musisz spytać klienta w jaki sposób sprawdzi, że funkcjonalność będzie działać prawidłowo. W odpowiedzi mogą być zawarte tzw. “ukryte wymagania”.
Oczekiwaniem testera jest otrzymanie jasno opisanych zasad działania funkcji, warunków początkowych oraz końcowych. Interesuje go przede wszystkim wynik funkcji, o którym niestety często zapominamy w opisach.
Oczekiwaniem programisty jest otrzymanie dokładnych wskazówek co ma być zaprogramowane. Zastanów się co należy wykonać w systemie, aby użytkownik mógł pracować w sposób przez siebie oczekiwany.
Problem #3: Nieefektywne warsztaty
Po spotkaniu masz poczucie, że niewiele udało Ci się osiągnąć? Zrobiłeś 2 kroki w przód i 3 kroki w tył? A może nie potrafiłeś zapanować nad grupą podczas dyskusji?
Takie sytuacje mają miejsce, jeśli Twoje przygotowanie do spotkania sprowadza się do przygotowania merytorycznego.
Przygotowanie do spotkania to również odpowiedź na kilka podstawowych pytań:
- Jaki jest cel spotkania? Dlaczego spotkanie jest konieczne lub potrzebne?
- Co będzie wynikiem spotkania: wiedza, zmiana w myśleniu, decyzja? Czy uwzględniłeś to w agendzie?
- Czy istnieje inna forma przekazania informacji, która będzie skuteczniejsza?
- Co powoduje, że klient się angażuje na spotkaniu (narzędzia, forma przekazywania informacji)?
Problem #4: Chaos podczas dyskusji
Jesteś moderatorem spotkania, zatem to na Tobie ciąży odpowiedzialność weryfikowania czy dyskusja nie odbiega od głównego tematu. Użyj parafrazy, aby to zweryfikować: “Jeśli dobrze Pana zrozumiałam mówimy o……czy mógłby Pan pomóc mi zrozumieć, dlaczego ten aspekt jest istotny z punktu widzenia naszego tematu, w którym….”.
Możesz również poprosić Twojego rozmówcę, aby wyjaśnił jak wątek, który właśnie poruszył łączy się z tematem: “Dziękuję za Pana wypowiedz. Jak wątek, który Pan poruszył łączy się z tematem?”. Jeśli trudno Tobie nadążyć nad zrozumieniem tego co Klient do Ciebie mówi, spróbuj rozrysować to jako mapę myśli, bądź powiązać pojęcia, które wypowiada Klient model pojęciowy.
Jeśli masz problem z chaosem wypowiedzi użyj jednej z wielu technik facylitacji. Jedną z propozycji jest technika udzielania głosu oraz koordynowania dyskusji.
Technikę udzielania głosu stosuje się, aby pomóc w uporządkowaniu dyskusji kiedy wszyscy jej uczestnicy chcą mówić jednocześnie.
Krok 1 – Proszę, aby wszystkie osoby, które chcą się wypowiedzieć, podniosły ręce
Krok 2 – Widzę, że głos chcą zabrać 2 osoby: wymień z imienia. Właśnie w takiej kolejności będziecie się wypowiadać. Najpierw X, potem Y.
Krok 3 – Gdy X skończy, teraz Y, zapraszam…..
Krok 4 – gdy Y skończy. Czy ktoś jeszcze chcę się wypowiedzieć w tej sprawie?
Koordynowanie dyskusji oznacza wydzielanie i nazywanie poszczególnych wątków z dyskusji. Technikę tą możemy również stosować
profilaktycznie. Zapobiegamy powstaniu u kogoś niepokoju, że „jego sprawa” nie jest ważna, nie interesuje nikogo poza nim.
Podsumuj wątki i wypowiedzi na „tu i teraz” oraz sprawdź, czy tak jest w istocie.
Powiedz: „Wygląda na to, że mamy tu 3 równoległe rozmowy, bo po pierwsze, wypowiadacie się o….. po drugie rozmawiamy o…, po trzecie rozmowa dotyczy…. Czy coś pominęłam, bądź źle zinterpretowałam?
Pamiętaj, aby po każdych warsztatach zrobić retrospekcję. Pozwoli ona na krytyczne spojrzenie na warsztaty, które poprowadziłeś. Dzięki temu będziesz w stanie wypisać:
- ZACZĄĆ: punktualne przychodzenie,wysyłanie zrzutów ekranowych przed sesją
- PRZESTAĆ: grzebać w przeszłości, zmienić nastawienie, wierzyć w dobre intencje
- ZWIĘKSZYĆ: podsumowania uwag i komentarzy, korzystanie z „czerwonych kartek”
- KONTYNUOWAĆ: punktualne zaczynanie krótkich przerw na przekąski
- ZMNIEJSZYĆ: ilość okien z nieprawdziwymi danymi
