Sytuacja kobiet w IT w 2024 roku
11.05.20207 min
Mikołaj Kukurba

Mikołaj KukurbaBA/QAThe Software House

Jak spełnić życzenie nie tylko jednej strony projektu

Sprawdź, jak analiza interesariuszy pomoże Ci dobrze spełnić oczekiwania wszystkich zaangażowanych w konkretny projekt.

Jak spełnić życzenie nie tylko jednej strony projektu

Co dziecięca wyliczanka ma wspólnego z projektem? O dziwo bardzo dużo! Na początek wyobraźmy sobie, że mamy tylko jeden cukierek, który będzie symbolizował czas i pieniądze w projekcie, a do obdarowania mamy od dwóch do kilku osób. I teraz tak jak w tej wyliczance możemy wybrać osobę, dla której poświęcimy nasz czas i kasę, pomijając resztę osób.

Czy dzięki temu osiągniemy sukces projektu? Nie sądzę. W takim razie jak spełnić oczekiwania wszystkich zaangażowanych? Rozwiązaniem tego problemu jest analiza interesariuszy, o której piszę w dalszej części tekstu. Zapraszam!

Interesariusze na start

Interesariusze (ang. Stakeholders) to znane pojęcie dla każdego, kto choć raz brał udział w projekcie, nie tylko tym z branży IT. Jest to najważniejsze źródło tzw. wymagań. To dzięki poznaniu interesariuszy możemy dobrze zaprojektować system aplikację, jakiej oczekuje klient. Sukces naszego projektu w dużej mierze zależy od współpracy z zainteresowanymi osobami, grupami lub instytucjami [1].

Należy jednak pamiętać, że interesariusze mogą nam również wprowadzić wiele namieszać w wymaganiach. Po pierwsze nie wszyscy muszą być pozytywnie nastawieni do naszego rozwiązania, a po drugie różne grupy lub osoby mogą mieć sprzeczne ze sobą życzenia.

Zanim zaczniemy projektować rozwiązanie na podstawie wymagań zebranych od zainteresowanych, zastanówmy się skąd mamy wiedzieć, kto jest interesariuszem? Czy interesariusz to tylko użytkownik? Co w przypadku gdy pracujemy w tzw. agile? Może wtedy tylko zespół projektowy i Właściciel Produktu (ang.Product Owner) są naszymi interesariuszami? Dla porządku przypomnijmy sobie kim jest interesariusz:

(...) to grupa lub osoba powiązana ze zmianą, potrzebą lub rozwiązaniem. Interesariusz to każda osoba, grupa lub organizacja, która może mieć wpływ, lub na którą może wpływać nasz projekt, program, inicjatywa, operacja lub wykonane prace [1].

Teoria, teorią, ale kto jest tym na kogo nasze rozwiązanie będzie wpływać w praktyce? Jak go odnaleźć? W idealnym świecie Klient powinien dostarczyć nam listę osób zaangażowanych w projekt [1; 2], a dodatkowo jeżeli pracujemy tzw. agile, to wiedza o interesariuszach powinna być po stronie Product Ownera [1; 3].

Jak wiemy, świat idealny nie istnieje, więc z pomocą Klienta, Product Ownera powinniśmy przeprowadzić tzw. analizę interesariuszy, czyli tak naprawdę spisać wszystkie osoby, grupy, na które nasze rozwiązanie będzie miało wpływ. Pamiętajmy, że największym ryzykiem w analizowaniu interesariuszy jest… pominięcie kogoś [1; 2]. Jak tego uniknąć? Odpowiedź jest prosta: należy obrać cebulę ;)

Obieramy cebulę

Analiza interesariuszy niektórym może bardzo kojarzyć się z obieraniem cebuli, bo również może przyprawić o łzy :), ale pamiętajmy, że tak jak cebula dodaje smaku do naszych potraw i jest ich ważnym składnikiem, tak zebranie wszystkich interesariuszy jest istotnym elementem w projektowaniu rozwiązania. Popełnione błędy na tym etapie mogą skutkować dużymi zmianami w architekturze w kolejnej fazie projektu, a co gorsza mogą przyczynić się do niepowodzenia całego projektu. Dlatego warto poświęcić swój czas i energię na przestudiowanie m.in.:

  • potrzeby biznesowej, czyli cel projektu, 
  • struktury organizacyjnej, 
  • analiza stanu obecnego poprzez istniejące już procesy, raporty, dane, 
  • internal or external media such as blogs, online chat forums, newsletters, social media [1;2].


W trakcie tej pracy z pewnością będą miały miejsce wywiady z już dostępnymi interesariuszami, jak również burze mózgów, warsztaty i być może ankiety [2]. Należy pamiętać, że proces analizowania interesariuszy odbywa się od samego początku istnienia projektu i trwa do jego zakończenia, więc naszą utworzoną listę należy aktualizować. 

Po spisaniu listy znanych nam interesariuszy, kolejnym krokiem jest ustalenie z nimi komunikacji oraz ustalenie kluczowych grup dla naszego rozwiązania. Pamiętajmy, że nie wszyscy będą tak samo zaangażowani w nasz projekt oraz że nasze rozwiązanie nie będzie wpływać na ich działanie. Dlatego, aby ustalić priorytetowe osoby możemy wykorzystać do tego wspomnianą cebulę.

Jest to jedna z technik, która może nam pomóc ustalić, kto jest najważniejszy. Interesariuszy przypisujemy do kolejnych warstw cebuli, gdzie warstwa pierwsza to ta najbliżej naszego rozwiązania tak jak na przykładzie poniższego opisu:

Warstwa 1 - rozwiązanie: produkt, serwis lub rezultat.
Warstwa 2 - dostawcy rozwiązania: interesariusze z dziedziny rozwiązania, PM i/lib Scrum Master, Analityk Biznesowy i/lub Product Owner.
Warstwa 3 - dotknięte jednostki organizacji: interesariusze w obszarze działalności biznesu, na którą ma to wpływ.
Warstwa 4 - biznes, organizacja, przedsiębiorstwo, projekt: interesariusze, którzy są powiązani z interesariuszami z warstwy 2.
Warstwa 5 - dotknięci zewnętrzni udziałowcy: interesariusze, którzy są na zewnątrz organizacji, przedsiębiorstwa [1; 2].

Literatura podaje sporo różnych sposobów na grupowanie interesariuszy - zewnętrzni, węwnętrzni, czy też aktywni, bierni [3; 4]. Moim zdaniem diagram cebulowy (ang.onion diagram) oddaje bardzo dobrze podział. No dobrze, a co dalej? Mamy spisanych i pogrupowanych naszych interesariuszy i co teraz z nimi należy zrobić? Czyje wymaganie jest ważniejsze od innej grupy? Które wymaganie jest naszą gwiazdą na niebie, za którą będziemy podążać?

“Świeć gwiazdeczko mała świeć, do … wymagań prowadź mnie

No to zaczynamy zabawę z koncertem życzeń naszych interesariuszy. Jak priorytetyzować wymagania? Bardzo często bywa tak, że Sponsor naszego rozwiązania ma najważniejsze zdanie. I to jest prawda, w końcu “ja płacę to wymagam”. Niemniej jednak praktyka pokazuje, że należy przebić się przez tą barierę i dotrzeć do realnego użytkownika. Moje niedawne osobiste doświadczenia pokazują, że wizja wysokiego managementu bywa zupełnie inna, niż jest w rzeczywistości.

Typowi użytkownicy, grupa docelowa naszego rozwiązania, potrafi zgłosić inne problemy oraz potrzeby niż zgłaszają ich przełożeni. Dlatego tak istotne jest dotarcie do grupy docelowej. Znalezienie osób, które będą pozytywnie nastawione do naszej wizji rozwiązania i pomogą nam w przekonaniu innych do słuszności nowej drogi, ale nie poprzez narzucenie odgórne, a poprzez działanie mentorskie. W tym celu można wykorzystać jedną z technik wykorzystywaną również w marketingu i podzielić naszych interesariuszy na cztery grupy:

  • Przeciwnik: interesariusz, który jest odporny na zmianę i nie jest zainteresowany jej wprowadzeniem. Przeciwnik ma ważne wymagania związane z potencjalnym ryzykiem, które będziesz musiał wydobyć.
  • Dyrygent: interesariusz, który udziela porad i wskazówek dotyczących wymagań dotyczących zmiany. Przewodnik ma również ważne wymagania związane z potencjalnymi problemami i ryzykiem.
  • Adwokat: interesariusz, który jest aktywnym promotorem określonych wymagań związanych ze zmianą. Adwokat często ma porady techniczne i konkretną wiedzę, które pomogą ci w całym cyklu życia zmiany.
  • Agent zmian: interesariusz, który jest całkowicie zintegrowany ze zmianą. Agent zmiany jest ostatecznie odpowiedzialny za zapewnienie, że realizacja działań związanych z zmianą zakończy się sukcesem [1].


Takie pogrupowanie, dla lepszego przekazu, można zobrazować też w następujący sposób:

Jest to jeden ze sposobów wykorzystania tzw. mapy interesariuszy zwany również macierzą interesariuszy [4]. Wyżej przedstawiona mapa pokazuje nam zaangażowanie naszych interesariuszy w nasze rozwiązanie. Nie odpowiada jeszcze w pełni na postawione pytanie: czyje wymaganie jest ważniejsze? W tym celu możemy posłużyć się inną mapą interesariuszy: 

  • Macierz władzy/wpływu (ang.Power/influence matrix) - porównuje poziom władzy interesariusza z poziomem aktywnego zaangażowania interesariusza [1].



W prawym górnym rogu umieszczamy interesariusza najbardziej zaangażowanego i mającego największy wpływ na nasze rozwiązanie, np.Sponsora [2].

No dobrze. Pogrupowaliśmy sobie naszych interesariuszy i wiemy już czyje wymagania mają najwyższy priorytet, a które należy wziąć pod uwagę, ale nie muszę być zrealizowane w pierwszej kolejności. Czas przejść do trudniejszej fazy, czyli zarządzania naszymi interesariuszami.

“Pan tu nie stał!”

Jak już wcześniej wspominałem, jednym z większych ryzyk w trakcie analizy interesariuszy, jest pominięcie jakiejś z grup zainteresowanych. Kolejnym ryzykiem, jakie wiąże się z interesariuszami to umiejętne zarządzanie nimi. Do tego możemy wykorzystać kolejną mapę:

  • Macierz wpływu/zaangażowania (ang. Power/interest matrix) - porównuje poziom uprawnień interesariuszy z poziomem zaangażowania interesariuszy [1].


W lewym dolnym rogu umieszczamy osoby, do jakich należy wracać co jakiś czas, aby sprawdzić, czy być może zostali zaangażowani w nasz projekt trochę bardziej niż wcześniej. Na przeciwnym biegunie znajdują się osoby, które będą odbierać nasze rozwiązanie i dostarczają najważniejsze wymagania [2].

Dzięki powyższej mapie będziemy w stanie dbać o zadowolenie osób zaangażowanych w nasze rozwiązanie [2; 4], i jednocześnie będziemy budować zaufanie wobec naszej pracy, a jak wskazuje literatura:

when trust is low, speed slows down and costs go up. Conversely, when trust is high, speed accelerates, and costs go down [1].

Podsumowanie

Podsumowując, analiza interesariuszy nie jest łatwym zadaniem do wykonania. Jak głosi teoria powinno ono spoczywać na Product Ownerze, ale zawsze warto samemu, dla dobra projektu, przejść proces wyszukiwania grup lub osób, na jakie wpływa lub będzie wpływać nasze rozwiązanie. Należy przy tym uważać, aby nikogo nie pominąć.

Gdy już spiszemy naszych interesariuszy warto określić ich zaangażowanie i ustalić im priorytety oraz określić sposób komunikowania się z nimi. Wszystko po to, aby budować zaufanie, dzięki czemu nasza praca pójdzie szybciej i mniejszym kosztem. Ostatnim krokiem jaki należy wykonać po takiej analizie jest stworzenie tzw. Person dla wybranych grup z map, ale to już temat na inną opowieść ;)


Bibliografia

  1. Mastering Business Analysis Standard Practices; Kelley Bruns, Billie Johnson
  2. http://analizait.pl/2012/analiza-udzialowcow-nie-pomin-nikogo/; Hanna Wesołowska, analiza.it
  3. https://agile247.pl/interesariusze/; Dawid Lewandowicz
  4. https://mtc.pl/interesariusze-projektu/;
<p>Loading...</p>