Analiza biznesowa

Czynniki sukcesu analizy w projektach zwinnych

Grudzień 21, 2015 0
Podziel się:

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łby 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, a 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.

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.

Oceń ten post
Kategorie: Analiza biznesowa
Cezary Kamiński
Autor: Cezary Kamiński
Product Owner aplikacji opartych o platformę Sharepoint Server 2013 oraz Scrum Master w zespole integrującym systemy wykorzystywane w Sii. Odpowiedzialny za specyfikację wymagań, zarządzanie backlogiem produktów oraz szerokorozumiany kontakt z klientem wewnętrznym. Wcześniej przez 4 lata (w rolach analityk > kierownik zespołu deweloperskiego) dostarczał aplikacje dla administracji publicznej na poziomie samorządowym i centralnym. Po godzinach utrzymuje aktywny kontakt z naturą (doskonaląc technikę jazdy enduro).

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz