Jak skutecznie ustalać KPI i zarządzać projektami IT w różnych modelach współpracy?

Wprowadzenie do odcinka – KPI w projektach IT, czyli więcej niż tylko czas i budżet

Cześć, dzień dobry. Witam Was w podcaście IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce. Podcast IT i Biznes kieruje do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 45. Jak skutecznie ustalać KPIE i zawiązać projektami IT w różnych modelach współpracy.

W dzisiejszym odcinku skupimy się na czymś, co ma ogromne znaczenie w każdym projekcie IT, ale o czym często zapominamy, czyli kluczowe wskaźniki KPIE. Chyba każdy z nas to pojęcie zna, jeżeli chodzi o KPIE, ale kiedy przychodzi do wdrożenia, a szczególnie w obszarze projektów IT, to już nie każdy wie, jak skutecznie je stosować i które wskaźniki warto śledzić. Jeśli kiedykolwiek zdarzyło Wam się zastanawiać, dlaczego Wasze projekty IT rozjeżdżają się z harmonogramem albo czemu mimo ogromnego wysiłku inwestycji nie widzicie oczekiwanych rezultatów, to może być tak, że problem leży właśnie w braku odpowiedniego monitorowania właściwych wskaźników.

Zatem nie przedłużając, serdecznie zapraszam do części głównej dzisiejszego odcinka. Cześć, dzień dobry. Cieszę się, że jesteście z nami w kolejnym odcinku podcastu IT i biznes.

Po co nam KPI w projektach IT?

Dzisiaj kontynuujemy temat z poprzedniego podcastu, czyli jak zarządzać projektem IT jako osoba nietechniczna. No i dzisiaj bierzemy sobie na wartat temat różnych wskaźników, które powinniśmy mierzyć, jeżeli chodzi o prowadzone współprace. No bo wiecie, wszyscy lubią mówić o tym, że najważniejsze to jest dowieźć projekt na czas i w budżecie, czyli to są te dwa główne wskaźniki, czas i budżet.

No i oczywiście to jest bardzo ważne, żeby te cele osiągnąć, jednak to są cele bardzo wysokopoziomowe, jakby nie patrzeć i należałoby mierzyć też coś, co dzieje się po drodze. Takie KPI pośrednie, które dają nam wskazówki, czy idziemy w dobrym kierunku. No i to jest właśnie kluczowe, bo jeśli coś zacznie się sypać, a raczej powinniśmy powiedzieć, kiedy coś zacznie się sypać, jeżeli chodzi o ten wysokopoziomowy wskaźnik czasu czy budżetu, no to wtedy monitorując te wskaźniki pośrednie, mamy dużo większą szansę na szybszą reakcję, no a nie dopiero wtedy, kiedy projekt jest już opóźniony np. o miesiące i trzeba się zastanawiać, jak ten projekt domknąć. No i teraz w ogóle powiedzcie, czy ktoś z wami w zespole, czy to wewnętrznym, czy zewnętrznym, ustalił takie KPI na początku projektu albo w ogóle pyta o was, jakie wskaźniki będą najważniejsze, jak będziecie monitorować postępy w pracach. No bo jeżeli nie, to macie właśnie odpowiedź, czemu może coś nie działać tak, jak powinno.

Często zapominamy, że jako osoby zlecające projekty powinniśmy mieć te KPI na oku i mieć je ustalone jasno z zespołem tak, żeby zespół wiedział, czego się będzie od niego oczekiwało. No i dobrze, po co nam te KPI w projektach? Trochę sobie to już powiedzieliśmy na początku, że chodzi o to, żeby rozwijać te wysokopoziomowe KPI czasu i budżetu na niskopoziomowe. Często jest tak, że w projektach ustala się np. harmonogram, który ma jakieś określone kroki milowe i super, ale często jest też tak, że te kroki milowe są czymś w rodzaju, po prostu są za duże, co w efekcie powoduje, że jeżeli krok milowy jest raz na miesiąc czy raz na dwa miesiące przy projekcie np. rocznym i tylko w taki sposób badamy, czy jesteśmy w czasie i w budżecie, no to jest to stanowczo zbyt ryzykowne z mojej perspektywy. Szczególnie przy tym, jak często te biznesy są mocno zwinne, mocno zmienne i projekt musi się też do tego dostosowywać i jego zakres tego się nie przeskoczy.

No i KPIE pomagają uniknąć sytuacji, w której projekt rozjeżdża się z harmonogramem lub budżetem, no bo oczywiście zawsze na koniec możemy powiedzieć, że udało się dopychać budżet czy też, że projekt został zakończony na czas, ale w międzyczasie mogliśmy popełnić różne błędy, które będą miały konsekwencje w przyszłości, jak np. domykanie czy dopychanie butem w cudzysłowie rzeczy czy przed końcówką np. terminu danego milestone’u, tak żeby go zamknąć.

Więc KPIE na poziomie organizacyjnym i na poziomie realizacji prac to narzędzie, które pozwala wychwycić te problemy wszelkiego rodzaju występujące na wczesnym etapie, ocenić na ile jakościowo pracuje zespół no i to nam daje też możliwość po prostu potwierdzenia, że idziemy cały czas w dobrym kierunku i że zapobiegamy dużym błędom lub co gorsza zapobiegamy np. niedowiedzeniu czy to pojedynczego milestone’u, czyli tego kroku milowego czy też w ogóle całego projektu jako pełnego terminu. No i teraz jeżeli chodzi o te KPIE, one są super w tym kontekście, że dają nam przejrzystość pojedynczego procesu, który sobie mierzymy.

No bo mierzymy postęp w danym procesie, w danym obszarze, więc mamy konkretną podstawę też do rozmów czy to z zespołem, czy np. z klientem, czy z interesariuszami naszego projektu na temat tego, co działa, co wymaga poprawy No i warto pamiętać, że KPIE to też jest coś, co niejako motywuje zespół, no bo daje konkretne cele do osiągnięcia i poczucie, że projekt idzie faktycznie w dobrym kierunku.

Główne błędy – czyli kiedy KPI zawodzi

Niestety, KPIE to też oczywiście nie jest taka łatwa sprawa, jeżeli chodzi o ich wdrożenie.

No bo w praktyce spotykamy się często z zespołami, czy to wewnętrznymi, czy zewnętrznymi, które realizują jakiś projekt z kilkoma wyzwaniami, które mogą utrudnić efektywne wykorzystanie tych wskaźników. Przede wszystkim pierwszy problem często czy takie wyzwanie spotykane w firmach, to jest to, że nie mamy do końca jasno określonych tych KPIE na początku projektu. Jest określony czas, budżet, harmonogram, kropka.

Lub co gorsza, nie ma tego, bo projekt jest prowadzony zwinnie i np. wyznacza się z grubsza zakres, z grubsza termin końcowy i nie ma tych milestone’ów, no to jeszcze gorzej. No i czemu tak jest? Może to wynikać z braku przemyślanej strategii, może to wynikać z braku komunikacji, albo po prostu z tego powodu takiego prozaicznego, że wydaje nam się, że wszyscy wiedzą o co chodzi, no bo przecież się dogadaliśmy.

No i niestety brak konkretnych wskaźników w tym przypadku powoduje, że nie mamy jak sprawdzić czy projekt zmierza we właściwym kierunku, chcąc to sprawdzić np. nie wiem, np. dzień do dnia, albo przynajmniej tydzień do tygodnia.

Drugim takim wyzwaniem jest to, że często pojawiają się trudności w egzekwowaniu tych KPI’ów, czyli nawet jak już sobie ustalimy, to albo ktoś ich nie wpisuje do jakiejś tabelki, albo ich nie liczy, albo ktoś zapomina o ich monitorowaniu, albo ktoś ich po prostu nie używa do feedbackowania, tylko nawet zespół monitoruje te rzeczy, wpisuje w tabelki, ocenia czy robi dobrze, czy źle, ale osoba, która też po drugiej stronie ze strony biznesu właśnie powinna też zerknąć w te KPI’y i monitorować nie robi tego, więc to powoduje, że projekt żyje własnym życiem, te wskaźniki są zapominane, no i znowu czeka się na koniec projektu, co też często skutkuje później opóźnieniami, bo np. pojawiają się jakieś błędy, czy nawet błędy logiczne względem tego, czego biznes oczekiwał, a co zaprogramowano i można by to było wychwycić wcześniej, gdyby no właśnie były te KPI’y monitorowane, więc istotne jest to, żeby mieć osobę, która będzie odpowiedzialna za monitorowanie tych KPI’ów na bieżąco, bo to jest serio ważne i taką osobą może być np. product owner po Twojej stronie, jako po stronie biznesu, czy nawet Ty sam słuchaczu, słuchaczko, który, która zleca Cię jakieś prace do IT.

Różne modele współpracy = różne podejścia do KPI

Trzecia rzecz to też są pewnego rodzaju różne podejścia w zależności od modelu współpracy, no bo np. w modelu hybrydowym, gdzie mamy zespół i wewnętrzny i zewnętrzny, kluczowe staje się dokładne określenie odpowiedzialności za poszczególne etapy projektu, czy właśnie za określone etapy procesu realizacji tego projektu. Czyli np. jeżeli część zespołu zewnętrznego odpowiada za wdrożenie jakieś na wersję testową, a część zespołu odpowiada za wersję produkcyjną, to musimy wyraźnie określić kto za co będzie odpowiadał w jakim obszarze i dzięki temu możemy sobie też dobierać odpowiednie KPI’y w zależności od etapu, na którym znajduje się np. dany zespół ze swoimi pracami. W innym wypadku może dojść do sytuacji, w której zespoły będą wzajemnie przyrzucały odpowiedzialność za ewentualne niepowodzenia względem siebie, co może prowadzić do frustracji i opóźnień.

No i tak samo jeżeli chodzi o zespół wewnętrzny, to również trzeba przygotować sobie KPI’y per konkretne procesy, no i podobnie jeżeli zdecydowamy na zewnątrz projektu, to też musimy ustalić w jaki sposób będziemy badać na bieżąco, czy projekt idzie jakościowo dobrze w kierunku dobrym i czy idzie zgodnie z harmonogramem też.

Jakie KPI warto mierzyć – przegląd 6 kluczowych wskaźników

No i teraz dzisiaj skupimy się w tym odcinku na tym, żeby wskazać mierniki, które naszym zdaniem warto wdrożyć do współpracy z dowolnym zespołem IT, czy to wewnętrznym, czy to zewnętrznym, po to, żeby móc jakościowo ocenić, czy projekt idzie w dobrym kierunku, nie będąc osobą techniczną. To jest super ważne.

Czyli nie będziemy się w tym odcinku skupiać na kwestii tego, w jaki sposób robić code review, jakie rzeczy sprawdzać ze strony technicznej, tylko skupimy się na tym, co widać, co można łatwo sprawdzić jako osoba nietechniczna. No i teraz podam kilka przykładów KPI, które warto mieć na uwadze, co powinniśmy sobie właśnie mierzyć.

1. Lead Time – kiedy to będzie na produkcji?

Pierwszy z nich to jest lead time.

Ja to nazywam jako, chcę żebyście zrobili to i to, kiedy to będzie na produkcji. Czyli lead time to jest czas, który upływa od rozpoczęcia zadania do jego zakończenia. Czyli ten wskaźnik będzie ci mówił, jak długo trwa realizacja różnych zadań, zarówno tych większych, jak i mniejszych.

I teraz, jak sprawdzić, czy lead time jest zgodny z planem? Odpowiedź znajdziesz w specyfikacji projektu. Tam powinno być też zapisane, ile zajmie wykonanie poszczególnych etapów i tam powinna być też zawarta informacja, jak często będą wykonywane deploy na produkcji, co wykonanie zadania plus deploy da nam ten lead time. Czyli to jest bardzo ważne, żeby wziąć pod uwagę to, że lead time.

Dlaczego to nie jest tak, że coś zaprogramujemy i od razu jest to wdrożone? No bo często jest tak, że wdrożenia na produkcję, czyli na to środowisko główne w danym projekcie odbywają się na przykład co jakiś czas, niekoniecznie od razu. Zdarza się, że zespoły na przykład grupują kilka zadań i dopiero wtedy robią tak zwane release, czyli to właśnie wdrożenie produkcyjne. I na przykład może być tak, że prace nad Twoim zadaniem, które zesisz w poniedziałek zostaną zakończone we wtorek, ale uruchomione na produkcji na przykład w czwartek.

Co powoduje, że wtedy Twój lead time od poniedziałku do czwartku, no to są łącznie 4 dni, jakby nie patrzeć. Licząc od początku dnia w poniedziałek do powiedzmy końca dnia w czwartek, to będą takie 3-4 dni robocze. No i teraz powinieneś bądź powinnaś tak ustalić zespołem ten lead time i jego wskaźnik, żeby był po prostu zgodny z Twoim biznesem.

No bo jeżeli na przykład w projekcie utrzymaniowo-rozwojowym realizujesz jakieś rzeczy marketingowe no i chcesz mieć prace wdrażane dynamicznie na środowisko produkcyjne, no to Twój lead time musi być jak najkrótszy. Kontra na przykład w projekcie, który startuje produkcyjnie dopiero za pół roku, to to czy lead time będzie miał bardziej 5 dni, czy bardziej 7 albo 8, no to nie ma aż takiego dużego znaczenia, no bo i tak ten projekt na przykład produkcyjnie jeszcze nie działa. Chyba, że ma to znaczenie w kontekście tego kiedy Ty na przykład masz czas i możliwości na odbiory zadań.

No to tutaj pod tym kątem warto ten lead time sobie przemyśleć.

2. Deployment Frequency – jak często wrzucacie zmiany?

No i teraz drugi taki miernik, który warto byłoby używać do sprawdzania czy projekt działa, a kamierzyć, to jest deployment frequency, czyli częstotliwość wdrożeń. I to jest to mógłbym nazwać jako jak często wrzucacie zmiany na produkcję.

To jest właśnie powiązane z tym lead time i z tą sytuacją, że zaczynamy jakieś zadanie w poniedziałek, kończymy we wtorek, ale wrzucamy dopiero w czwartek wraz z innymi zadaniami. I tutaj ten wskaźnik robi nic innego jak to, że określa jak często Twój zespół IT wdraża nowe funkcje, poprawki czy aktualizacje na środowisko produkcyjne. Oczywiście im częstsze wdrożenia, tym szybciej zespół dostarcza wartościowe zmiany.

I teraz dlaczego nie robi się deployów codziennie, albo dlaczego się je robi? No właśnie, robi się codziennie wtedy, kiedy faktycznie jest takie tempo zmian, że codziennie trzeba coś uruchamiać. Jeżeli jest dobrze zrobione tak zwane CICD, czyli taki proces ciągłego wdrażania zmian, to można te zmiany wdrażać codziennie. No ale natomiast jest tak, że często w projektach na przykład brakuje testów automatycznych.

Testy trzeba na przykład regresji, żeby te deploy były bezpieczne, czyli żeby nie powodowały regresji, czyli błędów nowych, których nie znamy po uruchomieniu produkcyjnym. No to na przykład te testy regresji wykonując manualne, jeżeli one same w sobie zajmują na przykład pół dnia, żeby je zrobić do porządku, no to jest mała szansa, że ktoś wtedy będzie w stanie robić deploye codziennie. Więc wtedy dla zachowania kosztów robi się je na przykład raz w tygodniu, dwa razy w tygodniu.

Myślę, że w takim rozsądnym świecie, nie idealnym, ale też nie super złym, te deploye takie planowe, które są robione na przykład dwa razy w tygodniu, to z reguły dla każdego biznesu jest w zupełności wystarczające, jako te planowe deploye, plus takie deploye nieoczekiwane na tak zwane hotfixy, czyli takie drobne zmiany, poprawki, które po prostu na produkcję trafić muszą znacznie szybciej.

3. Change Failure Rate – ile razy coś się psuje po wdrożeniu

Okej, trzeci wskaźnik to change failure rate, czyli to jest wskaźnik niepowodzeń zmian, czyli innymi słowy, jak często pojawiają się regresje w systemie. Więc to jest sytuacja, w której jeżeli wrzucasz coś na produkcję, no i pojawia się nowe pięć, dziesięć zadań i nagle się okazuje, że pojawia się jakiś nowy błąd, który nie był znany lub któreś zadanie, które zostało wdrożone na produkcję jako przetestowane i ocenione jako działające, nagle na produkcji przestaje działać.

No i to jest właśnie wskaźnik ten CFR, czyli change failure rate, to jest wskaźnik, który pokazuje, jak często takie problemy się zdarzają, na przykład w perspektywie miesiąca. I teraz, im wyższy jest ten wskaźnik, oznacza to, że tym więcej razy błędy pojawiły się nieoczekiwane. W idealnym świecie ten wskaźnik powinien wynosić zero.

Jeżeli robisz na przykład, nie wiem, wdrażasz tygodniowo 20-30 zadań, czyli miesięcznie wdrażasz między 80 a 120 zadań i ten wskaźnik jest na poziomie 4, 5, 6, to myślę, że to jest jak najbardziej akceptowalne, że to się może wydarzyć. No chyba, że po prostu masz na to możliwości i budżetowe, i czasowe, żeby twój zespół na przykład napisał bardzo dokładne testy automatyczne, no to wtedy można się zbliżyć do jedynki, dwójki, jeżeli chodzi o ten wskaźnik. Raczej nie ma systemów, w których kompletnie nic się nie psuje po wdrożeniach, co nie oznacza, że nie trzeba do takiego stanu rzeczy dążyć.

Tylko no, patrząc realistycznie, jakieś tam drobne zmiany, poprawki raczej są wdrażane rzadko, bo rzadko, ale też widzimy po projektach prowadzonych, czy to przez nas, czy przez inne firmy, że no jakieś błędy raz na jakiś czas niestety się pojawią. Ważne jest to, żeby to były drobiazgi. Niemniej każdy taki drobiazg jako CFR bym tutaj oznaczał i pilnował, żeby ten wskaźnik był jak najniższy.

Im wyższy ten wskaźnik jest, tym oznacza, że problemy są już wcześniej gdzieś na etapie na przykład testów, lub też wcześniej na etapie w ogóle samego, samej realizacji projektu, czy danego zadania, jego programowania przez programistę. Tutaj zdarza się, że jeżeli ten wskaźnik jest wysoki, to schodząc, że tak powiem poziom niżej, jeżeli chodzi o szczegółowość, czyli bezpośrednio na proces, jakie zadania, można czasem znaleźć powiązania na przykład z konkretną osobą, która, przez którą ten wskaźnik jest, czy przez której pracę ten wskaźnik jest właśnie odpowiednio wysoki, warto na to po prostu zwrócić uwagę.

4. Escaped Defects – czyli błędy wykryte na testach

Okej, i czwarty wskaźnik to jest Escaped Defects, czyli co się zepsuło, ale zostało wykryte, czyli to jest taki wskaźnik, który pokazuje nam to, że na etapie testów coś zostało wykryte i na szczęście nie trafiło to na produkcję, czyli wtedy to się nie kwalifikuje do CFR-a, bo nie zepsuło się na produkcji, tylko na środowisku testowym i to oznacza, że testy mamy dobre, czyli ktoś sprawdza, testuje, dobrze, jest okej, natomiast nie powinny te błędy się pojawić w ogóle, już na takim na przykład etapie, co powoduje, im niższy tutaj ten współczynnik, tym jest okej, bo co do zasady, inaczej, jeżeli ten współczynnik jest wysoki, a CFR ten poprzedni jest niski, to oznacza, że mamy dobre testy i tutaj brawa dla testerów, natomiast jeżeli ten współczynnik jest niski i CFR jest niski, to oznacza, że i testerów i deweloperów mamy okej, bo dowożą projekty po prostu dobrze, te zadania, które mają zlecone.

5. Code Review Feedback – ile zadań wraca do poprawy

Więc to jest też taki czynnik, który warto sprawdzić i coś, co jeszcze warto sprawdzać, to to, jak często kod wraca po code review. Tu znowu jest taka sytuacja, w ramach której jeżeli programiści realizują kod i on wraca po code review i teraz do poprawy i to się dzieje za każdym razem, praktycznie na przykład u danego dewelopera, to też warto przyjrzeć się tej sytuacji, bo to może być miejsce, gdzie jest też niejako przepalany czas i budżet na poprawki, które mieć miejsce nie powinny, przynajmniej nie na masową skalę, no bo jakieś drobne rzeczy wykryte na code review to się zdarzają i po to jest proces code review, czyli tego, że jeden programista po drugim czyta kod i ocenia, czy on jest dobrej jakości, żeby ewentualne jakieś uchybienia wykryć, natomiast jeżeli każdy kod po CRC tzw. czy po tym code review wraca, no to oznacza, że coś tam na pewno nie gra i to też trzeba sprawdzić i też powinno się to mierzyć, jeżeli chodzi o ilość.

No i teraz, jeżeli chodzi o tego typu wskaźniki, to takie liczbowe, no to myślę, że te pięć to są takie kluczowe rzeczy, które trzeba mierzyć, czyli lead time, czyli jak szybko coś od pomysłu będzie zrealizowane, wdrożone na produkcję. Deployment frequency, czyli ta częstotliwość wdrożeń na produkcję, czyli innymi słowy, czy dwa deploye wyszły w tygodniu. Change failure rate, czyli ten CFR, czyli wskaźnik niepowodzeń zmian, czyli co wrzuciliśmy na produkcję i musieliśmy to cofnąć.

Escaped defects, czyli to, co nie wrzuciliśmy na produkcję na szczęście i testy to wykryły, czyli super testy, ale co się dzieje na poziomie developmentu, że to trafiło na testy w takiej formie. No i to, jak często zmiany po code review wracają do programistów. Jeżeli wracają jednorazowo w co drugim, no tak bardziej co trzecim, czwartym zadaniu to jeszcze przyjąłbym, że jest to okej, ale jeżeli co drugie albo każde zadanie wraca po code review i jeszcze co gorsza wraca z tymi samym błędami, a to jako osoba nietechniczna wchodząc sobie do repozytorium jesteście w stanie sprawdzić, no to też warto to po prostu mieć na uwadze.

6. Efektywność komunikacji – chemia zespołu to też KPI

Jeszcze jeden wskaźnik, o którym chciałem powiedzieć, a który jest bardzo często pomijany, to jest efektywność komunikacji z zespołem, bo dobrze zorganizowana komunikacja nie tylko pozwala na takie szybkie przekazywanie informacji, co jest oczywiste, ale także na rozwiązywanie problemów, które pojawiają się w trakcie realizacji projektu i dopowiadanie sobie szczegółów, które nie zawsze będą niestety wynikały z zadań, jakkolwiek dokładnie ich sobie nie napiszemy. I regularne spotkania, jak regularne, czy też jasne określenie oczekiwań, terminów i metod raportowania, to będzie wszystko sprawiało, że projekt będzie szedł w określonym tempie, no i a ty z kolei jako osoba nietechniczna będziesz mieć wewnętrzny spokój, że twoje sprawy są w rękach osób, które wiedzą co robią i co najważniejsze, że te osoby są zsynchronizowane i że masz poczucie, że każdy wszystko wie to, co powinien wiedzieć. No i to też powoduje, że ta chemia we współpracy będzie na dobrym poziomie, no bo to jest trudne do oceny, jeżeli chodzi o wskaźniki.

Oczywiście można sobie zapisywać subiektywnie, jak oceniam współpracę z daną np. osobą w zespole, czy z całym zespołem, nie wiem, w skali od 1 do 10 i potem np. sobie to jakoś argumentować, że dlaczego dało się np. 8, a dlaczego w kolejnym miesiącu daje się 7 albo 6. Więc to jest w pewnym sensie takim miernikiem subiektywnym, ale można go sobie wprowadzić. Natomiast ważne jest to, żeby zadać sobie pytanie, czy ja chcę z tymi ludźmi współpracować długoterminowo. Bo widząc, że np. ta chemia we współpracy, ten tzw. vibe się psuje, nie łapiecie, nie macie wspólnego języka, czujesz, że wchodząc na spotkania, no niekoniecznie masz poczucie, że masz partnera po drugiej stronie, tylko raczej toczysz wojnę, walkę, no to z pewnością żadne KPI tutaj nie zmienią nic, nawet jeżeli będą się pokrywały, no bo po prostu twoje osobiste odczucie będzie niewłaściwe, a okazuje się, że w projektach IT te odczucia co do tej współpracy z zespołem są mega istotne i na nie też należy zwrócić uwagę, czy czujecie się w relacji ze swoim partnerem IT 10 na 10, czy czujecie się jednak bardziej 3 na 10.

Podsumowanie – KPI to nie wszystko, ale bez nich ani rusz

No dobrze i podsumowując dzisiejszy odcinek, skuteczne zarządzanie projektem IT wymaga nie tylko jasno określonych KPI, które pozwalają monitorować postęp i efektywność, ale też odpowiedniej komunikacji i współpracy z zespołem no i tej dobrej chemii, po prostu.

Te kluczowe wskaźniki, no to oczywiście jest czas, budżet i harmonogram, to są te trzy najważniejsze, natomiast te pięć mniej ważnych, czy bardziej może szczegółowych, o w tym sensie mniej ważnych, że po prostu rzadziej stosowanych, to Lead Time, czyli chcemy mieć to na produkcji, kiedy to będzie, Deployment Frequency, czyli jak często wdrwamy na produkcję, czyli czy te nasze deploye działają się chociaż dwa razy w tygodniu. Change Failure Rate, czyli wskaźnik niepowodzeń zmian, coś co trafiło na produkcję i wywołało regresję, nie powinno być takiej sytuacji. Escape Defects, czyli nasze testy działają super, ale ktoś na poziomie developmentu nie wykonuje pracy poprawnie, trzeba to sprawdzić.

I jak często zmiany po Code Review trafiają do poprawy. W kolejnym odcinku skupimy się na tym, jak efektywnie współpracować z zespołem w modelu hybrydowym, czyli takim, w którym mamy swój zespół in-house, ale część pracy outsourcujemy na zewnątrz, bo wiem, że dla wielu menadżerów nietechnicznych, ale ich zespołów IT podobnie, stanowi to bardzo duże wyzwanie. Ale okazuje się, że w praktyce wcale nie jest to aż takie trudne, jeżeli się to dobrze poukłada, więc opowiemy sobie o podziale odpowiedzialności, o skutecznym ustalaniu zakresu prac, jak i też o metodach utrzymywania przejrzystości w komunikacji między zespołami wewnętrznym i zewnętrznym.

Dzięki temu będziesz w stanie jeszcze lepiej radzić sobie z wyzwaniami biznesowymi, które pojawiają się przy zlecaniu części projektu zewnętrznym zespołom, jednocześnie mając kontrolę nad kluczowymi aspektami realizacji. No dobrze, po odcinku 44 wiesz już, jak powinien wyglądać twój zespół IT, albo innymi słowy też, komu i jakie pytania można zadać o to, żeby gdzieś tam pogłębić różne wątki. Po dzisiejszym odcinku wiesz już, jakie KPI można sobie podłączyć, jeżeli chodzi o zespół oprócz czasu, budżetu i harmonogramu, a w kolejnym odcinku dowiesz się, jak połączyć pracę zespołu wewnętrznego z zewnętrznym po to, żeby przyspieszyć realizację twoich celów biznesowych właśnie w taki sposób.

Nie przedłużam, bardzo dziękuję za uwagę i za odsłuchanie dzisiejszego odcinka do samego końca. No i do usłyszenia za tydzień we wtorek. Dzięki raz jeszcze i cześć!