Produktywność zespołu projektowego nie oznacza liczby zamkniętych zadań, przepracowanych godzin ani rosnącego velocity. Produktywny zespół sprawnie zamienia dostępny czas i kompetencje w wartościowe rezultaty, utrzymując przy tym jakość i przewidywalny sposób pracy.
Dlatego produktywności nie powinno się oceniać jednym wskaźnikiem. Zespół może kończyć dużo zadań, ale regularnie poprawiać błędy. Może pracować bardzo szybko, ale nad rzeczami, których użytkownicy nie potrzebują. Może również zwiększać tempo przez kilka miesięcy kosztem przeciążenia i późniejszego spadku jakości.
W zespołach pracujących zwinnie pomiar powinien przede wszystkim pomagać odpowiedzieć na cztery pytania:
- czy dostarczamy właściwe rezultaty,
- jak sprawnie praca przepływa przez proces,
- czy potrafimy przewidywać terminy,
- czy utrzymujemy jakość bez przeciążania zespołu.
Metryki mają pomagać w doskonaleniu systemu pracy, a nie tworzyć ranking pracowników.
Co oznacza produktywność zespołu projektowego?
Najprostsze rozumienie produktywności to relacja pomiędzy uzyskanym rezultatem a zasobami potrzebnymi do jego osiągnięcia.
W pracy projektowej sprawa jest jednak bardziej skomplikowana niż na linii produkcyjnej.
Nie można założyć, że:
20 zamkniętych zadań > 15 zamkniętych zadań
bo jedno zadanie może oznaczać zmianę koloru przycisku, a drugie rozwiązanie istotnego problemu klienta.
Podobnie:
200 linii kodu > 100 linii kodu
nie mówi nic o jakości ani wartości rozwiązania.
Wiedza projektowa jest pracą o dużej zmienności. Dlatego produktywność zespołu trzeba obserwować z kilku perspektyw.
| Obszar | Pytanie |
|---|---|
| Wartość | Czy zakończona praca przynosi oczekiwany rezultat? |
| Przepływ | Jak długo praca przechodzi przez proces? |
| Przewidywalność | Czy umiemy realistycznie określać, kiedy coś będzie gotowe? |
| Jakość | Ile pracy wraca do poprawy? |
| Stabilność | Czy wynik jest osiągany bez ciągłych nadgodzin i przeciążenia? |
Dopiero połączenie tych informacji daje użyteczny obraz.
Produktywność a efektywność – czy to to samo?
W praktyce oba pojęcia często są używane zamiennie, ale warto je rozdzielić.
Produktywność dotyczy relacji między wykonanym rezultatem a wykorzystanymi zasobami.
Efektywność jest szersza i uwzględnia również to, czy zespół osiągnął właściwy cel.
Przykład:
Zespół może bardzo szybko stworzyć 30 funkcji.
Jeżeli klienci potrzebowali tylko pięciu z nich, proces mógł być produktywny pod względem samego wykonania, ale słabo efektywny biznesowo.
Dlatego w projektach samo mierzenie ilości wykonanej pracy jest niewystarczające.
Najpierw trzeba sprawdzać, czy robimy właściwe rzeczy, a dopiero później, jak sprawnie je wykonujemy.
Nie istnieje jeden KPI produktywności zespołu
Największym błędem jest próba znalezienia jednej liczby opisującej cały zespół.
Przykładowo velocity może być przydatne do planowania pracy zespołu Scrum, ale nie powinno być traktowane jako wynik produktywności.
Atlassian wyraźnie wskazuje, że velocity jest specyficzne dla konkretnego zespołu i nie należy porównywać go między zespołami. Zespół z velocity 70 nie jest automatycznie bardziej produktywny od zespołu osiągającego 40, ponieważ sposób estymacji story points może być zupełnie inny.
Lepiej stworzyć mały zestaw wskaźników odpowiadających na różne pytania.
1. Wartość dostarczanej pracy
Najważniejszy pomiar znajduje się często poza samym systemem zarządzania projektami.
Jeżeli zespół rozwija produkt, warto sprawdzać rezultat osiągany przez użytkownika lub biznes.
W zależności od projektu może to być:
- wykorzystanie nowej funkcji,
- liczba użytkowników kończących określony proces,
- czas obsługi klienta,
- liczba spraw wymagających ręcznej interwencji,
- przychód,
- koszt procesu,
- liczba błędów,
- konwersja,
- czas potrzebny użytkownikowi na wykonanie zadania.
Przykład:
Zespół przez dwa Sprinty pracuje nad automatyzacją onboardingu klienta.
Samo zamknięcie wszystkich elementów backlogu nie potwierdza jeszcze sukcesu.
Znacznie ważniejsze jest sprawdzenie:
czy onboarding rzeczywiście trwa krócej i wymaga mniej ręcznych operacji?
Jeżeli nie, trzeba przeanalizować, czy rozwiązano właściwy problem.
2. Cycle time – czas cyklu
Cycle time, czyli czas cyklu, pokazuje, ile czasu upływa od rozpoczęcia pracy nad elementem do jego zakończenia.
Przykład:
zadanie trafia do realizacji w poniedziałek o 9:00 i zostaje zakończone w czwartek o 9:00.
Czas cyklu wynosi trzy dni.
To jedna z najbardziej użytecznych metryk do analizy przepływu.
Jeżeli podobne zadania przez kilka miesięcy potrzebowały średnio kilku dni, a później zaczynają trwać kilkanaście, warto sprawdzić, co zmieniło się w procesie.
Powodem może być:
- długa kolejka przed testami,
- zbyt dużo rozpoczętych zadań,
- niedostępność jednej kompetencji,
- oczekiwanie na decyzje,
- rosnąca złożoność,
- problemy techniczne.
Aktualny Kanban Guide z maja 2025 roku zalicza cycle time do czterech podstawowych metryk przepływu.
Krótszy cycle time nie zawsze oznacza lepszy zespół
To ważne zastrzeżenie.
Jeżeli zespół zacznie dzielić zadania na mniejsze elementy, czas cyklu może się skrócić bez jakiegokolwiek wzrostu produktywności.
Podobnie szybkie zamykanie zadań kosztem testów może poprawić wykres, ale pogorszyć jakość.
Dlatego cycle time warto analizować w trendzie i w kontekście podobnego rodzaju pracy, a nie jako samodzielny wynik.
3. Lead time – jak długo czeka odbiorca?
Lead time obejmuje szerszy okres niż czas cyklu.
W praktyce można go rozumieć jako:
potrzeba lub zgłoszenie → oczekiwanie → realizacja → dostarczenie
Jeżeli klient zgłasza potrzebę 1 marca, zespół zaczyna pracę 15 marca i kończy 20 marca:
- czas cyklu wynosi 5 dni,
- pełny czas realizacji wynosi 19 dni.
Różnica pokazuje coś ważnego.
Problemem nie zawsze jest powolna praca zespołu.
Czasami zespół wykonuje zadanie szybko, ale praca przez większość czasu czeka w kolejce.
Optymalizowanie developmentu z pięciu dni do czterech niewiele pomoże, jeżeli element przez dwa tygodnie czeka na rozpoczęcie.
4. Throughput – przepustowość
Przepustowość pokazuje, ile elementów pracy zespół kończy w określonym czasie.
Przykład:
- tydzień 1: 8 elementów,
- tydzień 2: 10,
- tydzień 3: 9,
- tydzień 4: 11.
Kanban Guide definiuje throughput jako dokładną liczbę zakończonych elementów w jednostce czasu.
Przepustowość jest przydatna do obserwowania możliwości systemu i prognozowania.
Nie należy jej jednak utożsamiać automatycznie z produktywnością.
Zespół może zwiększyć liczbę zakończonych elementów poprzez dzielenie pracy na mniejsze zadania.
Dlatego nie powinno się wyznaczać celu:
zwiększyć liczbę ticketów o 20%.
Takie cele bardzo łatwo prowadzą do optymalizacji wskaźnika zamiast procesu.
5. WIP – ile pracy rozpoczęliśmy jednocześnie?
WIP, czyli praca w toku, to liczba rozpoczętych, ale jeszcze niezakończonych elementów.
Jeżeli zespół ma:
- 4 zadania w development,
- 6 w review,
- 5 w testach,
jego WIP wynosi 15.
Duża liczba rozpoczętych elementów nie musi oznaczać wysokiej produktywności.
Często oznacza coś przeciwnego: praca jest rozpoczęta, ale nie płynie do zakończenia.
Aktualny Kanban Guide wskazuje WIP jako jedną z podstawowych metryk potrzebnych do oceny stanu przepływu.
Praktyczne pytanie brzmi:
ile rzeczy rozpoczynamy w stosunku do liczby rzeczy, które faktycznie kończymy?
Jeżeli WIP rośnie szybciej niż przepustowość, prawdopodobnie powstaje kolejka.
6. Work Item Age – jak długo trwa otwarta praca?
Nie każde zadanie trzeba zakończyć, żeby zauważyć problem.
Work Item Age pokazuje, jak długo trwa już praca nad niezakończonym elementem.
To szczególnie użyteczna informacja podczas codziennej pracy.
Jeżeli większość zadań jest kończona w 4–6 dni, a jeden element pozostaje otwarty od 18 dni, warto zainteresować się nim zanim dodatkowo pogorszy średni czas cyklu.
Aktualny Kanban Guide wymienia Work Item Age obok WIP, throughput i cycle time jako jedną z czterech minimalnych metryk przepływu.
7. Przewidywalność
Produktywny zespół nie musi za każdym razem kończyć pracy szybciej.
Dużą wartością biznesową jest także możliwość realistycznego prognozowania.
Jeżeli zespół mówi, że zadanie najprawdopodobniej zostanie ukończone w ciągu tygodnia, a regularnie trwa to miesiąc, problemem jest przewidywalność procesu.
Można obserwować:
- jak często zespół realizuje zakładany cel,
- jak duża jest zmienność czasu cyklu,
- ile pracy jest regularnie przenoszone,
- jaki odsetek elementów kończy się w oczekiwanym czasie.
W Kanban wykorzystuje się m.in. Service Level Expectation, czyli prognozę określającą prawdopodobieństwo zakończenia pracy w określonym czasie na podstawie danych historycznych.
Nie trzeba wdrażać formalnego SLE w każdym projekcie. Sama analiza rozrzutu czasów realizacji daje często więcej informacji niż jedna średnia.
8. Velocity – użyteczne, ale nie jako wskaźnik produktywności
Velocity jest popularne przede wszystkim w zespołach wykorzystujących Sprinty i story points.
Pokazuje ilość oszacowanej pracy ukończonej w kolejnych Sprintach.
Może pomóc odpowiedzieć na pytanie:
ile podobnie oszacowanej pracy możemy realistycznie uwzględnić w następnych Sprintach?
Atlassian opisuje velocity przede wszystkim jako narzędzie do prognozowania i planowania kolejnych Sprintów.
Nie powinno odpowiadać na pytanie:
czy zespół pracuje wystarczająco ciężko?
Dlaczego nie warto zwiększać velocity jako celu?
Story points są estymacją.
Jeżeli management oczekuje wzrostu velocity z 40 do 60, zespół może po prostu zacząć wyżej wyceniać podobne zadania.
Wskaźnik rośnie.
Produktywność pozostaje bez zmian.
Nie należy również porównywać velocity pomiędzy zespołami, ponieważ każdy zespół może mieć inną skalę i sposób estymowania. Atlassian wprost przestrzega przed takim porównywaniem.
9. Sprint Goal – czy osiągamy cel?
Jeżeli zespół wykorzystuje Scrum, ważniejszym sygnałem od samej liczby ukończonych story points może być realizacja Sprint Goal.
Scrum Guide określa Sprint Goal jako pojedynczy cel Sprintu, który zapewnia spójność pracy zamiast traktowania jej jako zestawu niezależnych inicjatyw.
Zespół może nie ukończyć każdego elementu, a mimo to osiągnąć wartościowy Sprint Goal.
Może też zamknąć wszystkie tickety, które nie tworzą żadnego spójnego rezultatu.
Dlatego ocena Sprintu wyłącznie przez procent wykonania backlogu bywa myląca.
10. Jakość i rework
Szybkość bez jakości tworzy pozorną produktywność.
Jeżeli zespół kończy 20 zadań, ale osiem w następnym tygodniu wraca do poprawy, część przepustowości pochłania ponowne wykonywanie tej samej pracy.
Można więc obserwować:
- liczbę błędów wykrytych po zakończeniu pracy,
- liczbę zadań wracających do wcześniejszego etapu,
- czas poświęcony na poprawki,
- udział nieplanowanej pracy naprawczej,
- awarie po wdrożeniu.
W zespołach tworzących oprogramowanie przydatne są również metryki DORA. Aktualny model rozdziela przepustowość dostarczania od jego stabilności, uwzględniając m.in. czas dostarczenia zmiany, częstotliwość wdrożeń, czas odzyskania po nieudanym wdrożeniu, odsetek nieudanych zmian oraz pracę naprawczą.
Nie ma potrzeby stosowania tych metryk w zespole marketingowym czy HR. Są szczególnie przydatne tam, gdzie zespół regularnie dostarcza oprogramowanie.
Burndown i burnup – dobre do kontroli zakresu, słabsze do oceny produktywności
Burndown pokazuje, ile zaplanowanej pracy pozostało.
Burnup pokazuje, ile pracy ukończono i może jednocześnie uwidaczniać zmianę całkowitego zakresu.
To użyteczne narzędzia do obserwowania realizacji planu.
Nie są jednak dobrym miernikiem produktywności zespołu.
Zielony burndown nie odpowiada na pytanie:
- czy powstała wartość,
- czy rozwiązanie jest wysokiej jakości,
- czy zespół jest przeciążony,
- czy użytkownicy potrzebują dostarczonego rezultatu.
Traktowałbym je więc jako narzędzia kontroli planu, nie główne KPI efektywności.
Jakich wskaźników nie używać do oceny pracowników?
Pomiar zespołu łatwo zamienić w system indywidualnego rozliczania ludzi.
Szczególnie problematyczne są:
- liczba zamkniętych ticketów na osobę,
- story points na programistę,
- liczba commitów,
- liczba linii kodu,
- liczba godzin przy komputerze,
- czas spędzony w statusie aktywnym,
- indywidualne velocity.
Takie wskaźniki bardzo łatwo zoptymalizować bez poprawy wyniku zespołu.
Programista rozliczany z liczby ticketów będzie preferował wiele niewielkich zadań.
Osoba rozliczana z liczby linii kodu nie ma motywacji do uproszczenia rozwiązania.
Zespół premiowany za velocity może podwyższać estymaty.
Atlassian zwraca uwagę na ryzyko wykorzystywania metryk jako narzędzia do porównywania zespołów i nacisku na pracowników zamiast jako informacji wspierającej doskonalenie.
Mierz system pracy, nie aktywność pojedynczego człowieka.
Jak stworzyć prosty zestaw mierników dla zespołu projektowego?
Nie trzeba budować dashboardu z 30 wskaźnikami.
Dla większości zespołów wystarczy kilka dobrze dobranych miar.
Przykład:
| Obszar | Wskaźnik |
| Wartość | Jeden miernik rezultatu biznesowego lub użytkowego |
| Szybkość | Czas cyklu |
| Przepływ | Praca w toku |
| Przepustowość | Liczba zakończonych elementów w czasie |
| Przewidywalność | Odsetek pracy realizowanej w oczekiwanym czasie |
| Jakość | Liczba powrotów/poprawek |
| Stabilność zespołu | Nadgodziny, przeciążenie lub inny sygnał braku zrównoważonego tempa |
Nie wszystkie trzeba umieszczać na jednym ekranie.
Każdy wskaźnik powinien mieć konkretny cel.
Jeżeli nikt nie potrafi odpowiedzieć na pytanie:
jaką decyzję podejmiemy dzięki tej metryce?
prawdopodobnie nie trzeba jej mierzyć.
Kanban Guide również podkreśla, że same metryki przepływu niewiele znaczą, jeżeli nie prowadzą do decyzji dotyczących sposobu pracy.
Przykład: zespół wygląda na mało produktywny, ale problem leży gdzie indziej
Załóżmy, że management widzi, że zespół kończy mniej zadań niż kwartał wcześniej.
Pierwsza interpretacja:
spadła produktywność pracowników.
Dane pokazują jednak:
- czas aktywnej pracy nad zadaniem praktycznie się nie zmienił,
- WIP wzrósł,
- zadania coraz dłużej czekają przed akceptacją,
- jedna osoba musi zatwierdzać większość zmian,
- Work Item Age rośnie właśnie na tym etapie.
Problemem nie jest więc tempo wykonywania pracy przez zespół.
Problemem jest wąskie gardło procesu akceptacji.
Rozwiązaniem może być zmiana odpowiedzialności lub zasad decyzyjnych, a nie nacisk na szybszą pracę.
To główny powód, dla którego metryki przepływu są przydatniejsze od prostego liczenia wykonanych zadań.
Jak wykorzystać retrospektywę do pracy z metrykami?
Metryka powinna rozpoczynać rozmowę, a nie ją kończyć.
Przykład:
cycle time wzrósł z typowych 5–7 dni do 10–14 dni.
Podczas retrospektywy zespół może sprawdzić:
- gdzie pojawiło się dodatkowe oczekiwanie,
- czy wzrósł WIP,
- czy zmienił się rodzaj realizowanej pracy,
- czy nowe zależności powodują blokady,
- czy więcej elementów wraca do poprawy.
Następnie można ustalić eksperyment:
przez następny okres ograniczamy liczbę zadań jednocześnie znajdujących się w review i obserwujemy wpływ na czas cyklu.
Wtedy metryka wspiera ciągłe doskonalenie zamiast kontrolowania ludzi.
Czy narzędzia projektowe wystarczą?
Jira, Azure DevOps, Asana czy inne systemy mogą automatycznie zbierać część informacji.
Przydatne są między innymi:
- historia statusów,
- cycle time,
- liczba zakończonych elementów,
- WIP,
- burndown,
- velocity,
- dane o blokadach.
Nie każda potrzebna metryka znajduje się jednak w systemie projektowym.
Jeżeli celem zespołu jest poprawa konwersji klienta, dane mogą pochodzić z analityki produktu.
Jeżeli projekt automatyzuje proces biznesowy, trzeba zmierzyć czas i liczbę ręcznych operacji w tym procesie.
Jeżeli poprawiamy jakość oprogramowania, potrzebne mogą być dane z systemu monitoringu i CI/CD.
Dashboard projektowy pokazuje aktywność zespołu. Nie zawsze pokazuje rezultat jego pracy.
Jak automatyzować pomiar produktywności?
Automatyzacja jest przydatna przede wszystkim do zbierania danych.
Można automatycznie:
- rejestrować czas przejścia między statusami,
- liczyć zakończone elementy,
- wskazywać starzejące się zadania,
- wykrywać przekroczenie limitu WIP,
- agregować wyniki testów,
- pobierać dane z CI/CD,
- generować raport przepływu,
- przygotowywać dane przed retrospektywą.
Nie należy natomiast automatycznie wyciągać wniosku:
zespół A ma niższy wynik, więc pracuje gorzej.
Metryka pokazuje sygnał. Interpretacja wymaga znajomości kontekstu.
Jak poprawiać produktywność zespołu projektowego?
Po zebraniu danych nie zaczynaj od pytania, jak zwiększyć liczbę ukończonych zadań.
Najpierw znajdź miejsce, w którym praca traci najwięcej czasu.
Jeżeli problemem jest:
wysoki WIP → ogranicz rozpoczynanie kolejnej pracy i skup się na kończeniu rozpoczętej,
długi czas oczekiwania → usuń kolejkę lub zbędną akceptację,
dużo poprawek → popraw jakość wcześniej w procesie,
duża zmienność czasu realizacji → przeanalizuj różne typy pracy i zależności,
niska wartość rezultatu → popraw priorytetyzację i feedback użytkowników,
przeciążenie → ogranicz zakres pracy zamiast zwiększać presję.
W Scrum Guide zwrócono uwagę, że praca w Sprintach w zrównoważonym tempie wspiera koncentrację i spójność działania Scrum Teamu.
Produktywności nie buduje się więc przez ciągłe zwiększanie obciążenia.
Buduje się ją przez usuwanie przeszkód, kolejek, pracy ponownej i zadań, które nie prowadzą do wartościowego rezultatu.
Zacznij od trzech pytań
Jeżeli dziś nie mierzycie produktywności zespołu projektowego w uporządkowany sposób, nie wdrażaj od razu kilkunastu KPI.
Zacznij od:
1. Ile trwa dostarczenie typowego elementu pracy?
Sprawdź czas cyklu i oczekiwanie.
2. Co najczęściej opóźnia zakończenie pracy?
Sprawdź WIP, blokady oraz starzejące się zadania.
3. Skąd wiemy, że zakończona praca przyniosła wartość?
Wybierz miernik rezultatu zależny od celu projektu.
Po kilku tygodniach danych pojawią się trendy, które można analizować na retrospektywie lub przeglądzie procesu.
Celem nie powinno być uzyskanie jak największej liczby na dashboardzie.
Dobry system pomiaru produktywności pomaga zespołowi szybciej zauważyć, gdzie traci czas, gdzie pogarsza się jakość i czy wykonywana praca faktycznie prowadzi do oczekiwanego rezultatu.
