Transcription

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. 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 to, nie bo to jest kreatywna praca, a kreatywność pracy nie da się zmierzyć. Nie, bo jeżeli zaczniemy mierzyć pracę programistów, to skupią się na ilości i 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. Ogólnie jest bardzo trudno mierzyć różne rzeczy w IT, w produkcji programowania. Wiele różnych prób i podejść, które miały miejsce w historii, kończyły się porażkami i powstawaniem różnych rzeczy, które nie miały najmniejszego sensu, nie wnosiły żadnej wartości. 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, spróbujemy się zaczepić najbliżej outcome'u 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ą podobnych metryki. Poczynijmy 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 output'cie, natomiast jeżeli odpowiednio zdefiniujemy sobie, czym jest user story i zbudujemy tę świadomość wśród naszych zespołów, 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 output'u, niekoniecznie outcome'u, ale wydaje mi się, że jest to najbliżej outcome'u, jak jesteśmy w stanie się na takim bardzo przednym poziomie zaczepić. Skupiając się na output'cie, jeżeli chcielibyśmy zmierzyć efektywność naszego zespołu czy naszych programistów, moglibyśmy sobie wymyśleć metrykę dla takiego output'u 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ć właśnie jakąś jednostkę wartości i sprawdzić, ile godzin zajmuje nam dostarczenie tej jednostki wartości. Wspomniałem o tym, że w naszym przypadku niedoskonałą, ale jednak bardzo bliską outcome'owi 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, jest wpisana z perspektywy myślenia outcome'owego, o którym wspomniałem we wcześniejszym odcinku. W Pragmatic Products 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 backlog'u, 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 np. usprawnienia jakichś środowisk czy zmiany infrastruktury. Dlaczego wybraliśmy takie podejście? 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. Jeden z naszych klientów powiedział kiedyś, że, cytuję, lepiej jest być częściej pokrywanym 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 to jest zauważane i doceniane. 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ść. Jeżeli raz na wiele razy popełnimy jakiś błąd, to ten błąd gdzieś tam zginie w całej historii, 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. Ta metryka, której używamy w Pragmatic Coders uwzględnia wszystkie godziny przepracowane dla klienta, wszystkie godziny, za które nasz klient nam zapłacił. Więc są to nie tylko godziny naszych programistów, ale też godziny pozostałych członków zespołu, czyli devopsów, UX-owców, prodaktorów. Na załączonym obrazku widzicie porównanie dwóch zespołów. Jeden z tych zespołów ma produktunera i UX-owca, a drugi z tych zespołów takiego produktunera i UX-owca nie ma. Zgadnijcie, które. Jeśli dobrze przyjrzycie, to zobaczycie, że średni czas potrzeby na zrealizowanie jednego user story w dłuższej perspektywie czasu jest bardzo zbliżony w jednym i w drugim przypadku. Prawda jest taka, że tutaj bardzo fajnie widać, że to, czy klient ponosi dodatkowy koszt za pracę UX-owca czy pracę produktunera, 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. 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. Żeby móc realnie ocenić wartość dostarczaną dla klienta, musielibyśmy porównać również ilość zrealizowanych user stories przez drugi zespół. No i oczywiście możecie śmiało się domyśleć, że ten zespół, który jest większy, dostarczył tych user stories cztery razy więcej na koniec dnia, ale oczywiście sumarycznie kosztowało to też cztery razy więcej. No dobrze, co w takim razie z jakością? Same user stories, same taski to nie wszystko, co z błędami? I tutaj zawsze, kiedy opowiadam o metrykach, kiedy uczę innych, jak stosować metryki, 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 jest dla nas najważniejsza, warto obłożyć sobie innymi metrykami. I w Pragmatic Orders też mamy taką metrykę, która mówi nam o tym, jaki procent realizowanych zadań stanowią poprawki błędów realizowanych przez nasze zespoły. Na załączonym obrazku widzicie, że historycznie liczba tych błędów, groba 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 jakiegoś story, ale mierzymy też liczbę wszystkich zadań na backlogu realizowanych przez nasze zespoły, w tym też właśnie zadania techniczne czy bugi. 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, produktów, które realizujemy dla naszych klientów, jest na dobrym poziomie, czy być może wymaga jakichś zmian. 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 fionetowym, 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ą, to są user stories, które starczamy, a większość to prawdopodobnie poprawki błędów, czy też realizacja jakichś zadań technicznych, czy rzeczy, które muszą być zrealizowane w sposób manualny i nie są jeszcze zautomatyzowane. 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. 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 tak, 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ę 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ąć. No dobrze, co nam to daje w Pragmatic Office? 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. 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. 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ł. 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 satysfakcji czy w trakcie sprintu. Ta metryka wspiera pracę zespołową. Tutaj nie ma znaczenia indywidualny performance, liczy się performance całego zespołu, to jak wspomniałem, wszyscy członkowie zespołu są brani pod uwagę przy liczeniu tej metryki. I tak, ta metryka pozwala nam porównywać ze sobą zespoły. Nie, nie wykorzystujemy tego do wynagrodzenia, do dawania premii czy podwyżek w żadnym wypadku. Wykorzystujemy to jedynie do tego, żeby sprawdzać, gdzie jesteśmy i czy np. kiedy startujemy nowy produkt, nowy projekt naszego klienta, to czy zespół performuje na oczekiwanym poziomie, czy też przewyższy na ten poziom, czy może jednak wymagana jest jakaś interwencja, obserwacja tego, co nam się tak naprawdę dzieje i pomoc temu zespołowi w osiągnięciu lepszych wyników. 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 oroczce, natomiast to jest najważniejsze i to jest promowane wśród naszych zespołów, wśród naszych deweloperów. 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ć. Taki najczęstszy pierwszy argument, który pada, dlaczego tego typu podejście nie zadziała, to to, że no przecież story, story jest nierówne. Jedne historiki 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 dwie story i będziemy je w ten sposób ze sobą porównywać, to znaczy 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 robić nie można. Natomiast w przypadku, kiedy tych historyjek mamy dużo, kilkadziesiąt, kilkaset, bądź nawet w dłuższej perspektywie czasu kilka tysięcy historyjek, 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. 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 definicję tego, czym jest user story, czym user 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. 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 do 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? No, 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 stories będą zgodne z naszą definicją i każdy z nich będzie dostarczało wartość, to co w tym złego? W zasadzie to świetne, że nasz zespół się nauczył dzielić wymagania na mniejsze, być może też te mniejsze wymagania dostarczać częściej, 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. Kolejnym argumentem jest to, że w ten sposób pójdziemy w ilość, a nie w 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ść, zapomniemy o jakości, natomiast jeżeli będziemy obserwować też kilka innych metrów, którymi sobie odbudujemy tą naszą jedną metrykę, to wtedy będziemy w stanie kontrolować zarówno jakość, jak i wartość i ilość rzeczy, które dostarczamy. 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, 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. 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. 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 np. jak nasze zespoły pracują zgodnie z zasadami skramowymi, 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, w jaki sposób tworzymy produkty w naszej firmie. Takie metryki związane z zgodnością ze standardami w firmie, czyli właśnie skramem, produktami, technicznymi aspektami, 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ść do naszych klientów. Na stronie pragmaticodders.com w zakładce Resources możesz pobrać wzór naszego pliku Product Health Checklist. Link w opisie. Dlaczego to u nas działa? Działa to u nas dlatego, że przede wszystkim mamy standardyzację wprowadzoną praktycznie w całej firmie. Mamy odpowiedni program szkoleniowy i onboardingowy 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 skorzystanie z tych metryk i 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 menadżerów, czy zarząd, czy ktokolwiek inny. Wszyscy w całej firmie wnoszą wartość do tych metryk, do ustawiania ich, do dodawania, do czasami też usuwania pewnych rzeczy z tych metryk, optymalizacji sposobów, w jaki mierzymy pewne rzeczy. Cała firma ciągle żyje, tak jak wspomniałem, tymi metrykami i pracą wokół nich. I myślę, że to, co jest najważniejsze, to to u nas działa, bo wszyscy widzimy w tym wartość. I to już wszystko, co chciałem Wam opowiedzieć na temat tego, jak mierzymy pracę naszych programistów w Pragmatic Codance. 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.