Pragmatycznie o… Mierzeniu Efektywności Zespołów Programistycznych

Wprowadzenie

0:00 Cześć. W dzisiejszym odcinku porozmawiamy pragmatycznie o tym, jak mierzyć efektywność zespołów programistycznych, a przynajmniej o tym, jak my to robimy w Pragmatic Coders, po wielu latach prób i błędów.

0:10 Zapraszam! Zapewne wielokrotnie słyszeliście o tym, że nie da się zmierzyć pracy programistów. Nie da się, bo i tutaj wiele różnych przyczyn, takich jak: „Nie, bo to jest praca kreatywna”. Pracy kreatywnej nie da się zmierzyć. „Nie, bo jeżeli zaczniemy mierzyć pracę programistów, to skupią się na ilości. Utracimy efekt jakościowy naszej pracy”. Nie da się zmierzyć, bo zadania są bardzo różnorodne. Nie da się porównywać ze sobą różnych zadań, nie da się porównywać ze sobą różnych zespołów, nie da się porównywać ze sobą pojedynczych programistów. Jest to niewykonalne.

0:46 Ogólnie jest bardzo trudno mierzyć różne rzeczy w IT, w produkcji oprogramowania. Wiele różnych prób i podejść, które miały miejsce w historii, kończyło się porażkami i powstawaniem różnych rzeczy, które nie miały najmniejszego sensu, nie wnosiły żadnej wartości.

1:01 A co, jeśli spróbujemy podejść do tematu troszeczkę inaczej? W jednym z poprzednich odcinków opowiadałem wam o tym, czym jest Output, Outcome i Impact. Co, jeśli zastanowimy się nad tym, co jest najmniejszą jednostką wartości pracy programistów? I co, jeśli wyjdziemy od tej wartości i spróbujemy się zaczepić najbliżej Outcome, jak się da, i na tej podstawie opracujemy nasze metryki, które pozwolą nam chociażby monitorować to, jak dobrze performuje nasz zespół w czasie, bądź też porównać ten zespół do innych zespołów w naszej firmie czy też w innych organizacjach, które stosują podobne metryki.

Definicja i znaczenie User Story

1:33 Poczyńmy na początek pewne założenie, że najmniejszą – oczywiście niedoskonałą – jednostką wartości dostarczaną przez zespół programistyczny jest zrealizowane i wdrożone na produkcję User Story. Nadal nie będzie to metryka skupiona bezpośrednio na Outcome, ona będzie dalej na Outpucie. Natomiast jeżeli odpowiednio zdefiniujemy sobie, czym jest User Story i zbudujemy tę świadomość wśród naszych zespołów i całej firmy, będziemy potrafić odróżniać User Story od tasków, to wtedy będziemy mogli faktycznie mierzyć te jednostki wartości dostarczane na produkcję, dalej na poziomie Outputu, niekoniecznie Outcome, ale wydaje mi się, że jest to najbliżej Outcome, jak jesteśmy w stanie się na takim bardzo obszernym poziomie zaczepić, skupiając się na Outpucie.

2:15 Jeżeli chcielibyśmy zmierzyć efektywność naszego zespołu czy naszych programistów, moglibyśmy sobie wymyślić metrykę dla takiego Outputu, mierzoną poprzez ilość zadań na liczbę przepracowanych godzin. Jeżeli natomiast chcielibyśmy spróbować zmierzyć Outcome pracy naszych programistów, to musielibyśmy sobie wybrać jakąś jednostkę wartości i sprawdzić, ile godzin zajmuje nam dostarczenie tej jednostki wartości.

2:39 Wspomniałem o tym, że w naszym przypadku niedoskonałą, ale jednak bardzo bliską Outcome jednostką wartości jest User Story. Żeby móc używać User Story jako jednostki wartości, najpierw musimy sobie dobrze zdefiniować, czym takie User Story jest, a czym ono nie jest. O tym, myślę, zrobimy kolejny odcinek w przyszłości. Natomiast na dzisiaj możemy skupić się na tym, że User Story to jest funkcjonalność, która wnosi wartość dla użytkowników i jest pisana z perspektywy myślenia atomowego, o którym wspomniałem we wcześniejszym odcinku.

3:10 W Pragmatic Coders używamy metryki, która pozwala nam określić, ile godzin średnio zajmuje nam dostarczenie na produkcję jednego User Story. Ale też podpieramy się obok metryką, która mówi o tym, ile godzin średnio zajmuje nam dostarczenie dowolnego taska – zadania z backlogu, w tym oczywiście też User Stories, ale także rzeczy, które są błędami, poprawkami błędów, bugami czy też taskami stricte technicznymi, dotyczącymi na przykład usprawnienia jakichś środowisk czy zmiany infrastruktury. Dlaczego wybraliśmy takie podejście?

Zwinność, zmiany i sukcesy w małych krokach

3:37 Przede wszystkim miarą zwinności jest zdolność do adaptacji do zmian. Czyli im częściej coś dostarczamy, im częściej jesteśmy w stanie zmienić kierunek naszej pracy, dostarczać w mniejszych jednostkach, w tym przypadku User Stories, tym bardziej zwinni jesteśmy. Dla interesariuszy zazwyczaj ważniejsze jest to, jak szybko reagujemy na potrzeby, niż to, jak dużo dostarczamy. Więc tutaj ten czas realizacji, czas dostarczenia jest kluczowy.

4:01 Jeden z naszych klientów powiedział kiedyś, że, cytuję: „Lepiej jest być częściej poklepywanym po plecach za małe sukcesy, niż co trzeci raz dostawać po głowie za dużą porażkę”. To, co miał na myśli, to to, że jeżeli często wdrażamy małe zmiany na produkcję i celebrujemy je, mówimy o nich, pokazujemy ich efekty, czyli Outcome, to wtedy po stronie klienta, po stronie firmy, po stronie całej organizacji jest to zauważone i docenione. Natomiast jeżeli wdrażamy na produkcję rzadko nawet duże zmiany, ale robimy to rzadko i raz na jakiś czas popełnimy jakiś błąd – to może być niewielka pomyłka – to wszyscy będą zawsze pamiętać o tym, że raz na trzy razy popełniliśmy błąd, niż o tym, że często dostarczaliśmy dużą wartość.

4:44 Jeżeli raz na wiele razy popełnimy jakiś błąd, to ten błąd gdzieś tam zginie w całej historii i wszyscy o nim bardzo szybko zapomną, bo ten błąd przykryjemy po prostu kolejnymi sukcesami, kolejnymi nowymi rzeczami czy też próbami wdrażania nowych rzeczy, które będą zakończone sukcesem bądź też jakąś lekcją, jakąś edukacją dla organizacji, dla nas samych.

Uwzględnianie wszystkich ról w mierzeniu efektywności

5:02 Ta metodyka, której używamy w Pragmatic Coders, uwzględnia wszystkie godziny przepracowane dla klienta, a więc wszystkie godziny, za które nasz klient nam zapłacił. Są to nie tylko godziny naszych programistów, ale też godziny pozostałych członków zespołu, czyli DevOpsów, UX-owców, Product Ownerów.

5:18 Na załączonym obrazku widzicie porównanie dwóch zespołów. Jeden z tych zespołów ma Product Ownera i UX-owca, a drugi z tych zespołów takiego Product Ownera i UX-owca nie ma. Zgadnijcie który. Jeśli dobrze przyjrzycie się, to zobaczycie, że średni czas potrzebny na zrealizowanie jednego User Story w dłuższej perspektywie czasu jest bardzo zbliżony w jednym i w drugim przypadku.

5:38 Prawda jest taka, że tutaj bardzo fajnie widać, że to, czy klient ponosi dodatkowy koszt za pracę UX-owca czy Product Ownera, tak naprawdę w ogólnym rozrachunku nie ma większego znaczenia. Na koniec dnia koszt wyprodukowania jednej jednostki wartości, czyli jednego User Story, jest bardzo zbliżony. Jest bardzo podobny. Natomiast przypuszczam, że w przypadku, kiedy w zespole jest produktowiec i UX-owiec, być może te User Stories, które są dostarczone, czasem mogą mieć większy sens biznesowy niż te, które może nie do końca są tak dobrze przemyślane, kiedy w zespole nie ma UX-owców i nie ma produktowców.

6:14 Kolejną zaletą stosowania tej metryki jest to, że rozmiar zespołu nie ma znaczenia i możemy takie zespoły nawet, uwaga, porównywać ze sobą. Tutaj na załączonym obrazku widzicie dwa zespoły, z których jeden jest prawie cztery razy większy od drugiego. I zgadnijcie który. Jak widzicie, oba te zespoły mają bardzo podobny koszt realizacji jednego User Story.

Metryki jakości i całościowe monitorowanie

6:36 Żeby móc realnie ocenić wartość dostarczaną dla klienta, musielibyśmy porównać również ilość zrealizowanych User Stories przez jeden czy drugi zespół. No i oczywiście możecie śmiało się domyślać, że ten zespół, który jest większy, dostarczył User Stories cztery razy więcej na koniec dnia. Ale oczywiście sumarycznie kosztowało to też cztery razy więcej.

6:54 No dobrze, co w takim razie z jakością samego User Story? Same taski to nie wszystko. Co z błędami? I tutaj zawsze, kiedy opowiadam o metrykach, kiedy uczę innych, jak stosować metodyki, jak dobierać metryki do ich pracy, to zawsze mówię o tym, że jedna metryka w izolacji nigdy nie pokazuje całego obrazu. Zawsze taką metrykę, która jest dla nas kluczowa, która dla nas jest najważniejsza, warto obłożyć sobie innymi metrykami. W Pragmatic Coders też mamy taką metrykę. Metrykę, która mówi nam o tym, jaki procent realizowanych zadań stanowią poprawki błędów realizowanych przez nasze zespoły.

7:29 Na załączonym obrazku widzicie, że historycznie liczba tych błędów – gruba niebieska linia – sukcesywnie spada, więc jako firma staramy się podnosić jakość naszych usług, zwracać na to uwagę. Oczywiście różnie to wygląda na różnych etapach pracy różnych zespołów. Tak jak wspomniałem, mierzymy nie tylko samą ilość User Stories czy też, ile godzin zajmuje nam średnio zrealizowanie jednego Story, ale mierzymy też liczbę wszystkich zadań na backlogu realizowanych przez nasze zespoły, w tym też właśnie zadania techniczne czy bugi.

Monitorowanie zmian i przewidywanie kosztów

7:58 Mierzenie tego typu rzeczy pozwala nam także zwizualizować to, czy mamy do czynienia z legacy code, czy być może poziom ogólnej jakości długu technicznego naszego produktu – produktu, który realizujemy dla naszych klientów – jest na dobrym poziomie, czy być może wymaga jakiś zmian?

8:13 Na załączonym obrazku widzicie proporcje User Stories do wszystkich realizowanych zadań. Znowu gruba niebieska linia pokazuje, jak to wygląda średnio we wszystkich naszych zespołach. Natomiast to, na co chciałbym, żebyście zwrócili uwagę, to linia, która jest na samym dole, linia w kolorze fioletowym, która obrazuje pracę zespołu, który pracuje nad projektem, który przejęliśmy po innym zewnętrznym dostawcy. Był to projekt, który był bardzo zaniedbany. Projekt z dużą ilością legacy code. Bardzo ładnie widać na tym wykresie, że w zasadzie średnio mniej niż 20% rzeczy, które realizujemy w tym projekcie, to są rzeczy związane z wartością User Story. Dostarczamy, a większość to prawdopodobnie poprawki błędów czy też realizacja zadań technicznych czy rzeczy, które muszą być zrealizowane w sposób manualny i nie są jeszcze zautomatyzowane.

8:55 To, co jest pozytywne, to widać pewien trend, który się podnosi, gdzie po prostu ten projekt zaczyna wyglądać coraz lepiej i jest spora szansa, że kiedyś dojdziemy do naszej średniej firmowej.

9:06 To, na co też warto zwrócić uwagę, to pomarańczowa linia na tym wykresie. To jest z kolei inny projekt, który zaczął się stosunkowo niedawno. I tutaj widzicie, jak na początku dużo było realizowanych User Stories w stosunku do innych rzeczy. Natomiast mniej więcej kilka miesięcy temu ten produkt wszedł na produkcję. Myślę, że to jest standardowy cykl życia produktu, że jeszcze zanim produkt wejdzie na produkcję, to realizujemy bardzo dużo wymagań, bardzo dużo wartości biznesowej. Natomiast w momencie, kiedy zderzamy ten produkt z produkcją, to okazuje się, że są tam jakieś błędy, które nasi użytkownicy wychwytują. Nie jesteśmy w stanie przewidzieć wszystkich scenariuszy, które nasi użytkownicy wymyślą – jak się zachować czy jak się zachowują, jak korzystają z naszej aplikacji. I też jest dużo rzeczy, które później pojawiają się, które trzeba zrobić, które często są manualną pracą, manualnymi zadaniami, taskami technicznymi czy też usprawnieniami związanymi z poprawą wydajności czy tego typu rzeczami, które po prostu wynikają z tego, że na początku bardzo mocno skupialiśmy się na tej wartości biznesowej, na czasie realizacji, a dopiero po wyjściu na produkcję pewne rzeczy wychodzą i trzeba się nimi zająć.

Praktyczne zastosowanie i korzyści ze wspólnej metryki

10:10 No dobrze. Co nam to daje w Pragmatic Coders? Przede wszystkim pozwala to nam monitorować zmiany w czasie. Czyli jeżeli wprowadzamy jakieś zmiany u nas w firmie, na przykład w metodach pracy czy w tym, jak chociażby mierzymy pewne rzeczy w firmie, to możemy w czasie obserwować, czy nasze zmiany wpłynęły na efektywność naszych zespołów, na to, jaką wartość dostarczamy dla naszych klientów.

10:29 Jest to też dla nas narzędzie do rozmów o kosztach i wartości z naszymi klientami. Naszym product managerom bardzo łatwo jest policzyć, ile kosztuje 50 godzin pracy zespołu i porozmawiać z klientem o tym, czy to story, które właśnie sobie wymyślił, które ma wątpliwy Outcome, jest warte tej kwoty.

10:50 Jest to też narzędzie do estymacji kosztów. Znając średnią wartość tego, ile kosztuje zrealizowanie jednego User Story, mając zapytanie od klienta o zrobienie czegoś nowego, możemy bardzo prosto podzielić nowy produkt na User Story, pomnożyć przez wartość średnią i z bardzo dużym prawdopodobieństwem oszacować, ile dany produkt będzie kosztował.

11:10 Jest to prosta miara, którą łatwo zrozumieć i łatwo wprowadzić w życie, i każdy może jej używać. Przykładowo nasze zespoły bardzo często same z niej korzystają. Bardzo często same monitorują to, jak ta metryka się zmienia w czasie i na jej podstawie wprowadzają usprawnienia w swojej pracy podczas retrospekcji czy też w trakcie sprintów.

11:28 Ta metryka wspiera pracę zespołową. Tutaj nie ma znaczenia indywidualny performance, liczy się performance całego zespołu. Tak jak wspomniałem, wszyscy członkowie zespołu są brani pod uwagę przy liczeniu tej metryki.

11:39 I tak – ta metryka pozwala nam porównywać ze sobą zespoły. Nie, nie wykorzystujemy tego do wynagradzania, dawania premii czy podwyżek – w żadnym wypadku. Wykorzystujemy to jedynie do tego, żeby sprawdzać, gdzie jesteśmy i czy na przykład, kiedy startujemy nowy produkt, nowy projekt naszego klienta, to, czy zespół performuje na oczekiwanym poziomie, czy też przewyższa ten poziom, czy może jednak wymagana jest jakaś interwencja, obserwacja tego, co tam się tak naprawdę dzieje, i pomoc temu zespołowi w osiągnięciu lepszych wyników.

12:07 No i last but not least – ta metryka promuje kulturę dostarczania wartości biznesowej. Skupiamy się na User Stories, na wartości biznesowej, oczywiście nie zapominając o tej całej otoczce. Natomiast to jest najważniejsze i to jest promowane wśród naszych zespołów, wśród naszych deweloperów.

Trudności we wdrażaniu metryk

12:23 No dobrze, ale zapewne powiesz teraz: „u mnie to nie zadziała” – i prawdopodobnie w wielu przypadkach masz rację. Natomiast większość argumentów, z którymi się spotkaliśmy, już dawno odbiliśmy i o kilku z nich chciałbym ci też tutaj opowiedzieć.

12:35 Taki najczęstszy, pierwszy argument, który pada, dlaczego tego typu podejście nie zadziała, to to, że przecież jedno story nie jest równe drugiemu. Jedne historyjki są mniejsze, inne są większe, jedne zajmują mniej czasu, drugie zajmują więcej czasu. Nie można w ten sposób porównywać. Otóż jeżeli weźmiemy dwa story i będziemy je w ten sposób ze sobą porównywać lub małą liczbę historyjek, to faktycznie masz rację. Wyciąganie średniej z kilku historyjek nie ma najmniejszego sensu. To jest tak jak z powiedzeniem, że jak wychodzę z psem na spacer, to ja i mój pies mamy średnio po trzy nogi. Tak to być nie może.

13:04 Natomiast w przypadku, kiedy tych historyjek mamy dużo, kilkadziesiąt, kilkaset bądź nawet w dłuższej perspektywie czasu kilka tysięcy, to wtedy jesteśmy w stanie naprawdę, korzystając z prawa wielkich liczb, wyciągać bardzo dobre wnioski na podstawie empirycznych danych dotyczących właśnie średniego czasu realizacji historyjek.

13:21 Kolejny argument, który często pada: „no ale my robimy taski, a nie historyjki”. O tym już wspomniałem. Taski też mierzymy, historyjki też mierzymy. Natomiast to, co jest najważniejsze, to to, że żeby mierzyć, trzeba mieć wspólne definicje tego, czym jest User Story, czym story nie jest, co jest taskiem, co jest bugiem. Wtedy, jeżeli wprowadzimy to rozgraniczenie, to będziemy w stanie faktycznie oddzielić to, co jest wartością biznesową, czyli User Stories – i tak, w niektórych przypadkach może być tego naprawdę niewiele w stosunku do reszty rzeczy, które realizujemy – ale będziemy w stanie oddzielić to od rzeczy, które są rzeczami technicznymi czy też od błędów, które poprawiamy.

13:57 Kolejnym argumentem, który często pada, dlaczego tego typu podejście nie zadziała u was czy nie zadziała w ogóle, jest to, że jeśli w ten sposób postawimy cele dla naszego zespołu oparte o tego typu metrykę, to oczywiście nasz zespół będzie chciał ten cel jak najszybciej osiągnąć. Troszeczkę nagiąć rzeczywistość i co zrobi? Przede wszystkim podzieli User Stories na jeszcze mniejsze kawałki, które będzie dostarczał coraz częściej, żeby zmniejszyć ilość godzin potrzebnych na realizację jednego User Story. Moja odpowiedź jest taka, że jeśli faktycznie te User Story będą zgodne z naszą definicją i każde z nich będzie dostarczało wartość, to co w tym złego? W zasadzie to świetnie, że nasz zespół się nauczył dzielić wymagania na mniejsze, być może też te mniejsze wymagania dostarczać częściej i być może też rezygnować z kilku czy niektórych z tych wymagań, które niekoniecznie wnoszą wartość z tych mniejszych wymagań, i realizować te duże rzeczy, które wcześniej realizował w całości, w mniejszym stopniu, jednocześnie dostarczając taką samą wartość, czyli zwiększając wartość versus koszt.

14:56 Kolejnym argumentem jest to, że w ten sposób pójdziemy w ilość, a nie jakość. No i tutaj znowu to, co wspomniałem wcześniej – jeśli będziemy używać tylko tej metryki, to tak, prawdopodobnie pójdziemy w ilość, zapomnimy o jakości. Natomiast jeżeli będziemy obserwować też kilka innych metryk, którymi sobie obudujemy tę naszą jedną metrykę, to wtedy będziemy w stanie kontrolować zarówno jakość, jak i wartość i ilość rzeczy, które dostarczamy.

15:17 Argumentów jest znacznie więcej. Myślę, że te, o których wspomniałem, były najbardziej istotne. Natomiast jeżeli masz wątpliwości, masz jakieś pytania co do tej metryki i co do tego, jak ją wdrożyć u siebie, czy widzisz jakieś problemy z tym związane, daj znać w komentarzach. Bardzo chętnie porozmawiamy o tym.

Podsumowanie

15:33 Wdrożenie tej metryki nie stało się w jeden wieczór, nie stało się w jedną noc. Nie stało się nawet w tydzień ani w miesiąc. Zajęło nam to w zasadzie kilka miesięcy, jeśli nawet nie ponad rok. Żeby wdrożyć tę metrykę, musieliśmy odpowiednio przygotować firmę i myślę, że na ten temat zrobimy osobny odcinek.

15:49 Natomiast to, co jest tutaj najważniejsze, to to, że oprócz tej jednej metryki mamy jeszcze kilka innych rzeczy, które mierzymy w naszej firmie. Między innymi na przykład, jak nasze zespoły pracują zgodnie z zasadami scrumowymi, czy też jak nasze zespoły pracują zgodnie z innymi wytycznymi, które są sformułowane w postaci technicznych checklist czy też checklist produktowych na temat tego, w jaki sposób budujemy rozwiązania i w jaki sposób tworzymy produkty w naszej firmie. Takie metryki związane ze zgodnością ze standardami w firmie, czyli właśnie ze Scrumem, aspektami technicznymi czy też aspektami pracy UX-owców, połączone z tą metryką dają nam pełen obraz tego, w jakim stopniu realizujemy to, co sobie założyliśmy w firmie, i w jakim stopniu dostarczamy realną wartość dla naszych klientów.

16:34 Na stronie PragmaticCoders.com, w zakładce “Resources”, możesz pobrać DARMOWY wzór naszego pliku – Product Health Checklist. Link w opisie!

Dlaczego to u nas działa?

16:44 Działa to u nas dlatego, że przede wszystkim mamy standaryzację wprowadzoną praktycznie w całej firmie. Mamy odpowiedni program szkoleniowy i onboarding dla nowych osób, ale też dla osób, które są na pokładzie, który wzmacnia korzystanie z tych naszych standardów pracy, wzmacnia korzystanie z tych metryk. Ludzie, którzy przychodzą do nas do pracy czy też pracują z nami od dłuższego czasu, żyją tymi metrykami i w sposób ciągły je monitorują, adaptują swoją codzienną pracę pod te metryki – oczywiście też pod wiele innych rzeczy, ale te metryki są bijącym sercem naszej firmy i tym, w jaki sposób zarządzamy całą naszą firmą. Jest to kluczowe dla realizacji naszych działań i myślę, że najważniejsze jest to, że te metryki nie są skończone. Cały czas nad nimi pracujemy i to nie jest tak, że pracuje nad nimi jakaś grupa menedżerów czy zarząd, czy ktokolwiek inny. Wszyscy w całej firmie wnoszą wartość do tych metryk, do usprawniania ich, dodawania, czasami też usuwania pewnych rzeczy z tych metryk, optymalizacji sposobu, w jaki mierzymy pewne rzeczy. Cała firma ciągle żyje, tak jak wspomniałem, tymi metrykami, pracą wokół nich. I myślę, że to, co jest najważniejsze – to u nas działa, bo wszyscy widzimy w tym wartość.

Zakończenie

17:49 I to już wszystko, co chciałem wam opowiedzieć na temat tego, jak mierzymy pracę naszych programistów w Pragmatic Coders. Jeżeli macie jakieś pytania, to tak jak wspomniałem, zapraszam do komentowania. A może chcecie też się podzielić tym, jak wy mierzycie pracę swoich zespołów, swoich programistów? Na to też jest wiele miejsca w komentarzach. Dziękuję za uwagę i zapraszam do kolejnych odcinków.