Nie używamy metryk, bo…

Na portalu AgileBrains Przemek napisał bardzo dobry tekst „Metryki w Scrum – Jak mierzyć efektywność wdrożenia Scruma?”. Po przeczytaniu tego artykułu można odnieść wrażenie, że bardzo łatwo jest zacząć mierzyć i odkrywać nowe wymiary efektywności. Bułka z masłem. Albo kawałek ciastka, jak mawiają Amerykanie.

Tymczasem w organizacjach, z którymi pracowałem, bardzo rzadko spotykałem się z używaniem wartościowych metryk. Dlaczego tak jest? Dlaczego mamy dostępnych sporo ciekawych metryk – a tak rzadko ich używamy?

 

Nie używamy metryk, bo… nie widzimy celu ich zastosowania

Pierwszą przyczyną braku używania metryk jest niezrozumienie celu ich stosowania. Niejednokrotnie widziałem taką sytuację: menedżer przychodzi do swoich pracowników i mówi: „Musimy być bardziej uprocesowieni i musimy stworzyć KPI dla naszych projektów/zadań/przedsięwzięć. Wymyślcie coś do jutra”.

Co robią w tym momencie pracowników? Drapią się po głowach i wymyślają metryki, które spełniają dwie cechy: a) są możliwe do zmierzenia, b) są dla nich bezpieczne, tzn. od razu wiadomo, że nie pokażą żadnych trudnych rzeczy.

Często bywa tak, że po jakimś czasie wszyscy zapominają o tej metryce, przestają zbierać dane, a po jakimś czasie przychodzi nowy menedżer i mówi: „Musimy być bardziej uprocesowieni, musimy stworzyć KPI dla naszych projektów…”.

 

Nie używamy metryk, bo… nie mamy wspólnego systemu ALM

Załóżmy bardziej pozytywny scenariusz. Menedżer mówi coś takiego. „Sukces naszego produktu jest oparty na szybkim dostarczaniu zmian do klientów oraz na jakości naszego systemu. Te rzeczy są trudne do bezpośredniego zmierzenia. Jak myślicie – jak moglibyśmy zmierzyć, na ile dobrze i skutecznie realizujemy te cele?”.

To jest zupełnie inne otwarcie niż w poprzednim przypadku. Zespół zaczyna się zastanawiać i wymyśla na przykład, że można mierzyć „cycle time” dla funkcjonalności – czyli ile czasu mija od złożenia zlecenia przez klienta do wdrożenia rozwiązania na produkcję.

Ale okazuje się, że zlecenia od klienta są rejestrowane w systemie A, następnie są rozbijane na podzadania w systemie B, a dane o zmianach przenoszonych na produkcję są w systemie C. Konsolidacja danych z wszystkich systemów jest żmudna i pracochłonna.

Mamy więc kolejny warunek konieczny: jeżeli chcemy używać metryk, musimy zautomatyzować ich tworzenie.

 

Nie używamy metryk, bo… używamy specyficznych rozwiązań

Załóżmy jednak, że mamy wspólny system realizacji zleceń. Dla przykładu niech będzie nim JIRA. Załóżmy również optymistycznie, że mamy w nim zarówno zlecenia klienta, rozbicie na zadania oraz zalogowany czas pracy nad każdym zadaniem. Wszystko w jednym miejscu, super!

W międzyczasie zespół zdecydował, że chciałbym mierzyć cztery rzeczy:

  1. „cycle time” dla zlecenia klienta
  2. czas pracy spędzony nad zleceniem klienta
  3. „cycle time” dla błędu
  4. czas pracy spędzony na błędem

Ale okazuje się, że nasza JIRA jest dość uboga w raportowanie – a istniejące raporty nie są dopasowane do naszej specyfiki używania tego narzędzia. Okazuje się na przykład, że zlecenia klienta są zapisywane w trzech projektach, a zadania z tych projektów są łączone z zadaniami z projektu deweloperskiego. I niestety nie ma raportu, który pozwoli nam na automatyczne wyliczenie czasu cyklu…

 

Nie używamy metryk, bo… mamy bałagan w danych

Załóżmy jednak, że mamy zdolnego programistę, który napisał nam program do wyciągania danych z JIRA przez API, obrabania ich oraz prezentowania w sensowny sposób. Dostajemy wreszcie nasze metryki!

Niestety, po bliższym przyjrzeniu się tym danym okazuje się, że wyglądają one dziwnie… Zagłębiamy się w szczegóły („dlaczego średni czas poprawy błędu w zespole A wynosi 20 dni, a w zespole B wynosi 60 dni?”) i okazuje się, iż:

  • zespół A rejestruje błędy jako typ zadania „Bug”, zespół B rejestruje błędy jako „Error”;
  • ktoś w kwietniu 2017 roku zrobił „bulk update” na wszystkich historyjkach z zespołu C, w związku z tym pole „Resolution Date” zostało przestawione na tę datę – czyli raport dla tego zespołu działa niepoprawnie;
  • kolejny zespół używa historyjek-separatorów o nazwach „Technical Stuff” albo „End of release here”, które też zostały uwzględnione w raporcie;
  • zespół D rejestruje czas pracy bezpośrednio przy zadaniu, zespół E tworzy sobie osobne zadania testowe.

Wszystkie powyższe przykłady są wzięte z życia…

Z reguły czeka nas pracowity czas analizy raportu, sprawdzania poprawności danych, poprawiania mechanizmu raportującego oraz czyszczenia danych. Musimy też ustalić z zespołami wspólne zasady pracy, żeby metryki pokazywały nam spójny obraz rzeczywistości.

 

A jeżeli to wszystko uda się zrobić…

A jeżeli to wszystko uda się zrobić, to… to mamy zmierzone dane dotyczące naszej pracy. Możemy je wspólnie obejrzeć. Możemy się wspólnie zastanowić, co wynika z tego, że klient średnio czeka 90 dni na poprawieniejego błędu. Możemy zastanowić się, co możemy zrobić, żeby skrócić czas dostarczania funkcjonalności lub ilość błędów w produkcie. Coś, co wcześniej było intuicją zespołu („wydaje mi się, że mamy za dużo błędów”) zaczyna być mierzalne i widoczne.

Ale może być również tak, że zespół obejrzy te dane i stwierdzi „W zasadzie niewiele z tego wynika”. „I tak to już wiedzieliśmy”. „Skupmy się na swojej robocie”.

Czy warto pracować nad metrykami? Na pewno tak. Ale przeważnie nie jest to proste. I nie zawsze jest to uwieńczone sukcesem.

2 thoughts on “Nie używamy metryk, bo…

  • Stanisławie, zgadam się z tobą w 100% i jest jeszcze dużo innych powodów dlaczego zespoły nie chcą (nie potrafią) pracowac z metrykami. Jednym z wiekszych problemów jest też strach przed mierzeniem czegokolwiek. W naszych głowach metryki bardzo często mieszane są z KPIami albo SLA. Zespół boi się, że tzw metryki mogą być wykorzystane przeciwko nim (i tu wchodzi nasza rola SM).

    Kolejny problem z metrykami jest taki, że nie są one postrzegane „systemowo”. Weźmy twój przykład:

    „cycle time” dla zlecenia klienta
    czas pracy spędzony nad zleceniem klienta
    „cycle time” dla błędu
    czas pracy spędzony na błędem

    Jeśli sprawa zostanie postawiona w taki sposób jest duża pokusa do „ciecia rogów”, opuszczaniu jakości, itd, by wszelkim kosztem zminimalizować „cycle time”, bo przecież to nas „sukces”.

    Ostatnie 0.5 roku zagłębiałem się w statystyke i jej zosowaniu w projektach Agile (polecam actionable agile metrics i cos o statystyce jako takiej), pomimo zautomatyzowania procesu i rozwiązaniu wiekszości problemów które opisujesz, został mi najtrudniejszy – czynnik ludzki :)

    Pozdrawiam.

  • Cześć, myślę, że negatywne nastawienie do metryk wynika z głęboko zakorzenionych doświadczeń szkolnych. Tam metrykami były oceny, które w niejednym domu decydowały o atmosferze jeszcze przez kilka dni po wywiadówce. Raczej rzadko można było usłyszeć o nagrodach za dobre oceny, za to często o karach.

    Co można zrobić w takiej sytuacji? Pracować nad zmianą nastawienia do procesu oceniania. A to jest o tyle trudne, że pracownicy w domu mają dzieci, które przynoszą oceny, do których rodzice przecież muszą się odnieść :) Więc ciągle działa czynnik utrwalający negatywne nastawienie :(

    Dlatego w tej zmianie bardzo ważne jest zaufanie zespołu, że metryki nie zostaną przez innych wykorzystane przeciwko niemu lub poszczególnym członkom zespołu. Ważne jest pokazywanie co zespół zyska dzięki metrykom: gdy są dobre pewność siebie, może nawet jakąś nagrodę, a gdy są złe możliwość bycia lepszym, ale przede wszystkim realne spojrzenie na siebie.

    pozdrawiam :)

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *