Метрики розробки без Jira
Jira не потрібна для вимірювання важливого. Дізнайтесь, як відстежувати стан команди через Git, CI та інструменти, які вже використовуєте.
By Ellis Keane · 2026-03-23
Невеликі команди з найкращою видимістю інженерної роботи – як правило, ті, що перестали гнатися за метриками, які Jira хоче, щоб вони відстежували.
Я розумію, що це звучить так, ніби я просто суперечу заради суперечки, і, чесно кажучи, може трохи й так – але я витратив більшу частину трьох років на сумлінне ведення sprint-дошок, грумінг беклогу та оновлення оцінок тікетів, робота над якими вже наполовину була виконана до того, як хтось відкривав Jira того ранку. Кожні два тижні ми сиділи в кімнаті (власне, в Zoom – це був 2023 рік) і пильно дивилися на графік velocity, який не говорив нічого такого, чого ми вже не знали з розмов між собою. Метрики розробки без Jira – це не те, що я шукав. Це сталося тоді, коли я перестав вдавати, що графіки velocity кажуть мені щось корисне.
Якщо ваша команда достатньо маленька, щоб сидіти за одним столом, вам, мабуть, не потрібна Jira, щоб знати, як у вас справи. Вам потрібні кращі сигнали від інструментів, які ви вже використовуєте.
Це не стаття «Jira погана». Jira – чудовий інструмент для організацій, яким потрібне відстеження у стилі Jira (і на певному масштабі вони справді потребують). Але якщо ви engineering manager у стартапі на 10–40 осіб і платите за Jira лише задля графіків velocity, це трохи схоже на купівлю промислової печі, щоб розігріти обід.
"Платити за Jira лише задля графіків velocity – це трохи схоже на купівлю промислової печі, щоб розігріти обід." attribution: Chris Calo
Що насправді вимірюють метрики Jira
Скажу прямо: більшість метрик Jira вимірюють використання Jira, а не продуктивність розробки. Story points вимірюють здатність команди оцінювати story points. Velocity вимірює, наскільки послідовно команда заповнює спринти приблизно однаковою ємністю. Burndown charts вимірюють, чи хтось пам'ятав перетягнути тікети через дошку у четвер після обіду.
Жодне з цього не є абсолютно марним. Але це все – метрики процесу, що вдягнулися у developer productivity metrics, і прогалина між ними – це місце, де engineering managers губляться.
Я був тим EM, який витрачав майже годину перед зустріччю зі стейкхолдерами на те, щоб «масажувати» дані Jira у слайд-дек із написом «ми в графіку». Стейкхолдер кивав, ставив одне запитання про баг із логіном з минулого вівторка, і нарада завершувалася. Ця година була присвячена слайд-деку. Реальна відповідь звучала як «запитайте інженера».
Якщо ваші метрики потребують більше обслуговування, ніж робота, яку вони вимірюють, – проблема в метриках.
Cycle time з Git, а не з дошок тікетів
Для невеликих продуктових команд cycle time – зазвичай метрика з найвищим рівнем сигналу, яку можна відстежувати. Вона вимірює тривалість від першого коміту до деплою в production, і її можна повністю отримати з Git-історії та CI pipeline – без жодної дошки тікетів.
Компоненти:
- Часова мітка першого коміту у гілці або PR
- Часова мітка злиття PR
- Часова мітка деплою (з вашого CI/CD – GitHub Actions, CircleCI або будь-чого, що ви використовуєте)
Різниця між 1 і 3 – це ваш cycle time. Розбийте його на сегменти – час написання коду (від 1 до відкриття PR), час перегляду (від відкриття PR до злиття) та черга деплою (від злиття до production) – і ви отримаєте діагностику, яка показує, де робота насправді зупиняється.
Коли я вперше зробив це для нашої команди, цифри були справді несподіваними. Я вважав, що час перегляду – наше вузьке місце (всі завжди вважають час перегляду вузьким місцем, хіба ні?). Виявилося, що наша фаза від написання коду до PR була нормальна, перегляди були нормальні, і ми втрачали в середньому близько двох днів між злиттям і деплоєм, тому що наше середовище для тестування було нестабільним і ніхто не надавав пріоритету його виправленню. Жоден графік velocity ніколи б не виявив це.
Як виміряти
Якщо ви на GitHub, можна витягнути це за допомогою CLI:
```bash
Get merged PRs for the last 30 days
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
Для часових міток деплою більшість CI-систем надають їх через API або webhook. Зіставте SHA злиттів PR з подіями деплою – і ви отримаєте cycle time, сегментований за фазами.
Підказка: Якщо ваш CI не надає часові мітки деплою в зручному вигляді, дуже простий підхід – Slack-бот, який публікує в канал #deploys з SHA коміту. Ви отримуєте часові мітки, зрозумілий для людини лог і – як побічний ефект – канал, що показує, як часто ви відправляєте.
Пропускна здатність code review
Review throughput – кількість PR, переглянутих кожним інженером на тиждень, та медіанний час від відкриття PR до першого перегляду – говорить більше про здоров'я команди, ніж будь-яка sprint-метрика. Її недооцінюють.
Чому? Тому що поведінка під час перегляду – це випереджальний індикатор. Коли час перегляду починає зростати, це зазвичай означає, що інженери перевантажені, занадто активно здійснюють перемикання контексту або (і це незручне припущення) уникають коду один одного. Будь-що з цього варто знати до того, як це проявиться як пропущений дедлайн через два тижні.
GitHub надає ці дані через свій API. Ключові поля – createdAt у PR і submittedAt у події першого перегляду.
Число, яке я відстежую, – це медіанна кількість годин до першого перегляду. З нашого досвіду в кількох невеликих командах здоровий ритм перегляду зазвичай тримається нижче приблизно 8 годин. Коли він стабільно перевищує добу, щось структурне змінилося – і що б це не було, у Jira цього не видно.
Співвідношення нарад до рішень
Це не традиційна метрика розробки, і варто бути відвертим: це груба евристика, а не KPI. Але для невеликих команд я знаходжу її напрочуд показовою.
Підрахуйте наради, які провела ваша команда цього тижня. Підрахуйте конкретні рішення, що були прийняті за їхніми результатами (не «нам слід вивчити X» – реальні рішення з відповідальними особами і наступними кроками). Поділіть останнє на перше.
Якщо менш ніж половина ваших нарад породила рішення, варто запитати, чи виправдовують ці наради свій час. Деякі наради існують для зменшення ризику або обміну контекстом, і це законно – не все має закінчуватися резолюцією. Але коли ви починаєте відстежувати це навіть неформально (я буквально вів підрахунок у блокноті), ви виробляєте відчуття, які наради продуктивні, а які – просто ритуали, які ніхто не ставив під сумнів.
Я відстежував це приблизно місяць, і це змінило спосіб, яким я планую наради, більше, ніж будь-яка стаття про продуктивність. Коли ви бачите, що ваш понеділковий standup не прийняв жодного рішення три тижні поспіль, його скасування перестає здаватися радикальним.
Побудова метрик розробки без Jira: легкий дашборд
Вам не потрібен інструмент BI для цього. Сторінка Notion, Google Sheet або щотижневий пост у Slack із чотирма числами – цього достатньо:
- Медіанний cycle time (з Git/CI) – ми відправляємо швидше чи повільніше?
- Медіанний час до першого перегляду (з GitHub) – команда переглядає вчасно?
- Deploy frequency (з CI або каналу #deploys) – як часто ми відправляємо?
- Співвідношення нарад до рішень (ручний підрахунок) – наради виправдовують себе?
Чотири числа, всі отримані з інструментів, які у вас вже є, жодне з яких не вимагає ведення дошки Jira. Оновлюйте щотижня. Якщо число рухається в неправильному напрямку два тижні поспіль – розслідуйте. Якщо тримається стабільно – залиште як є.
Суть не в тому, щоб створити систему стеження (будь ласка, не робіть цього – ваші інженери вас зненавидять, і вони матимуть рацію). Видимість інженерної команди має надходити з самої роботи, а не від того, що ви просите людей звітувати про роботу.
Найкращі метрики розробки дешеві у зборі, їх важко фальсифікувати, і вони говорять вам щось, на підставі чого можна діяти. Story points провалюються за всіма трьома критеріями.
Коли вам справді потрібна дошка тікетів
Я сказав, що це не стаття «Jira погана», і я так вважаю. Є законні ситуації, коли відстеження метрик без інструменту управління проектами стає справді безвідповідальним:
- Галузі з жорсткими вимогами відповідності, де аудит-сліди статусу завдань юридично обов'язкові
- Великі інженерні організації, де міжкомандні залежності роблять неформальну координацію нежиттєздатною
- Організації з виділеними функціями управління проектами, яким потрібне єдине канонічне джерело правди між командами
Якщо це ваша ситуація, Jira (або Linear, або Shortcut) – правильний вибір. Я стверджую, що для невеликих команд підтримка важкого інструменту виключно заради метрик – поганий обмін. Ви закінчите тим, що оптимізуватиметесь під модель роботи інструменту, а не під реальну роботу вашої команди.
І чесно? Навіть команди, які використовують Jira, виграли б від доповнення даних дошки вищезазначеними Git-похідними метриками. Jira розповідає вам, що люди кажуть, що вони роблять. Git розповідає вам, що вони насправді роблять. Обидва корисні, але тільки один є невразливим до театру оновлення статусів.
Якщо питання метрик продовжує виникати у вашому стартапі, спробуйте чотиричисловий дашборд протягом місяця. Метрики розробки без Jira можуть здаватися роботою без страхувальної сітки – але коли ви побачите, скільки сигналів живе у вашій Git-історії та CI pipeline, ви здивуєтесь, що взагалі додавала дошка тікетів.
Автоматично виявляйте cycle time, зупинені PR та вузькі місця в перегляді – без спеціальних скриптів або дошки Jira.
Q: Чи можна отримати значущі метрики розробки без інструменту управління проектами? A: Так. Cycle time (від першого коміту до деплою), review throughput і deploy frequency – усі вони містяться у вашій Git-історії та CI pipeline. Для команд менш ніж 40 інженерів вони, як правило, точніші та важче фальсифікуються, ніж будь-що на дошці тікетів – і не вимагають, щоб хтось перетягував картки через дошку для збереження точності.
Q: Чи відображає Sugarbug метрики розробки автоматично? A: Sugarbug підключається до GitHub, Linear, Slack і календарів, щоб побудувати граф знань активності вашої команди. Він позначає такі патерни, як зупинені PR, вузькі місця у перегляді та нерозв'язані рішення – охоплюючи багато сигналів, описаних тут, без необхідності писати та підтримувати спеціальні скрипти для GitHub API.
Q: Як отримати підтримку для відмови від Jira як інструменту метрик? A: Подайте це як експеримент, а не бунт. Запускайте Git-похідні метрики паралельно з наявними дашбордами Jira протягом чотирьох тижнів, а потім порівняйте, які числа спонукали до реальних змін. Якщо Git-метрики виявляться більш дієвими (а з нашого досвіду вони зазвичай такими є), справа доведе себе сама.
Q: У чому різниця між метриками процесу та метриками продуктивності? A: Метрики процесу (story points, velocity, burndown) вимірюють наскільки послідовно команда дотримується робочого процесу. Метрики продуктивності (cycle time, deploy frequency, review throughput) вимірюють, що команда реально відправляє і як швидко. Невеликі команди майже завжди отримують більше сигналу від останніх, тому що метрики продуктивності отримані із самої роботи, а не з ручних оновлень статусів.