Pomiar wartości dla interesariuszy projektów wytwarzania oprogramowania

Pomiar wartości dla różnych grup interesariuszy zespołów projektowych jest dużym wyzwaniem, ponieważ wartości te ciężko jest prognozować i szacować, podlegają one subiektywnej i nieprzewidywalnej ocenie w dynamicznym procesie cyklu życia projektu oraz

198

produktu, a także pozostają, podobnie jak i realizowany projekt, pod wpływem znacznej liczby czynników projektowych i organizacyjnych, takich jak nowe technologie, digitalizacja, czy nowe metody zarządzania i organizowania pracy (Łada i Kozarkiewicz, 2010).

Wartość projektu powinna być analizowana w kontekście wybranych grup interesariuszy, z tym jednak, że wyróżnione grupy interesariuszy są wzajemnie od siebie zależne. Nie jest, więc możliwe tworzenie wartości i pomiar wyłącznie dla wybranej grupy, a to powoduje dodatkowe wyzwanie w opracowaniu samego sposobu pomiaru, jak i pomiaru wartości, które zapewniałyby stan równowagi pomiędzy tymi grupami. Ponadto, kryteria oceny i preferowane sposoby pomiaru wartości będą inne dla właścicieli, zarządzających, inne dla zespołu projektowego, a często również inne dla klienta i użytkownika produktu projektu (Łada i Kozarkiewicz, 2010). Ponieważ nie ma jedynego słusznego sposobu pomiaru wartości poszukiwania będą dotyczyć takiego sposobu pomiaru, który pasowałby do specyfiki projektów wytwarzania oprogramowania realizowanych z wykorzystaniem zwinnych metod organizacji pracy w zespołach projektowych, na co odpowiedzią jest niniejsza praca.

Pomiar wartości dla różnych grup interesariuszy zespołu projektowego w proponowanym modelu będzie stanowił rozwiązanie hybrydowe, ponieważ - jak zostało wcześniej wspomniane - nie jest możliwa ocena wartości wyłącznie dla wybranej grupy interesariuszy, bez tworzenia wartości dla pozostałych grup. Pomiar wartości dla właścicieli powinien uwzględniać i zawierać w sobie: pomiar satysfakcji klientów, pomiar przychodów ze sprzedaży, pomiar zadowolenia członków zespołu projektowego z możliwości rozwoju zawodowego, systemu wynagrodzeń i systemu motywacyjnego oraz pomiar siły relacji z partnerami, dostawcami i innymi grupami interesariuszy (Kozarkiewicz, 2012). W szczególności jest to widoczne na przykładzie właścicieli przedsiębiorstwa oraz właściciela produktu, który reprezentuje w tym wypadku interesy przedsiębiorstwa i tychże właścicieli. Właściciel produktu posiada perspektywę produktu rozwijanego przez zespół projektowy, perspektywę zespołu, który ma największy wpływ na tworzony produkt, jak i perspektywę klienta, który realizuje swoje oczekiwania, co do rozwijanego produktu.

Pomiar z perspektywy właścicieli będzie związany bardziej z obiektywnymi miernikami ilościowymi, w odróżnieniu od perspektywy klienta i użytkownika, których ocena lub pomiar jest w dużej mierze subiektywna. Dzieje się tak ze względu na specyfikę projektów wytwarzania oprogramowania, w których właściciel dąży do ukończenia określonego produktu, o określonych cechach i funkcjonalnościach w celu zwrotu z inwestycji, a klient ten sam produkt, traktuje jedynie jak środek lub narzędzie do realizacji swojej wizji i oczekiwań, których realizacja ma mu przynieść zamierzone korzyści. Wizja klienta bardzo często nie jest

199

znana w trakcie planowania projektu, ani dla właściciela, ani dla zespołu projektowego, ponieważ zazwyczaj powstaje ona w głowie klienta w trakcie jego realizacji, co więcej złożoność technologiczna powoduje znaczne rozbieżności pomiędzy tym, co jest możliwe do zrealizowania, a tym, czego oczekiwałby klient od gotowego produktu.

Pomiar wartości dla klienta i użytkownika ma kluczowe znaczenie i jest znacznie bardziej skomplikowany, głównie, dlatego, że w dużej mierze jest on subiektywny. Pomiar ten powinien być wykonywany w ciągu całego cyklu trwania projektu od planowania koncepcji produktu, przez fazę realizacji projektu, po etap wykorzystania produktu, ponieważ wartość projektu powstaje w ciągu całego cyklu jego życia (Łada i Kozarkiewicz, 2010; Kozarkiewicz, 2012). Dla zespołów pracujących z metodykami zwinnymi pomiar ten będzie tym wiarygodniejszy im proces będzie bardziej iteracyjny, ponieważ w częstych i stałych interwałach czasu dostarczany jest jednocześnie fragment koncepcji produktu, działający fragment jego funkcjonalności oraz prezentacja dla klienta, która pozwala zebrać od niego natychmiastową informację zwrotną, a tym samym już po kilku iteracjach można podjąć się wiarygodnej oceny wartości dla klienta. W tej sytuacji klient czy sam użytkownik może łatwiej ocenić czy dany fragment dostarczonej funkcjonalności oprogramowania spełnia jego oczekiwania i czy pozwala na choćby częściową realizację jego wizji, ewentualnie, co trzeba by zmienić w dostarczonej już części produktu, aby tę wizję zrealizować, lub przynajmniej się do niej zbliżyć w kolejnych iteracjach.

Zakres, jakość, termin realizacji projektu bardzo często określane są przez klienta, a w metodykach zwinnych klient jest traktowany na zasadzie członka zespołu projektowego, choć de facto nim nie jest. O pomiarze decydują w dużym stopniu korzyści ekonomiczne, techniczne oraz społeczne stanowiące wartość postrzeganą przez klienta, za którą będzie on w stanie zapłacić z uwzględnieniem cen produktów konkurencyjnych lub substytutów (Kozarkiewicz, 2012). Koncepcja zarządzania projektami dyktowanego przez klienta (customer-driven project management) jest szczególnym przykładem, w którym rola klienta jest bardzo uwidoczniona i kluczowa, a jego udział na każdym etapie cyklu życia projektu jest naturalną częścią każdego dnia projektu (Barkey i Saylor, 2001). Koncepcja ta jest bardzo silnie zbieżna z częstym zaangażowaniem klienta w prace zespołu w zwinnych metodach organizacji pracy, co powinno w rezultacie przełożyć się na łatwiejszy i dokładniejszy pomiar wartości z perspektywy klienta i użytkownika rozwijanego w projekcie produktu.

Pomiar wartości dla członków zespołów projektowych jest równie trudny, jak pomiar wartości dla klienta, ponieważ i w tym wypadku ocena jest bardzo subiektywna, a korzyści, zarówno materialne, jak i niematerialne zależą nie tylko od wyniku całego zespołu, ale

200

również od indywidualnego zaangażowania w realizację zadań w zespole projektowym. Pomiar korzyści niematerialnych w postaci: możliwości zdobywania nowej wiedzy i doświadczenia, nowych umiejętności technicznych jak i kierowniczych, nawiązywania kontaktów i rozwoju umiejętności pracy w grupie jest niezwykle trudny, a jednocześnie bardzo istotny z perspektywy projektów wytwarzania oprogramowania, gdzie bardzo często zatrudniani są wysokiej klasy specjaliści stale poszukujący nowych wyzwań, możliwości rozwoju i awansu, a nie tylko wymiernych korzyści finansowych. Ponieważ wartości dla różnych grup interesariuszy są od siebie wzajemnie zależne, to wyniki pomiaru satysfakcji z pracy zespołu projektowego będą wpływać na wyniki pomiaru wartości dla klienta, a tym samym i dla właścicieli (Łada i Kozarkiewicz, 2010).

Jednym z najpopularniejszych i relatywnie nowych narzędzi w nowoczesnym zarządzaniu, które pozwala na pomiar i ocenę jest zrównoważona karta wyników (Balanced Scorecard, BSC) wskazująca na cztery różne perspektywy oceny i pomiaru wyników przedsiębiorstwa – finansowej, klienta, procesów wewnętrznych oraz doskonalenia umiejętności i rozwoju, które zapewniają równowagę pomiędzy różnymi miernikami i wskaźnikami oraz celami krótko- i długoterminowymi (Kaplan i Norton, 1992). W wersji zmodyfikowanej i uwzględniającej zasady zwinności BSC może być wykorzystana do przygotowaniu długofalowej strategii budowania zwinności organizacyjnej (Gurd i Ifandoudas, 2014), a przy kolejnych modyfikacjach i doborze odpowiednich mierników w każdej z perspektyw, szczególnie w perspektywie rozwoju silnie związanej z podejściem zwinnym – do pomiaru i oceny zwinności zespołu projektowego i wartości dla interesariuszy tego zespołu.

Mistrz scruma, trener agile lub kierownik zwinnego zespołu projektowego pracując, na co dzień z zespołem jest w stanie dostarczyć zarówno subiektywnej (jakościowej), jak i obiektywnej (wymiernej liczbowo) oceny wartości dla różnych, wzajemnie od siebie zależnych grup interesariuszy zespołu projektowego, ocenę stopnia wykorzystania określonych praktyk zwinnych, jak również ocenę warunków i kontekstu, w jakim dany zespół funkcjonuje. Powiązanie różnego rodzaju ocen, z różnych perspektyw wzajemnie zależnych grup interesariuszy, w jeden wspólny model pomiaru zwinności zespołu projektowego powinno dostarczyć odpowiedź na zasadnicze pytanie: jak poziom zwinności przekłada się na wartość dla interesariuszy zespołu projektowego wytwarzającego oprogramowanie w postaci produktu powstającego w ramach realizacji projektu. W celu wyeliminowania zaburzeń losowych w dostarczonej ocenie będzie ona przeprowadzona za ustalony, uśredniony i dłuższy okres pracy danego zespołu projektowego, a więc będzie to równoznaczne z okresem kilkunastu iteracji / sprintów.