Do niniejszego wpisu zainspirował mnie Jeff Patton, który w swoim artykule opisuje sposób na wizualizację wysiłku (kosztu) oraz outcome’u nowej funkcji (funkcjonalności) lub całego produktu. Chciałbym się skupić tylko na tej ostatniej kwestii – outcome(s).
Wizualizacja stanu realizacji
Jednak zanim przejdę do outcomes, chciałbym podzielić się z Wami bardzo trafną (moim zdaniem) analogią, którą posłużył się Jeff. Mianowicie, każdy nowy feature lub też cały nowy produkt składa się kilku (-nastu; -dziesięciu) zadań, które należy zrealizować (rzecz oczywista!). Tak otrzymujemy całość, którą sobie na początku założyliśmy. W artykule możecie zobaczyć rysunek jak niżej.
Jednym zdaniem – aby Spock mógł się dostać poprzez teleportację ze statku Enterprise na wybraną planetę, potrzebny jest “rozkład” Spoca na drobne elementy, ich przesłanie i złożenie z powrotem w całość. “Elementami Spocka” są w naszym przypadku zadania, które musimy zrealizować, aby wytworzyć wspomniany feature / produkt.
Można też spojrzeć na to zagadnienie z innej strony, bardziej oczywistej (i tu znowu posłużę się rysunkiem Jeffa).
Wpis Jeffa skupia się przede wszystkim na pokazaniu (wizualizacji) “stanu” poszczególnych elementów składowych, czyli zadań. Jednak wspomina on również o outcome, który jest końcowym rezultatem zaplanowanej pracy i tym, co może zobaczyć i doświadczyć Użytkownik (jedna z definicji outcome to to, co robią, mówią i czują Twoi użytkownicy).
Czy dostarczona wartość biznesowa jest wystarczająca?
W tym miejscu chciałbym Wam pokazać bardziej złożony wykres, niż rysunki i podejście prezentowane przez autora wpisu, do którego się odnoszę.
Jeff zakłada (w uproszczeniu), że aby dostarczyć końcowy produkt dla Użytkownika (czyli teleportować Spocka), należy dostarczyć całość.
Ja podchodzę do tego inaczej. Kluczowe dla mnie jest, aby na bieżąco monitorować dostarczoną wartość i w momencie, kiedy stwierdzamy, że dalsze prace (effort) są nie współmierne do planowanych rezultatów (oczekiwanej wartości), zaprzestać realizacji, tj przejść w fazę utrzymania (oczywiście niektóre funkcje lub produkty muszą być dostarczone jako całość ale też czasami jest to tylko wymówka lub symptom złego definiowania zadań).
Na wykresie poniżej możecie zobaczyć:
- effort – rozumiany jako liczbę zrealizowanych zadań lub czas poświęcony na ich realizację,
- business value – rozumiana jako wartość dostarczona dla Użytkownika,
- time – rozumiany jako liczba Sprintów lub tygodni pracy.
Przy takim podejściu do wytworzenia feature / produktu, nie czekamy na realizację całości, tylko oddajemy w ręce Użytkownika jak najczęściej jak najmniejsze elementy i monitorujemy je. To wymaga (i takie też jest założenie wykresu), że wprowadzenie nowych elementów na produkcję następuje po każdym zakończonym okresie (zaznaczonym na osi Time).
Miejsce przecięcia się osi Effort i Business Value to punkt, w którym należy poświęcić więcej czasu na przemyślenie, czy warto dalej realizować daną funkcję / produkt.
Dwa podstawowe pytania, na które musicie znaleźć odpowiedzieć, aby takie podejście zastosować:
- jak zmierzyć Effort?
Jeżeli wykorzystujcie w swojej pracy Jirę lub inne narzędzie do “trackowania” postępu zadań (a zadania składają się w większą całość, np w epici, projekty, inicjatywy, idee) to jest to dość proste. Należy tylko ustalić, czy chcemy effort mierzyć poprzez np. liczbę zrealizowanych zadań, czas poświęcony na ich realizację czy też w inny sposób,
- jak zmierzyć Business Value?
W jednym ze wcześniejszych moich wpisów, podałem Wam konkretne metody mierzenia business value. Możecie z nich skorzystać lub, jeżeli jesteście na początku drogi zmierzającej do skwantyfikowania wartości biznesowej, wykorzystać miarę, którą sami stworzycie (najprostszy sposób – przy każdym zadaniu podajecie, jaką Waszym zdaniem da ono wartość Użytkownikowi).
Zebranie tych dwóch wartości pozwoli Wam stworzyć wykres, jak powyżej.
Zakładając, że pracujecie w sposób zwinny i Wasz backlog “zapełnia” się nowymi zadaniami w miarę upływu czasu i kolejnych Refinementów, dane potrzebne do stworzenia powyższego wykresu również będą się zmieniać – nic prostszego, jak powtarzać rysowanie wykresu w miarę pojawiania się nowych informacji.
MVP jako “dobry” dług techniczny
Jak zauważycie na wykresie, linie effort i business value nie rozpoczynają się w punkcie 0 (przecięcia się osi X i Y). Obszar pomiędzy punktem 0 i 1 celowo zostawiłem pusty, ponieważ jest to miejsce, gdzie powinno pojawić się MVP, i długość tego okresu może być różna.
Zacytuję twórcę podejścia MVP, abyśmy lepiej zrozumieli, co rozumiem poprzez to pojęcie – “Eric Ries przedstawił koncepcję Minimum Viable Product (MVP) w swojej książce Lean Startup, gdzie m.in. możemy przeczytać – „Minimum Viable Product (MVP) pomaga przedsiębiorcom jak najszybciej rozpocząć proces uczenia się. Niekoniecznie jest to jednak najmniejszy produkt, jaki można sobie wyobrazić; jest to po prostu najszybszy sposób na przejście przez pętlę sprzężenia zwrotnego (feedback loop; Build-Measure-Learn) przy minimalnym wysiłku.”
Chcę Wam zwrócić uwagę na jeden punkt, który nie jest (często) opisywany przy okazji MVP. Chodzi mianowicie o dobry / zły dług techniczny (czyli w/w fazę Build, o której wspomina Ries). Cytując mój stary wpis, “traktujmy dług techniczny jak dług finansowy (metafora stworzona przez Warda Cunninghama). Z jednej strony pozwala on nam kupić rzeczy, które chcemy / musimy mieć. Pozwala nam także funkcjonować na pewnym oczekiwanym poziomie. Z drugiej strony jest on niebezpieczny, jeśli nie spłacimy go w odpowiednim czasie.” Konstruując MVP celowo tworzycie kod (tak naprawdę to tworzy go cały zespół), który ma umożliwić sprawdzenie jakieś hipotezy / nauczenie się zachowania Użytkownika. Z definicji nie jest on zły ale tylko pod warunkiem, że po fazie MVP (czasami Discovery) zostanie on usunięty (więcej o sztuce równowagi technicznej w Agile możecie poczytać w ebooku AgileHints).
Podsumowanie
Często zakładamy, że aby dostarczyć do Użytkownika nowy feature / produkt, musimy zrealizować całość wymagań (które często pojawiają się dopiero w trakcie pracy na wymaganiami). Wprowadzenie metody bieżącego monitorowania dostarczonej już wartości dla Użytkownika, może “uwolnić” możliwości pracy nad czymś innym. Aby ją wprowadzić, konieczne jest skwantyfikowanie kosztu (effort) i business value. Takie podejście pozwoli nam podejmować decyzję, czy dostarczona Użytkownikowi wartość biznesowa jest już wystarczająca, czy może jeszcze nie.