KPI, targety – to korporacyjne słówka-zmory, znane bardzo dobrze naszym kolegom i koleżankom z działów sprzedaży, ale nam też 🙂 Często w naszej rzeczywistości mają postać znienawidzonych tabelek w Excelu, które trzeba wypełniać, bo ktoś nam każe – ale w sumie nikt nie wie, po co. Taki bat, który zawsze był i nad nami wisiał. Ale najchętniej byśmy się go pozbyli.
A tak nie musi być! W tym odcinku Paweł wytłumaczy, w jaki sposób zespoły w jego dziale stosują KPI do pchania naprzód ważnych dla siebie spraw, pozbywania się długu technologicznego, wdrażania innowacji i pilnowania jakości. I to w sposób strawny dla każdego lidera i developera.
Z tego odcinka dowiesz się:
- Czym tak naprawdę są KPI?
- Jaką rolę ma zespół w pracy nad nimi?
- Kiedy i jak je monitorować?
- Dlaczego część KPI musi zginąć?
i wiele więcej 🙂
Agenda
00:00 – Intro
00:58 – Wprowadzenie
01:36 – Czym są KPIs?
02:14 – Kiedy KPI nie mają sensu?
02:53 – Przykładowe KPIs które warto mierzyć
05:07 – Jak wyznaczać KPI?
08:13 – Jak często monitorować KPI?
10:17 – Jak przekonać zespół do monitorowania KPIs?
12:35 – Co zrobić z KPI który u Ciebie jest ok, ale inne zespoły muszą jeszcze nad nim popracować?
15:46 – Co dla Ciebie oznacza KPI w którym jesteś poniżej targetów?
17:05 – KPI nie są batem do poganiania cię do pracy!
18:03 – Co zrobić z KPI który jest od dłuższego czasu ok?
20:40 – Jak długo żyje KPI?
23:44 – Instytucjonalizacja zmiany
24:07 – Co zrobić po zautomatyzowaniu jednego z KPIs?
26:36 – Podsumowanie
Wersja do słuchania
Linki
- Kurs Pawła: Test Driven Development w PHP
- Odcinek 58: Poszukaj kolejnego smoka do zabicia – o przekraczaniu celów
- Odcinek 81: Jak wyznaczyć kierunek IT? Tworzenie strategii technologicznej w zespole
Transkrypcja odcinka
[00:00:58.670] – Krzysztof
Cześć, witamy w Nerd Management, tutaj Krzysztof Rakowski…
[00:01:02.060] – Paweł
…i Paweł Rekowski.
[00:01:04.670] – Krzysztof
Zawsze podziwiałem w waszym dziale Operations, że na wszystko macie metryki. Bardzo dużo rzeczy mierzycie, wyciągacie z tego wnioski. Czyli porozmawiamy w dzisiejszym odcinku o KPI, które niektórym z nas się kojarzą z takim korpo bullshitem, wypełnianiem Exceli, raportów i generalnie robieniem czegoś, co jest nam zupełnie niepotrzebne.
[00:01:28.510] – Krzysztof
Więc Paweł, powiedz na samym początku co to jest KPI i czemu Twoim zdaniem musimy z tego korzystać?
[00:01:36.750] – Paweł
To jest właśnie piękne, kiedy myślimy o tym w kategoriach korpo bullshit. To są dwie takie rzeczy: KPI – Key Performance Indicator, czyli wskaźniki, które nam mierzą, że to są nasze kluczowe wskaźniki naszej efektywności, wydajności i czegoś, co de facto nas interesuje. Bo mierzyć możemy wszystko i o tym za chwilę.
[00:01:57.200] – Paweł
Ale drugi taki buzzword, który z KPI jest nieodłączny, to są targety. I teraz, kiedy słyszymy korpo mowę w stylu „szejpujemy targety, by spełnić kejpijaje”, to już co niektórym się nóż w kieszeni otwiera. I mają rację. Ale tak się dzieje tylko i wyłącznie w sytuacji, kiedy te KPI dla Ciebie nie mają najmniejszego sensu, nie mają pożytku i nie mają absolutnie znaczenia.
[00:02:24.140] – Paweł
I teraz tu jest kilka rzeczy ważnych, które musicie rozpakować i się zastanowić, czy tak u Was jest, czy tak nie jest. Jeżeli u Was tak będzie, no to musicie sobie pogadać z innymi zespołami, pogadać z przełożonymi, pogadać z zarządem, czy to działu czy organizacji, w zależności od skali, aby dojść do ładu.
[00:02:45.110] – Paweł
Ponieważ KPI mają to do siebie, że one są jak kompas. One pokazują nam gdzie jesteśmy w danej metryce. I takimi metrykami mogą być różne rzeczy. Może to być pokrycie kodu testami, które czasem się przydaje, zwłaszcza jeżeli testów nie ma. Może to być metryka pod tytułem cycle time, czyli lead time, żeby zobaczyć na ile Wasz proces jest zdrowy, czy dowozicie rzeczy, na które się umówiliście w terminie, czy np. od pomysłu do wdrożenia trwają może miesiące, bo to też jest jakaś informacja.
[00:03:18.290] – Paweł
Ogólnie zasada jest taka, że żeby coś usprawnić, to trzeba to mierzyć, bo tylko rzeczy, które mierzycie, na które patrzycie i regularnie weryfikujecie, to są te rzeczy, które mają dla was jakieś znaczenie. Obserwujecie to i widzicie jak się poruszacie. Więc wracając jeszcze na chwilę do tej analogii kompasu, to nam pokazuje to, gdzie aktualnie jesteśmy, gdzie jest północ i południe. Czy pójdziemy w lewo to dojdziemy bliżej, czy może decyzja nas odsunie tak naprawdę od tego co chcemy osiągnąć?
[00:03:49.550] – Krzysztof
Bardzo fajnie to przedstawiłeś, bo zgodnie z zasadą, że nie możemy zmieniać rzeczy co do których nie wiemy nic, których nie mierzymy. Często jest tak, że wychodzimy z jakimś pomysłem, z jakąś inicjatywą, żeby coś zmienić. Moim zdaniem ważne jest to, żeby zastanowić, jak w ogóle możemy zmierzyć, gdzie teraz jesteśmy, żeby wiedzieć, gdzie chcemy dojść, gdzie ta zmiana ma nas zaprowadzić, a nie tylko tak intuicyjnie powiedzmy, że coś chcemy zmienić i już.
[00:04:17.510] – Krzysztof
Wracając do tego, o czym wspomniałem, że u Was w dziale Paweł bardzo przykładacie wagę do fajnych dashboardów, raportujecie to sobie, ale właśnie nie jest to takie korporacyjne marnowanie czasu, tylko ma to jakiś cel i ma to jakąś korzyść. Czy mógłbyś nam dać kilka przykładów KPI, które mieliście u siebie? Jak ten cykl życia przeszedł od momentu ich wyznaczenia do momentu korzystania z nich i potem co się dalej z tym stało? Takie z zespołu deweloperskiego, żebyśmy mogli sobie lepiej wyobrazić, jak developerzy mogą korzystać z KPI. W jaki sposób my jako menedżerowie możemy mierzyć to, co zespół robi? W jaki sposób to może być ciekawe dla naszych przełożonych czy dla organizacji? Podaj konkretne przykłady, proszę.
[00:05:07.380] – Paweł
Jasne, to wszystko się zaczyna od tego, co nas tak naprawdę boli. Ponieważ KPI są właśnie do tego, żeby wyleczyć daną sytuację, naprawić daną sytuację. Więc musicie zobaczyć co Was boli. U nas na przykład jedna z takich rzeczy, która przeszła już przez taki cały cykl życia, o tym zaraz opowiem więcej, to jest jakość kodu. Mamy aplikację legacy i ogólnie w naszym ekosystemie jest ponad 200 aplikacji, więc ten ekosystem jest duży. U mnie w zespole są 4 aplikacje. Z czego ludzie w całym dziale, ponieważ te KPI u nas są w ramach działu, dział to jest 9 zespołów i te 9 zespołów ma łącznie kilkanaście aplikacji, z czego jedna to jest jeden z najstarszych monolitów. Więc jakość kodu dla nas była istotna, żeby nie babrać się z rzeczami, które są bezsensowne.
[00:05:59.300] – Paweł
Zaczęło się od tego, że patrzyliśmy na przykład na pull request, gdzie powychodziły jakieś głupie błędy albo jakieś literówki, albo jakieś takie rzeczy, że na przykład proste testy nie przechodziły. Albo w drugą stronę – ktoś wrzucał kod na produkcję, to jest typowe właśnie zwłaszcza dla seniorów czy liderów. Typu ja jestem już tak dobry, doświadczony, że mogę zmieniać kod na prodzie vimem i w ogóle będzie super. Nie będzie super, bo właśnie najczęściej w takich sytuacjach wpadało coś na produkcję, co wysypało dany flow czy daną funkcję, aplikację, bo było to nieprzetestowane. Więc zależało nam na tym, żeby te aplikacje też miały testy automatyczne, a co za tym idzie, jeżeli mieliśmy coś mierzyć, to zmierzmy na początku to pokrycie, bo ich nie było wcale.
[00:06:44.630] – Paweł
Mało tego – w zespołach nie było wiedzy na temat tego jak w ogóle te testy pisać. U mnie w zespole ja kiedyś popełniłem nawet kurs na temat tego, jak pisać testy jednostkowe w PHP. Może nawet podlinkuję tutaj. Ale wiele osób nie miało na ten temat bladego pojęcia. I to był nasz taki cel. Słuchajcie, byśmy chcieli, żebyśmy mieli to pokrycie, żebyśmy byli bezpieczni, żeby nie mieć problemów z kodem. Nie mieć problemu z jakością. Nie marnować czasu na głupie pull request, które tak naprawdę sprowadzało się w większości najpierw do takiej sesji ping pong, na zasadzie: ogarnij się, tutaj za dużo enterów, tutaj formatowanie nie takie, tu w ogóle nazwa nie taka, tutaj składnia nie taka, tu parametry pomyliłeś.
[00:07:28.580] – Paweł
Bo te rzeczy da się wyłapać automatycznie i te rzeczy możemy wyciągnąć właśnie z metryk. To można sobie zmierzyć, używając pokrycia kodu. Wiem, że dla zespołów zaawansowanych to może nie jest idealna metryka i to jest też właśnie istotne, żeby zacząć od tego, co Cię boli, jaką metrykę możesz wziąć, żeby zobaczyć ten progres. Od miejsca gdzie jesteś, czyli jesteś w lesie, nie masz nic, nie ma wiedzy, nie ma doświadczeń, ale wiesz, żebyś chciał mieć sytuację taką, że robisz releasy często, nie boisz się zmian na produkcji. Możesz wrzucić tam dowolną rzecz, bo wiesz, że ten flow jest ok. To taki KPI ci pokaże: jesteś tu, pokrycia masz 0… 5%, 10% i stopniowo na to patrzysz.
[00:08:08.570] – Paweł
Więc najpierw wyszło to dokładnie od tego i w ten sposób zaczynaliśmy nad tym pracować. Ponieważ my monitorujemy te KPI tydzień w tydzień. dokładnie co tydzień w poniedziałek spotykamy się z zespołem team liderów na to, żeby zrobić sobie taki status cotygodniowy, przelecieć się po projektach, zobaczyć, gdzie w danych projektach jesteśmy, zobaczyć, gdzie w ramach danych KPI jesteśmy. Jak ostatni tydzień wyszedł. To jest też taki okres, w którym porównujemy te dane. Czyli np. jeżeli mierzymy rzeczy pod kątem code quality czy np. liczby zadań supportowych, które się pojawiają, które chcemy zredukować. To patrzymy, czy w danym tygodniu coś się zadziało, czy nie. I też weryfikujemy to na bieżąco. Więc to jest też ważne, żeby mieć taki moment, proponuję raz na tydzień, żeby się spotkać.
[00:08:53.900] – Paweł
Wiem, że są zespoły, które tego nie robią, co dla mnie jest chore. Bo w jaki sposób można wiedzieć gdzie się jest, jeżeli się synchronizujemy z innymi. Jeżeli mamy aplikacje, gdzie kilka zespołów nad tym pracuje, no to musimy się z nimi spotkać raz na jakiś czas, raz na tydzień, raz na dwa tygodnie i zobaczyć gdzie jesteśmy. W tych metrykach, jesteśmy tutaj, w tych jesteśmy tutaj, o tutaj trochę nie idzie, trzeba nad tym popracować. Ponieważ to jest taki właśnie moment na to, żeby nam pokazaćL słuchaj, to jest taka czerwona lampka, żeby wam powiedzieć, że słuchajcie, kurczę, to nie jest to, co chcecie.
[00:09:24.720] – Paweł
Bo jeżeli te KPI wychodzą od was, wychodzą od problemów i prowadzą was w miejsce, gdzie chcecie być, czyli tak jak właśnie mamy tę jakość kodu, chcecie, żebyście byli z tym kodem bezpiecznym i żeby ten kod był dobry, żebyście nie musieli co chwilę go poprawiać, naprawiać czy się go bać i spać spokojnie. To metryka, ona nie jest po to, żeby Was tutaj biczować i robić głupie rzeczy, tylko ona jest po to, żeby rozwiązać Wasz konkretny problem i was tam zaprowadzić.
[00:09:51.860] – Krzysztof
Ciekawi mnie, bo tak jak mówisz o tym, że takie ciągłe monitorowanie, uzupełnianie tych metryk, ale z drugiej strony spotkania statusowe co poniedziałek, pewnie jeszcze jak Cię znam to o ósmej rano. To nie brzmi zbyt atrakcyjnie dla developerów. Więc w jaki sposób pracujesz z ludźmi? W jaki sposób ich przekonujesz do tego, żeby korzystali z tego, żeby wyrobić ten nawyk, żeby jednak rzeczy mierzyć, żeby KPI było narzędziem codziennej pracy?
[00:10:17.960] – Paweł
KPI, ale się automatyzuje i to temat takich statusów to nie jest temat dla developerów. To po pierwsze. Nie ma potrzeby absolutnie żadnej, żeby na takim statusie pojawił się ktoś z developerów czy testerów. To jest robota dla lidera, dla managera, który musi ogarniać te projekty z lotu ptaka, gdzie one idą, jak one idą, gdzie one są, to monitorować. A z zespołem rozmawiać po pierwsze o targetach, czyli na początku, kiedy zaczynamy kwartał, ustalamy sobie jaki poziom byśmy chcieli mieć na danym KPI, który nas zaprowadzi dalej na drodze do celów, które chcemy osiągnąć. Czyli ten target jest istotny dla zespołu, ponieważ zespół wtedy będzie patrzył na, czy my idziemy w dobrą stronę, czy robimy dobrą robotę czy nie.
[00:11:00.440] – Paweł
Bo target, czyli określenie właśnie tego elementu, gdzie w ciągu np. kwartału, pół roku, raczej stosował krótsze okresy niż dłuższe, gdzie my chcemy dojść, żeby na koniec jakiegoś okresu, roku czy kilku lat, może jeżeli są takie długie projekty, być tam gdzie chcecie. Spełnić tę wizję, dojść do tego waszego North Stara, o którym też mówiliśmy w jednym z odcinków.
[00:11:23.130] – Paweł
Więc to nie jest robota dla developerów. Więc tutaj pamiętajcie, że jako liderzy, jeżeli jesteście teraz deweloperami, a będziecie liderami, to właśnie takie spotkania Was czekają. A jeżeli ich nie macie, to to jest wręcz wasz obowiązek moim zdaniem, żeby takie spotkania zorganizować. Bo jeżeli nie będziecie się synchronizować z innymi, nie będziecie tego mierzyć, to sorry, ale macie problem, bo skąd Wy macie wiedzieć kiedy coś poprawić? A jeżeli coś nie działa, no to trzeba to właśnie zmierzyć, ustalić gdzie się chce być, wyznaczyć targety jako takie, kroki pośrednie, do których chcemy dojść i to mierzyć i sprawdzać czy idziemy w dobrą stronę, czy może się cofamy. Bo może być tak, że się będziemy cofać i robić nie to co trzeba. Także tak to wygląda.
[00:12:01.740] – Krzysztof
Prawie zawsze się zdarza, że nie mamy wyłącznie KPI na poziomie zespołu, które sobie wyznaczymy, ale są na poziomie działu czy całej organizacji. No i wyobraźmy sobie, że np. na poziomie działu mamy KPI dotyczący tego, żeby mieć jaki tam procent automatyzacji testów, bo w innych zespołach z tym bywa różnie, a akurat u was już dawno macie to zrobione. To co, zaznaczacie to na zielono i macie temat z głowy, nie interesujecie się tym? Jak do tego podchodzicie?
[00:12:35.070] – Paweł
To tak, formalnie to tak, zaznaczamy na zielono, by default jest zielono. Bo mamy dokładnie taką sytuację, kiedy to my uczymy wręcz inne działy, my wyznaczamy trendy i to gdzie można być właśnie w kontekście np. testów i automatyzacji, gdzie mamy pełną regresję zrobioną, wszystko zautomatyzowane, pipelines, które nam ratują tyłek. I możemy robić praktycznie z tą aplikacją wszystko. Jeżeli coś wyjdzie nie tak, to automat nam powie sorry, to nie zbuduje i powie nam, że tutaj jest błąd. Czy rozwalamy jakieś flow.
[00:13:08.520] – Paweł
Ale inne zespoły mają z tym problem. I teraz ważne jest to, bo taki sygnał to są dwie informacje. Czyli z jednej strony good job, zrobiliście naprawdę świetną robotę, macie temat ogarnięty. To jest super. To jest powód do tego, żeby taką informację przekazać zespołowi, że robi świetną robotę, pochwalić ich za to, może nawet wybrać się na jakieś kręgle czy jakiegoś steka czy coś dobrego. To jest powód do radości.
[00:13:36.510] – Paweł
Ale jednocześnie to jest powód, aby zakasać rękawy i innym zespołom pomóc. Bo najgorsze, co możecie zrobić jako zespół, czy ty jako team lidera razem z zespołem, to stwierdzić: u nas ogarnięte, a reszta niech się buja. bo to tak nie działa. Bo w firmie pracując nad danymi projektami pracujemy w jednej firmie, jedziemy na jednym wózku, mamy te same realia, to samo otoczenie. I to, że u nas jest super, a u kogoś się wali to nie jest tylko ich problem, bo to jest też wasz problem. Bo jeżeli ten zespół odpowiada za jakiś flow sprzedażowy, a teraz czasy mamy jakie mamy, a wy im nie pomożecie, bo jesteście dupkami zadufanym w sobie i robicie dobrze swoją robotę. No to Houston mamy problem. Bo może się okazać, że zaraz walnie sprzedaż i tak naprawdę wszyscy razem stracicie pracę, bo sytuacja będzie jakaś kryzysowa.
[00:14:26.820] – Paweł
Więc w waszym interesie jest zadbać o to. Jeżeli u Was jest dany KPI ogarnięty, jesteście w czymś dobrzy, aby zacząć szkolić inne zespoły, jeżeli tego chcą, jeżeli tego potrzebują.
[00:14:39.570] – Paweł
A to jest też taka magiczna sytuacja, ponieważ jeżeli te KPI są uzgodnione na poziomie działu, pionu, organizacji, no to to jest coś, co się liczy dla wszystkich, łącznie z szefem działu, czy np. właścicielem danej firmy. To są dane, które są istotne dla wszystkich, więc wszystkim będzie zależało na tym, żeby podnieść to. Więc w tym momencie wy nawet możecie się też wykazać, pomagając innym zespołom podnosić te statystyki, robić dla nich szkolenia, warsztaty, mentoring. Sposobów jest multum, żeby podzielić się wiedzą, możecie zaprosić kogoś z tego zespołu do siebie, popracować z nim w parze. Możliwości są nieograniczone i to jest moim zdaniem właśnie Wasza robota w takiej sytuacji, żeby się tym zająć.
[00:15:21.650] – Krzysztof
Tak, to jest ciekawy przykład tego, o czym będziemy mówić w następnym odcinku, czyli takiego obracania tych wyzwań, które się pojawiają na możliwości. Więc zapiszcie się do newslettera, jeżeli chcecie mieć przypomnienie o kolejnym odcinku. I to jest ważne, z jednej strony, że fajnie, jeżeli jakieś KPI już mamy spełniony i mamy to z głowy, ale żeby nie osiadać na laurach, nie rozleniwiać się. Ale z drugiej strony też nie należy się bać sytuacji, kiedy my ustalamy jakiś KPI i jesteśmy w nim bardzo nisko bardzo słabo. Bo jeżeli przestaniemy traktować KPI jako coś narzucane z góry, bicz nad nami, a raczej coś, co nam ma pomóc usprawnić coś, poprawić. No to to jest dobrze. Jeżeli mamy jakąś metrykę, wypadamy w niej słabo, ale wiemy, że powinniśmy być lepsi. No to wtedy, skoro to jest oficjalny czynnik, który jest mierzony, wtedy z jednej strony musimy to poprawić, musimy aktywnie pracować nad tym, żeby ta wartość była lepsza, ale z drugiej strony też jest to zadaniem organizacji, czyli koledzy i koleżanki z innych zespołów powinni nas wspierać. Nasz przełożony powinien nas wtedy wspierać. Wtedy też ciężej powiedzieć: dobra, nie róbcie tych zadań, które sobie zaplanowaliście, żeby podciągnąć dany wskaźnik, no bo organizacja od Was oczekuje, że podciągniecie ten wskaźnik.
[00:16:43.270] – Krzysztof
Więc tak samo jak wartości w firmie są takim świetnym narzędziem do tego, żeby robić te rzeczy, które chcemy robić, które są oczywiście spójne z wartościami, tak samo KPI są świetnymi narzędziami do tego, żeby również robić rzeczy, które chcemy robić. Jeżeli poprawa tych metryk z jednej strony jest oczekiwana przez firmę, a z drugiej strony my chcemy to robić.
[00:17:05.200] – Paweł
I to jest mega ważne, co powiedziałeś. I jeszcze raz podkreślę KPI nie są batem, one nie są biczem, nie są po to, żeby was biczować. One zupełnie nie po to są. Jeżeli macie takie myślenie lub wasi liderzy je sprzedają w ten sposób, że to jest właśnie bat, który ma was wycisnąć jak cytrynę i macie się zarzynać po to, żeby swoją krwawicę wylać w tej organizacji. I tak jest naprawdę. To uciekajcie stamtąd, bo to zupełnie nie o to chodzi. One nie są, nie są po to. Więc jeżeli to jest bat i to jest coś nie tak z tą firmą i naprawdę mikroserwisy patologii w firmie nie naprawiają. Bądźcie tego świadomi. Jeżeli jest to normalne podejście to KPI wam pomogą i pokażą wam gdzie macie iść, gdzie jesteście i będą rozwiązywać problemy.
[00:17:53.920] – Krzysztof
No to załóżmy, że ten KPI rozwiązał nasz problem, czyli było czerwono, potem żółto i teraz jest zielono. Co dalej?
[00:18:03.930] – Paweł
No i dalej następuje bardzo ważny moment, czyli już jesteśmy tutaj, gdzie chcieliśmy być. Doszliśmy do naszego celu, osiągnęliśmy sukces. To jest super. Czyli znowu wracamy do punktu: świętowanie. Czyli to jest ważne, żeby to świętować. KPI nie jest batem, kiedy osiągniemy ten cel, jak wejdziemy na dany szczyt, to już na niego weszliśmy, to mamy zdobyte. Super, zaliczone, good job, piona, piona i to jest mega ważne.
[00:18:30.190] – Paweł
Ale teraz nie można go tak zostawić. Nie można go zostawić w tej liście KPI, statusów i co tydzień patrzeć na niego w kółko i patrzeć, że już jest dobrze. I tak przez następne trzy lata będziecie tylko odhaczać, że to jest dobrze i nie można go trzymać. Ponieważ takiego KPI kiedy będziemy trzymać, on się zrobi takim korpo-bullshitem na zasadzie odhaczania go i sprawdzania, że no w sumie jest dobrze i to będzie coś, co będzie was denerwowało. Bo po co siedzicie na tych statusach? Z tego myślę się bierze taka nienawiść do tych statusów, że po co wy siedzicie na tym statusie i odhaczacie znowu te głupie tabelki, które one właściwie w kółko są takie same.
[00:19:10.190] – Paweł
Bo właśnie tego nie należy robić, KPI są elementem, jak wyznaczacie sobie cel na trasie. Wyznaczacie cel, dojeżdżacie do tego celu. Jesteście. Super. Później wyznaczacie następny cel, następną drogę, następny wyjazd czy następne jakieś marzenie na Waszej liście do spełnienia. To jest ważne, żeby te stare cele już sprzątnąć, usunąć. Jeżeli byście mieli na GPS mapę, zresztą Google Maps chyba pozwala zaznaczyć 5 czy 10 punktów, kiedyś próbowałem zaznaczyć 15, się nie dało, on nie trzyma tych starych rzeczy, nie trzyma tych KPI czy tych punktów gdzie chcieliście dojść. I wy tak samo nie powinniście ich trzymać. Powinniście je usunąć.
[00:19:49.330] – Paweł
I najlepsze co możecie zrobić, to zależy jeszcze co to jest, bo nie wszystkie się da. To mówię od razu, ale najlepsze co możecie zrobić, jeżeli to się da zrobić dla danej metryki, to jej weryfikację trzeba zautomatyzować. I teraz przykład, od którego zacząłem, czyli ten quality code, czyli z jednej strony pokrycie kodem, mogą to być różne metryki, ilość bugów, może to być ilość code smells, czyli takich miejsc w kodzie, które śmierdzą i prawdopodobnie nie powinny tak wyglądać, czy tak funkcjonować. To te metryki da się z powodzeniem zautomatyzować. Da się w buildzie zapiąć narzędzie, które będzie automatycznie przy każdym commicie weryfikować czy my spełniamy te warunki czy nie. Dzięki temu da się ustawić poziom sprawdzania na taki, który nas satysfakcjonuje, który sprawia, że my już nie musimy się tym przejmować. Nawet nie musimy o tym pamiętać. Ponieważ kiedy kiedy będziemy pracować z takim KPI przez pół roku, rok czy kilka lat, bo też nie zakładajcie, że wyznaczycie KPI na poprawę jakości kodu i za miesiąc już będzie super. No nie. To jest proces, który trwa latami i to też jest OK. Pamiętajcie, że to w wielu przypadkach KPI to jest maraton, a nie sprint. A żeby ten maraton przebiec i się nie wyłożyć po drodze, to muszą być te KPI, muszą być te targety. Potem żebyśmy byli w stanie z jednej strony dobiec do celu, ale z drugiej strony też rozłożyć siły, czasem docisnąć, czasem może odpuścić po to, żeby się nie wykoleić po drodze.
[00:21:18.330] – Paweł
I jeżeli już jesteśmy na tym etapie, że to już nam weszło w krew, weszło nam w nawyk i tak naprawdę jest to dla Was coś totalnie naturalnego, co mogło nie być, bo tak jak w przypadku testów czymś, co jest naturalne mieć pokrycie kodem na poziomie 80%, już pomijając temat czy to jest metryka sensowna czy nie, porównując do sytuacji, gdzie kilka lat temu nie mieliście bladego pojęcia czym jest w ogóle PHPUnit czy JUnit, czy w ogóle narzędzia do testowania, a teraz macie to na poziomie 80% nowego kodu, wszystko otestowane automatycznie, a z reguły nawet i więcej, bo zreguły macie to otestowane już tak jak należy. No to słuchajcie, no to jest progres niesamowity i wtedy nie musicie już co chwilę o tym pamiętać, czy to już macie czy nie. Wystarczy, że zapniecie jakąś automatyzację, która Wam to sprawdzi.
[00:22:07.080] – Paweł
I teraz ona jest też o tyle ważna i przydatna, bo różne są sytuacje w życiu i czasem potrzebujemy coś zrobić na szybko. Albo zapomnimy, albo mamy gorszy dzień, też możemy mieć gorszy dzień, wypchniemy coś za szybko. Taka automatyzacja nam przypomni: słuchaj, spędziłeś razem z całym działem 3 lata czy tam 5 lat na tym, żeby walczyć o jakość oprogramowania. Macie super jakość oprogramowania. Dlaczego ty chcesz teraz to spitolić? To jest też istotne, że to wam powie, że słuchaj, to są nasze standardy, to są nasze zasady, ogarnij się chłopie, ogarnij się koleżanko, zrób tak żeby było dobrze.
[00:22:49.950] – Paweł
To też pomaga wdrażać nowych pracowników i uświadamiać im. Bo często możemy też patrzeć przez pryzmat świeżej osoby, która wchodzi, której nie zostało to dobrze wytłumaczone. I właśnie pierwsze takie skojarzenie, nie wiem czemu tak w Polsce jest, pierwsze skojarzenie właśnie to bat jakiś, który ma nas tutaj biczować, że mamy tutaj cisnąć. Jest to takie fajne narzędzie do tego właśnie, żeby pokazać: słuchaj, na początku nie wiedzieliśmy co to jest, nie wiedzieliśmy co to są testy, nie wiedzieliśmy jak to zrobić i wyznaczyliśmy sobie cele, zajęło nam to cztery lata czy tam X lat, żeby do tego punktu dojść, Zrobiliśmy to w taki sposób. Dzięki temu, że my to mierzyliśmy, sprawdzaliśmy, byliśmy w stanie po pierwsze tym zarządzić, po drugie coś z tym zrobić, po trzecie zlokalizować, który zespół coś wie, które zespoły czegoś nie wiedzą, żeby się zaczęły tą wiedzą wymieniać się, uczyć od siebie i dojść do takiej sytuacji. Także to jest coś, na czym nam zależy. Długo nad tym pracowaliśmy, nie chcemy tego zepsuć.
[00:23:44.940] – Krzysztof
To jest ważne, co mówisz, bo jednym z elementów takiej zmiany, która odniesie sukces, jest instytucjonalizacja jej, czyli stworzenie takiego nawyku, że ta zmiana, która nastąpiła i to, co zrobiliśmy, to już nie ma od tego odwrotu. To jest coś, co mamy gdzieś tam zapisane w naszych zasadach, w tym naszym frameworku, którego używamy do pracy.
[00:24:06.210] – Krzysztof
No to co dalej?
[00:24:07.350] – Paweł
No i już mamy już mamy sytuację idealną, czyli mamy zautomatyzowane KPI, czyli te nasze wskaźniki. Kompas już jest na autopilocie, jedziemy na autopilocie. Mamy temat ogarnięty, więc wtedy czas najwyższy wybrać kolejnego smoka. Czyli tutaj wracamy do odcinka 58, kiedy zdobywamy cel, zdobywamy szczyt. No to jakoś tak jest, że z reguły chcemy więcej, chcemy zrobić coś dalej, grać w następny poziom. To jest też właśnie dobry moment na to, żeby zrobić sobie takie retro, spotkać się z zespołem i pomyśleć: dobra, to już jest okej, ogarnięte, ten czas, który my poświęcaliśmy… Bo to jest też bardzo ważne, że dojście do tego KPI, dojście do tych targetów, rezultatu, no to zajmuje czas. Więc ten czas musicie poświęcać. Jeżeli poświęcacie czas na zadania A, nie poświęcacie ich automatycznie na zadania B. Więc to jest teraz taki dobry moment, kiedy dochodzi się do tego momentu, że jest temat odhaczony, usuwacie go z listy monitorowanych KPI. Jeżeli się dało, to go zautomatyzowaliście, więc nie musicie tego sprawdzać, nie musicie o tym pamiętać, to już jest nawyk.
[00:25:16.170] – Paweł
Więc wtedy warto się zastanowić, co jest dalej. Co jest naszym obecnym teraz największym wyzwaniem. Gdzie mamy problem? Czy to co nas boli w ogóle mierzymy, czy nie. I wtedy cała zabawa zaczyna się od początku i w ten sposób dochodząc właśnie do tego, gdzie nas boli? Jak można to zmierzyć? Jak chcemy do tego dojść? W jakim czasie? Co jest w ogóle możliwe, jakim nakładem pracy? Bo jeżeli np. chcemy coś osiągnąć typu chcemy przepisać czy wdrożyć np. AI czy Deep Learning w naszej organizacji, a nie mamy w organizacji absolutnie nikogo, kto ma jakiekolwiek pojęcie na ten temat, to wiadomo, że to nie będzie kwartał. To raczej proces uczenia jest bardzo długi. O procesie uczenia może też kiedyś zrobimy odcinek, bo to też jest ciekawy temat. To zajmuje jakiś czas, więc wyznaczając te targety, dochodząc stopniowo krok po kroku, kierując swoją uwagę na realizację tego, dochodzimy, automatyzuje, porządkujemy i szukamy dalej.
[00:26:13.250] – Paweł
I tak w kółko. Ta zabawa się kręci. I nie wiem jak dla Was, ale ja w IT jestem już 15 lat i dalej mnie to bawi, kręci i sprawia dużą satysfakcję, żeby te smoki znajdywać, wyszukiwać, dochodzić do nich, ubijać i szukać dalej.
[00:26:27.770] – Krzysztof
A poza tym jest dużo super fajnej zabawy z automatyzacją tego wszystkiego i liczeniem automatycznym, a nie za pomocą Exceli chociażby.
[00:26:36.260] – Krzysztof
Dzięki Paweł, że nam rozbroiłeś ten temat korpo strasznych KPI, mam nadzieję, że wy też dostrzeżecie to, że mierzenie rzeczy, wyznaczanie sobie celów liczbowych to jest rzecz, która zwłaszcza w dużych firmach może działać na Waszą korzyść i warto z tego skorzystać. Dzięki Paweł.
[00:26:55.760] – Paweł
Proszę bardzo i polecam się na przyszłość. A żebyście wiedzieli więcej o takich rzeczach jak w dzisiejszym odcinku, to zapiszcie się koniecznie do newslettera na nerd.management/newsletter, gdzie informujemy Was o nowych odcinkach, które co tydzień publikujemy we wtorek o 8:00. Więc jeżeli nie chcecie zostać z dobrego specjalisty beznadziejnym liderem, to nie może Was tutaj zabraknąć.