Jeżeli już ktoś zaczyna wprowadzać jakikolwiek mierniki, to zwykle dotyczą one samego procesu wytwórczego. Podejście zwinne powinno być skupione wokół produktu, ale niestety prawie nikt nie sprawdza, jak nasze produkty sobie radzą.
Effort, Output, Outcome
Zacznijmy od zdefiniowania trzech dość podstawowych pojęć które pomogą nam zgrabnie poruszać się w tematyce zarówno projektów, jak i produktów. Mowa tu angielskiej trójce: effort, output, outcome.
Effort to nic innego jak włożony wysiłek. Tu warto odwołać się do tekstu pod tytułem gloryfikacja zapracowania, gdzie znęcałem się nad naszą kulturą pracy. Trzeba bowiem podkreślić, że w dalszym ciągu wielu managerów patrzy na włożony wysiłek, jako na jedyny wskaźnik skuteczności pracownika bądź zespołu. Znaczy to tyle, że osoba która wymęczona wychodzi z pracy po wielu nadgodzinach jest oceniana pozytywnie. Bo przecież się stara i daje z siebie wszystko.
Mało komu przyjdzie do głowy, że nasz wiecznie zarobiony bohater po prostu sobie nie radzi. Oczywiście, to może wynikać z wielu rzeczy. Powodem może być to, że ktoś się po prostu nie nadaje do danej pracy bądźcie się obija. Ale równie dobrze może mieć za dużo obowiązków, wrzucanych nań przez „kogoś”. To jednak temat na inny tekst przy innej okazji.
Output to efekty naszej pracy – nasze działania i/lub to co udało nam się wytworzyć. W największym uproszczeniu możemy przyrównać to do zrealizowanych funkcjonalności, liczby wdrożeń, linii napisanego kodu, i tak dalej. To rzeczy, które „wychodzą na zewnątrz” z naszego zespołu bądź organizacji. To nie to samo co wysiłek, bo na output w postaci poprawionej setki błędów, effort może wynieść zarówno 70 jak i 700 godzin. No dobrze, ale jaki skutek dla odbiorców ma te poprawione 100 błędów? To właśnie będzie outcome.
Outcome to odpowiedź na pytanie „No i co z tego?” Są to konsekwencje naszych działań, tych rzeczy, które są rezultatem naszej pracy (output). Co z tego, że wdrożyliśmy pięć funkcjonalności, co z tego że poprawiliśmy 500 błędów? Liczy się, jakie są konsekwencje dla naszych odbiorców i czy tak naprawdę nasze działania sprawiły jakąkolwiek różnicę.
Nie muszę chyba dodawać że właśnie outcome jest czymś, czym wszyscy powinniśmy być zainteresowani. Najbardziej oczywiście Product Owner, który przecież odpowiada za produkt.
Projekt produkt
Zanim przejdziemy dalej, warto też wspomnieć o miernikach i wszystkich policzalnych aspektach naszej pracy, zarówno w kontekście projektu jak i produktu.
W podejściu projektowym największym sukcesem jest oczywiście dowiezienie projektu na czas, w budżecie i w zakresie. Wszystkie mierniki, którym będziemy się przyglądać będą dotyczyły wydajności, efektywności i tym podobnych rzeczy. Przecież wszyscy dobrze wiemy, za co należy się premia na projekcie.
Na projektach najczęściej sprawdzamy effort i outcome. Patrzymy, czy na przykład jest odpowiednia utylizacja pracowników, czy wszyscy mają źródło finansowania, ale też jak szybko realizowane są wymagania i jak dużo błędów jest znajdowane w wytworzonych rozwiązaniach. Wszystko jest bardzo istotne dla Project Managera, ale w zasadzie klient może zapytać „No i co z tego?”.
Idąc dalej, większości projektów zakończonych sukcesem nie obchodzą dalsze losy wytworzonego rozwiązania. Świętujemy zakończenie projektu, a niewielkie przekroczenie budżetu lub terminu to dla nas wyznacznik sukcesu. „Po nas choćby potop.” Nie widziałem niestety sytuacji, w której projekt zrealizowany na czas i w budżecie był określany jako porażka, bo nikt nie korzystał z wytworzonego rozwiązania. Widziałem za to wiele projektów zakończeniach „sukcesem”, gdzie całe wytworzone rozwiązanie szło do kosza. Ale projekt się udał!
Dlatego tak ważne jest żeby wiedzieć, co w ogóle chcemy osiągnąć, a potem potrafić zweryfikować, czy nam się to udało. Nawet w tym nieszczęsnym podejściu projektowym, jeżeli naszym celem jest wytworzenie nowej usługi, która ma przynosić jakąś rentowność albo ma być używana w określone wolumenie, to dobrze byłoby się upewnić, że udało się to (ten outcome) osiągnąć. Niestety, tutaj borykamy się z tym, że w przypadku klasycznych projektów zespoły są rozmontowane na koniec i tak naprawdę nikogo już nie obchodzą dalsze losy rozwiązania. Nawet jeśli zostaje nam do obsługi jakiś produkt, to bardzo często nie ma ani środków, ani możliwości, żeby jakiekolwiek informacje zwrotne wyciągnąć.
Mierzenie sukcesu produktu
Mierzenie sukcesu produktu nie jest skomplikowane, ale musimy o to zadbać na wczesnym etapie powstawania naszego rozwiązania. Jeżeli np. budujemy nowe kanały sprzedaży, to musimy wiedzieć, która sprzedaż pochodzi z jakiego kanału. Przydałoby się w jakiś sposób policzyć, ilu nowych klientów dostarczyliśmy firmie.
Brzmi prosto? Niestety, w przypadku działań rynkowych, często mamy do czynienia z cyklami tygodniowymi, miesięcznymi, rocznymi, a także z koniunkturalnymi. Bez danych historycznych niewiele zrobimy. Możemy pokazać, że na przykład zyskaliśmy 100 000 nowych transakcji, ale w żaden sposób nie będziemy wiedzieli czy to w danym okresie jest dużo czy mało.
Dlatego też zaryzykuję stwierdzenie, że nie da się działać w podejściu produktowym i nie da się być skutecznym Product Ownerem, jeżeli masz nasze rozwiązanie/nasz produkt nie jest omiernikowany. Bez analizy danych działamy na ślepo – niby coś robimy, ale potem nie mamy jak sprawdzić efektów. Zostaje nam trzymanie kciuków, że „będzie dobrze”. A przecież klienci cały czas do nas „mówią”.
Oczywiście „mówią” jest w cudzysłowie, bo najczęściej możemy wydobyć potrzebne nam informacje na podstawie zachowań naszych użytkowników. Jeżeli mamy 50 funkcjonalności w naszej aplikacji użytkowej i chcemy dodać 5 kolejnych, to fajnie by było wiedzieć w jakim stopniu te nowe pięć będzie używane na tle poprzednich. A tak naprawdę warto też byłoby wiedzieć, które z tych 50 można spokojnie przestać rozwijać albo wręcz usunąć. Często okazuje się, że samo utrzymanie funkcjonalności jest nieopłacalne, bo… nikt z nich nie korzysta! A to są tylko podstawowe informacje, które świadomy Product Owner powinien mieć na wyciągnięcie ręki. Najczęściej jednak ich nie ma, bo jedyny miernik to „jak szybko dostarczamy kolejne funkcjonalności”. A to, czy są one faktycznie używane, nikogo już nie interesuje.
Mamy tyle możliwości na pokazywanie klientom różnych wariantów naszych procesów, na testy A/B, na mierzenie popularności rozwiązań i badanie „w jaki sposób ludzie korzystają z naszych rozwiązań” oraz jak poruszają się po naszych procesach. Szczególnie w dzisiejszych czasach warto z tych możliwości skorzystać i przestać skupiać się na tym „jak szybko jedziemy” i zacząć zastanawiać się „w którym kierunku podążamy”. I czy przypadkiem nie kręcimy się w kółko.
