Szukaj

Wydajność kontra Efektywność

Zaktualizowano: lip 1



Bardzo często myśląc o efektywności mówimy o realizacji jak największej liczby zadań w określonym czasie (ang. output). Często nasuwają nam się również miary pokroju Velocity czy Capacity. O ile nie ma nic złego w mierzeniu prędkości zespołu, o tyle mówimy tutaj bardziej o wydajności, a nie efektywności.

Prawdziwą efektywność należy utożsamiać z efektem naszej pracy jakim jest produkt. Powinniśmy więc mówić o wartości jaką dostarczamy końcowemu użytkownikowi (ang. outcome), czy też ujmując inaczej z mierzalną zmianą w zachowaniu użytkownika.

Co wpływa na efektywność i jak możemy ją poprawić?

Pamiętajmy o celu produktu

W kontekście efektywności chodzi nie tyle o posiadanie samego celu produktu, co o filtrowanie wymagań przez ten cel produktu (przy okazji warto spojrzeć do najnowszego Scrum Guide 2020 gdzie cel produktu został bardzo mocno podkreślony). Zadanie sobie pytania dlaczego robimy daną funkcjonalność i jaki ma być jej finalny efekt? Czy ona rzeczywiście wspiera cel produktu czy jest tylko kolejnym elementem backlogu zdjętym z góry kolejki lub zleconym przez interesariusza.

Róbmy właściwą rzecz

Powinniśmy zadać sobie pytanie czy robimy właściwą część danego wymagania. W tym celu najlepiej dokonać dekompozycji na mniejsze elementy np. na sesji Refinement. Pamiętajmy, że słynna zasada Pareto mówi, że 20% nakładu odpowiada za 80% efektu. Znajdźmy więc te 20% najważniejszych rzeczy, w przeciwnym razie może okazać się, że przepalimy czas w sprincie na nikomu nie potrzebne dodatki.

Bądźmy blisko biznesu

Jeśli oczekujemy od zespołu developerskiego aktywnego i kreatywnego wkładu w projektowane rozwiązanie, zespół powinien być blisko biznesu. Developerzy powinni dobrze rozumieć potrzeby końcowego użytkownika, tylko wtedy będą w stanie prowadzić wyrównany dialog z Product Ownerem i interesariuszami, a tym samym dobrać najlepsze możliwe rozwiązanie.

Pozostańmy skupieni

W sytuacji gdy wspieramy wiele wersji tego samego produktu możemy dojść do miejsca gdzie zbyt dużo czasu będziemy poświęcać na ich utrzymanie, naprawę błędów i szeroko pojęte wsparcie. Może nam fizycznie brakować czasu na dostarczanie nowych funkcjonalności i co ważniejsze chęci na eksperymentowanie.

Drugim przypadkiem, zaburzającym skupienie zespołu, jest praca w kilku obszarach na raz. Czas potrzebny na przełączenie między nimi ma negatywny wpływ zarówno na samą wydajność jak i ogólne zaangażowanie zespołu.

Dążmy do autonomii

Jeśli Product Owner dysponuje ograniczonym poziomem decyzyjności, wynikającym np. z takiej a nie innej struktury organizacyjnej lub zbyt silnym umocowaniu interesariuszy w produkcie. Kiedy potrzebuje pozwolenia na każdą nawet najmniejszą zmianę kierunku, wtedy cały produkt traci na zwinności, a w efekcie cierpi końcowa efektywność.

Miary efektywności

Mówiąc o miarach efektywności najlepiej skierować się w stronę Evidence Based Management (EBM). Jest to empiryczny framework, mające swoje korzenie w medycynie, a obecnie szeroko stosowany w organizacjach w celu poprawy ich efektywności w dostarczaniu wartości klientom i realizacji strategicznych celów.

EBM wyróżnia 4 główne obszary (ang. Key Value Areas):

  • Current Value (CV) - jaką wartość dostarcza nasz produkt, w chwili obecnej, w odniesieniu do celu produktu

  • Unrealized Value (UV) - potencjalna przyszła wartość którą możemy zrealizować w odniesieniu do celu produktu

  • Time-to-Market (T2M) - jak długo zajmuje nam dostarczenie nowej wartości

  • Ability to Innovate (A2I) - jak skuteczni jesteśmy w dostarczaniu nowych możliwości, które mogą lepiej zaspokoić potrzeby klientów

Każdy z obszarów zawiera szereg miar (po szczegóły odsyłam do EBM Guide). W kontekście efektywności chciałbym wyróżnić kilka z nich.

Z obszaru Current Value:

  • Usage Index - ile osób, tak naprawdę, korzysta z naszych nowych funkcjonalności i czy poświęcają na nie tyle czasu ile oczekiwaliśmy

  • Customer Satisfaction - ocenia zaangażowanie i ogólne zadowolenie klienta z produktu bądź jego części

Z obszaru Ability-to-Innovate:

  • Innovation Rate - ile czasu procentowo poświęcamy na utrzymanie lub poprawę bugów, a ile na nowe funkcjonalności

  • Version Index - ile wersji danego produktu utrzymujemy. Zarówno w kontekście wysiłku jaki wkładamy w zarządzanie poszczególnymi wersjami jak i faktu, że nie wszyscy użytkownicy są w stanie skorzystać z najnowszych funkcjonalności.



Referencje:

https://www.scrum.org/resources/blog/making-sense-product-owner-effectiveness

https://www.scrum.org/resources/measuring-effectiveness

https://www.scrum.org/resources/evidence-based-management

Podcast Porządny Agile - #60 Efektywność Zespołu Scrumowego



0 komentarz

Ostatnie posty

Zobacz wszystkie