Project Discovery jest jednym z pierwszych etapów tworzenia produktu cyfrowego. Celem tego etapu jest zebranie jak najwięcej informacji na temat realizowanego projektu, zbadanie jego założeń biznesowych i technicznych oraz wyznaczenie dalszych kroków projektowych.
Na czym polega praca Analityka Biznesowego (ang. Business Analyst) na etapie Project Discovery? Analityk pozyskuje i analizuje dane, cele i potrzeby interesariuszy, a następnie przekształca zebrane informacje w specyfikację wymagań. Co więcej, pomaga w dostrzeżeniu różnic między tym, co interesariusze mówią o planowanym produkcie, a tym, czego rzeczywiście oczekują. Podejmowane przez analityka kroki zmierzają do tego, by końcowy produkt spełniał określone potrzeby i pomógł osiągnąć wyznaczone cele biznesowe.
Na czym polega etap Project Discovery?
Project Discovery to dosyć złożony zestaw prac i warsztatów umożliwiających m.in.:
- ustalenie i spriorytetyzowanie wymagań klienta,
- przeanalizowanie potrzeb grupy bądź grup docelowych produktu,
- ocenienie potencjału rynkowego projektu,
- określenie czasu i kosztu realizacji.
Inaczej mówiąc, discovery to proces pozyskiwania i identyfikacji danych, który prowadzi do określenia celu i potencjału projektowanego rozwiązania, ale przede wszystkim stawianych przed nim wymagań i ograniczeń. Ten etap realizacji projektu jest niezwykle istotny, ponieważ dzięki niemu można upewnić się, że planowane wdrożenie jest w pełni uzasadnione z punktu widzenia biznesu. Faza discovery pozwala ocenić wartość przygotowywanych rozwiązań oraz pomaga w stworzeniu produktu, który zaowocuje przywiązaniem użytkowników do marki i docenieniem jej wartości.
Czym są pozyskiwanie i identyfikacja wymagań w projekcie?
Pozyskiwaniem wymagań nazywamy proces ich identyfikowania na podstawie różnych źródeł, za pomocą wybranych technik np.: wywiadów, warsztatów, obserwacji czy analiz dokumentów (o technikach stosowanych przez analityków biznesowych pisaliśmy w poprzednim artykule). Źródłem szczegółowej wiedzy są z kolei informacje pozyskane od klienta i grupy docelowej produktu.
Pierwsza część fazy discovery obejmuje wywiady z interesariuszami. Rozmowy prowadzone są ze specjalistami z poszczególnych dziedzin w ustrukturyzowany sposób, z wykorzystaniem kwestionariusza wcześniej ułożonych pytań, który rozmówcy otrzymują z wyprzedzeniem.
Celem pozyskiwania wymagań jest:
- Identyfikacja wszystkich wymaganych funkcji, oczekiwań i ograniczeń.
- Zorientowanie wymagań względem wizji projektu.
- Uszczegółowienie wymagań wysokopoziomowych.
- Wyodrębnienie funkcji, których klient nie potrzebuje.
Na samym początku prac analityk biznesowy powinien zaplanować podejście do pozyskiwania wymagań. Pozwala to uniknąć sytuacji, w których uczestnicy wywiadów będą odrywani od swoich codziennych zajęć, co mogłoby zniechęcić ich do aktywnego udziału w warsztatach.
Analityk biznesowy jest przede wszystkim odpowiedzialny za poprawne, wyczerpujące oraz rzetelne zbieranie i identyfikowanie:
- wymagań funkcjonalnych,
- wymagań niefunkcjonalnych (np. wydajność, bezpieczeństwo, monitoring systemu itp.)
Głównym zadaniem analityka w procesie discovery jest zdefiniowanie potrzeb klienta oraz określenie, jakie funkcjonalności należy uwzględnić w projektowanym oprogramowaniu. Sformułowanie wymogów funkcjonalnych w jasny i poprawny sposób pozwala deweloperom zaimplementować je zgodnie z rzeczywistymi potrzebami interesariuszy.
Wybrane techniki identyfikacji wymagań
Przepływ procesu biznesowego (AS-IS -> TO-BE)
W pierwszym kroku rozmawiamy o aktualnym procesie biznesowym (AS-IS): zazwyczaj jest to proces niewydajny, wymagający zoptymalizowania. Zdarza się, że potrzeba zastosowania nowego rozwiązania informatycznego wynika nie z wady aktualnego procesu, ale z przyjętego przez klienta kierunku rozwoju organizacji.
Po omówieniu aktualnego systemu i ustaleniu problemów z nim związanych przechodzimy do rozmowy o docelowym rozwiązaniu (TO BE). Należy pamiętać, że jest to dopiero wizja procesu biznesowego widziana oczami klienta, bardzo często przesiąknięta różnego rodzaju przyzwyczajeniami. Jako analitycy biznesowi musimy jednak poznać wszystkie – jawne i ukryte -wymagania klienta, aby dowiedzieć się, do jakiego rozwiązania on rzeczywiście dąży.
Diagram kontekstowy i mapa ekosystemu
Diagram kontekstowy oraz mapa ekosystemu pozwalają na określenie prawdziwego zakresu projektu. Mapa ekosystemu przedstawia wszystkie systemy mające związek z projektowanym rozwiązaniem. Dodatkowo pokazuje tzw. “otoczenie systemowe”, czyli te platformy, które nie muszą być bezpośrednio związane z planowanym produktem, ale mają na niego pośredni wpływ. Mapa ekosystemu powinna zawierać wszystkie zewnętrzne systemy, z którymi komunikuje się projektowane rozwiązanie. Z kolei diagram kontekstowy definiuje granice systemu oraz interfejsy pomiędzy projektowanym produktem a zewnętrznymi platformami, aktorami (potencjalnymi użytkownikami) oraz używanymi danymi.
Omówienie funkcjonalności nowego systemu
Po zapoznaniu się z wizją nowego systemu oraz otaczającym go ekosystemem można przejść do omówienia głównych funkcjonalności nowego rozwiązania. Na tym etapie analityk stara się rozpoznać wszystkie elementy wpływające na jakość, złożoność i skomplikowanie projektowanego produktu.
To dobry moment, żeby zaangażować w warsztaty deweloperów, aby ocenili możliwości wdrożenia omawianych wymagań. Zestawienie potrzeb biznesowych z możliwościami i ograniczeniami technologicznymi pozwala dostrzec występujące zależności, a także oszacować szanse, ryzyko czy potencjalne konflikty. Współpraca z deweloperami jest niezbędna, aby określić złożoność projektu, jego czasochłonność oraz zakres niezbędnych zasobów.
Analityk biznesowy pełni więc zarówno funkcję pośrednika, jak i mediatora, który przekazuje wymagania biznesowe (funkcjonalne i niefunkcjonalne) od interesariuszy do zespołów deweloperskich.
Modelowanie
Identyfikowanie wymagań poprzez modelowanie to kolejny sposób, by zyskać pewność, że wszyscy interesariusze jednakowo rozumieją dane zagadnienie – zdarza się bowiem, że każdy z nich widzi ten sam aspekt inaczej, co sprzyja nieporozumieniom i utrudnia wypracowanie spójnych wymagań projektowych. Zastosowanie techniki modelowania okazuje się w takich sytuacjach bardzo efektywne – opracowany model jest zwykle krótszy, a zarazem łatwiejszy w zrozumieniu niż opis w języku naturalnym, co ułatwia uzyskanie ogólnego porozumienia (między interesariuszami i nie tylko).
Najpopularniejszym rodzajem modeli używanych w analizie biznesowej są różnego rodzaju diagramy. Pozwalają one przedstawić budowany system i jego kontekst z wielu perspektyw z odpowiednim poziomem abstrakcji, skupiając się tylko na istotnych aspektach, a pomijając cały “szum informacyjny”, który je otacza.
Proces modelowania nie jest obowiązkowy, jednak może znacząco pomóc przy walidacji założeń i poprawności zebranych danych. Modelowanie przyśpiesza wykrycie sprzeczności czy znalezienie uproszczeń i optymalizacji rozwiązania.
Dokumentowanie podczas warsztatów z klientem
Dodatkiem do ostatecznego dokumentu specyfikacji wymagań mogą być wszelkiego rodzaju notatki i nagrania zebrane podczas warsztatów. Choć nie muszą one wchodzić w skład oficjalnej dokumentacji, warto je zachować dla późniejszej weryfikacji czy ustalenia chronologii zmian zebranych wymagań.
Kluczowe produkty fazy discovery
Planując fazę Project Discovery, powinniśmy ustalić z klientem zestaw produktów, które chcemy w jej wyniku otrzymać, oraz procesów, jakie mają nam w tym pomóc.
Podstawowe produkty (deliverables) fazy discovery:
- Lista celów biznesowych wraz z określeniem miary KPI i jej wartości wymaganej do osiągnięcia danego celu,
- Lista interesariuszy,
- Lista oraz opis grup docelowych użytkowników wraz z ich priorytetyzacją,
- Mapa ekosystemu serwisu wraz z diagramem kontekstowym,
- Diagram Przypadków Użycia (Use Case) wraz z opisem przypadków,
- Lista wymagań funkcjonalnych,
- Lista procesów biznesowych w zakresie projektu wraz z diagramami aktywności,
- Lista wymagań niefunkcjonalnych,
- Architektura informacji produktu,
- Architektura logiczna i fizyczna systemu,
- Zakres projektu i podejście do jego realizacji.
Wypracowanie wymienionych deliverables w fazie discovery pozwala zapobiec konfliktom i niejasnościom na dalszych etapach cyklu projektowego. Produkty te stanowią fundament dalszej komunikacji między interesariuszami a zespołem wdrożeniowym – służą wyodrębnieniu aspektów kluczowych dla sukcesu projektu, a także stanowią punkt odniesienia w podejmowaniu decyzji, by były one zgodne z przyjętym kierunkiem prac i skoncentrowane na celach interesariuszy.
Podsumowanie
Umiejętne przeprowadzenie procesu discovery znacząco zwiększa prawdopodobieństwo powodzenia projektu digitalowego. Rola analityka biznesowego jest w tej fazie o tyle kluczowa, że dzięki zastosowaniu technik, takich jak modelowanie czy tworzenie diagramów, pomaga on doprecyzować cele, potrzeby i wymagania interesariuszy. Co więcej, jest w stanie zidentyfikować ewentualne ograniczenia, a nawet zagrożenia, które mogą obniżyć jakość produktu końcowego. Przed przejściem do kolejnego etapu – „Solution design” – odbywa się warsztat produktowy, gdzie prezentuje się opracowane deliverables, omawia wszelkie zastrzeżenia i nanosi niezbędne poprawki.
W Infinity Group od lat przeprowadzamy klientów przez proces discovery, pomagając im zidentyfikować ich potrzeby biznesowe i przekuć je w kompleksowe rozwiązania digitalowe z wykorzystaniem platform DXP. Więcej informacji o naszych projektach znajdziesz w zakładce „Case Studies”, a jeśli chcesz dowiedzieć się, jak Project Discovery może pomóc w rozwoju Twojego biznesu – skontaktuj się z nami i umów na konsultację.
