Artykuł powstał we współautorstwie z Antonem Babenkiem, Senior BA w SPD-Ukraine
Każdy projekt IT ma swoją charakterystykę: poziom złożoności, liczbę interesariuszy i ich kompetencje, otwartość klienta i inne czynniki. Faza Discovery jest konieczna, aby ocenić, czy firma będzie w stanie zrealizować konkretny projekt i zmieścić się w budżecie. Udana faza Discovery pomaga zrozumieć cele produktu/rozwiązania, uzyskać realistyczny kosztorys i plan wdrożenia, a także sprzedać projekt.
Każdy BA ma swój własny pomysł na to, jak powinny wyglądać artefakty w Discovery Phase. Mogą różnić się formą i prezentacją, ale najważniejsze nie są formaty i szablony, ale informacje, które zostaną w nich osadzone.
Trzy artefakty dla analityka biznesowego
Podobnie jak w bajce „Trzy orzeszki dla Kopciuszka” – magiczne orzeszki prowadzą do szczęśliwego zakończenia, tak i artefakty z poniższej listy pomagają BA pomyślnie przetworzyć wszystkie informacje otrzymane w Discovery Phase:
- Business Requirements Document.
- Use Case Diagram.
- Context Diagram.
Każdy artefakt ułatwia pracę BA, pomagając dokładnie opracować główne pytania w fazie odkrywania.
Business Requirements Document
Business Requirements Document (BRD) — dokument, w którym wprowadzasz wszystkie informacje od klienta: od możliwości biznesowych po cele biznesowe i wskaźniki sukcesu. Przykład struktury BRD:
- Business Problem statement
- Business objectives
- Project scope
- Main project success/cancellation criteria
- Functionals and Non-Functional requirement
- Project costs
- Stakeholder list
- Project assumptions and constraints
- Project risks
Discovery Phase ma przede wszystkim pomóc zrozumieć: jakie są potrzeby biznesowe klienta, co zaoferować jako rozwiązanie i jak je wdrożyć. Dlatego zalecam jak najdokładniejsze wypełnienie BRD i nie wahaj się zadawać klientowi pytań.
Pamiętaj, że klient nie zawsze rozumie, co jest tak naprawdę potrzebne jego biznesowi, lub może skupiać się na drobnych kwestiach. Zadaniem Analityka Biznesowego w fazie odkrywania jest „dotarcie do sedna” i na tej podstawie opracowanie dla klienta propozycji rozwiązania jego problemu lub zarekomendowanie firmie IT całkowitej rezygnacji z projektu.
Use Case Diagram
Use Case Diagram (UCD) — to szybki i wizualny sposób podsumowania możliwości technicznych przyszłego produktu. Ten diagram ułatwia zrozumienie:
- Kto jest potencjalnym użytkownikiem Twojego rozwiązania.
- Jakie role, uprawnienia i system dostępu są potrzebne.
- Jakie są główne wydarzenia, które wykonają użytkownicy, co jest do tego wymagane.
Na Use Case Diagram nie ma potrzeby opisywania najdrobniejszych szczegółów – najważniejsze jest uwzględnienie wszystkich kluczowych use cases i ról. W fazie Discovery musisz kopać szeroko, a nie głęboko. Na tym etapie ważniejsze jest zebranie pełnych informacji o całym projekcie, aby zidentyfikować i ocenić jak najwięcej potencjalnych ryzyk, niż dogłębne badanie jednego obszaru.
Lepiej zebrać 80% danych i zrozumieć 20% z tego, niż na odwrót. W przeciwnym razie możesz przegapić kluczowych interesariuszy, potrzebne funkcje i wiele innych rzeczy. W rezultacie ważne informacje nie zostaną uwzględnione, co spowoduje błędy w ocenie projektu i dalszą reakcję łańcuchową.
Context Diagram
Context Diagram — to wszystkie Twoje potencjalne integracje i dane do analizy, transformacji i migracji. Wszystko, co otacza projekt i może mieć wpływ na efekt końcowy, jest wpisane w diagram kontekstu:
- potencjalni użytkownicy;
- procesy biznesowe w firmie Klienta;
- organizacje zewnętrzne;
- specyfika obszaru dystrybucji produktu IT;
- różne regulacje.
Diagram kontekstu można wykonać na kilku poziomach: Business Context Diagram i System Context Diagram. W pierwszym przypadku w centrum diagramu umieszczamy organizację/biznes klienta, a na obwodzie głównych kontrahentów. Strzałki wskazują informacje, jakie wymieniają z „centrum”.
Na Diagram System Context, centrum nie będzie biznesem klienta, ale systemem, z którym pracujemy. Wzdłuż obwodu znajdują się inne systemy, urządzenia i instytucje, które wchodzą w interakcję lub powinny wchodzić w interakcję z naszymi w taki czy inny sposób. Strzałki wskazują, jakie dane/informacje wymieniają.
Zamiast wniosków
Każdy analityk biznesowy może korzystać z różnych typów i ilości artefaktów, nie ma idealnej listy, ale właśnie Business Requirements Document, Use Case Diagram i Context Diagram pomagają szybko i maksymalnie przejrzyście przeanalizować przyszły projekt, odpowiednio ocenić wszystkie zagrożenia i zapisać otrzymane informacje w formie wizualnej.
Gdybym więc utknął na bezludnej wyspie z projektem w przygotowaniu i mógłbym wybrać tylko trzy artefakty, byłyby to moje ulubione. Dopiero później poprosiłbym jako bonus o słownik głównych terminów używanych przez klienta i zespół, aby móc rozmawiać z klientem w tym samym języku i tym samym ułatwić pracę wszystkim uczestnikom Discovery Phase.