Odpowiedź.

Historia pytania:

W klasycznych projektach często występowały konflikty między analitykami a architektami, a także między analitykami systemowymi a biznesowymi: każdy starał się "przejąć" lub wręcz przerzucić część obowiązków. Wyraźne określenie granic stało się jednym z znaków dojrzałego zespołu.

Problem:

Niebezpieczeństwo polega na nakładaniu się i dublowaniu prac, co prowadzi do nieporozumień, utraty odpowiedzialności, opóźnień, a w niektórych przypadkach także do równoległej i sprzecznej pracy nad opisem tej samej części systemu.

Rozwiązanie:

Określane są artefakty i końcowe produkty dla każdej roli (np.: analityk biznesowy odpowiada za cele biznesowe, analityk systemowy — za specyfikacje funkcjonalne, architekt — za decyzje architektoniczne)
Na początku projektu przeprowadza się warsztaty/spotkania z wyraźnym omówieniem stref odpowiedzialności i uzgodnieniem dokumentów regulacyjnych (np. RACI-matrix)
Ważne jest regularne omawianie i korygowanie granic w miarę rozwoju projektu i zmiany kontekstu

Kluczowe cechy:

Przejrzysty podział ról i stref odpowiedzialności
Wyraźne określenie artefaktów oraz punktów wejścia/wyjścia między nimi
Stała komunikacja i kontrola styków między zadaniami

Pytania podchwytliwe.

Czy analityk systemowy powinien wchodzić na poziom projektowania architektury całego systemu?

Nie, architekt odpowiada za decyzje architektoniczne. Analityk doprecyzowuje wymagania, które architekt może wykorzystać, ale nie projektuje architektury całościowo.

Czy analityk biznesowy może zajmować się opisem ograniczeń technicznych bezpośrednio?

Zazwyczaj nie — analityk biznesowy formułuje wymagania biznesowe. Ograniczenia techniczne to obszar analityka systemowego lub architekta.

Jeśli opis zadania pochodzi od analityka biznesowego, czy analityk systemowy powinien dublować spotkanie z biznesem?

Nie, ale analityk systemowy musi upewnić się, że wszystko zrozumiał poprawnie i w przypadku wątpliwości zainicjować pytania.

Typowe błędy i antywzorce

Przerzucanie stref odpowiedzialności "z automatu"
Niejasne określenie końcowych produktów (artefaktów)
Konflikty z powodu braku regularnej komunikacji między rolami

Przykład z życia

Negatywny przypadek:

Dwie zespoły równolegle opracowywały jedną część systemu: analitycy pisali pseudo-architekturę, a architekci opisywali procesy biznesowe. W rezultacie specyfikacje się różniły, realizacja się opóźniała.

Plusy:

Próba przyspieszenia pracy

Minusy:

Dublowanie, różnice w dokumentach, utrata terminów

Pozytywny przypadek:

Wspólne warsztaty na początku, gdzie uzgodniono, kto za co odpowiada, udokumentowano granice i styki. W dalszej kolejności na każdym etapie przeprowadzano rewizje tych uzgodnień.