Miary zwinności vol. 2 

Oto druga część „miar zwinności”. W poprzednim poście obiecałem, że nie będzie on ostatnim. Wszyscy łakniemy praktycznych kąsków, możliwych do wykorzystania w naszych projektach. Jako Scrum Masterzy z krwi i kości, jesteśmy między innymi po to, aby posiadaną przez nas wiedzą się dzielić.

TTM, czyli Time to Market

Time to market to czas od momentu rozpoczęcia prac nad daną rzeczą, aż do jej udostępnienia użytkownikom końcowym. Pisaliśmy już o TTM, po szczegóły zapraszamy więc do odpowiedniego wpisu. Zajmiemy się za to praktycznym wykorzystaniem tego miernika.

Im mniejsza wartość TTM, tym lepiej dla naszego zespołu. Im szybciej dostarczymy działający przyrost, tym szybciej zdobędziemy informację zwrotną od interesariuszy i tym krócej nasz klient czeka na rozwiązanie swoich problemów.

Możemy mierzyć Time to market zarówno dla kompletnej, ostatecznej funkcjonalności, jak i dla biznesowo użytecznego Minimum Viable Product. Ten ostatni da naszemu klientowi możliwość zaznajomienia się z funkcjonalnością i zgłoszenie uwag. W takim przypadku jak na dłoni będziemy widzieli, że MVP dostarcza wartości o wiele szybciej. Time to market będzie o wiele krótszy (a klient bardziej zadowolony).

TTM jest, a przynajmniej powinien być języczkiem u wagi każdego Zespołu Deweloperskiego. W końcu na końcu każdego zadania znajduje się to, po co istnieje na rynku każda firma – pieniądze.

Kej-Pi-Aj

Tak, jak Excel jest najlepszym narzędziem do zarządzania wszechświatem, tak KPI (ang. Key Performance Indicators) to miara wykorzystywana do mierzenia postępów wszelakich projektów. Kluczowych wskaźników efektywności używa się co najmniej tak długo, jak prowadzi się projekty. Samo to jednak nie jest jeszcze rekomendacją do ich wykorzystania.

KPI to wszelkiego rodzaju finansowe i niefinansowe mierniki, wykorzystywane w procesie pomiaru stopnia realizacji celów projektu. Już powyższa definicja pokazuje, że mamy prawo zamodelować dowolny KPI (najczęściej na podstawie wcześniej obserwowanych wielkości) i weryfikować go w każdej chwili trwania naszego projektu. Przykład?

„22 sierpnia powinniśmy mieć zrealizowanych 84,5% zaplanowanych na 34 sprint wymagań”

Na podstawie wcześniejszych Sprintów jesteśmy w stanie przewidzieć velocity, a co za tym idzie jesteśmy w stanie wyliczyć powyższy stosunek wymagań zakończonych do niezakończonych. Czy miara ta jest jednak dokładna? Oczywiście, że nie. Nie przewidujemy w niej możliwości zmian w naszym projekcie, o których niejednokrotnie już pisaliśmy, na które musimy umieć odpowiedzieć.

Do popularnych KPI należą też zysk netto, marża ze sprzedaży, ale również np. liczba błędów do ilości wykonanych transakcji czy koszty złej jakości (które obiecuję, że opiszę szerzej w najbliższym czasie).

Jak więc widać, KPI to narzędzie uniwersalne. Jako takie może być wykorzystywane w dobry i zły sposób. Musimy jednak pamiętać, że wszystko co w ten sposób mierzymy zostanie wypaczone, jeżeli zaczniemy za to nagradzać lub karać. Pisaliśmy o „Ukrytych korzyściach” w tekście na temat motywacji.

Lead Time, Cycle Time, Throughput

Podstawowe miary wykorzystywane w metodyce Kanban to właśnie Lead Time, Cycle Time i Throughput.

Lead Time to inaczej opisany powyżej TTM. Cycle time to z kolei tylko czas przejścia zadania przez wszystkie czynności. Jako taki nie obejmuje on okresów oczekiwania w backlogu czy na liście To Do. Pisaliśmy już o nich przy okazji innych zagadnień poruszanych na naszym blogu.

Czym jest throughput? To wydajność, czyli średnia liczbą produktów dostarczonych w danym czasie. Znów pojawia się słowo „średnia”. Mam do niej dość negatywny stosunek, ale umiejętne wykorzystanie tej miary, na podstawie długich obserwacji może dać nam jakiś input do podejmowania dalszych decyzji.

Czy miary te są „wykorzystywalne”? Z metodyki, z której pochodzą jak najbardziej. Odniosły one tam duży sukces pozwalając na optymalizację procesów zachodzących w fabrykach wykorzystujących Toyota Production System. Czy w Scrumie chcemy maksymalizować np. throughput liczby wymagań dowiezionych per Sprint? Cóż, raczej nie o to nam chodzi.

Customer Happiness Index

Często pomijany indeks zadowolenia użytkownika. Niesłusznie, bo jak każdy z nas nie jeden raz się przekonał, od klienta bardzo dużo zależy. Nie mówię tutaj jedynie o odbiorze przygotowanego przez nas produktu, ale też o jakości współpracy, na którą wpływa tyle czynników, że trudno byłoby opisać je w jednym poście.

W jaki sposób mierzyć zadowolenie klienta? Możemy poprosić nasz biznes o przedstawienie swojego poziomu zadowolenia na podstawie kilku przygotowanych wcześniej emotek (pamiętając, aby przygotować wcześniej dokładną legendę) czy poprosić o odpowiedź na jedno proste, ale podchwytliwe pytanie:

Czy przygotowana przez nas funkcjonalność spełniła Twoje oczekiwania?

Istnieje również możliwość założenia. że zadowolenie naszego klienta zależeć będzie od ilości błędów, jaką musiał zgłosić. Wykonując proste działanie sami dowiemy się, jak bardzo „zepsuliśmy” zadowolenie naszego klienta.

Czy to już koniec?

Koniec na dziś wcale nie oznacza, że opisaliśmy wszystkie „miary zwinności”. Jest ich dużo, a nawet bardzo dużo. Co możemy z nimi zrobić? Wykorzystywać. A bardziej konkretnie – mądrze wykorzystywać do pomiaru rzeczy, które nas interesują.

Czy są idealne mierniki? Oczywiście, że nie – nie ma rzeczy idealnych. Mówią one wiele o naszej przeszłości i są wykorzystywane do prób przewidzenia przyszłości. I jako do takich, trzeba do nich podchodzić z pewną rezerwą.

Przede wszystkim zaś, należy unikać pułapki optymalizacji mierników za wszelką cenę. Na nic skupienie się na cycle time czy jakimś KPI, jeżeli nasz klient nie dostaje tego, za co zapłacił. W końcu to „Działające oprogramowanie jest podstawową miarą postępu.”

Zapraszamy także do przeczytania pierwszego wpisu z cyklu Miary Zwinności.