W tym artykule zgłębiamy temat potrzeb biznesowych. Jeśli nie wiesz, czym one są - przeczytaj artykuł Czym jest potrzeba biznesowa?
Pierwszym narzędziem do poszukiwania tych właściwych potrzeb biznesowych są pytania. Odpowiednio zadane pytania pozwalają uzyskać wiele istotnych informacji. Jesteśmy absolutnie przekonani, że jeśli osoba z biznesu z którą rozmawiasz, nie udzieli ci informacji, których oczekujesz, to z całą pewnością zadałeś niewłaściwe pytania, w niewłaściwym momencie.
Ponieważ istnieją dwa odcienie potrzeb biznesowych: problem do uniknięcia oraz korzyść do osiągnięcia, są również dwie grupy pytań pomagające w odkrywaniu tych potrzeb.
W poszukiwaniu problemów
Podstawowym pytaniem do poszukiwania potrzeb w postaci problemów, których rozmówca stara się uniknąć jest pytanie „Dlaczego?”. Starając się odpowiedzieć na pytanie „Dlaczego?” zazwyczaj koncentrujemy się na przeszłych problemach. Podobny rezultat wywołują bardziej szczegółowe pytania eksplorujące obszar problemów do rozwiązania:
- Dlaczego to jest ważne?
- Co jest w tym trudnego?
- Co dzięki temu unikniesz?
- Co możesz stracić?
- Czego starasz się uniknąć?
- Co może się stać, jeśli nie dostaniesz tej funkcjonalności?
- Ile pieniędzy możesz stracić?
W zadawaniu pytań tego rodzaju chodzi przede wszystkim o możliwie ścisłe sprecyzowanie tego, co motywuje twojego rozmówcę do tego, aby chcieć danej funkcjonalności albo innymi słowy: jaką wartość przypisuje danej funkcjonalności, albo jeszcze inaczej jakie jest business value funkcjonalności.
W poszukiwaniu korzyści
Podstawowym pytaniem poszukującym korzyści do osiągnięcia jest pytanie „Po co?”. Odpowiadając na to pytanie zazwyczaj koncentrujemy się na przyszłych korzyściach, podobnie jak w przypadku bardziej szczegółowych pytań tego rodzaju:
- Co ci to da?
- Jaki jest cel, tego, że…?
- Co/Ile możesz na tym zyskać?
- Co się wydarzy jeśli to wdrożymy?
- Co się stanie możliwe dzięki temu?
- Co można dzięki temu osiągnąć?
- Jakie są nowe możliwości z tym związane?
- Co jest rzeczywiście w tym nowego?
Być może zastanawiasz się teraz, skąd będziesz wiedzieć, w którym kierunku poszukiwać potrzeb. Czy w stronę problemów do uniknięcia, czy może w stronę korzyści do rozwiązania? Odpowiedź jest dość prosta: słuchaj tego, co mówi rozmówca. Możesz zacząć rozmowę od neutralnych pytań:
- Co spowodowało, że chcesz tej funkcjonalności?
- Co takiego ważnego jest w tej funkcjonalności?
a następnie uważnie słuchaj odpowiedzi i poszukuj wyrażeń wskazujących na konkretny rodzaj potrzeby biznesowej (patrz: część pierwsza cyklu), a następnie zadawaj pytania w kierunku, w którym rozmówca ma więcej do powiedzenia.
Szukaj potrzeb konkretnych
- Co spowodowało, że chcesz tej funkcjonalności?
- Oj, wtedy będzie super!
Cóż, być może warto, aby „było super” jednak nic nam to nie mówi o potrzebach biznesowych. W tym miejscu pomocny będzie zestaw pytań konkretyzujących:
- Po czym poznasz, że…?
- W jaki sposób zmierzysz, że…?
- Jak? W jaki sposób?
- Co konkretnie sprawi, że…?
- Kto? Gdzie? Kiedy? Z kim? Ile?
- Podaj przykład...
W kontekście wymienionych pytań konkretyzujących, bardzo pomocne będzie skłanianie rozmówcę do takiego formułowania wypowiedzi, aby były one zgodne z tak zwanym konkretyzmem semantycznym. Konkretyzm to jeden z obszarów filozofii stworzony przez Tadeusza Kotarbińskiego, który uznaje za poprawne tylko te zdania, które zawierają w sobie jedynie nazwy odnoszące się do realnie istniejących rzeczy. Zatem zdanie „Będzie super” nie jest poprawne w sensie konkretyzmu semantycznego, natomiast zdanie „Osoba X wyśle do nas formularz zamówienia” już tak.
Szukaj potrzeb związanym z tym biznesem
„Zwiększenie miesięcznego przychodu”, „zmniejszenie kosztów ukrytych” są potrzebami w miarę konkretnymi, lecz jednocześnie pasują do niemal każdego istniejącego biznesu. Poszukuj potrzeb, które są związane z tym konkretnym biznesem, dla którego tworzysz oprogramowanie. Na przykład jako użytkownik księgarni internetowej mam następujące potrzeby:
- Aby nie zakładać nowego konta (problem),
- Aby nie wpisywać wszystkich danych przy każdym zakupie (problem),
- Aby otrzymać książkę następnego dnia po zakupie (korzyść),
- Aby nie płacić za przesyłkę każdej książki oddzielnie (problem).
Niektóre z nich przełożą się na funkcjonalności, inne na charakter usługi poza systemem informatycznym.
Szukaj potrzeb, które motywują
Szukaj takich, które sprawiają, że osoba z biznesu z którą rozmawiasz ma ochotę wstać i krzyknąć „Tak! To jest to! Tego chcę”. To właśnie te potrzeby powinny się znaleźć spisane w User Story. Do rozstrzygnięcia, z którą z potrzeb jest najbliżej tego, co biznes rzeczywiście chciał przekazać, pomocne będą pytania:
- Jakie będą konsekwencje jeśli tego unikniesz?
- Jakie będą konsekwencje jeśli to osiągniesz?
- Gdybyś na teraz był zmuszony do pogodzenia się z jednym problemem, to który byś wybrał?
- Gdybyś na teraz mógł osiągnąć tylko jedną z korzyści, to na którą byś się zdecydował?
- Gdybyś na teraz był zmuszony do zrezygnowania z jednej korzyści, to którą byś wybrał?
Są to pytania, w których z jednej strony staramy się odnaleźć konsekwencje zaspokojenia potrzeb biznesowych, a z drugiej próbujemy ustalić priorytety, aby wyłonić najistotniejszą potrzebę.
Odkrywanie potrzeb in action
Połączmy teraz wszystkie przedstawione dotąd informacje na temat odkrywania potrzeb w jedną całość. Przykładem niech będzie rozmowa między biznesem a programistami, która wydarza się dość często, i która zazwyczaj przebiega według tego samego schematu:
- [Biznes]:Słuchajcie, chciałbym dodać do tego ekranu przycisk po naciśnięciu którego generowałby się częściowy raport…
- [Zespół]:Które dane mają być pokazane? Co pokazać, gdy nie ma danych? Czy to wymaganie jest spójne z całościową wizją procesu? Czy pomyślałeś o konsekwencjach agregowania częściowych danych? To może wymagać większego refaktoringu…
- [Biznes]:yyyyy, to ja muszę się skonsultować…
Dociekliwość może być napastliwa
Pozornie w pytaniach zadawanych przez Zespół nie ma nic nadzwyczajnego. Ot, porządne pytania konkretyzujące. Jednak jak zwykle kluczem jest kontekst sytuacyjny. W takich przypadkach jak powyżej, zespół używa dużej ilości szczegółowych i czasem technicznych pytań po to, aby powiedzieć „Nie!”.
Gdy rozmawiasz z kimś zespołu, to wymienione pytania są jak najbardziej na miejscu, ponieważ ta osoba jest wystarczająco kompetentna, aby na nie odpowiedzieć. Jeśli tych samych pytać używasz w kontakcie z osobą, która nie jest na nie przygotowana, gdyż na przykład nie posiada w danym zakresie odpowiedniej wiedzy, to mogą być one odebrane jako celowe zachowanie agresywne.
Jeśli więc chcesz powiedzieć „Nie!”, powiedz „Nie!”. Jest to zdecydowanie bliżej asertywności niż obstrzeliwanie rozmówcy gradem niezrozumiałych pytań. Często również taka rozmowa kończy się wzajemnym przekonywaniem, że dana funkcjonalność ma albo nie ma sensu.
Czy to oznacza, że w kontakcie z osobami z biznesu w ogóle należy unikać tego typu pytań? Oczywiście nie! Podobne pytania muszą w pewnym momencie paść. To, co jest to istotne to, żeby najpierw odkryć potrzebę, a dopiero w drugiej kolejności zadawać szczegółowe czy nieco techniczne pytania.
Po pierwsze: nazwij potrzebę biznesową
Jak mógłby przebiegać przytoczony wcześniej dialog?
- [Biznes]:Słuchajcie, chciałbym dodać do tego ekranu przycisk po naciśnięciu którego generowałby się częściowy raport…
Teraz się zatrzymaj. Nawet jeśli jesteś absolutnie przekonany, że to wymagania jest nieuzasadnione albo zupełnie nie ma sensu, zatrzymaj się. Nie argumentuj, nie przekonuj. Odkryj potrzebę.
- [Zespół]:Co spodziewasz się zyskać mając ten częściowy raport?
- [Biznes]: Nie chcę czekać na wykresy sprzedaży do końca miesiąca.
Jak możesz zauważyć Zespół zapytał o potencjalną korzyść do osiągnięcia, natomiast Biznes wskazał na problem do uniknięcia. Tak może się zdarzyć, podążaj wtedy za rozmówcą.
- [Zespół]:A zatem kluczowy jest czas oczekiwania na wykresy sprzedaży?
- [Biznes]:Tak!
W tym momencie została nazwana potrzeba biznesowa w postaci problemu do uniknięcia: „Chcę uniknąć czekania na wykresy sprzedaży do końca miesiąca”.
Po drugie: Sprecyzuj kryteria akceptacji
Mając potrzebę możesz przystąpić do zdefiniowania dla niej kryteriów akceptacji. Innymi słowy należy określić po czym rozmówca pozna, że problem został rozwiązany albo że korzyść została osiągnięta. Dlaczego ważne jest sformułowanie kryteriów akceptacyjnych? O tym już za chwilę.
- [Zespół]:Które konkretnie wykresy chciałbyś oglądać i jak często, aby być na czasie?
- [Biznes]:W zasadzie to potrzeba mi wykresów dla kluczowych klientów dwa razy w tygodniu.
Jeśli Zespół chciałby ująć w zwięzłą formę to, czego właśnie się dowiedział od klienta, to brzmiało by to mniej więcej tak: „Chcę uniknąć czekania na wykresy sprzedaży do końca miesiąca i uniknę tego, gdy dwa razy w tygodniu będę mógł obejrzeć wykresy sprzedaży dla kluczowych klientów”. Z tą wiedzą Zespół może kontynuować dialog.
Po trzecie: Zaproponuj rozwiązanie
- [Zespół]:Acha! A zatem możemy to zrobić w ten sposób... albo w ten…albo w ten… Które z tych rozwiązań jest twoim zdaniem najlepsze?
- [Biznes]:To wygląda intersująco…
Po to zespół starał się nazwać potrzebę oraz określić dla niej kryteria akceptacji, aby móc zaproponować alternatywy. To jest właśnie magia stojąca za potrzebami. Najpowszechniejszymi taktykami postępowania w przypadku nowych funkcjonalności, które „nie pasują” do architektury są argumentowanie, przekonywanie i forsowanie swoich pomysłów. Skupienie się na potrzebach w pierwszej kolejności pozwala znaleźć takie alternatywne rozwiązanie, które z jednej strony satysfakcjonuje biznes, a z drugiej jest do zaakceptowania przez zespół.
