W tym cyklu artykułów opisuję – na podstawie własnych doświadczeń – od czego zależy sukces analizy biznesowej w SCRUM. W poniższym wpisie skupię się na znajomości dziedziny, która w przypadku Analityka Biznesowego jest niezwykle ważna, jako że jego osoba stanowi niejako łącznik pomiędzy biznesem a IT.
Znajomość dziedziny
Kompetencje miękkie, o których pisałem w poprzednich wpisach, są podstawą pracy analityka. Niemniej jednak bez odpowiedniej wiedzy merytorycznej oraz biznesowej szanse na powodzenie projektu są raczej niewielkie. W tym wpisie dowiesz się, jak wiedza biznesowa pomoże ci dobrze udokumentować procesy i zaplanować skuteczne spotkania z uwzględnieniem realiów pracy firmy, z którą współpracujesz.
Dokumentacja procesów w SCRUM
Dobrze rozwinięte firmy wykorzystują w swojej pracy podejście procesowe. Wdrażanie systemów informatycznych zawsze ma jeden cel: zwiększenie zysku poprzez minimalizację kosztów. Koszty można minimalizować na różne sposoby, jednym z nich jest optymalizacja procesów np. procesu zatrudniania nowego pracownika (i związanego z tym przydzielania sprzętu, organizacji szkoleń, podpisania odpowiednich dokumentów).
W takim przypadku przy podejściu kaskadowym powstałyby:
- diagram procesu,
- macierz uprawnień,
- szczegółowy opis przypadków użycia,
- projekty interfejsu użytkownika
- i jeszcze kilka innych dokumentów.
Powstałyby one na pierwszym etapie projektu tj. w fazie analizy, po czym nastąpiłaby realizacja całości zakresu wymagań.
Przy podejściu zwinnym ważne jest zidentyfikowanie celu biznesowego i podzielenie analizy na etapy:
- minimalny kształt procesu umożliwiający osiągnięcie celu (wymagania typu „Must Have”),
- podzielenie procesu na etapy wytwarzania (np. przygotowanie POC, implementacja podstawowych wymagań, profilowanie rozwiązania).
Przy takim podejściu analitycznie na początku dokumentujemy tylko podstawowy przebieg procesu oraz wykrywamy istotne zależności. Z każdym kolejnym sprintem doprecyzowujemy poszczególne jego elementy.
Korzyści są dwie: stosunkowo mała część analizy trafi do kosza w przypadku zmiany wymagań oraz od początku wytwarzamy system spójny z dalszymi etapami rozwoju.
Przekładając to na pojęcia SCRUM (i upraszczając), możemy powiedzieć, że duży Proces to „Theme” (mniejszy to „Epic”), faza dużego procesu to „Epic” a pojedyncze aktywności w procesie to „User Stories”.
Znajomość klienta i dziedziny
Klienci przedstawiając wizję rozwiązania lub istniejące problemy, często posługują się swoim codziennym językiem zawodowym (językiem dziedzinowym). Zakładają oni przy tym, że Ty jako analityk rozumiesz, o czym mówią.
Znajomość dziedziny jest ważna z dwóch powodów. Po pierwsze wskazuje na to, że znasz i rozumiesz procesy i problemy, które ma rozwiązać opisywane przez Ciebie narzędzie. Po drugie (ważniejsze) buduje twój wizerunek jako osoby profesjonalnej, partnera do współpracy a w pewnych przypadkach nawet autorytetu. Dzięki temu łatwiej będzie Ci przekonać klienta do rozwiązań, które w lepszy sposób spełnią jego oczekiwania, pomimo tego, że być może w tej chwili jeszcze nie widzi tego tak wyraźnie.
Dlaczego warto poznać klienta?
W kontekście znajomości klienta ważne jest dobre zrozumienie jego charakterystyki pracy, struktury organizacyjnej, specyficznych pojęć (charakterystycznych tylko w jego organizacji) oraz jego interpretacji istniejących specyfikacji czy instrukcji. Jakie informacje mogą się przydać i kiedy:
- Faktyczny sposób realizacji procedur w firmie – jeżeli klient literalnie realizuje procedury, które posiada i znajduje to odzwierciedlenie w systemach informatycznych, możesz się spodziewać, że jeżeli dobrze udokumentujesz wymagania, to zostaną one odebrane bez niespodziewanego koncertu życzeń.
- Struktura organizacyjna (pozioma i pionowa) i projektowa w firmie – dobre zrozumienie pozwoli Ci uniknąć nieporozumień przy modelowaniu procesów, modelowaniu przebiegu eskalacji zgłoszeń (do przełożonego i wyżej) oraz określaniu kto co powinien widzieć w aplikacji. Jest to szczególnie ważne, w organizacjach posiadających biura w różnych lokalizacjach z rozbudowanymi strukturami projektowymi.
- Charakterystyka pracy – dowiedz się w jakich terminach poszczególne działy klienta, z którymi będziesz współpracował, są najbardziej zapracowane oraz czy jest dostępny kalendarz urlopów. Następnie wykreśl te daty ze swojego kalendarza. W tych terminach nic nie ustalisz. Przykładowo na pewno będą to pierwsze i ostatnie dni miesiąca (przelewy pensji, rozliczenia czasu pracy), zamykanie roku rozliczeniowego oraz np. sierpień (miesiąc, w którym w wielu firmach produkcyjnych planowane są masowe urlopy).
W kolejnym, ostatnim już poście pochylę się nad znajomością narzędzi, zarówno rozwijanych systemów, jak również narzędzi, które automatyzują i przyspieszają prace analityczne.
***
Wszystkie artykuły z serii znajdziesz tutaj:
Zostaw komentarz