analizawymagan, pracaanalityka

Jak nie pominąć żadnego interesariusza

Posted by admin

Na szczęście nie za często ale czasami potrafi się zdarzyć sytuacja w projekcie gdzie zostanie pominięta ważna osoba, która już w trakcie trwania developmentu poprzewraca nam wymagania do góry nogami.

Samemu mi się zdarzyło być takim pominiętym interesariuszem w jednym z projektów. Nie chciałem ale musiałem wtedy sporo namieszać w projekcie i zakończyło się to niczym innym a opóźnieniem(czyli jakby nie patrzeć porażką z racji przekroczenia zakresu).

Z racji że nie są to zbyt przyjemne doświadczenia to staramy się ich unikać jak najczęściej. W tym poście postaram się opisać swoje sposoby na niepomijanie interesariuszy w projekcie.

1. Pierwsze i najważniejsze w przypadku wymagań to cel biznesowy

Samo określenie celu biznesowego potrafi nam wyczerpać temat interesariuszy. Przykładowo chcemy skrócić proces raportowania zgłoszenia który raportują tylko użytkownicy z jednego zespołu o określoną ilość minut np. z 5 do 2 minut. Projekt ma zostać zrealizowany do określonej daty.

W takim przypadku droga jest uproszczona. Wiemy kto jest użytkownikiem końcowym. Osobą odpowiedzialną w 95% przypadków będzie osoba zarządzająca podanym wcześniej zespołem. Zostaje nam określić sponsora danej zmiany i eksperta od danych zgłoszeń.

2. Struktura organizacyjna 

Kolejnym krokiem jest analiza struktury organizacyjnej. Jakie są jednostki w organizacji? Za co odpowiadają? Jak ze sobą różne jednostki współpracują itp. Analiza samej struktury potrafi bardzo dużo powiedzieć o funkcjonowaniu samej firmy.

 3. Proces biznesowy

Zastanawiałem się nad umieszczeniem procesu jeszcze wyżej aczkolwiek uznałem że ważniejszy jest człowiek „otaczający” dany cel niż sam proces. Jak najlepiej wykryć interesariuszy w danej zmianie? Najprościej jak się da to zobaczyć jakiego procesu dotyczy nasz cel biznesowy i z jakimi procesami się łączy. Po poznaniu polityk, zasad, reguł z łatwością można wskazać jednostki które uczestniczą w trakcie procesu który jest zmieniany.

4. Typy interesariuszy

Ten podpunkt traktuję zawsze jako framework do zmian które są wykonywane w danym projekcie. W każdym projekcie mamy poszczególne role do odegrania. Czasami niektóre role są odgrywane przez jedną osobę równocześnie ale zawsze ta rola musi być odegrana aby projekt się udał. Dlatego po wypełnieniu każdej z tych ról jestem pewien że na 80% nie pominąłem kogoś(a jeśli kogoś pominąłem to wykryje to w procesie i strukturze. Te role mam zawsze w postaci checklisty i sprawdzam czy każda jest wypełniona:

1. Analityk biznesowy
W skrócie osoba która:
-pozyskuje wymagania
-analizuje wymagania
-specyfikuje wymagania
-projektuje rozwiązania
-jest obecny przy wytwarzaniu oprogramowania(odpowiada na pytania programistów)
-wspomaga testerów przy określeniu czy potrzeba biznesowa jest spełniona.

2. Klient/Sponsor
 Osoba która jest odpowiedzialna za finansowanie projektu, za kształt zespołu projektowego, za podejmowanie kluczowych decyzji i za informowanie o zmianach w otoczeniu projektu(organizacji)

3. Eksperci w danej dziedzinie (biznes)
Osoby które posiadają wiedzę na temat danego procesu, ograniczeń prawnych, polityk firmy itp. Bardzo dobrym przykładem są tutaj specjaliści od RODO w poszczególnych organizacjach. Często się zdarza że ekspertami są użytkownicy końcowi.

4. Użytkownik końcowy
Osoba która będzie korzystać z rozwiązania

5. Ekspert od implementacji
Tutaj osoba która odpowiada za to jak ma być coś zaimplementowane. Często jest to Architekt, lider technologiczny aczkolwiek zdarzało się że zespół developerski chciał skorzystać z zewnętrznych konsultacji.

6. Osoby wspierające użytkowników w codziennej pracy
tzw. pierwsza linia wsparcia. Często specjalne zespoły w IT. Często też dedykowane osoby do wspierania z poszczególnych aplikacji.

7. Kierownicy projektu
Osoby odpowiedzialne za zarządzanie pracą do wykonania aby projekt był wdrożony w umówionym zakresie w umówionym czasie.

8. Osoba sprawdzająca standardy, zgodność z prawem itd.
Często się łączy z pkt. 3. Osoba która sprawdzi czy dane rozwiązanie nie łamie prawa, procedur czy kultury organizacyjnej.

9. Zewnętrzni dostawcy
Przykładowo wdrażane rozwiązanie potrzebuje informacji z innego systemu. Ten drugi system jest już kolejnym dostawcą i interesariuszem.

10. Testerzy
Ludzie odpowiedzialni za jakość danych rozwiązań. Ważne jest to żeby działające funkcjonalności spełniały też cel biznesowy. Dlatego ważne żeby współpracować z testerami.

5. Przydatne techniki

 Kolejne techniki które są polecane przez innych z których sam korzystałem i nie podpasowały do mojego stylu(nie że nie działają bo działają i dlatego je polecam -> może się spodobają Tobie).

1. Macierz RACI
https://pl.wikipedia.org/wiki/Macierz_odpowiedzialno%C5%9Bci

2. Cebulowa mapa interesariuszy
http://www.bawiki.com/wiki/Stakeholder-Onion-Diagram.html

6. Jak tym zarządzać? 

Jedyna fajna technika którą spotkałem to matryca wpływu i zaangażowania. Niczego lepszego nie trafiłem(jak widziałeś/łaś coś lepszego to prośba o kontakt).

https://analizowac.pl/wp-content/uploads/2020/01/6132fe33c4a6e56d3017c45b6785a3aaf84db772_large-300x300.jpg

SZKOLENIE "Czy zawód Analityk IT jest dla mnie?"

Zapisz się na listę mailową a prześlę za darmo szkolenie Czy zawód Analityk IT jest dla mnie? Co muszę umieć żeby być Analitykiem IT?