„Oczywiście pracujemy na celach sprintu, biznesowo dostajemy wartość…”
„Podejmujemy kluczowe decyzje dot. funkcjonalności, tak by tworzyć dla klientów realną wartość…”
„Jak definiować zakres, aby zmieścić się w budżecie i dostarczać wartość biznesową…”
To tylko kilka cytatów z całej masy podobnych pytań i dyskusji toczonych w social media. Słowo „wartość” odmienia się w projektach IT przez wszystkie przypadki. Czym tak naprawdę jest wartość w projektach IT? Jak ją określić? Jak ją zmierzyć?
Czym jest wartość w projektach IT – definicje
W Scrum Guide słowo „value” występuje 25 razy. Mimo to nie ma tam jednej konkretnej definicji, która by wyjaśniła co to tak naprawdę znaczy.
W wikipedii znajdziemy następującą definicję:
„Customer value is the value received by the end-customer of a product or service. End-customer can include a single individual (consumer) or an organization with various individuals playing different roles in the buying-consumption processes. Customer value is conceived variously as utility, quality, benefits, and customer satisfaction.”
Jest to już jakiś punkt zaczepienia.
A co powiesz na taką definicję:
Value is perceived benefit: that is, the benefit we think we will get from something
Cytat pochodzi z książki „Competitive Engineering”, w której wyraz „value” pojawia się 304 razy!
Tyle teorii, przechodzimy do praktyki.
Praktyczna definicja wartości w projektach IT
Wartość najłatwiej przedstawić przy pomocy dwóch słów – Output i Outcome. Po polsku można by to tłumaczyć jako wytwór/produkt i efekt. Dla większej czytelności zostanę przy angielskich wyrażeniach.
Output – definicja
Output to widoczny rezultat pracy. To na przykład widok w aplikacji, w którym użytkownik podaje kryteria wyszukiwania. Żeby dostarczyć Output potrzebny był czas po stronie programisty, analityka oraz testera. Koszt każdego Outputu można więc łatwo określić.
Output jednak nie ma związku z wartością. Wyobraź sobie na przykład portal, w którym osoby bezdomne mogą składać wnioski o różne świadczenia. Jest to konkretny Output, ale wartość z tego jest żadna. Prawdopodobnie nikt nie będzie takich funkcjonalności używał. Jest to zresztą autentyczny przykład z historii polskich zamówień publicznych.
Outcome – definicja
Po drugiej stronie jest Outcome, czyli zmiana w świecie, którą spowodował Output. Ta zmiana może być na plus, lub minus. Na przykład, gdy wykop.pl aktualizuje stronę tak, że utrudnia użytkownikom korzystanie z kluczowych funkcjonalności to Outcome nie jest na plusie.
Celem jest oczywiście pozytywny Outcome, na przykład:
- przyspieszenie realizacji procesu,
- zmniejszenie liczby pomyłek,
- obniżenie kosztów itd.
Co ważne, pozytywny Outcome można osiągnąć niekoniecznie inwestując ogromne kwoty w budowę oprogramowania. Przykładowo, jeżeli korzystanie z pewnej aplikacji wymaga częstego przełączania się pomiędzy klawiaturą a myszką, lub zapamiętania złożonych skrótów klawiszowych, to można w kilka minut przygotować skrypty np. w AutoHotkey, które pomogą zautomatyzować te czynności.
Outcome jest to więc wartość, którą dostarczamy. Przy czym:
- zwykle można ją zaobserwować dopiero po czasie,
- żeby określić zmianę, trzeba najpierw wyznaczyć jaki jest obecny poziom danej cechy.
Właściciel produktu jako producent muzyczny
Jeżeli w realizacji projektów kierujesz się nastawieniem na wartość, to masz w sobie coś z producenta muzycznego. Dobry producent angażuje się w dopracowanie albumu, ale nie kończy na tym swojej pracy. Prawdziwe wyzwanie dopiero przed nim, czyli planowanie działań promocyjnych, mierzenie wskaźników sprzedażowych itd.
Projekt IT nastawiony na wartość nie może więc kończyć się w momencie wydania wersji na produkcję. Projekt taki powinien kończyć się dopiero po sprawdzeniu, że oczekiwany poziom wartości został osiągnięty.
W praktyce projekty często kończą się zaraz po ostatnim deploymencie. Zwłaszcza dotyczy to fixed-price, które mają dostarczyć zakres, a nie wartość. Bywa też, że zamawiający przeprowadził solidną analizę i potrzebuje jedynie kogoś, kto zbuduje oprogramowanie według precyzyjnych wytycznych. Osiągnięcie i mierzenie wartości zamawiający bierze wtedy w pełni na siebie. To też jest jak najbardziej ok.
Jak przygotować analizę nastawioną na wartość?
Wartość wynika z postawionych celów i wymagań. A te pochodzą od kogoś konkretnego – autora danego wymagania. Analizę warto więc zacząć od zdefiniowania osób decyzyjnych.
Wymagania te będą definiowane na różnych poziomach w strukturze organizacyjnej. Na przykład:
- dla prezesa firmy ważne jest, aby miał komplet informacji o trwających projektach w czasie rzeczywistym (a nie dopiero po miesiącu). Dzięki temu zareaguje z odpowiednim wyprzedzeniem, być może ratując firmę przed przykrymi konsekwencjami.
- dla administratora IT ważne jest, aby nowe rozwiązanie można było w 10 minut odtworzyć na innym serwerze w razie awarii (a nie jak do tej pory w 2 godziny). Przez to liczba sfrustrowanych klientów zdecydowanie się zmniejszy.
W kolejnym kroku należy wyciągnąć od tych osób jak najwięcej informacji na temat tego co jest dla nich ważne.
Dlaczego to jest ważne? Jak sytuacja wygląda teraz i jak miałaby wyglądać w przyszłości?
Dla przykładu prezesa, będzie to np.:
- aktualność informacji o budżecie projektu, liczona jako różnica w dniach między stanem otrzymanym przez prezesa a stanem faktycznym. Obecnie => 30 dni, Docelowo => 1 dzień.
Mierzone przez 1 miesiąc, na koniec każdego dnia przez asystenta X.
Co zrobić, gdy ktoś definiuje wartość wyłącznie przez Output?
To jest normalne. Myślenie o wartościach jest nienaturalne i trudniejsze od rozmawiania o funkcjonalnościach. Jeżeli słyszy o w kółko o funkcjonalnościach, a masz pomysł na inne Outputy, które mogą być korzystniejsze dla klienta, to możesz zadać proste pytanie:
„Panie X, zaproponowane przez Pana rozwiązania są bardzo interesujące. Czy chce Pan, żebym zaproponował również alternatywne rozwiązania, które dadzą podobny efekt, ale być może będą tańsze lub szybsze?”
Jeżeli tak, to trzeba najpierw określić ten efekt, czyli wartość. A jeżeli nie, to jako wykonawca nie ponosisz odpowiedzialności za Outcome, a jedynie za zrealizowanie Outputu.
Dostarczanie wartości w projektach IT – proces
Budowanie rozwiązań z nastawieniem na wartość, czy po prostu rozwiązań jako takich nie różnią się technicznie. Zasadniczą różnicą jest podejście do testowania. W przypadku Outputu, testujemy czy technicznie jest ok. Dla Outcomów potrzebujemy też weryfikować, czy faktycznie zmierzamy w kierunku założonego poziomu wartości.
W przypadku prezesa i informacji o budżecie, wewnętrzny zespół testowy może przez kilka dni symulować prace projektowe i sprawdzać, czy wyliczenia budżetu aktualizują się na bieżąco.
Administrator IT może symulować awarie i odtwarzać system od zera.
Najciekawsze w temacie wartości w IT dopiero przed nami…
Teraz pora na najciekawszą część. Coś, co w niektórych projektach bywa koszmarem. Czyli uruchomienie produkcyjne. W nastawieniu na wartość jest to najwspanialszy moment projektu. Wreszcie można zobaczyć, czy dotychczasowe wysiłki dały zamierzone efekty.
Z czasem zaczyna spływać feedback. Widać gdzie jest ok, a gdzie jest miejsce na poprawę. Pojawiają się nowe pomysły. Czasami stare pomysły się dewaluują. Przestają być istotne, bo wartość jaką otrzymali użytkownicy jest wystarczająca.
Na przykład, wyobraź sobie, że dodałeś w systemie wiele funkcjonalności wspierających obsługę błędów. W planach masz dodawanie obsługi kolejnych wyjątków. Jednak po uruchomieniu produkcyjnym okazuje się, że żaden z tych przypadków nie zaszedł przez kilka tygodni. Może warto zmienić plany?
W uruchomieniu produkcyjnym ważne są dwie rzeczy:
- warto je zrobić jak najszybciej i jak najprościej. Szkoda czekać na idealny moment. Zrobione jest lepsze od idealnego.
- z perspektywy wartości nic innego się nie liczy. Nie ma znaczenia ile zainwestowano godzin. Nie jest ważne jak dobre technicznie jest to rozwiązanie. Albo pozwala osiągnąć pewne cele, albo nie.
Podsumowanie
- Wartość jest potencjalną zmianą, wynikającą z dostarczonego oprogramowania, z perspektywy przynajmniej jednego interesariusza.
- Oczekiwany poziom wartości jest związany ściśle z danym interesariuszem. Nie istnieje jedna miara, która wskazuje czy jest ok, czy nie. Przykładowo, dla jednego prezesa, dostarczanie informacji z dokładnością do miesiąca może być ok. Dla innego będzie to nieakceptowalne.
- Wartość – Outcome, nie ma proporcjonalnej zależności z Outputem. Czasami szybka i tania zmiana może wiele zmienić. I odwrotnie.
Jeżeli interesuje Cię ta tematyka to dołącz do wartościowego newslettera projektowego.
Czytaj też o podejściu nastawionym na wartość – Design to Cost
Sprawdź dlaczego rozdzielanie celu i zakresu projektu jest ważne z perspektywy wartości
