Jakiś czas temu rozmawiałem ze managerem produktu o wpływie przejścia na metodyki zwinne (w tym przypadku framework Scrum), na jego organizację. Podobnie jak niektóre osoby, nie był zadowolony z tej metody. Problemem było to, że od czasu wdrożenia Scruma otaczające go zespoły były całkowicie czarnymi skrzynkami (ang. black box). Brak przejrzystości (transparentności), szczególnie w odniesieniu do rzeczy, nad którymi zespół pracuje / będzie pracował. Sytuacja to nie jest odosobniona i moim zdaniem (pewnie nie tylko moim), jest ona spowodowana “złą drogą” implementacji Scruma, złym sposobem jego implementacji.
Scrum Guide wymaga, aby Właściciel Produktu dopilnował, aby kluczowi interesariusze uczestniczyli w Przeglądzie Sprintu, ale kim są ci „kluczowi interesariusze”?
Kto to jest interesariusz (ang. stakeholder)?
Zgodnie ze Scrum Glossary, interesariuszem jest „osoba spoza Zespołu Scrumowego, która jest szczególnie zainteresowana jego pracą i produktem, który rozwija. Reprezentowana przez Właściciela Produktu (pol. Product Owner) i aktywnie współpracująca z Zespołem Scrumowym.„
Zazwyczaj osoby te należą do jednej z wymienionych kategorii:
- Użytkownicy zewnętrzni – osoby, które są skłonne zapłacić za korzystanie z produktu / oprogramowania
- Klienci wewnętrzni – osoby odpowiedzialne za podejmowanie decyzji o finansowaniu prac związanych z opracowywaniem oprogramowania
Zazwyczaj jest to osoba zarządzająca produktem lub osoba zarządzająca w linii biznesowej.
- Użytkownicy wewnętrzni – osoby, które korzystają z produktu wewnątrz firmy. Często, jeżeli istnieją “Użytkownicy wewnętrzni”, nie mamy już do czynienia z “Użytkownikami zewnętrznymi” (np. produkt tylko używany wewnętrznie)
Jedna uwaga – kluczowymi interesariuszami są osoby, które otrzymują bezpośrednią korzyść finansową (produkt pomaga im lub organizacji zarobić więcej pieniędzy lub zaoszczędzić pieniądze).
Można również zdefiniować interesariusza jako (waszą) organizację, której przedstawiciele powinni uczestniczyć w Przeglądach Sprintu, zastępując w ten sposób wszelkie raporty o statusie i postępach Zespołów Scrumowych. Jeśli zarząd (“wasza organizacja”) poprosi o raporty z postępów, odpowiedź powinna prawie zawsze brzmieć: „W Scrumie ta informacja jest przekazywana w ramach Przeglądu Sprintu, więc pozwól mi znaleźć cię na liście zaproszonych lub zaprosić”.
W niektórych przypadkach będziecie mieli tak wielu „użytkowników”, że często nie będzie możliwa ich fizyczna obecność podczas Review. W takich przypadkach postaraj się uzyskać reprezentatywną próbę użytkowników i/lub skorzystaj z innych mechanizmów gromadzenia opinii (np, ankiety).
Dlaczego tak ważne jest, aby interesariusze uczestniczyli w pracach zespołu
Rozmawiając z wieloma osobami, czy to od strony biznesu czy też od strony technologicznej, doszedłem do wniosku, że najważniejszym czynnikiem sukcesu projektu / produktu jest bieżący udział zainteresowanych stron w procesie. W tradycyjnych metodykach, wkład interesariuszy jest wymagany na początku projektu (w celu zatwierdzenia specyfikacji) i na końcu (w celu zatwierdzenia, że oprogramowanie spełnia specyfikację).
Jak pisze Stefan Wolpers w swoim artykule “32 Scrum Stakeholder Anti-Patterns”, w starszych metodykach lub bardziej w całych organizacjach je stosujących, łatwo dostrzec jakąś formę Tayloryzmu, objawiająca się ścisłą hierarchią dowodzenia i kontroli funkcjonalnych silosów o ograniczonej autonomii. Często takie organizacje były tworzone po to, aby szkolić “chłopców z farmy” na pracowników linii montażowych w ramach znormalizowanego procesu przemysłowego, produkującego znormalizowane produkty w imię optymalizacji wydajności.
W Agile wkład stakeholderów jest dużo większy – są proszeni o udział we wszystkich wydarzeniach zespołu, a także konieczne są ich codzienne interakcje z zespołem Scrumowym. Jednak jak słusznie zauważa Semi Koen w artykule “From FrAgile to Agile with the Stakeholders’ Buy-in“, trudno jest dopasować kołek w kształcie Agile, do otworu w kształcie nadanym przez biznes (ang. It is hard to fit an Agile-shaped peg into a business-shaped hole).
Jeszcze jednym wątkiem związanym z uczestniczeniem stakeholderów w pracach zespołu są ich konflikty. Często interesariusz jest menedżerem “funkcjonalnego silosu”, którego cele niekoniecznie są zgodne z celami produktu lub Zespołu Scrumowego. Tam, gdzie organizacja musi przekształcić się w coś w rodzaju struktury „zespołu zespołów” ze wspólnym zrozumieniem celu i kierunku, a także potrzebą stworzenia wartości dla klientów, rzeczywistość może generować bardzo różne zjawiska / postępowania. Takie przejście organizacji z myślenia “silosowego” na myślenie holistyczne, może dla menedżerów silosów oznaczać przejście od WIIFM (ang. What’s In It For Me, pol. Co ja z tego będę miał?) do gry zespołowej, co z jednej strony jest trudne, a z drugiej bardzo czasochłonne.
Ludzie nie są zbyt dobrzy w określaniu czego chcą. Jednak z drugiej strony jako ludzie jesteśmy dobrzy w wskazywaniu tego, co myślimy, że chcemy. Zwłaszcza, kiedy już coś zobaczymy i możemy określić, co nam się podoba, a co nie. Innymi słowy, musimy współpracować z naszymi interesariuszami, aby określić szczegółowo ich wymagania, stworzyć coś, co odzwierciedla to zrozumienie, uzyskać ich opinie, a następnie zaktualizować nasze rozwiązanie, aby odzwierciedlić nasze lepsze zrozumienie. Implikacja polega na tym, że musimy pracować w sposób bardziej ewolucyjny i oparty na współpracy, jeśli mamy zapewnić rozwiązania, które odzwierciedlają rzeczywiste potrzeby naszych interesariuszy, i aby to zrobić, musimy ściśle i regularnie z nimi współpracować.
Pracujmy razem, ale jak?
Oczywiste jest, że aby odnieść sukces, wszyscy interesariusze muszą aktywnie współpracować z zespołem. Istnieje kilka “strategii” tej praktyki:
- Terminowe decyzje
Zainteresowane strony muszą być przygotowane do dzielenia się wiedzą biznesową z zespołem oraz do podejmowania trafnych i terminowych decyzji dotyczących zakresu projektu i priorytetów wymagań.
- Zarządzanie wymaga umiejętności i wiedzy informatycznej
Aby managerowie (zwłaszcza biznesowi) skutecznie wspierali wasz projekt, muszą najpierw zrozumieć technologie i techniki, z których korzysta zespół. Zrozumieć, dlaczego zespół z nich korzysta i poznać konsekwencje ich użycia. Dzięki tej wiedzy ich wysiłki dotyczące kwestii odnośnie projektu / produktu na poziomie całej organizacji, będą bardziej skuteczne. Managerowie nie będą w stanie zdobyć wymaganej wiedzy czytając cotygodniowy raport o stanie projektu / produktu lub na przykład uczestnicząc w comiesięcznym spotkaniu. Zamiast tego muszą poświęcić niezbędny czas, aby dowiedzieć się o rzeczach, którymi zarządzają, muszą aktywnie uczestniczyć w rozwoju systemu.
- Interesariusze są zaangażowani od samego początku
Organizacja musi zainwestować szeroko rozumiane zasoby niezbędne do zrozumienia zarówno waszego systemu, jak i wykorzystywanych technologii. Interesariusze powinni poświęcić czas na poznanie niuansów, co implikuje konieczność współpracy z zespołem w miarę rozwoju projektu / produktu.
- “Widok” całego przedsiębiorstwa
W pracach nad nowym oprogramowaniem musicie współpracować z innymi zespołami projektowymi, jeśli wasz system wymaga integracji z innymi systemami. Na przykład, być może wasz system potrzebuje dostępu do starszej bazy danych, interakcji z systemem online, pracy z plikiem danych wygenerowanym przez system zewnętrzny lub dostarczenia wyciągu danych w postaci XML. Integracja często okazuje się trudna, jeśli nie niemożliwa bez aktywnego udziału innych zespołów. I w tym wypadku to te “inne zespoły” będą jednym z interesariuszy waszej pracy.
Uczestnicy, czy tylko obecni?
Różnica między uczestnictwem (ang. participation; przyjdź na spotkanie i mów), a braniem udziału (and. attend; przyjdź na spotkanie, ale nie mów) jest trudna do zdefiniowania.
Trudność wynika z mieszania pojęć „kluczowych interesariuszy” i „ekspertów technicznych”. Kluczowymi interesariuszami są zazwyczaj klienci, nabywcy, użytkownicy oraz osoby finansujące rozwój produktu.
Z drugiej strony, w części dotyczącej Planowania Sprintu, Scrum Guide stanowi, że „Zespół deweloperów może również zaprosić inne osoby do udziału, w celu udzielenia porad technicznych lub porad dotyczących domeny”.
Z tego wynika, że takie osoby („eksperci techniczni”), nie są kluczowymi interesariuszami. Są ekspertami technicznymi i dziedzinowymi. I udzielają oni porad technicznych.
Interesariusze powinni pojawiać się na Przeglądach Sprintu, natomiast eksperci ds. technicznych powinni również uczestniczyć w Planowaniu Sprintu, jeżeli jest taka potrzeba.
Inne spojrzenie na temat uczestnictwa ma Przeglądzie Sprintu interesariuszy ma przytoczony wyżej Stefan Wolpers. Pisze on o pasywnych interesariuszach, nie zaangażowanych jako jednym z wielu anty-wzorców zaangażowania stakeholderów w procesy pracy zespołu. Podaje też receptę na taką postawę – pozwól interesariuszom poprowadzić Przegląd Sprintu i postawić się im na świeczniku. Lub zorganizować dla nich Shift & Share.
Podsumowanie
Na zakończenie wpisu, chciałem się z wami podzielić zestawieniem charakterystyk, które zostały oryginalnie przygotowane przez portal agilemodeling.com, a które opisują różne cechy interesariuszy i waszej współpracy z nimi.
| Charakterystyka | Zakres | Potencjalny wpływ |
| Styl współpracy | Reaktywny ⇔ Proaktywny | Zainteresowane strony (np. interesariusze), które proaktywnie uczestniczą w rozwoju produktu, mogą mieć dalszą wizję, którą starają się realizować. Interesariusze, którzy pracują w sposób reaktywny, mogą spowolnić projekt, ponieważ zespół musi czekać na odpowiedzi (Właściciel Produktu będzie musiał zgadywać odpowiedź, zwiększając prawdopodobieństwo potencjalnej przeróbki w przyszłości). |
| Relacje | Negatywne ⇔ Pozytywne | Gdy relacje pomiędzy IT a interesariuszami są negatywne, interesariusze prawdopodobnie będą uczestniczyć rzadziej i w mniejszym stopniu w pracach zespołu. |
| Kanały komunikacji | Formalne ⇔ Nieformalne | Formalna komunikacja, taka jak np. pisemna dokumentacja w określonym formacie, może zwiększyć biurokratyczne obciążenie zespołu, zwiększyć koszty projektu i wydłużyć czas potrzebny na dostarczenie rozwiązania. Nieformalne strategie komunikacji, takie jak komunikacja bezpośrednia, zmniejszy ogólną złożoność i koszty przedsięwzięcia, a często skraca również czas wprowadzenia produktu na rynek. |
| Dostępność | Nieregularna ⇔ Stała | Gdy interesariusze nie są regularnie zaangażowani w pracę zespołu, zwiększa się szansa, że zespół zbuduje niewłaściwe rozwiązanie. |
| Lokalizacja | W jednym miejscu ⇔ globalna | Gdy zespół znajduje się w tym samym miejscu, co interesariusze, znacznie łatwiej jest im regularnie i aktywnie współpracować. W miarę, jak zespół staje się bardziej rozproszony geograficznie, szanse na sukces projektu maleją. |