Analityk biznesowy odpowiada przede wszystkim za zrozumienie potrzeby, celu, procesu i wartości zmiany. Analityk systemowy doprecyzowuje, jak system ma zachować się wobec użytkowników i innych systemów: jakie przetwarza dane, stosuje reguły, udostępnia interfejsy oraz obsługuje błędy.
To rozróżnienie opisuje punkt ciężkości, a nie szczelną granicę. W małej organizacji jedna osoba może pełnić obie role. W dużym programie role bywają rozdzielone między kilka zespołów. Najważniejsze jest to, aby żadna z perspektyw nie zniknęła między „biznesem” a „technologią”.
Porównanie odpowiedzialności
| Wymiar | Analityk biznesowy | Analityk systemowy |
|---|---|---|
| Główne pytanie | Dlaczego i dla kogo wprowadzamy zmianę? | Jak system ma zrealizować uzgodnione zachowanie? |
| Zakres | Cel, proces, interesariusze, reguły biznesowe, wartość | Funkcje, dane, stany, integracje, interfejsy, ograniczenia |
| Typowe źródła | Użytkownicy, właściciele procesu, dane operacyjne | Wymagania, istniejące systemy, API, model danych, logi |
| Rezultaty | Karta potrzeby, model procesu, wymagania, warianty | Specyfikacja systemowa, model danych, kontrakt API, sekwencje |
| Główni partnerzy | Biznes, produkt, operacje, UX | Architekt, programiści, testerzy, administratorzy |
| Ryzyko przy braku roli | Poprawnie zbudowane rozwiązanie niewłaściwego problemu | Dobra idea opisana zbyt ogólnie, by bezpiecznie ją wdrożyć |
Jeden projekt, dwie perspektywy
Bank chce umożliwić klientowi zmianę limitu karty w aplikacji. Analityk biznesowy ustala, dlaczego klienci dzwonią na infolinię, jakie grupy mogą skorzystać z samoobsługi, jakie ryzyko akceptuje właściciel produktu oraz jaki spadek liczby połączeń będzie sukcesem. Modeluje obecny proces i uzgadnia przyszły: wniosek, ocena, decyzja, informacja dla klienta.
Analityk systemowy bierze uzgodniony proces i doprecyzowuje zachowanie rozwiązania. Określa dane wejściowe, walidacje kwoty, źródło aktualnego limitu, kolejność wywołań usług, statusy wniosku, mechanizm ponowienia po błędzie oraz komunikaty. Uzgadnia z architektem, który system jest właścicielem danych, a z testerem — jak zasymulować odmowę z usługi scoringowej.
Obie osoby pracują nad tą samą zmianą. Jeżeli warunek „klient nie może mieć zaległości” zostanie odkryty podczas analizy integracji, musi wrócić do walidacji biznesowej. Jeżeli biznes zmieni dopuszczalny zakres kwot, trzeba ocenić wpływ na reguły systemowe i testy. Przekazanie dokumentu „przez płot” nie wystarczy.
Gdzie role się przenikają
Reguły biznesowe
Znaczenie reguły i jej właściciel należą do perspektywy biznesowej. Sposób odwzorowania reguły, źródła danych i zachowanie w razie braku wartości wymagają perspektywy systemowej. Obie strony powinny korzystać z tej samej identyfikowalnej definicji.
Wymagania niefunkcjonalne
Biznes określa skutek: klient ma otrzymać decyzję w czasie akceptowalnym dla procesu. Analiza systemowa przekłada go na mierzalne warunki, np. percentyl czasu odpowiedzi, obciążenie oraz zachowanie przy niedostępności zależności. Więcej przykładów zawiera tekst wymagania niefunkcjonalne w praktyce.
Kryteria akceptacji
Kryteria opisują uzgodniony rezultat widoczny dla odbiorcy, ale muszą uwzględniać realne stany systemu. Ich przygotowanie jest dobrą okazją do wspólnego przeglądu obu perspektyw, zanim zakres trafi do implementacji.
Kontrakt współpracy między rolami
- Wspólny słownik: nazwy statusów, zdarzeń i danych mają jedną definicję.
- Ślad celu: elementy specyfikacji systemowej wskazują wymaganie lub regułę, z której wynikają.
- Jawne założenia: informacja niepotwierdzona nie jest przedstawiana jako decyzja.
- Dwukierunkowa informacja: ograniczenie techniczne wraca do oceny biznesowej, a zmiana potrzeby do analizy wpływu.
- Wspólny przegląd: proces, wymagania, dane i wyjątki są sprawdzane razem przed rozpoczęciem realizacji.
Kiedy wystarczy jedna osoba
Połączenie ról działa, gdy zakres jest umiarkowany, analityk zna domenę i system, a zespół zapewnia dostęp do ekspertów technicznych. Nie oznacza to pominięcia któregoś poziomu — ta sama osoba powinna osobno potwierdzić cel biznesowy, proces, wymagania oraz szczegóły systemowe.
Rozdzielenie jest korzystne przy wielu integracjach, złożonym modelu danych, regulowanym procesie albo kilku strumieniach biznesowych. Wtedy specjalizacja zmniejsza ryzyko, o ile nie tworzy kolejnej warstwy przekazywania informacji. Kryterium nie powinna być nazwa stanowiska, lecz złożoność pracy i kompetencje dostępnych osób.
Artefakt przekrojowy: mapa od celu do interfejsu
Dobrym wspólnym artefaktem jest prosta mapa śladu. Dla każdego celu pokazuje potrzebę interesariusza, krok procesu, wymaganie funkcjonalne, regułę, dane, dotknięty system i kryterium. Nie musi być rozbudowanym narzędziem — może być tabelą z identyfikatorami. Ważne, aby przejście między perspektywami było możliwe w obie strony.
Podczas przeglądu analityk biznesowy sprawdza, czy element systemowy nadal wspiera uzgodniony rezultat. Analityk systemowy wskazuje funkcje bez źródła, brakujące stany oraz ograniczenia, które zmieniają proces. Mapa ujawnia także „sieroty”: cel bez realizacji, endpoint bez wymagania albo test bez powiązanej reguły.
W małej zmianie wystarczy wspólna sesja przy jednej tablicy. W dużym programie warto ustalić konwencję identyfikatorów i automatyczne raportowanie brakujących relacji. Nie chodzi o pełną śledzalność wszystkiego, lecz o ślad dla elementów mających wpływ na wartość, zgodność i ryzyko.
Checklista podziału pracy
- Czy wiadomo, kto odpowiada za potwierdzenie celu i miary sukcesu?
- Czy ktoś modeluje przebieg procesu oraz odpowiedzialności poza systemem?
- Czy określono właścicieli danych, reguł i decyzji?
- Czy zachowanie systemu obejmuje ścieżki błędów i integracje?
- Czy wymagania biznesowe mają powiązanie ze specyfikacją systemową?
- Czy zmiany są komunikowane w obie strony?
- Czy testerzy i programiści uczestniczą w doprecyzowaniu odpowiednio wcześnie?
- Czy odbiorca wie, do kogo kierować pytanie biznesowe, a do kogo techniczne?
Na początku inicjatywy ustalcie też język eskalacji. Pytanie systemowe bez odpowiedzi może ujawnić brak decyzji biznesowej, a oczekiwanie biznesowe może być niewykonalne w terminie. Krótki przegląd zależności raz lub dwa razy w tygodniu pozwala przekazać te informacje bez tworzenia kolejnego formalnego etapu i oczekiwania na „gotową specyfikację”.
Podstawy pierwszej z ról opisuje artykuł kim jest analityk biznesowy. Jeśli zespół przechodzi właśnie od potrzeby do specyfikacji, pomocne będzie również rozróżnienie typów wymagań.
