Discovery pomaga ocenić, czy firma jest w stanie zrealizować projekt klienta i ile będzie on kosztował. BA w fazie Discovery znajduje problemy biznesowe, bada domenę, identyfikuje wymagania i uczestniczy w projektowaniu rozwiązania.
Jak przebiega proces discovery, jakie trudności najczęściej się pojawiają i co zrobić, jeśli klient odmawia wstępnego etapu? Zapytaliśmy dwóch BA Leads z ponad 14-letnim doświadczeniem w branży IT, Kiryła Bielawskiego i Antona Babienko, którzy odpowiedzieli na pytania dotyczące Discovery i roli analityka biznesowego w tym procesie.
W branży IT istnieją co najmniej dwa pojęcia związane z discovery: produktowe i projektowe. Od razu ustalmy, o którym z nich będzie mowa w tym artykule:
Product Discovery – wymyślanie produktu lub jego udoskonalanie i rozwijanie. Główny nacisk kładziony jest tu na opracowywanie hipotez, walidację i badanie doświadczenia użytkownika. Nie będziemy się dziś skupiać na odkrywaniu produktu.
Project Discovery – wstępne lub dodatkowe badanie projektu, które jest przeprowadzane przed rozpoczęciem prac lub już w bieżącym projekcie. Firma IT występuje jako wykonawca (dostawca) dla klienta w outsourcingu. To właśnie o Project Discovery będzie mowa dalej.
O celach discovery i poziomie analityka biznesowego
Discovery to faza analizy i projektowania, podczas której określa się wymagania biznesowe i przygotowywana jest wizja projektu klienta. Dla firmy outsourcingowej, discovery jest jednym z etapów sprzedaży usług związanych z opracowywaniem rozwiązań dla klienta.
Klienci często przychodzą z dokumentami, które zawierają minimalne informacje na temat tego, czego chcą i dlaczego. Discovery pomaga zrozumieć, czego naprawdę potrzebuje biznes, i jak różnią się prawdziwe cele od życzeń klienta. Dla analityka biznesowego ważne jest znalezienie kompromisu między rzeczywistymi potrzebami biznesowymi a „zachciankami” klienta.
Czy faza discovery jest zawsze potrzebna
Jeśli projekt, który do was trafia, ma skomplikowaną strukturę i logikę biznesową, a także zakłada wiele integracji — to zdecydowanie konieczne jest przeprowadzenie fazy discovery. Jeśli jednak dostaniecie zapytanie o rozwiązanie szablonowe, które firma IT już wcześniej realizowała, to być może będzie można obejść się sprintem zero. Domeny także wpływają na konieczność przeprowadzenia fazy discovery. W branżach, w których stale zmienia się prawo lub wymagania dotyczące oprogramowania, nie można obejść się bez fazy discovery.Celem Discovery jest zrozumienie: co dokładnie musimy zrobić, jakie rozwiązanie zaproponować biznesowi klienta, jakie są trudności i zakres realizacji postawionych zadań, — oraz dostarczenie jasnej oceny projektu.
Faza discovery to proces o dużym stopniu odpowiedzialności, a jakość tej fazy ma wpływ na to, jak projekt będzie się rozwijać i jakie potencjalne problemy mogą wystąpić. Poprawnie przeprowadzona faza discovery pomaga zidentyfikować możliwe ryzyka i zmniejszyć poziom problemów w przyszłości.
Oczywiście firmy chcą, aby w takim odpowiedzialnym procesie uczestniczył jak najbardziej doświadczony specjalista (zwykle senior). W rzeczywistości zdarzają się sytuacje, gdy z braku innych alternatyw na badania zostają wysłani również juniorzy, zwłaszcza jeśli początkujący BA jest ekspertem w danej dziedzinie. Jednak dla wysokiej jakości discovery samo doświadczenie w konkretnej niszy lub obszarze to wciąż za mało.
Co zrobić, jeśli klient nie chce Discovery
Anton Babenko: Discovery to logiczne przedłużenie presale, a zadaniem menedżera jest przekonanie klienta, że Discovery pomoże znaleźć rozwiązanie, które w pełni zaspokoi potrzeby biznesowe:
- Wszystkie strony będą miały wspólne zrozumienie, jakie dokładnie biznesowe wymagania trzeba spełnić.
- Konkretne wymagania odnośnie rozwiązania zostaną sprecyzowane.
- Klient otrzyma realistyczną ocenę realizacji projektu.
Jeśli klient z trudnym projektem nie zgadza się na fazę Discovery, firmie bardziej „opłaca się” odmówić współpracy. Bez jakościowo przeprowadzonego Discovery istnieje duże ryzyko, że nie zostaną spełnione cele biznesowe klienta, ponieważ to, co klient mówi, rzadko zgadza się z tym, czego jego firmie naprawdę potrzeba.
Zwykle trudny projekt bez Discovery kończy się następująco:
Klient pracuje z nami do pierwszego wydania, otrzymuje gotowy produkt i mówi, że to zupełnie nie to, czego się spodziewał, i jest rozczarowany. Następnie klient odmawia płatności, zespół traci inne interesujące projekty, współpraca się kończy, a klient rozpowszechnia negatywne opinie na temat naszej firmy.
Kirył Bielawski: Klienci często nie rozumieją, dlaczego muszą dodatkowo płacić za badanie projektu, przecież przyszli do profesjonalistów, przedstawili wymagania i chcą rozpocząć pracę.
Co można zrobić:
- Zaproponować klientowi podzielenie się ryzykiem. Przeprowadzamy Discovery, prezentujemy wyniki, a jeśli klient odmawia współpracy, to koszty Discovery ponosimy my. Jeśli klientowi wszystko się podoba, to opłaca on ten etap, a my kontynuujemy pracę nad projektem.
- Wprowadzić płatność za Discovery jako odrębną usługę lub zaoferować rabat.
- Zgodzić się na tworzenie oprogramowania bez fazy Discovery, uwzględniając wszystkie możliwe ryzyka w kosztorysie.
Brak Discovery zazwyczaj skutkuje wzrostem zakresu prac (scope), co z kolei prowadzi do niezadowolenia klienta i zakończenia współpracy. Faza Discovery nie gwarantuje braku problemów, ale znacznie zmniejsza ryzyko niepowodzenia projektu. Ważna jest tu wspólna praca zespołu: kwestie płatności najlepiej pozostawić Project Managerowi i menedżerowi ds. sprzedaży.
Jak jest zorganizowany proces Discovery w SoftServe i Binariks
Kirył Bielawski: W SoftServe pracujemy z wieloma domenami, różnymi metodologiami i zespołami o różnej wielkości. Dlatego nie mamy jednego standardu lub podejścia do Discovery. Mamy jednak specjalny dział, który jest odpowiedzialny za przeprowadzanie Discovery. W jego skład wchodzą analitycy biznesowi, architekci i menedżerowie projektu, którzy regularnie przeprowadzają proces Discovery. Mają własne frameworki, które zależą od domen i innych warunków. To coś w rodzaju konstruktora: decydują, kogo zaangażować w proces Discovery, jaki będzie proces i tak dalej, w zależności od produktu.
Na przykład w projekcie dla masowego użytkownika, gdzie istotny jest UX, jednym z kluczowych uczestników procesu Discovery będzie designer, a w pracy prawdopodobnie skorzystamy z frameworka design thinking.
Teraz weźmy projekt o charakterze technicznym, w którym zadaniem jest load balancing serwerów, a projekt jest kierowany do specjalistów technicznych. Tutaj UI i UX nie są tak krytyczne, a na pierwszy plan wysuwają się aspekty niefunkcjonalne lub czysto techniczne wymagania, a podejście do przeprowadzenia Discovery w tym przypadku będzie inne.
Anton Babenko: W Binariks analityk biznesowy uczestniczy w komunikacji z klientem na etapie presale. Na tym etapie głównym zadaniem BA jest nie odstraszać klienta, zadając zbyt szczegółowe pytania lub zbyt głęboko “zagłębiając się” w jego działalność. Podczas presale klient chce poznać koszty projektu, a nie dokładnie analizować swoje potrzeby biznesowe i zmiany, jak to zazwyczaj ma miejsce na etapie Discovery.
Główne zadania BA na etapie Presale to:
- Wykazanie swojego poziomu profesjonalizmu i wiedzy w dziedzinie, zadając właściwe pytania.
- Zachęcenie klienta do dodatkowych pomysłów za pomocą pytań takich jak: “Jakie inne opcje rozważałeś?”
- Okazanie zainteresowania biznesem klienta i gotowości do pomocy.
Na etapie Discovery zadania są nieco inne. Tutaj BA musi zidentyfikować problemy, cele i rzeczywiste potrzeby biznesu oraz dowiedzieć się, co i jak klient chce osiągnąć za pomocą przyszłego produktu. Na podstawie tych informacji analityk biznesowy tworzy Scope and Vision (lub coś podobnego). Wynikiem całej pracy i części takiego dokumentu będzie story map, w której zarejestrowany jest zakres prac podzielony na wydania/etapy projektu.
Discovery jest logicznym przedłużeniem Presale, więc ważne jest, aby analityk biznesowy trzymał się początkowych ustaleń. Silne rozbieżności między tym, co zostało powiedziane podczas Presale i po Discovery, mogą zdezorientować lub przestraszyć klienta.
Na przykład, jeśli klient potrzebuje modułu kalendarza, na presale mówi się o prostym rozwiązaniu z trzema przyciskami. Po Discovery okazuje się, że potrzebny jest wielofunkcyjny system, co znacząco zwiększa koszty rozwiązania.
Co w takiej sytuacji robi doświadczony BA, aby nie odstraszyć klienta? Ostrożnie pomaga klientowi zrozumieć nową sytuację za pomocą pytań naprowadzających, takich jak: “Czy pamiętasz, że chciałeś tego i tego? Teraz okazuje się, że potrzebne jest inne rozwiązanie, które wprowadza istotne zmiany w pracy i kosztach”. Zazwyczaj to pomaga, ale jeśli nie, można zaproponować realizację projektu częściami. Najpierw robimy kluczowe rzeczy, a resztę później.
W trakcie procesu Discovery, podobnie jak w każdym projekcie, ważne jest odpowiednie zarządzanie oczekiwaniami klienta. Aby uniknąć sytuacji, w której analityk biznesowy zebrał scope “na 5 lat tworzenia oprogramowania”, a PM zdaje sobie sprawę, że budżet na pierwsze wydanie jest ograniczony do 35 000$ i cały backlog stworzony przez BA trzeba skrócić, co wiąże się ze złamaniem oczekiwań klienta.
Główne wyzwania w fazie Discovery i jak sobie z nimi radzić
Anton Babenko: Głównym problemem w każdym projekcie Discovery jest brak czasu, ponieważ wszystko trzeba zrobić szybko. Aby uniknąć ponownego wymyślania, co należy zrobić i w jakiej kolejności, wygodnie jest podzielić proces na standardowe kroki – i działać zgodnie z planem:
- Problemy biznesowe, które trzeba rozwiązać.
- Pytania użytkowników i procesy.
- Opis systemu.
Kiedy analityk biznesowy rozumie, co robi i w jakim dniu, pomaga to w dotrzymywaniu terminów. Nawet jeśli coś nie pójdzie zgodnie z planem, zawsze istnieje przybliżona mapa działań, a proces przebiega znacznie szybciej niż bez “pracy domowej”.
Oprócz braku czasu, klient często nie chce lub nie może odpowiedzieć na pytania dotyczące swojej działalności, ma problem, żeby opisać, jak pracują stakeholderzy lub użytkownicy.
Na przykład otrzymujesz prośbę o opracowanie widżetu: klient mówi, że chce wyświetlić pewne informacje na ekranie. Dobry analityk biznesowy zawsze zapyta, dlaczego, w jakim celu jest to potrzebne. Klient albo wyjaśnia, albo… unika odpowiedzi.
W pierwszym przypadku można kontynuować rozmowę, aby zrozumieć potrzeby biznesowe i wspólnie z projektantem zaproponować najlepsze rozwiązanie. Jeśli klient nie odpowiada na pytanie „Po co?”, przygotuj się na to, że widżet będzie przerabiany kilka razy.
Kirył Bielawski: Klient nie zawsze potrafi poprawnie opisać problem, który chce rozwiązać. Kiedy klienci przychodzą i mówią, że potrzebują jakiś system, ważne jest, aby pamiętać, że rozwiązanie, które proponują, może nie uwzględniać wszystkich niuansów, a tutaj BA musi myśleć w kategoriach biznesu, a nie solution.
Zawsze rozpoczynamy od badania biznesu: podstawowe pojęcia, potrzeby, model, jak wszystko działa. Następnie przechodzimy do systemu proponowanego przez klienta. Analizujemy, czy jest on odpowiedni dla działalności biznesowej, czy nie. Następnie gromadzimy przypadki zastosowań, role, interakcje między różnymi elementami systemu, integracje i stopniowo wybieramy technologię.
Na przykład, klient potrzebuje systemu rezerwacji. Jeśli zaczniemy od razu od pytań technicznych: jakie funkcje powinny być dostępne, jacy użytkownicy, możemy przeoczyć ważne wymagania. W takich sytuacjach lepiej jest zadać pytanie: Dlaczego potrzebujesz tego systemu, co on ma rozwiązać? — i dowiedzieć się od klienta o rzeczywistych potrzebach, po prostu rozmawiając o jego biznesie. Tutaj zadaniem BA jest uważne słuchanie, budowanie logicznych powiązań i wyjaśnianie kwestii spornych.
Innym częstym problemem jest niechęć klienta do dzielenia się informacjami lub brak zrozumienia, na czym w zasadzie polega rola analityka biznesowego. Z mojego doświadczenia wynika, że w takich przypadkach najlepiej sprawdza się kompleksowe podejście: na każdym spotkaniu z klientem wyjaśniasz, co robisz i dlaczego oraz jaka jest rola BA w projekcie. Najlepiej, jeśli w tej kwestii pomagają sales i project manager.
Często zdarza się, że analityk biznesowy rozpoczyna Discovery z myślą, że wszyscy ze strony klienta są gotowi do współpracy. Nie zawsze jest to prawdą. Nie wszyscy interesariusze wspierają projekt i są gotowi odpowiadać na pytania.
Droższe i tańsze rozwiązania
Kirył Bielawski: Podczas oceny każdego projektu bierzemy pod uwagę ograniczenia klienta: budżet, terminy, ograniczenia poza sferą wpływu klienta (na przykład projekt został wcześniej opracowany w określonej technologii i po prostu fizycznie niemożliwe jest przejście na inne rozwiązanie). Istnieją również tak zwane “ograniczenia polityczne”, gdy kierownictwo firmy nie ufa nowym technologiom z własnych powodów, uzasadnionych lub nie.
W każdym przypadku oferujemy klientowi najlepsze rozwiązanie, które może być między innymi droższe niż początkowy budżet klienta. To jego prawo, czy się na to zgadza, czy odmawia.
Anton Babenko: W mojej karierze miałem przypadki, w których musiałem nalegać na trzymanie się początkowego budżetu. Niektórzy klienci są gotowi rozszerzyć scope do nierealnych rozmiarów i wtedy trzeba ich hamować, przypominając im o początkowych wymaganiach i o tym, że i tak osiągają swoje cele biznesowe.
Zadanie jest jeszcze bardziej interesujące, gdy trzeba znaleźć kompromis pomiędzy różnymi interesariuszami. Jedynym wyjściem jest skłonienie ich do rozmów, aby omówili między sobą, czego chcą i jak widzą dalszy przebieg projektu. Wtedy istnieje szansa na konstruktywny dialog.
Jakie umiejętności powinien posiadać BA do przeprowadzenia fazy Discovery
Kirył Bielawski: Jedną z ważnych umiejętności dla BA jest szybkie zrozumienie domeny, która jest dla niego nowa. Inne przydatne umiejętności:
- Dobrze rozwinięta komunikacja: zdolność do rozmawiania, prowadzenia spotkań, organizacji warsztatów, klarowne wyrażanie swoich myśli.
- Zdolność do zbierania danych i wyników w formie diagramów, strukturyzacja dokumentów (listy funkcji, przypadki użycia, scenariusze), przedstawianie danych wizualnie.
- Umiejętność odpowiedniego przygotowania do Discovery: znalezienie podstawowych informacji o projekcie, poznanie dziedziny i historii klienta, stworzenie założeń odnośnie do wymagań klienta.
- Zdolność do właściwego podziału swoich działań, umiejętności zarządzania czasem.
Główne błędy na etapie Discovery:
- Skupienie się wyłącznie na solution i pominięcie potrzeb biznesowych.
- Bycie pewnym, że wszyscy są gotowi na współpracę.
- Brak dokładnego zrozumienia poziomu wpływu interesariuszy i ich roli w projekcie.
Przestudiuj odpowiednią literaturę, znajdź dobrego mentora i spróbuj zdobyć więcej doświadczenia. Doskonalenie teorii poprzez praktykę pod okiem doświadczonego profesjonalisty to najlepsze wyjście!
Anton Babenko: Jedno jest pewne – nie warto udawać, że się rozumie, jeśli tak naprawdę tak nie jest. Lepiej nie bać się “wyjść na głupka” na początku i zadawać pytania, które rozwieją wszelkie wątpliwości. Dzięki temu nie zrobisz z siebie głupka w trakcie projektu.
Kilka rad:
- Nie skupiaj się od razu na systemie. Skoncentruj się na celach i problemach, które trzeba rozwiązać.
- Nie włączaj “koparki”. Nie zagłębiaj się zbytnio w Discovery, aby uniknąć stawiania klientowi fałszywych oczekiwań.
- Nie rób czegoś bez omówienia swoich działań z zespołem. Nie jest to najlepszy przykład współpracy.
Nie bój się uczyć i wprowadzać nowości. Zawsze warto poznać opinie innych specjalistów, którzy na pewno wiele doświadczyli i na swoich przykładach mogą udzielić cennej lekcji do wykorzystania w praktyce. Zawsze warto uczyć się, rozwijać i dążyć do zrozumienia biznesu. W końcu jesteśmy analitykami biznesowymi.