W moim artykule w ostatnim wydaniu Strefy PMI, w oparciu o historię lekarza z wiedeńskiej kliniki Ignáca Semmelweisa, podkreśliłem znaczenie podejmowania decyzji opartych na solidnych faktach i dowodach, a także omówiłem ruch społeczny związany z Evidence Based Management (dalej EBM). Tych, którzy jeszcze nie czytali serdecznie zachęcam do nadrobienia zaległości. W poniższym materiale zagłębię się w szczegóły frameworku EBM opracowanego przez Scrum.org. W moim odczuciu jest on niezwykle ciekawy i przydatny, gdyż znacząco wspiera zarządzanie organizacją i produktem. W jaki sposób? Odpowiedzi jest kilka: promuje ciągłe doskonalenie (continuous improvement), realizuje model biznesowy oparty na zarabianiu jak największej ilości pieniędzy (business outcomes) poprzez zwiększanie wartości biznesowej klientów oraz użytkowników (customer/user outcomes).
Jak być może pamiętacie, EBM pełni rolę silnika zmian w organizacji. To co jest jego sporą zaletą to fakt, że bazuje na wyznaczaniu mierzalnych celów, formułowaniu hipotez oraz przeprowadzaniu eksperymentów. Te z kolei pozwalają na potwierdzenie lub obalenie przyjętych do sprawdzenia hipotez. Zmiany wprowadzanie są stopniowo, małymi krokami i co istotne na fundamencie intensywnie mierzonych i analizowanych danych.
Pamiętacie film Predator? Tytułowa postać to niewidzialny zabójca i przybysz z kosmosu. Ma jedną zasadniczą przewagę nad gatunkiem ludzkim, dzięki czemu rzuca wyzwanie Alanowi Schaeferowi (w tej roli Arnold Schwarzenegger) – widzi świat w podczerwieni, co umożliwia mu łatwe wykrywanie i śledzenie swoich ofiar. Zachowując odpowiednią powagę, EBM również wykorzystuje specyficzny sposób postrzegania rzeczywistości, skupiając wybiórczo naszą uwagę na czterech kluczowych obszarach organizacji (tzw. Key Value Areas), zmuszając nas do dokładnego ich pomiaru i analizy. Twórcy metody dają pełną swobodę w wyborze mierników, ale oferują również zestaw 30 gotowców, spośród których można wybierać, dostosowując je do konkretnych potrzeb i celów organizacji1. Kończąc wątek filmowy wiemy, że historia Predatora finalnie kończy się nie po jego myśli, wręcz przeciwnie do systematycznego rozwoju frameworku EBM. O wspomnianych wyżej obszarach zainteresowania frameworku przeczytacie w kolejnych podrozdziałach.
Current Value
Pierwszy kluczowy obszar to Current Value, rozumiany jako wartość jaką, dostarcza nasza organizacja klientom, użytkownikom oraz interesariuszom dzisiaj. Jest ona dostarczana za pomocą produktu albo serwisu i można ją mierzyć na różne sposoby, a kilka z nich postaram się opisać.
Jednym z przykładów jest zastosowanie podejścia bazującego na określeniu, w jakim stopniu jest spełniona potrzeba użytkownika albo interesariusza na poziomie tzw. wymagań niefunkcjonalnych. Wywodzi się ono z Evolutionary Project Management i Impact Estimation. Jak to może wyglądać w praktyce? Nasze biletomaty pozwalają kupić pasażerowi bilet w średnio 10 sekund. Mamy zatem cechę niezwiązaną z główną funkcją maszyny.
Do Current Value można też podejść bardziej od strony ekonomicznej, biznes uwielbia przecież pieniądze. Zbadanie miesięcznego poziomu zysku, kosztów utrzymania czy ilości subskrypcji pozwala wyliczyć nam rachunek finansowy produktu.
Często niedocenianym aspektem pracy nad produktem jest pomiar poziomu zadowolenia pracowników pracujących nad jego powstaniem (tzw. Employee Satisfaction). Wysoki poziom zadowolenia pracownika to podstawa wysokiego Current Value. Z własnego, długoletniego doświadczenia zawodowego mogę stwierdzić, że nigdy nie spotkałem się z wysokiej jakości produktem, który zostałby stworzony przez zespół niezadowolonych ludzi.
Scrum.org proponuje jeszcze inne miary, a mnie szczególnie zainteresowały dwie. Pierwszą z nich jest dochód generowany przez organizację na jednego pracownika (Revenue per Employee). Jeśli obserwujemy, że przy wzroście firmy dochód na pracownika maleje, warto zastanowić się nad przyczynami tego zjawiska. Drugą miarą jest Customer Usage Index, który określa, jak często konkretne funkcjonalności produktu są faktycznie wykorzystywane przez użytkowników. Nierzadko zdarza się, że pewne funkcjonalności używane są tylko w małym procencie przypadków. Jeśli nie są krytyczne dla bezpieczeństwa systemu, taki niski wskaźnik wykorzystania, może wskazywać na potrzebę przemyślenia inwestycji w te obszary i skupienia się na rozwiązaniach bardziej istotnych dla użytkowników.
Unrealized Value
Kolejnym istotnym obszarem (Key Value Area) jest tzw. Unrealized Value. Odzwierciedla on niewykorzystany potencjał wartościowy – innymi słowy: o ile więcej wartości organizacja jest w stanie wygenerować po zmianie pewnych właściwości produktu lub serwisu.
EBM daje nam tutaj swobodę pod kątem podejścia do opomiarowania tego obszaru. Jedno z nich proponuje zbadanie Unrealized Value jako różnicy między tym, czego oczekują użytkownicy, a tym, co faktycznie im oferujemy. Pozostając przy wspomnianych biletomatach możemy sprawdzić, jak wyglądają one na tle konkurencji. Załóżmy sytuację, że nasze biletomaty i te konkurencji obsługują klientów w ciągu 30 sekund, a nasze prognozy wskazują, że skrócenie tego czasu do 15 sekund może zwiększyć sprzedaż biletów o 70%. Wykorzystanie tej informacji może znacznie zwiększyć nasze przychody niwelując tzw. User Satisfaction Gap (lukę w zadowoleniu użytkowników).
Kolejnym sposobem na zmniejszenie niewykorzystanego potencjału wartościowego może być analiza udziałów w rynku (Market Share). Często obserwuję Product Ownerów zaniepokojonych faktem, że przyrost nowych użytkowników ich aplikacji miesiąc po miesiącu maleje. Chcąc ratować sytuację, decydują się na dodawanie nowych funkcjonalności do aplikacji, a może się okazać, że przyczyna spadków jest inna, a użytkownicy są już tak naprawdę w pełni z niej zadowoleni. Przyczyna spowolnienia wzrostu liczby użytkowników może leżeć gdzie indziej i być na przykład wynikiem osiągnięcia przez nasz produkt maksymalnego udziału w rynku. W takiej sytuacji zamiast skupiać się na dodawaniu nowych funkcjonalności, warto rozważyć wprowadzenie produktu do innego kraju odpowiednio go do tego adaptując.
Time to Market
Obszar Time to Market informuje nas o poziomie zwinności organizacji. Rozumieć go można jako zdolność do szybkiego zdobywania feedbacku, wprowadzania zmian w planach oraz dostarczania wartości klientom. Mówiąc bardziej obrazowo jest to poziom sterowności organizacji i długość pętli zwrotnych z rzeczywistością.
Dlaczego optymalizacja Time to Market jest tak ważna? Dlatego, że stanowi ona swoisty system nerwowy organizacji, będący kluczem do procesu empirycznego. Bez możliwości szybkiego uzyskiwania feedbacku biznesowego i technicznego nie jesteśmy w stanie efektywnie weryfikować hipotez i opierać się na danych. Zaniedbanie tego obszary powoduje, że organizacja staje się powolna w swoich działaniach i traci konkurencyjność na rynku.
Jednym ze sposobów analizy sterowności może mierzenie Lead Time, czyli czasu od powstania idei do momentu, gdy użytkownik może jej „doświadczyć” w działającym produkcie. Drugim przykładem jest Cycle Time, rozumiany jako czas od momentu przyjęcia zadania przez zespół, do jego zakończenia.
Myśląc o wytwarzania oprogramowania, wiemy, jak ważnym parametrem jest tzw. Release Frequency, czyli to, jak często użytkownicy dostają nowe wersje produktu. W moim odczuciu jest to prawdziwy papierek lakmusowy zwinności, bo jeśli aktualizacje czy nowe wersje produktu nie pojawiają się z odpowiednią częstotliwością to ryzykujemy niezadowolenie klienta i utratę pozycji w walce z konkurencją.
Ability to Innovate
Czwartym i ostatnim obszarem EBM jest Ability to Innovate, czyli poziom efektywności procesu w dostarczaniu wartości. Dokładne zrozumienie tego obszaru pomaga ustalić, co spowalnia i utrudnia dostarczanie pożądanej wartości oraz pozwala na świadomą redukcję „tłuszczyku procesowego”, czyli marnotrawstwa. Widać tutaj mocną inspirację autorów EBM podejściem Lean.
Co zatem można mierzyć i optymalizować w tym obszarze? Ciekawym wskaźnikiem może być Innovation Rate, rozumiany jako procent czasu, jaki pracownicy poświęcają na wytwarzanie wartości. Jako przykład mogę podać zespół deweloperski: jeśli Innovation Rate jest na poziomie 70% oznacza to, że 70% czasu pracy członkowie zespołu spędzają na wytwarzaniu oprogramowania, a 30% czasu na spotkaniach.
Kolejnym miernikiem proponowanym przez Scrum.org jest On-Product Index, czyli procent czasu jaki jest poświęcany na wytwarzanie nowych elementów produktu versus czas poświęcany na przywracanie do działania (w podejściu Lean jest to rework lub defects). Przykładowo, jeśli w zespole deweloperskim On-Product Index wynosi 40% oznacza to, że zespół programistyczny 60% przeznacza na naprawę błędów, a tylko 40% na nowe funkcjonalności.
***
EBM opiera się na zestawie czterech obszarów, Key Value Areas, z których każdy dotyka nieco innego wymiaru do optymalizacji. Framework pozwala nam swobodnie dobrać metryki opisujące te obszary, jednak bardzo ważne jest, aby wszystkie były rozwijane harmonijnie. Należy zastanowić się, który obszar w chwili obecnej stanowi ograniczenie i na nim priorytetowo skupić swoją uwagę. Jeśli tego odpowiednio nie zaplanujemy to ryzykujemy jedynie lokalną optymalizację, którą w izraelskim slangu określa się mianem chupchik – coś ładnego, ale niepotrzebnego.
Na koniec chcę, abyśmy pamiętali, że EBM to nie tylko framework stworzony przez Scrum.org, ale też (albo przede wszystkim) ruch społeczny i sposób myślenia. Wszyscy pamiętamy zapewne cytat Petera Druckera, że „bez danych jesteś jedynie kolejną osobą z kolejną opinią”. Pamiętając, że w sercu EBM leżą właśnie dane, pozwolę sobie na pewną autorską parafrazę: „Bez potwierdzenia, że to co robisz ma sens, jesteś kolejną osobą tworzącą chupchika”.
1 Evidence-Based Management Guide: www.scrum.org/resources/evidence-based-management-guide
Akredytowany trener Scrum.org oraz Kanban University. Posiada doświadczenie z najróżniejszych obszarów powiązanych z projektami IT. Od wielu lat pomaga rozwiązywać najróżniejsze problemy organizacjom począwszy od startupów na korporacjach kończąc. Gdy wymaga tego sytuacja dołącza do projektu i pomaga wyprowadzić go z krytycznej sytuacji. Nie akceptuje kosmetycznych zmian i podążania za projektową modą. Jeżeli pomaga wdrażać w organizacji Kanbana albo Scruma to tylko po to, aby wytwarzano lepsze oprogramowanie spełniające oczekiwania i potrzeby
użytkowników.