Metryki inżynieryjne bez Jiry
Nie potrzebujesz Jiry, aby mierzyć to, co ważne. Dowiedz się, jak śledzić kondycję inżynieryjną z Gita, CI i narzędzi, których Twój zespół już używa.
By Ellis Keane · 2026-03-23
Małe zespoły, które osiągają najlepszą widoczność inżynieryjną, to zazwyczaj te, które przestały gonić za metrykami, których Jira chce, żeby śledziły.
Rozumiem, że brzmi to jak zwykła przekora dla samej przekory – i szczerze mówiąc, może trochę tak jest. Przez blisko trzy lata sumiennie zarządzałem tablicami sprintów, pielęgnowałem backlog i aktualizowałem szacunki na biletach, które były już w połowie ukończone, zanim ktokolwiek otworzył Jirę tamtego ranka. Co dwa tygodnie siadaliśmy razem (no, na Zoomie – to był 2023 rok) i wpatrywaliśmy się w wykres prędkości, który nie mówił nam absolutnie niczego, czego nie wiedzieliśmy już z rozmów. Metryki inżynieryjne bez Jiry – tego nie szukałem. To po prostu stało się, gdy przestałem udawać, że wykresy prędkości cokolwiek mi mówią.
Jeśli Twój zespół jest wystarczająco mały, by usiąść przy jednym stole, prawdopodobnie nie potrzebujesz Jiry, żeby wiedzieć, jak sobie radzicie. Potrzebujesz lepszych sygnałów z narzędzi, których już używasz.
To nie jest tekst o tym, że "Jira jest zła". Jira to świetne narzędzie dla organizacji, które potrzebują śledzenia w stylu Jiry (i na pewnym poziomie skali rzeczywiście go potrzebują). Ale jeśli jesteś inżyniером menedżerem w startupie liczącym 10–40 osób i płacisz za Jirę wyłącznie po to, by generować wykresy prędkości, to trochę jak kupowanie przemysłowego pieca do odgrzewania lunchu.
"Płacenie za Jirę wyłącznie w celu generowania wykresów prędkości przypomina kupowanie przemysłowego pieca do odgrzewania lunchu." – Chris Calo
Co naprawdę mierzą metryki Jiry
Powiem wprost: większość metryk Jiry mierzy użycie Jiry, a nie wyniki inżynieryjne. Punkty historyjki mierzą zdolność zespołu do szacowania punktów historyjki. Prędkość mierzy, jak konsekwentnie zespół wypełnia sprinty do mniej więcej tej samej pojemności. Wykresy burndown mierzą, czy ktoś pamiętał, żeby przeciągnąć bilety po tablicy w czwartkowe popołudnie.
Żadna z tych metryk nie jest bezużyteczna sama w sobie. Ale to metryki procesu przebrane za wskaźniki produktywności deweloperów – i właśnie ta luka powoduje, że inżynierowie menedżerowie tracą z oczu to, co naprawdę ważne.
Sam byłem tym EM, który spędza prawie godzinę przed spotkaniem z interesariuszami na przekształcaniu danych z Jiry w prezentację pokazującą, że "jesteśmy na dobrej drodze". Interesariusz kiwa głową, zadaje jedno pytanie o błąd logowania sprzed poprzedniego wtorku i spotkanie się kończy. Ta godzina była dla prezentacji. Prawdziwa odpowiedź brzmiała: "zapytaj inżyniera".
Jeśli Twoje metryki wymagają więcej pracy konserwacyjnej niż praca, którą mierzą, problem leży w metrykach.
Czas cyklu z Gita, nie z tablicy zadań
Dla małych zespołów produktowych czas cyklu to zazwyczaj najlepszy sygnał, jaki możesz śledzić. Mierzy czas od pierwszego commita do wdrożenia na produkcję i możesz go wyliczyć wyłącznie z historii Gita i potoku CI – bez żadnej tablicy zadań.
Składowe:
- Znacznik czasu pierwszego commita w gałęzi lub PR
- Znacznik czasu scalenia PR
- Znacznik czasu wdrożenia (z CI/CD – GitHub Actions, CircleCI lub czegokolwiek używasz)
Różnica między 1 a 3 to Twój czas cyklu. Podziel go na segmenty – czas kodowania (od 1 do otwarcia PR), czas recenzji (od otwarcia PR do scalenia) i kolejka wdrożenia (od scalenia do produkcji) – a otrzymasz narzędzie diagnostyczne, które mówi Ci, gdzie praca faktycznie utyka.
Gdy po raz pierwszy zrobiłem to dla naszego zespołu, liczby były naprawdę zaskakujące. Zakładałem, że czas recenzji jest wąskim gardłem (wszyscy zawsze tak zakładają, prawda?). Okazało się, że faza kodowania do PR była w porządku, recenzje też, a traciliśmy średnio dwa dni między scaleniem a wdrożeniem, ponieważ nasze środowisko stagingowe było niestabilne i nikt nie nadał naprawieniu tego priorytetu. Żaden wykres prędkości nigdy by tego nie ujawnił.
Jak to mierzyć
Jeśli korzystasz z GitHuba, możesz to pobrać za pomocą CLI:
```bash
Pobierz scalone PR z ostatnich 30 dni
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
W przypadku znaczników czasu wdrożeń większość systemów CI udostępnia je przez API lub webhook. Zmapuj SHA scalenia PR na zdarzenia wdrożeń, a otrzymasz czas cyklu podzielony na fazy.
Wskazówka: Jeśli Twój CI nie udostępnia znaczników czasu wdrożeń w przejrzysty sposób, najprostszym podejściem jest bot Slackowy publikujący na kanale #deploys z SHA commita. Zyskujesz znaczniki czasu, czytelny dla człowieka dziennik i – przy okazji – kanał informujący, jak często wdrażasz.
Przepustowość recenzji kodu
Przepustowość recenzji – liczba PR przeglądanych przez inżyniera tygodniowo oraz mediana czasu od otwarcia PR do pierwszej recenzji – mówi więcej o kondycji zespołu niż jakakolwiek metryka sprintu. Jest niedoceniana.
Dlaczego? Bo zachowanie przy recenzjach to wskaźnik wyprzedzający. Gdy czasy recenzji zaczynają rosnąć, zwykle oznacza to, że inżynierowie są przeciążeni, zbyt intensywne przełączanie kontekstu lub – i to jest ta niekomfortowa opcja – unikają wzajemnie swojego kodu. Każda z tych sytuacji jest warta poznania zanim pojawi się jako przekroczone terminy dwa tygodnie później.
GitHub udostępnia te dane przez API. Kluczowe pola to createdAt na PR i submittedAt na pierwszym zdarzeniu recenzji.
Liczba, którą obserwuję, to mediana godzin do pierwszej recenzji. Z naszego doświadczenia w kilku małych zespołach zdrowy rytm recenzji utrzymuje się poniżej około 8 godzin. Gdy konsekwentnie przekracza jeden dzień, coś strukturalnego się zmieniło – i cokolwiek to jest, jest niewidoczne w Jirze.
Stosunek spotkań do decyzji
To nie jest tradycyjna metryka inżynieryjna i powiem wprost: to przybliżona heurystyka, nie KPI. Ale w małych zespołach okazuje się zaskakująco odkrywcza.
Policz spotkania, które Twój zespół odbył w tym tygodniu. Policz konkretne decyzje, które z nich wynikły (nie "powinniśmy zbadać X" – prawdziwe decyzje z właścicielami i kolejnymi krokami). Podziel drugie przez pierwsze.
Jeśli mniej niż połowa spotkań dała decyzję, warto zapytać, czy te spotkania są warte swojego czasu. Niektóre spotkania istnieją po to, by zmniejszyć ryzyko lub podzielić się kontekstem i to jest uzasadnione – nie wszystko musi kończyć się rozwiązaniem. Ale gdy zaczniesz to śledzić nawet nieformalnie (ja dosłownie prowadziłem zliczanie w notatniku), zaczyna się rozwijać wyczucie, które spotkania są twórcze, a które to tylko rytuały, których nikt nie zakwestionował.
Śledziłem to przez około miesiąc i zmieniło to sposób planowania przeze mnie spotkań bardziej niż jakikolwiek artykuł o produktywności. Gdy widzisz, że Twój poniedziałkowy standup przez trzy tygodnie z rzędu nie wygenerował dosłownie żadnej decyzji, anulowanie przestaje wydawać się radykalnym krokiem.
Budowanie metryk inżynieryjnych bez Jiry: lekki pulpit nawigacyjny
Nie potrzebujesz do tego narzędzia BI. Strona w Notionii, arkusz Google lub tygodniowy post na Slacku z czterema liczbami w zupełności wystarczy:
- Mediana czasu cyklu (z Gita/CI) – czy dostarczamy szybciej, czy wolniej?
- Mediana czasu do pierwszej recenzji (z GitHuba) – czy zespół recenzuje sprawnie?
- Częstotliwość wdrożeń (z CI lub kanału #deploys) – jak często wdrażamy?
- Stosunek spotkań do decyzji (zliczanie ręczne) – czy nasze spotkania są opłacalne?
Cztery liczby, wszystkie możliwe do uzyskania z narzędzi, które już masz, żadna nie wymaga utrzymywania tablicy Jiry. Aktualizuj co tydzień. Jeśli liczba idzie w złym kierunku przez dwa kolejne tygodnie, zbadaj to. Jeśli się utrzymuje, zostaw ją w spokoju.
Chodzi o to, żeby nie budować systemu nadzoru (proszę, nie rób tego – Twoi inżynierowie będą Cię nienawidzić i będą mieć rację). Widoczność zespołu inżynieryjnego powinna wynikać z samej pracy, a nie z proszenia ludzi o raportowanie o pracy.
Najlepsze metryki inżynieryjne są tanie w zbieraniu, trudne do sfałszowania i mówią Ci coś, na co możesz zareagować. Punkty historyjki zawodzą we wszystkich trzech kwestiach.
Kiedy naprawdę potrzebujesz tablicy zadań
Powiedziałem, że to nie jest tekst o tym, że "Jira jest zła" – i tak to rozumiem. Istnieją uzasadnione sytuacje, w których śledzenie metryk bez narzędzia do zarządzania projektami staje się naprawdę nieodpowiedzialne:
- Branże z dużymi wymogami zgodności, gdzie ślady audytu statusu zadań są wymagane prawem
- Większe organizacje inżynieryjne, gdzie zależności między zespołami sprawiają, że nieformalna koordynacja staje się niemożliwa
- Organizacje z dedykowanymi funkcjami zarządzania projektami, które potrzebują kanonicznego źródła prawdy między zespołami
Jeśli taka jest Twoja sytuacja, Jira (lub Linear, lub Shortcut) to właściwy wybór. Moim argumentem jest to, że dla małych zespołów utrzymywanie ciężkiego narzędzia wyłącznie na potrzeby metryk to zły interes. Kończysz na optymalizacji pod kątem modelu pracy narzędzia, a nie rzeczywistej pracy Twojego zespołu.
I szczerze? Nawet zespoły korzystające z Jiry skorzystałyby na uzupełnieniu danych z tablicy powyższymi metrykami opartymi na Gicie. Jira mówi Ci, co ludzie mówią, że robią. Git mówi Ci, co faktycznie robią. Obydwa są użyteczne, ale tylko jedno jest odporne na teatr aktualizacji statusów.
Jeśli kwestia metryk ciągle pojawia się w Twoim startupie, spróbuj przez miesiąc czteroliczbowego pulpitu nawigacyjnego. Metryki inżynieryjne bez Jiry mogą brzmieć jak chodzenie bez siatki bezpieczeństwa – ale gdy zobaczysz, ile sygnałów tkwi w historii Gita i potoku CI, zaczniesz się zastanawiać, co właściwie wnosiła tablica zadań.
Odkryj czas cyklu, zablokowane PR i wąskie gardła recenzji automatycznie – bez własnych skryptów ani tablicy Jiry.
Q: Czy można uzyskać znaczące metryki inżynieryjne bez narzędzia do zarządzania projektami? A: Tak. Czas cyklu (od pierwszego commita do wdrożenia), przepustowość recenzji i częstotliwość wdrożeń – wszystko to jest w historii Gita i potoku CI. Dla zespołów liczących poniżej około 40 inżynierów są to wskaźniki ostrzejsze i trudniejsze do sfałszowania niż cokolwiek, co produkuje tablica zadań – i nie wymagają od nikogo przeciągania kart po tablicy, by pozostać dokładnymi.
Q: Czy Sugarbug automatycznie wyświetla metryki inżynieryjne? A: Sugarbug łączy się z GitHub, Linear, Slack i kalendarzami, aby zbudować graf wiedzy aktywności Twojego zespołu. Oznacza wzorce, takie jak zablokowane PR, wąskie gardła recenzji i nierozwiązane decyzje – co obejmuje wiele sygnałów opisanych tutaj bez konieczności pisania i utrzymywania własnych skryptów do API GitHuba.
Q: Jak uzyskać akceptację dla rezygnacji z Jiry jako źródła metryk? A: Przedstaw to jako eksperyment, nie rewolucję. Śledź metryki oparte na Gicie obok istniejących pulpitów Jiry przez cztery tygodnie, a następnie porównaj, które liczby skłoniły do rzeczywistych zmian. Jeśli metryki z Gita okażą się bardziej wartościowe (a z naszego doświadczenia mają taką tendencję), argument broni się sam.
Q: Jaka jest różnica między metrykami procesu a metrykami wydajności? A: Metryki procesu (punkty historyjki, prędkość, burndown) mierzą, jak konsekwentnie zespół podąża za przepływem pracy. Metryki wydajności (czas cyklu, częstotliwość wdrożeń, przepustowość recenzji) mierzą, co zespół faktycznie dostarcza i jak szybko. Małe zespoły prawie zawsze uzyskują więcej sygnałów z tych drugich, ponieważ metryki wydajności wywodzą się z samej pracy, a nie z ręcznych aktualizacji statusu.