“Mystification is simple;
clarity is the hardest thing of all.”

– Julian Barnes

Chciałbym, żeby poruszany temat trafił do większej liczby osób oraz pozwolił przyjrzeć się Wam jakie ryzyko wprowadza do Waszych projektów niejasno zdefiniowany cel lub problem. Decyzja o tym, czy warto poświęcać czas klarowności, zostawiam Wam.

Swój artykuł silnie opieram na prezentacji przedstawionej w trakcie wykładów.

Dlaczego mam mierzyć wartości?

Wytwarzane przez szeroko pojęte IT oprogramowanie jest narzędziem w ręku szeregu interesariuszy. Dla CEO firmy ważnym jest, żeby inwestycja w projekt się zwróciła i żeby mógł z niej czerpać zysk. Dla osób bezpośrednio zaangażowanych w wytwarzanie rozwiązania ważna może być technologia, chęć nauki nowych rzeczy albo możliwość pracy, która pozwala utrzymać zdrowy work-life balance. Użytkownicy i osoby w ich otoczeniu również będą chcieć czerpać korzyści z wytwarzanego przez nas rozwiązania.

Od tego w jaki sposób zdefiniujemy sobie interesariuszy, określimy wartość, którą chcą uzyskać od naszego projektu i w jaki sposób będziemy ją dostarczać zależeć będzie sukces lub porażka projektu. Czasem jeden niezadowolony krytyczny interesariusz może przekreślić cały projekt.

W artykule silnie zwracam uwagę na:

• Różnicę między wartością, a środkami dostarczania wartości.
• Definicje interesariuszy.
• Dekompozycję i kwantyfikację wartości.

Definicja wartości

“Value is perceived benefit: that is, the benefit we think we get from something.”

– Tom Gilb

Czym są wartości? Według definicji podanej powyżej wartością jest postrzegana korzyść, czyli korzyść którą chcemy od czegoś uzyskać.

Postaram się zobrazować postrzeganą wartość w poniższych przykładach. Przykłady są uproszczone do pojedynczej potrzeby:

Rozmowa dwóch przyjaciół:

• Dlaczego kupujesz samochód?
• Kupuję samochód, bo chciałbym mniej czasu spędzać w drodze do pracy.
• Dlaczego chcesz mniej czasu spędzać w drodze do pracy?
• Chciałbym więcej czasu spędzać w domu.
• Dlaczego chcesz więcej czasu spędzać w domu?
• Żeby móc więcej czasu spędzać z rodziną.

Postrzeganą wartością dla przyjaciela nie jest chęć posiadania samochodu, tylko chęć spędzenia większej ilości czasu z rodziną. Samochód jest tylko narzędziem, które ma mu to umożliwić. Jeżeli jednak czas spędzony na staniu w korkach i szukaniu parkingu przekroczy czas, który aktualnie poświęca na dojazd do pracy, jego podstawowa potrzeba nie zostanie zaspokojona.

Przykład bliższy środowisku IT, rozmowa ze sponsorem projektu:

• Przenosimy projekt do chmury.
• Dlaczego chcesz to zrobić?
• Ponieważ słyszałem, że dzięki temu wytworzymy rozwiązanie taniej.

Podstawową potrzebą sponsora projektu jest w tym wypadku zmniejszenie kosztów rozwoju i utrzymania systemu informatycznego. Wykorzystując to rozwiązanie uzyska on szereg innych korzyści, ale na tej jednej najbardziej mu zależy.

Czy to rozwiązanie spowoduje, że koszty się zmniejszą? O ile i kiedy?

Inżynierowie pracujący przy danym projekcie mogą to ocenić. Jesteśmy w stanie policzyć aktualny koszt utrzymania systemu, wyestymować jaki będzie koszt jego prowadzenia po przeniesieniu go do chmury i ustalić kiedy inwestycja się zwróci umożliwić podjęcie świadomej decyzji sponsorowi.

Podobnie jak w poprzednim przypadku, jeżeli narzędzie, jakim jest technologia chmurowa, nie spowoduje, że sponsor osiągnie oczekiwany rezultat, będzie on niezadowolony ze swojej decyzji. Czy spowoduje to zamknięcie projektu? Być może nie, ale może okazać się zmarnowaną inwestycją w kontekście uzyskania konkretnego celu.

Zauważcie, że w przykładach podłożem decyzji jest chęć zmiany obecnego stanu. Nie ma znaczenia czy jest to decyzja projektowa związana z funkcjonalnością, bezpieczeństwem czy decyzja zakupowa, zazwyczaj kryje się pod tym pewna mierzalna wartość, którą jako inżynierowie powinniśmy umieć udowodnić, że została dostarczona.

Samych wartości jest bardzo wiele i dla każdego mogą być inne. Wiele z nich wydaje się z pozoru niepoliczalne. Jak na przykład policzyć chęć zabawy? Jak policzyć miłość do chodzenia po górach? Jak policzyć chęć zjedzenia dobrego ciasta?

Można zmierzyć wszystko

Na jednym ze spotkań rozmawiałem z kolegą na temat mierzenia wartości. Zadał mi pytanie: “Kasjan, a w jaki sposób zmierzysz dobre ciasto?”

Dobrego ciasta nie traktuję jako wartość, ale podjąłem się dyskusji i zbadania tego tematu. Rozpocząłem pracę od zdefiniowania czym jest dobre ciasto. Udało mi się ustalić po rozmowach z wieloma osobami, że dobre ciasto można podzielić na pewne mierniki:

• rodzaj składników – procent każdego składnika,
• temperatura – stopnie Celsjusza,
• porcja ciasta –  gramy,
• gęstość – gramy na cm3,
• słodkość – procent substancji słodzącej.

Część osób również opisywała parametry środowiskowe – Dobre ciasto tylko z przyjaciółmi!

Jak widzicie, dokonałem dekompozycji “dobrego ciasta” na 5 mierzalnych parametrów. Dla każdej osoby chcącej wybrać ciasto, rozkład podanych parametrów będzie wpływać na decyzję o wyborze konkretnego rozwiązania kawałka ciasta. Będą więc te parametry miały znaczenie.

Podobnie jest z wartościami. Dla konkretnych interesariuszy ich konkretne wartości mają znaczenie, i dlatego są przez nich odczuwalne lub obserwowalne. A jeżeli są obserwowalne, mogą być zmierzone w myśl podanego ciągu logicznego:

If it matters, it is detectable/observable.
If it is detectable, it can be detected as an amount (or range of possible amounts).
If it can be detected as a range of possible amounts, it can be measured.
– Douglas W. Hubbard, „How To Measure Anything”, 2010

Badanie wartości w warunkach projektowych

Przykład z ciastem wydaje się dosyć prosty, jednak w jaki sposób możemy definiować wartości w projektach, z którymi mamy do czynienia w trakcie naszej codziennej pracy?

Spróbujemy dokonać dekompozycji wartości wykorzystując proces Evolutionary Project Management (EVO). Jest to proces zarządzania projektem, który został wprowadzony przez amerykańskiego inżyniera systemów Toma Gilba. Jeżeli będziecie analizować na czym polega EVO zauważycie, że agile czerpał z niego wiele inspiracji.

Nie wchodząc w szczegóły samego EVO wykonamy część cyklu składający się z:

• analiza interesariuszy,
• dekompozycji wartości,
• generowaniu rozwiązań.

Analiza interesariuszy

Będziemy operować na nieistniejącej firmie Safety4Family, która zajmuje się szeroko pojętym zwiększaniem poczucia bezpieczeństwa rodzin.

Zanim rozpoczniemy szukanie wartości musimy wiedzieć komu daną wartość należy dostarczyć. Trzeba zidentyfikować interesariuszy projektu, gdzie interesariuszem może być każda osoba, grupa osób lub system, który jest – lub chcemy, żeby był – zainteresowany naszym projektem.

Dla przykładu Safety4Family mogę podzielić interesariuszy na podane kategorie:

• Pojedyncze osoby – osoby mające dużą władzę nad projektem, które piastują pojedyncze role, np. CEO firmy.
• Grupy osób – np. grupy odpowiedzialne za wytworzenie i utrzymywanie rozwiązania,
• Dokumenty – wszelkiego rodzaju plany, standardy czy prawa, które nakładają pewne ograniczenia.
• Otoczenie – zewnętrzne ryzyka lub szanse.
• Koszta – zasoby i czynności zmniejszające budżet projektu.
• Strategie zarządzania interesariuszami – wszelkie czynności mające na celu definiowanie interesariuszy, ustalanie i mierzenie wartości. Na tej podstawie wiemy, czy projekt idzie zgodnie z założonym kierunkiem.
• Rodzina i jej środowisko – osoby wykorzystujące bezpośrednio lub pośrednio wytwarzane rozwiązanie.
• Zagrożenia rodziny – przed czym nasze narzędzie ma ochraniać rodzinę.
• Atrybuty interesariuszy – pozwalające ustalić krytycznych interesariuszy.

Wiedząc ilu jest interesariuszy trzeba rozpocząć szukanie tych, którzy będą mogli zadecydować o sukcesie lub porażce projektu. Taki typ interesariuszy nazywamy kluczowymi interesariuszami.

Przedstawię Wam czterech interesariuszy:

Założyłem, że CEO będzie kluczowym interesariuszem – w każdej chwili może zamknąć projekt, jeżeli jego oczekiwania nie będą spełnione.

Prawo również będzie kluczowym interesariuszem. W przeciwieństwie do CEO, nie jest ono w stanie zamknąć projektu od razu, ale jest w stanie przerwać jego dystrybucję, gdy ten już będzie gotowy. Warto się wcześniej upewnić jakie warunki muszą być spełnione, żeby do tego nie doszło lub nie rozpoczynać projektu.

Rodzina ma nadać rozwiązaniu kierunek i sens. Możemy jednak wybrać tylko część wartości – te, które są zgodne z wizją firmy. Powinniśmy monitorować inne wartości interesariuszy, jeżeli uznamy, że mogę one mieć znaczący wpływ na projekt.

Niektórzy interesariusze, jak na przykład zespół wytwarzający rozwiązanie, możliwe, że nie będzie na tym etapie kluczowy i wrócimy do niego w innym czasie.

Podane przeze mnie przykłady są tylko propozycją i będą różne dla każdego projektu. Każda decyzja o dołączeniu interesariusza do grupy kluczowych i decyzja o badaniu wartości danego interesariusza powinna być poprzedzona analizą oraz informacją o tym dlaczego uważamy, że jest on aktualnie ważny.

Dekompozycja i kwantyfikacja wartości

“A problem well stated is a problem half solved.”

– Douglas W. Hubbard, „How To Measure Anything”, 2010

Na początku artykułu opisywałem jak zmierzyć dobre ciasto. Zdekomponowaliśmy je na szereg mniejszych parametrów, które dało się zmierzyć i które miały znaczenie.

Podobnie zdekomponowana zostanie wartość o nazwie “bezpieczeństwo rodziny”, jednak tym razem z większą liczbą szczegółów.

Czym jest bezpieczeństwo rodziny? Jak się okazuje bezpieczeństwo rodziny może być jedną z wielu różnych rzeczy! Może to być:

• zmniejszenie szansy na włamanie do mieszkania,
• szybkie udzielenie pomocy medycznej,
• zdrowe i czyste środowisko,
• maksymalizacja czasu, w którym dziecko jest pod opieką,
• itd.

Dokonując analizy wartości  dekomponujemy ją i zaczynamy rozumieć CZYM dana wartość jest dla interesariusza.

Czy mając taką listę uzyskaliśmy klarowność? Czy podane elementy dekompozycji są już teraz jednoznaczne? Niekoniecznie, podane zdania jeszcze nie pozwalają na uzyskanie klarowności. Ryzykujemy niezrozumieniem co dokładnie się kryje za konkretnym elementem z wytworzonej przez nas listy.

Spróbujmy przeanalizować następujące zdanie:

Zmniejszenie czasu wymaganego do uzyskania pomocy medycznej.

Co się może za nim kryć? Czy chodzi tutaj o kolejkę do specjalisty? O czas potrzebny do dojazdu do lekarza? Czym jest pomoc medyczna? Konsultacją lekarską czy naklejeniem plastra? Informacją, że wszystko jest ok, czy operacją?

Na podstawie tego zdania nie możemy być pewni czego oczekuje interesariusz. Otwiera to drogę do błędnej interpretacji, co może się zakończyć dostarczeniem rozwiązania, które doskonale radzi sobie z jakimś problemem, ale niekoniecznie tym ważnym dla interesariusza.

Miernik ten może brzmieć następująco:

Liczba minut potrzebna dla Interesariusza od momentu podjęcia decyzji o interwencji związanej z problemem zdrowotnym domownika, aż do czasu, w którym rozpocznie się rzetelny proces diagnozy.

Czy podany opis uściśla o co dokładnie chodzi interesariuszowi? Tak, ale dalej istnieje pole do błędnej interpretacji. Słowa pogrubione mogą być różnie zinterpretowane i mogą stać się ryzykiem projektowym. Zdefiniujmy je sobie:

Interesariusz =  {Rodzic, Samotny Rodzin, Sąsiad, Dziecko, Dziadkowie}.

Interwencja = {Konsultacja medyczna}.

Problem zdrowotny = {Gorączka, kaszel, ból, złamania, krwawienie, omdlenie}.

Domownik= {Rodzic, Samotny Rodzic, Dziecko, Dziadkowie, Współlokator}.

Rzetelny proces diagnozy: Medyczna procedura wykonywana przez Specjalistę na Domowniku w celu uzyskania informacji o aktualnym zagrożeniu zdrowia lub życia.

Specjalista = {Lekarz Pierwszego Kontaktu, Chirurg, Lekarz Pogotowia, Pediatra}

Wszystkie słowa, które mogę zostać błędnie zinterpretowane zostały zdefiniowane. Minimalizujemy ryzyko błędnego zrozumienia na czym zależy interesariuszowi i wytworzenia rozwiązania, które świetnie radzi sobie z nieważnym dla interesariusza problemem.

Czy spotkaliście się kiedyś z sytuacją w której niejednoznaczne wymaganie doprowadziło do straty dużej ilości czasu lub pieniędzy? Ja spotkałem się z takimi wymaganiami:

• Skuteczność algorytmu ma wynosić 80%
  • Ok, ale czym jest skuteczność?
• Testy mają być wykonywane szybciej!
  • Ok, ale jakie testy? I jak szybko? Czy przyspieszenie czasu o 10 minut miesięcznie jest sukcesem?
• Aplikacja ma mieć wysoki poziom UX!
  • Ok, ale dla kogo? Czym dla danych osób jest wysoki poziom UX?

Warunki sukcesu i porażki

Zdefiniowaliśmy jasno jaki rodzaj problemu chcemy rozwiązać, zmianę jakiej wartości chcemy obserwować. Na podstawie powyższego miernika nadamy wartości, które będą świadczyć o sukcesie i porażce projektu.

Jak bardzo ważna dla interesariusza jest jednak ta zmiana? Czy jest możliwa do osiągnięcia? Może się okazać, że będziemy próbować polepszyć pewien aspekt życia interesariuszy, który i tak jest już bliski idealnemu poziomowi lub spróbujemy zmierzyć się z problemem, którego nie można rozwiązać.

Możemy się przed tym bronić określając następujące poziomy miernika:

• Życzenie interesariusza, które zazwyczaj będzie niemożliwe do osiągnięcia, ale określa kierunek zmiany.
• Nasz zadeklarowany cel, jako warunek osiągnięcia sukcesu.
• Poziom tolerowany przez interesariusza, który nieosiągnięty definiuje porażkę projektu.
• Poziom aktualny, który określa jak daleko jesteśmy obecnie od celu i czy problem w ogóle występuje.

Mając ustalony warunek porażki (poziom tolerowany) i warunek sukcesu (cel) jesteśmy w stanie:

• Zakończyć prace nad poprawą wartości miernika, kiedy cel będzie osiągnięty.
• Przedstawić interesariuszom w jakim procencie cel jest spełniony.
• Weryfikować stawiane hipotezy i je korygować.
• Jeżeli w aktualnym sprincie/tygodniu/jednostce czasu skupialiśmy się na poprawie konkretnego miernika, informowani jesteśmy czy przypadkiem jeden z innych ważnych mierników nie osiągnął nieakceptowalnego poziomu.

Wartości mierników trzeba cyklicznie mierzyć tak samo, jak programiści mierzą techniczne aspekty aplikacji – wykorzystanie bazy danych, aktualne zużycie pamięci RAM czy maksymalną liczbę transakcji na sekundę. Jeżeli my nie zauważymy, że interesariusz jest niezadowolony, będziemy się mierzyć z tego konsekwencjami.

Normalizacja mierników

Załóżmy, że udało nam się przeanalizować 3 cele:

Cel	Poziom Aktualny / Tolerowany / Docelowy
Zmniejszenie czasu potrzebnego na uzyskanie pomocy medycznej	60 minut / 35 minut / 15 minut
Czas potrzebny na dojście do szkoły przez dzieci	45 minut / 30 minut / 15 minut
Czyste środowisko	120% PM 10 / 120% PM 10 / 80% PM 10

Na podstawie tabeli można zwrócić uwagę na 3 kwestie:

• W jaki sposób przyrównać różne jednostki miary? W tym jak porównać jednostki czasu do jednostki czystości powietrza?
• Co zrobić, kiedy poziom aktualny jeszcze nie jest na tolerowanym poziomie?
• Dlaczego mamy badać miernik, który już jest na poziomie tolerowanym?

Żeby rozwiązać te kwestie musimy dokonać normalizacji każdego celu. Możemy przeliczyć różnicę między czasem docelowym a tolerowanym do formy procentowej dla każdego miernika. Uzyskamy informację jak daleko w procentach jesteśmy od naszego celu.

Dla czasu potrzebnego do uzyskania pomocy medycznej wizualizacja wygląda następująco:

Co wynika z powyższej wizualizacji? Jeżeli poziom aktualny znajduje się poniżej poziomu tolerowanego, wskaźnik procentowy będzie ujemny! Nie spełniamy minimalnych kryteriów akceptacji. Jeżeli zbliżamy się z każdą iteracją w kierunku czasu tolerowanego, ale go nie osiągamy, to dalej wartość tego miernika informuje, że któryś z interesariuszy jest niezadowolony! Płyniemy pod wodą, jesteśmy coraz bliżej tafli wody, ale nie jesteśmy w stanie jej przekroczyć. Ryzykujemy porażką projektu.

Jeżeli poziom aktualny i poziom tolerowany się zbiegną, przekroczono taflę wody, można odetchnąć. To nie jest jeszcze moment, w którym odczuwamy komfort. W każdej chwili możemy znowu zacząć tonąć, ale cykliczne badanie miernika o tym poinformuje i da możliwość zareagowania.

Generowanie strategii

Evolutionary Project Management opisuje narzędzie, które pozwala zwizualizować cele i strategie, oraz dokonać ich porównania. Dzięki temu mamy możliwość obserwowania wszystkich ważnych celów i strategii minimalizując ryzyko pominięcia ważnego miernika.

Żeby osiągnąć jasność jak konkretne strategie wpływają na mierniki i koszt, w Impact Estimation Table podajemy do 10 najważniejszych mierników (mierzalnych celów), strategie i ich wpływ na miernik. Po podaniu tych informacji mierzymy sumę wpływów wszystkich strategii, koszt implementacji i stosunek wpływu do kosztów. Przykładowa, minimalistyczna wersja Impact Estimation Table widoczna jest poniżej:

Uzupełnimy tabelę wykorzystując 3 wartości:

• Czas potrzebny od uzyskania pomocy medycznej (Pomoc Medyczna).
• Czas potrzebny do dojścia do szkoły (Droga do Szkoły).
• Stan miernika PM10 (Środowisko).

Do zapewnienia wartości interesariuszom wykorzystamy 3 strategie:

• Wytworzenia samochodu.
• Przeniesienia rodziny do miasta.
• Wytworzenie aplikacji do zdalnej konsultacji medycznej.

W każdej komórce krzyżującej strategię i cel wpisujemy estymowany wpływ na strategii na miernik.

W trakcie estymacji warto wiedzieć dlaczego tak myślimy? Na jakiej podstawie? Czy jest to ślepy traf czy może już znana strategia, która wielokrotnie wykazywała wzrost podanego wskaźnika? Im jesteśmy bardziej pewni, że dana strategia będzie wygrywająca, tym mniejsze ryzyko podejmujemy wchodząc pod tą strategię.

W wierszu z procentową sumą wpływów po wykonaniu estymacji sumujemy wszystkie wartości procentowe dla danego rozwiązania i wpisujemy estymowany koszt. Dzieląc sumę wpływów do kosztów uzyskujemy wygrywającą strategię.

Oczywiście decyzja z której strategii skorzystać jest w Waszych rękach. Kolejny etap zakłada dekompozycję strategii, która ma za zadanie doprecyzować estymację. Być może będzie trzeba w ostateczności przyjąć inną strategię, jednak narzędzie jest w stanie wskazać tę, która ma największą szansę sukcesu na dany stan wiedzy.

W jaki sposób możecie wykorzystać te informacje w Waszych projektach?

Czy wybieraliście kiedyś narzędzie DevOps, które miało służyć Waszemu projektowi? Próbowaliście w swoich projektach wprowadzić automatyczne testy? A może chcieliście wykonać refaktoryzację kodu pewnej części aplikacji?

Jeżeli tak, to wybieraliście strategie dla projektu mające wprowadzić pewną zmianę. Zastanówcie się:

• Jaką zmianę wprowadzenie strategii ma spowodować? Zdefiniujcie ją do formy policzalnej.
• Jaki jest stan aktualny?
• Jaki ma być stan docelowy? Jaką masz pewność, że uda Ci się go osiągnąć? Zobowiąż się do tego.
• Ustal ile potrzebnych jest zasobów, żeby ten cel osiągnąć.
• Pomyśl o alternatywnych strategiach i wybierz najlepszą.

Być może się okaże, że nie warto wykonać refaktoryzacji –  zaoszczędzisz wtedy czas i pieniądze swoje, swojej firmy lub swojego klienta. Może znajdziesz inne, korzystniejsze rozwiązanie. A może uda Ci się uzyskać twarde, klarowne dowody, które konkretnie określą jaką korzyść będziesz w stanie uzyskać dla interesariusza?

Podsumowanie

Jako inżynierowie, analitycy, specjaliści od systemów (i nie tylko, bo mierzenie wartości można wykorzystywać w różnych sytuacjach) powinniśmy pamiętać o tym dla kogo coś robimy i w jaki sposób interesariusze chcą czerpać korzyści z projektu.

Zdaję sobie sprawę, że nie zawsze będziemy wiedzieć jaką zmianę nasze rozwiązania mają wprowadzić, nie zawsze uda nam się uzyskać czas na analizę, a czasami po prostu musimy podejmować ryzyko bez rozeznania wszystkich możliwości.

Zachęcam jednak Was do zadawania pytań, które pomogą Wam zrozumieć CZYM jest Wasz projekt lub DLACZEGO dana zmiana jest ważna.

Spróbujcie zadawać następujące pytania:

• Komu dana zmiana ma przynieść korzyść? Któremu interesariuszowi?
  • Może się okazać, że żadnemu! A skoro żadnemu, to po co to robimy?
• Jaki jest cel danej zmiany? Na jaki wskaźnik ma ona mieć wpływ?
  • Dopytujcie o aktualny problem, spróbujcie sparafrazować go, spróbować nadać wartość numeryczną i uzyskać informację jaki ma być stan docelowy. Może nie da się stanu docelowego osiągnąć? Może czas, który ma zostać zainwestowany, nie jest tego wart?
• Dlaczego wybrano tę strategię?
  • Może istnieje inna strategia, która wymaga mniejszego nakładu pracy, z szacowanym lepszym wynikiem?

Bez względu na kontekst Twojego projektu możesz rozpocząć wykonywać kroki w celu klaryfikacji wymagań. Szczerze Cię do tego zachęcam i życzę powodzenia!

Bilbiografia:

• Tom Gilb: Value Planning in a Lean and Agile Way for Managers
• Quantify the un-quantifiable: Tom Gilb at TEDxTrondheim
• How to Measure Anything by Douglas W. Hubbard
• Value Planning Book by Tom Gilb
• User Stories – Ujęcie Krytyczne
• Spójność – notatki z warsztatów
• 12 Tough Questions – Tom Gilb