10 инженерных метрик, которые должен отслеживать каждый менеджер в 2026 году
Отчёт McKinsey о продуктивности разработчиков (2023) показал, что инженеры тратят лишь 25–30% времени на написание кода. Остальное исчезает в митингах, переключении контекста и ожидании. Если вы Engineering Manager и полагаетесь на интуицию — вы не видите, куда уходит 70% мощности вашей команды.
Вот 10 метрик, которые заточат ваши решения. Без воды и совета «отслеживайте всё» — только то, что отличает управление на основе данных от гадания.
1. Activity Time (фактические часы кодинга)
Что это: Реальное время активного написания кода в IDE, измеренное через heartbeat-сигналы редактора — не самоотчёт, не на основе календаря.
Почему это важно: Большинство менеджеров понятия не имеют, сколько их команда реально пишет код. Наши данные по B2B-инженерным командам показывают, что медиана — 78 минут в день. Это согласуется с выводами McKinsey о том, что разработчики тратят менее трети времени на кодирование — остальное уходит на митинги, коммуникацию и процессный оверхед.
Как использовать:
- Не используйте для ранжирования разработчиков (разработчик с 30 мин/день может заниматься архитектурной работой)
- Используйте для обнаружения аномалий — если обычно активный разработчик снижается до 10 мин/день на неделю, что-то не так
- Отслеживайте средний показатель по команде во времени, а не индивидуальные цифры
Бенчмарк: 1-2 часа/день чистого кодинга — это норма для разработчика, который также делает ревью, участвует в митингах и планировании.
Страница сотрудника PanDev Metrics — Activity Time (198ч) и Focus Time (63%) одним взглядом.
2. Focus Time
Что это: Непрерывные блоки времени кодинга — длительные сессии работы без переключения контекста между проектами и без длинных пауз.
Почему это важно: Исследование Cal Newport в Deep Work утверждает, что большинство специалистов способны поддерживать максимум 4 часа глубоко сфокусированной творческой работы в день. Для разработчиков даже этот потолок труднодостижим. Исследование Gloria Mark из UC Irvine показало, что для повторной фокусировки после одного прерывания требуется в среднем 23 минуты. Разработчик с двумя 90-минутными фокус-блоками намного продуктивнее, чем тот, у кого шесть 30-минутных фрагментов, разбросанных между митингами.
Как использовать:
- Проведите аудит расписания митингов команды — не разрушаете ли вы их фокус-блоки?
- Стремитесь к хотя бы одному 2-часовому непрерывному блоку на разработчика в день
- Сравнивайте Focus Time по дням — если по средам фокус-блоков ноль, проверьте календарь митингов
Бенчмарк: Если у ваших разработчиков менее 1 часа непрерывного фокуса в день, проблема — в культуре митингов.
3. Lead Time for Changes (с разбивкой по стадиям)
Что это: Время от первого коммита до деплоя в продакшен, разбитое на стадии: Coding → Pickup → Review → Deploy.
Почему это важно: Это самая действенная DORA-метрика. Но только если разбить её на стадии.
Как использовать:
- Стадия Coding слишком длинная? Задачи слишком большие. Разбейте на меньшие PR.
- Стадия Pickup слишком длинная? PR лежат без ревью. Установите командную норму «ревью в течение 4 часов».
- Стадия Review слишком длинная? Слишком много раундов ревью. Создайте чеклист PR для уменьшения переписки.
- Стадия Deploy слишком длинная? CI/CD-пайплайн нуждается в оптимизации. Поговорите с DevOps.
Бенчмарк (Elite-команды): Общий Lead Time менее 1 дня. Pickup time менее 4 часов.
4. Deployment Frequency
Что это: Как часто команда отгружает код в продакшен.
Почему это важно: Частые деплои = меньшие изменения = ниже риск = быстрее обратная связь. Команды, деплоящие ежедневно, находят баги за часы. Команды, деплоящие ежемесячно, находят баги... через месяц.
Как использовать:
- Отслеживайте тренд, а не абсолютное число
- Если частота снижается, спросите почему — это сложная фича или процесс тормозит?
- Установите командную цель (например, «не менее 3 деплоев в неделю»)
Бенчмарк: Высокопроизводительные команды деплоят от ежедневно до еженедельно.
5. Change Failure Rate
Что это: Процент деплоев, вызывающих инциденты в продакшене (требующие хотфикса, отката или патча).
Почему это важно: Эта метрика держит Deployment Frequency «в честности». 10 деплоев в день ничего не значат, если 4 из них что-то ломают.
Как использовать:
- Отслеживайте вместе с Deployment Frequency — они должны улучшаться вместе
- Если failure rate растёт, проанализируйте изменения — новые члены команды? Меньше тестов? Сжатые сроки?
- 0% failure rate подозрителен, а не впечатляет. Обычно это значит недостаточный мониторинг.
Бенчмарк: 5-10% — здоровый показатель. Ниже 5% — элитный уровень. Выше 15% — тревожный сигнал.
6. Planning Accuracy
Что это: Насколько оценки команды близки к реальному времени выполнения. Отношение запланированных усилий к фактическим.
Почему это важно: Неточное планирование создаёт каскад: сорванные дедлайны → урезание скоупа → недовольные стейкхолдеры → давление → ещё больше сорванных дедлайнов. Разорвать этот цикл начинается с измерения.
Как использовать:
- Обсуждайте на каждой ретроспективе
- Отслеживайте, какие типы задач стабильно недооцениваются (обычно: интеграции, миграции, «небольшие» рефакторинги)
- Используйте исторические данные для калибровки будущих оценок — «задачи такого типа обычно занимают в 1,5 раза больше нашей оценки»
Бенчмарк: Planning Accuracy 70-80% — хороший показатель. Ниже 50% означает, что процесс оценки сломан.
7. Delivery Index
Что это: Метрика скорости разработки, измеряющая темп без привязки к строкам кода — с учётом сложности, коммитов и пропускной способности доставки.
Почему это важно: Строки кода — ужасная метрика (удаление кода бывает ценнее, чем его написание). Delivery Index даёт сигнал скорости, который действительно коррелирует с результатом.
Как использовать:
- Отслеживайте еженедельные тренды по команде
- Сравнивайте команду с её собственной исторической базой, а не с другими командами
- Снижение Delivery Index при стабильном Activity Time указывает на растущую сложность или техдолг
8. MTTR (Mean Time to Restore)
Что это: Среднее время от инцидента в продакшене до полного восстановления.
Почему это важно: Невозможно предотвратить все инциденты. Но можно восстанавливаться быстро. MTTR в 30 минут означает, что инцидент — это мелочь. MTTR в 3 дня означает кризис.
Как использовать:
- Проводите post-mortem инцидентов и отслеживайте MTTR для каждого
- Инвестируйте в обнаружение (быстрые алерты) и восстановление (feature flags, автоматизация отката)
- Установите командную цель по MTTR и пересматривайте ежемесячно
Бенчмарк: Элитные команды восстанавливаются менее чем за 1 час. Если ваш MTTR больше 1 дня — приоритизируйте observability и механизмы отката.
9. Cost per Project
Что это: Реальная инженерная стоимость каждого проекта, рассчитанная из времени разработчиков (отслеживаемого через IDE), умноженного на часовые ставки.
Почему это важно: Когда CEO спрашивает «сколько нам стоила Фича X?», большинство инженерных лидеров не могут ответить. Эта метрика позволяет отвечать реальными числами.
Как использовать:
- Уверенно отчитывайтесь руководству — «Проект Alpha стоил $45 000 инженерного времени за 6 недель»
- Сравнивайте стоимость проектов, чтобы понять, куда уходят инженерные инвестиции
- Используйте для бюджетирования — исторические данные о стоимости делают будущие оценки точнее
Почему большинство компаний это не отслеживают: Потому что нужно объединить трекинг времени и финансовые данные. PanDev Metrics делает это автоматически через IDE heartbeats + настраиваемые часовые ставки.
10. Team Productivity Trend (30-дневный)
Что это: Скользящий 30-дневный обзор совокупного показателя продуктивности команды — с учётом активности, Focus Time, Delivery Index и других факторов.
Почему это важно: Точечные метрики зашумлены. Тренды рассказывают историю. Команда с нисходящим трендом на протяжении 4 недель требует внимания. Команда с восходящим трендом делает что-то правильно — выясните что.
Как использовать:
- Просматривайте на еженедельном командном синке
- Соотносите провалы с событиями (праздники, реорганизации, дежурства, кранчи)
- Используйте для раннего обнаружения выгорания — постепенное снижение на протяжении недель часто сигнализирует о перегрузке до того, как разработчик сам об этом скажет
Дашборд команды PanDev Metrics — все ключевые метрики в одном виде: активность, онлайн-статус, таймлайн событий и список команды.
Анти-метрики: что НЕ стоит отслеживать
| Метрика | Почему вредна |
|---|---|
| Строки кода | Стимулирует раздутый код. Удаление кода зачастую ценнее. |
| Коммиты в день | Стимулирует бессмысленные микрокоммиты. |
| Часы в офисе/онлайне | Измеряет присутствие, а не продуктивность. |
| Индивидуальные рейтинги | Создают конкуренцию вместо коллаборации. |
| Velocity по story points | Легко накручивается, сильно варьируется между командами, бессмысленна для сравнения. SPACE-фреймворк (Forsgren et al., 2021) прямо предостерегает от использования одиночных метрик активности для оценки индивидов. |
Формирование дашборда
Начните с трёх метрик. Добавляйте новые только когда начнёте действовать по этим:
Уровень 1 (начните отсюда):
- Activity Time (среднее по команде)
- Lead Time с разбивкой по стадиям
- Deployment Frequency
Уровень 2 (добавьте через месяц): 4. Focus Time 5. Change Failure Rate 6. Planning Accuracy
Уровень 3 (добавьте через 3 месяца): 7. Cost per Project 8. Delivery Index 9. MTTR 10. Team Productivity Trend
Бенчмарки основаны на DORA State of DevOps Reports (Google Cloud, 2019–2023), SPACE-фреймворке (Forsgren et al., ACM Queue, 2021), отчёте McKinsey о продуктивности разработчиков (2023) и данных платформы PanDev Metrics по B2B-инженерным организациям.
Отслеживайте все 10 метрик на одной платформе. PanDev Metrics подключается к вашей IDE, Git-провайдеру и таск-трекеру — давая полную картину в одном дашборде. Бесплатный старт.