Метрики разработки без Jira
Вам не нужна Jira, чтобы измерять важное. Узнайте, как отслеживать состояние команды с помощью Git, CI и инструментов, которые вы уже используете.
By Ellis Keane · 2026-03-23
Небольшие команды, которые добиваются наилучшей видимости разработки, как правило, – это те, кто перестал гнаться за метриками, которые Jira хочет, чтобы они отслеживали.
Понимаю, что это звучит как противоречие ради противоречия – и, честно говоря, возможно, так оно и есть немного. Но я провёл почти три года, добросовестно поддерживая доски спринтов, прорабатывая бэклоги и обновляя оценки задач, которые уже были наполовину завершены до того, как кто-то открыл Jira тем утром. Каждые две недели мы собирались (ну, в Zoom – это был 2023 год) и смотрели на график скорости, который не говорил нам ничего, чего мы уже не знали из разговоров. Метрики разработки без Jira – это не то, что я искал намеренно. Это просто случилось, когда я перестал притворяться, что графики скорости что-то мне говорят.
Если ваша команда достаточно мала, чтобы сидеть за одним столом, вам, вероятно, не нужна Jira, чтобы знать, как дела. Вам нужны лучшие сигналы от инструментов, которые вы уже используете.
Это не статья о том, что "Jira плохая". Jira – отличный инструмент для организаций, которым нужно отслеживание в стиле Jira (и на определённом масштабе они действительно в нём нуждаются). Но если вы – инженерный менеджер стартапа из 10–40 человек и платите за Jira исключительно для создания графиков скорости, это немного похоже на покупку промышленной духовки, чтобы разогреть обед.
"Платить за Jira исключительно для создания графиков скорости – всё равно что купить промышленную духовку, чтобы разогреть обед." – Chris Calo
Что на самом деле измеряют метрики Jira
Скажу прямо: большинство метрик Jira измеряют использование Jira, а не результаты разработки. Story points измеряют способность команды оценивать story points. Скорость измеряет, насколько последовательно команда заполняет спринты примерно одинаковым объёмом. Графики burndown измеряют, не забыл ли кто-то перетащить задачи через доску в четверг после обеда.
Всё это не является абсолютно бесполезным. Но это метрики процесса, замаскированные под метрики продуктивности разработчиков, – и именно этот разрыв приводит к тому, что инженерные менеджеры теряют нить.
Я был тем EM, который проводил почти час перед встречей со стейкхолдерами, форматируя данные из Jira в презентацию, демонстрирующую, что "мы в графике". Стейкхолдер кивает, задаёт один вопрос про баг логина с прошлого вторника, и встреча заканчивается. Час ушёл на презентацию. Реальный ответ был: "спросите инженера".
Если ваши метрики требуют больше обслуживания, чем работа, которую они измеряют, проблема в метриках.
Время цикла из Git, а не с доски задач
Для небольших продуктовых команд время цикла – обычно самая информативная метрика. Оно измеряет продолжительность от первого коммита до деплоя в продакшн и может быть полностью получено из истории Git и пайплайна CI – без каких-либо досок задач.
Компоненты:
- Временная метка первого коммита в ветке или PR
- Временная метка мержа PR
- Временная метка деплоя (из вашего CI/CD – GitHub Actions, CircleCI или того, что вы используете)
Разница между 1 и 3 – это ваше время цикла. Разбейте его на сегменты – время кодирования (от 1 до открытия PR), время ревью (от открытия PR до мержа) и очередь деплоя (от мержа до продакшна) – и вы получите диагностический инструмент, показывающий, где работа реально стопорится.
Когда я впервые сделал это для нашей команды, цифры оказались по-настоящему неожиданными. Я предполагал, что узкое место – время ревью (все всегда так думают, не правда ли?). Оказалось, что фаза от кодирования до PR была в порядке, ревью – тоже, а мы теряли в среднем два дня между мержем и деплоем, потому что наша staging-среда была нестабильной и никто не приоритизировал её починку. Никакой график скорости этого бы не выявил.
Как это измерить
Если вы на GitHub, данные можно получить через CLI:
```bash
Получить смёрженные PR за последние 30 дней
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
Для временных меток деплоев большинство CI-систем предоставляют их через API или webhook. Сопоставьте SHA мержа PR с событиями деплоя – и вы получите время цикла, разбитое по фазам.
Совет: Если ваш CI не предоставляет временные метки деплоев в удобном виде, предельно простой подход – Slack-бот, который публикует в канале #deploys с SHA коммита. Вы получаете метки времени, читаемый человеком журнал и – как побочный эффект – канал, который показывает, как часто вы делаете релизы.
Пропускная способность код-ревью
Пропускная способность ревью – количество PR, проверяемых на инженера в неделю, и медианное время от открытия PR до первого ревью – говорит о здоровье команды больше, чем любая метрика спринта. Это недооценённый показатель.
Почему? Потому что поведение при ревью – это опережающий индикатор. Когда время ревью начинает расти, это обычно означает, что инженеры перегружены, слишком интенсивное переключение контекста или – и это неудобная причина – избегают чужого кода. Любое из этих явлений стоит знать прежде, чем оно проявится как сорванный дедлайн через две недели.
GitHub предоставляет эти данные через API. Ключевые поля: createdAt у PR и submittedAt у первого события ревью.
Цифра, за которой я слежу, – медианное время в часах до первого ревью. По нашему опыту в нескольких небольших командах, здоровый ритм ревью держится ниже примерно 8 часов. Когда он стабильно превышает сутки, что-то структурное изменилось – и что бы это ни было, в Jira это невидимо.
Соотношение встреч к решениям
Это не традиционная инженерная метрика, и буду честен: это приблизительная эвристика, а не KPI. Но для небольших команд она оказывается удивительно показательной.
Подсчитайте встречи, которые ваша команда провела на этой неделе. Подсчитайте конкретные решения, которые из них вышли (не "нам нужно изучить X" – реальные решения с ответственными и следующими шагами). Разделите второе на первое.
Если менее половины ваших встреч дали решение, стоит задаться вопросом: оправдывают ли эти встречи затраченное время? Некоторые встречи существуют для снижения рисков или обмена контекстом – и это оправдано, не всё должно заканчиваться резолюцией. Но когда вы начинаете отслеживать это даже неформально (я буквально вёл подсчёт в блокноте), вы развиваете чутьё на то, какие встречи продуктивны, а какие – просто ритуалы, которые никто не ставил под сомнение.
Я отслеживал это около месяца, и это изменило то, как я планирую встречи, больше, чем любая статья о продуктивности. Когда вы видите, что ваш понедельничный стендап три недели подряд не дал ни одного решения, его отмена перестаёт казаться радикальной.
Построение метрик разработки без Jira: лёгкий дашборд
Инструмент BI для этого не нужен. Достаточно страницы в Notion, таблицы в Google или еженедельного поста в Slack с четырьмя цифрами:
- Медианное время цикла (из Git/CI) – мы выпускаем быстрее или медленнее?
- Медианное время до первого ревью (из GitHub) – команда делает ревью оперативно?
- Частота деплоев (из CI или канала #deploys) – как часто мы делаем релизы?
- Соотношение встреч к решениям (ручной подсчёт) – встречи оправдывают себя?
Четыре цифры, все получаемые из уже имеющихся инструментов, ни одна из которых не требует ведения доски Jira. Обновляйте еженедельно. Если цифра два раза подряд движется в неправильном направлении – разбирайтесь. Если стабильна – не трогайте.
Цель – не создавать систему слежки (пожалуйста, не делайте этого – инженеры будут ненавидеть вас, и они будут правы). Видимость инженерной команды должна исходить из самой работы, а не из требования к людям отчитываться о работе.
Лучшие инженерные метрики дёшевы в сборе, трудны для манипуляций и говорят вам что-то, на что можно действовать. Story points не отвечают ни одному из трёх критериев.
Когда доска задач действительно нужна
Я сказал, что это не статья о том, что "Jira плохая" – и имел это в виду. Существуют обоснованные ситуации, когда отслеживание метрик без инструмента управления проектами становится по-настоящему безответственным:
- Отрасли с жёсткими требованиями к соответствию, где журналы аудита статусов задач юридически обязательны
- Крупные инженерные организации, где зависимости между командами делают неформальную координацию невозможной
- Организации с выделенными функциями управления проектами, которым нужен канонический источник истины между командами
Если это ваш случай, Jira (или Linear, или Shortcut) – правильный выбор. Мой аргумент в том, что для небольших команд поддержание тяжёлого инструмента исключительно ради метрик – плохая сделка. В итоге вы оптимизируете под модель работы инструмента, а не под реальную работу команды.
И честно? Даже команды, которые используют Jira, выиграли бы от дополнения данных доски метриками на основе Git, описанными выше. Jira говорит вам, что люди говорят, что делают. Git говорит вам, что они реально делают. Оба полезны, но только один защищён от театра обновления статусов.
Если вопрос метрик постоянно поднимается в вашем стартапе, попробуйте дашборд из четырёх цифр в течение месяца. Метрики разработки без Jira могут звучать как работа без страховочной сетки – но когда вы увидите, сколько сигналов живёт в истории Git и пайплайне CI, вы удивитесь, что вообще давала доска задач.
Отслеживайте время цикла, зависшие PR и узкие места ревью автоматически – без собственных скриптов и доски Jira.
Q: Можно ли получить значимые метрики разработки без инструмента управления проектами? A: Да. Время цикла (от первого коммита до деплоя), пропускная способность ревью и частота деплоев – всё это находится в истории Git и пайплайне CI. Для команд до 40 инженеров они, как правило, острее и труднее поддаются манипуляциям, чем всё, что производит доска задач, – и не требуют, чтобы кто-то перетаскивал карточки по доске ради точности.
Q: Отображает ли Sugarbug метрики разработки автоматически? A: Sugarbug подключается к GitHub, Linear, Slack и календарям, чтобы построить граф знаний активности вашей команды. Система отмечает такие паттерны, как зависшие PR, узкие места ревью и нерешённые задачи, – что охватывает многие сигналы, описанные здесь, без необходимости писать и поддерживать собственные скрипты к API GitHub.
Q: Как получить одобрение на отказ от Jira как источника метрик? A: Представьте это как эксперимент, а не бунт. Запустите метрики на основе Git параллельно с существующими дашбордами Jira на четыре недели, а затем сравните, какие цифры привели к реальным изменениям. Если метрики Git окажутся более actionable (а по нашему опыту, они таковы), аргумент сформируется сам.
Q: В чём разница между метриками процесса и метриками производительности? A: Метрики процесса (story points, скорость, burndown) измеряют, насколько последовательно команда следует рабочему процессу. Метрики производительности (время цикла, частота деплоев, пропускная способность ревью) измеряют, что команда реально выпускает и как быстро. Небольшие команды почти всегда получают больше сигналов от вторых, потому что метрики производительности выводятся из самой работы, а не из ручных обновлений статусов.