Które z poniższych pytań zadane teraz, na początku lektury tego artykułu, pozwoli Ci uzyskać z niego najwięcej praktycznych treści:
- Zastanawiam się, o czym będzie ten artykuł?
- Co było dla mnie najtrudniejsze w trakcie ostatniej rozmowy z klientem?
- Dlaczego wciąż popełniam te same błędy, gdy rozmawiam z klientami?
- Jakie nowe możliwości pojawiłby się, gdyby moje rozmowy z klientami wyglądały tak, jak tego chcę?
Które pytanie wybierasz? Jeśli nie masz całkowitej jasności, co do swojej decyzji, tym bardziej zachęcam Cię do przeczytania tego artykułu. Wrócimy do tych pytań nieco później.
User Stories, Use Cases to nie wszystko
Nawet mając spisane US bądź US można nie rozumieć potrzeb biznesu. Jest taki żart, że w pewnym małym miasteczku zbudowano aż trzy mosty, ponieważ…dopiero za trzecim razem trafiono na rzekę. Można wykonać naprawdę dużo dobrej i kosztowej roboty, nie rozumiejąc o co właściwie chodzi w projekcie.
User Stories, Use Cases i inne metody do nadawania kształt wymaganiom używane są po to, aby lepiej rozumieć, czego oczekuje biznes. Istnieją również metody[4], które pozwalają lepiej modelować rzeczywistość biznesową. Tutaj powstaje pytanie – Gdzie mieszczą się wspomniana wiedza biznesowa i oczekiwania? Odpowiedź jest oczywista: w głowach ludzi z biznesu!
Jeśli będziesz szczegółowo i konkretnie wiedział, co należy wykonać, zapisanie tego w dowolnej formie: User Stories, Use Cases, scenariuszy, modeli takich czy innych będzie bardzo proste. Tak proste, że będzie można napisać do tego skrypt. Trudne jest natomiast wydobywanie wiedzy biznesowej od ludzi jest, precyzowanie oczekiwań, oddzielanie rzeczy koniecznych od tylko atrakcyjnych.
Potrzeba, czyli problem albo korzyść
Przeczytaj dwie poniższe przykładowe wypowiedzi:
- Jestem odpowiedzialny za zwiększenie liczby obsługiwanych umów do sześciuset, WIĘC chcę zobaczyć miesięczny wykaz zawartych umów.
- Jeśli liczba obsługiwanych umów pozostanie na poziomie dwustu miesięcznie, to zamkną nasz departament, WIĘC chcę zobaczyć miesięcznych wykaz umów.
Wypowiedzi te pochodzą od różnych klientów, którzy jednak chcą tej samej funkcjonalności – zobaczyć miesięcznych wykaz zawartych umów. Tym, co różni powyższe wypowiedzi jest powód, dla którego funkcjonalności są konieczne do dostarczenia. Powód ten nazywamy potrzebą biznesową.
Skoro w wymienionych przykładach, oczekiwane funkcjonalności są dokładnie takie same, to czym różnią się od siebie wyrażone tam potrzeby biznesowe? Przyglądając się im zauważasz, że pierwsza potrzeba dotyczy osiągnięcia większej liczby obsługiwanych umów, druga zaś dotyczy uniknięciazamknięcia departamentu. Te przykłady obrazują dwie grupy potrzeb biznesowych –korzyści do osiągnięciaoraz problemy od uniknięcia.
Za każdą funkcjonalnością stoi albo oczekiwana korzyść albo problem, który należy rozwiązać. Jeżeli osoby z biznesu nie przewidują osiągnięcia korzyści lub uniknięcia problemów w związku z zaimplementowaniem nowej funkcjonalności, to nie ma żadnego powodu, aby ją implementować. Nie ma powodu, aby za nią płacić!
Bardzo łatwo jest rozmawiać o funkcjonalnościach ponieważ są one namacalne. Możesz narysować ekran użytkownika albo przepływ sterowania. W przypadku oprogramowania typu backend, możesz narysować diagram komponentów albo wyspecyfikować API dla modułu. Te rzeczy bardzo łatwo nazwać oraz definiować. Odnalezienie oraz nazwanie potrzeb jest o wiele trudniejsze, ponieważ najczęściej są one ukryte.
Kiedy biznes mówi o problemach?
Idąc za podziałem potrzeb na problemy do uniknięcia oraz korzyści do osiągnięcia, załóżmy że rozmawiasz z osobą z biznesu, na przykład w trakcie spotkania planistycznego, starasz się sformułować nowe User Storyi twój rozmówca mówi: Jako Użytkownik chcę funkcjonalności X ponieważ…
- …obawiam się, że marża będzie wyliczana niepoprawnie,
- …to GUI jest nieintuicyjne,
- …lepiej, aby użytkownik nie miał wrażenia, że (…).
Słuchając uważnie, usłyszysz w tych wypowiedziach bardzo specyficzne frazy: obawiam się, że, to nie jest, nie chcę aby.Inne podobne do nich to:
- …działa zbyt wolno, działa nie tak jak trzeba,
- …jest za bardzo…
- …problem w tym, że…
- …to niemożliwe ponieważ…
- …to trudne ponieważ…
Podane frazy niemal jednoznacznie wskazują, że osoba z którą rozmawiasz stara się opisać coś, czego chce uniknąć. Opisuje w ten sposób swoją potrzebę w formie problemu do uniknięcia.
Po rozpoznaniu wymienionych sygnałów wskazujących na problem, nazwij go wprost. Najczęściej pasuje on do poniższych schematów:
- Chcę uniknąć…
- Nie chcę, aby…
- To trudne, ponieważ…
- Jeśli tego nie zrobimy, to…
Gdy wstawisz rozpoznane wyrażenie określające problem w miejsce wykropkowania, zdanie będzie miało sens. Dla początkowego przykładu może to mieć następującą postać:
- Chcę uniknąć źle wyliczonej marży.
- Nie chcę nieintuicyjnego GUI.
- Nie chcę, aby użytkownik miał wrażenie, że.
Kiedy biznes mówi o korzyściach?
Gdy podczas rozmowy na temat nowych funkcjonalności słyszysz, że rozmówca mówi Jako Użytkownik chcę funkcjonalności X, ponieważ…:
- …będziemy mogli sami projektować raporty,
- …użyjemy kalkulatora płac tak szybko jak to możliwe,
- …lepiej przetestujemy ten moduł.
Podobnie jak w przypadku problemów do rozwiązania, w podanych wypowiedziach słyszysz charakterystyczne frazy: będziemy mogli, użyjemy tak szybko jak to możliwe, lepiej przetestujemy.Inne podobne do nich to:
- …spodziewam się, że…,
- …dzięki temu…
- …to powinno/musi/może/mogłoby…
- …będzie wspaniale jeśli…
Dość łatwo możesz nazwać korzyść o której mowa, ponieważ najczęściej pasuje ona do jednego z poniższych schematów:
- Chcę osiągnąć…
- To sprawi, że…
- To będzie oznaczać, że..
Dla podanego przykładu mamy:
- To sprawi, że sami zaprojektujemy raporty.
- To będzie oznaczać, że użyjemy kalkulatora płac tak szybko jak to możliwe.
- Chcę osiągnąć lepsze przetestowanie tego modułu.
User Story a potrzeby biznesowe
Przyjrzyj się dwóm powszechnie używanym szablonom User Story:
- JAKO <rola> CHCĘ <funkcjonalność>, PONIEWAŻ <cel>?
- ABY <cel> JAKO <rola> CHCĘ <funkcjonalność>?
Jakie będą Twoim zdaniem konsekwencje używania każdego z nich? Używając pierwszego zaczynasz rozmowę od funkcjonalności. Ponieważ rozmawianie o funkcjonalnościach jest dość łatwe i naturalne, można spędzić bardzo wiele czasu na: rysowaniu ekranów, modeli czy procesów. To są oczywiście bardzo ważne rzeczy, lecz na koniec dnia będziesz chciał mieć całe User Story w pełni spisane. Pojawi się wtedy pokusa, aby w miejsce celu wpisać ogólne sformułowanie, a nie ten właściwy, który motywuje biznes do zamówienia danej funkcjonalności.
Drugi szablon przyniesie o wiele lepszy efekt, gdyż zaczynasz rozmowę od poszukiwania celu, czyli potrzeby biznesowej. Używając drugiego szablonu nie zaczynasz rozmawiać o funkcjonalnościach dopóki nie zdefiniujesz potrzeby wystarczająco wyraźnie.
Zauważ, że możesz wykorzystać wiedzę na temat potrzeb do usprawnienia szablonu User Story.Zamiast jednego schematu pojawiają się dwa bardziej precyzyjne:
- ABY UNIKNĄĆ <problem do uniknięcia> JAKO <rola> CHCĘ <funkcjonalność>.
- ABY OSIĄGNAĆ <korzyść do osiągnięcia> JAKO <rola> CHCĘ <funkcjonalność>.
Osobiście używam dwustronnie zadrukowanych karteczek. Jedna strona dla szablonu poszukującego korzyści, druga dla szablonu związanego z problemami biznesu. Używając tego szablonu łatwiej zauważysz potrzeby stojące za wymaganiami zgłaszanymi przez biznes, łatwiej poprowadzisz rozmowę, a w konsekwencji będziesz mógł zaproponować funkcjonalności, które trafią w samo sedno.
Które pytanie wybrałeś?
Wróćmy do pierwszego akapitu, które z zaproponowanych pytań wybrałeś?
Zastanawiam się, o czym będzie ten artykuł? To pytanie o „funkcjonalność”. Jeśli je wybrałeś, to przeczytałeś artykuł, dowiedziałeś się, co w nim było i wkrótce o nim zapomnisz.
Co było dla mnie najtrudniejsze w trakcie ostatniej rozmowy z klientem?To bardzo wartościowe pytanie, ponieważ naświetla trudność (problem), z którym się borykasz. Wybierając to pytanie będziesz poszukiwał w tym artykule pomysłów na rozwiązanie problemu.
Dlaczego wciąż popełniam te same błędy, gdy rozmawiam z klientami? Jest to również pytanie o problem, lecz zadając sobie to pytanie będziesz się czuł gorzej i gorzej. Oczywiście umiejętność przeżywania trudnych emocji jest pożyteczna, lecz w przypadku tego pytania brak jakiegokolwiek odniesienia do oczekiwanego rezultatu.
Jakie nowe możliwości pojawiłby się, gdyby moje rozmowy z klientami wyglądały tak jak chcę? Jest to również wartościowe pytania, gdyż odnosi się to potencjalnych korzyści. Jeśli wybrałeś to pytanie, to będziesz poszukiwał w artykule inspiracji do osiągnięcia tych korzyści.
Podsumowując: rekomendowanymi pytaniami są pytania numer dwa oraz cztery. Jeśli chcesz dowiedzieć się więcej na temat rozmawiania z klientem, który nie wie, czego chce, czytaj kolejne części cyklu.
