Delivery Index: как измерить скорость разработки без строк кода
Фред Брукс предупреждал в Мифическом человеко-месяце (1975), что измерять продуктивность программистов объёмом кода — ловушка: больше кода не значит больше ценности. Пятьдесят лет спустя некоторые организации всё ещё приравнивают написанные строки к выполненной работе. Фреймворк SPACE (Forsgren et al., 2021) прямо предостерегает от одномерных метрик активности — и всё же потребность, которую они адресуют, реальна: как понять, что ваша инженерная команда доставляет результат?
Ответ — не очередная vanity-метрика. Это составной сигнал, который мы называем Delivery Index.
Почему строки кода не работают
Строки кода (LoC) как метрика продуктивности критиковались десятилетиями, и не зря. Начнём с очевидных проблем:
| Сценарий | Строки кода | Реальная ценность |
|---|---|---|
| Разработчик рефакторит 3 000 строк в 800 | −2 200 | Высокая — проще, быстрее, меньше багов |
| Джуниор копирует ответ со Stack Overflow | +500 | Низкая — без тестов, плохо интегрировано |
| Сениор проектирует чистый API | +120 | Очень высокая — даёт возможность работать 5 другим разработчикам |
| Разработчик добавляет логирование повсюду | +2 000 | Низкая — шум, влияние на производительность |
LoC наказывает хорошую инженерию. Сениор, потративший неделю на элегантное решение в 200 строк, выглядит «менее продуктивным», чем джуниор, написавший 2 000 строк спагетти-кода. Метрика вознаграждает многословность, а не ценность.
Но более глубокая проблема — искажение стимулов
Когда вы измеряете LoC, разработчики пишут больше кода. Они копипастят вместо абстракции. Избегают рефакторинга, потому что он снижает их «баллы». Добавляют ненужную сложность. Метрика не просто не измеряет продуктивность — она активно ухудшает вашу кодовую базу.
Биллу Гейтсу приписывают слова: «Измерять продуктивность софта строками кода — всё равно что измерять прогресс самолёта его весом». Сказал ли он это на самом деле — спорно. Правда ли это — нет.
Что на самом деле нужно VP of Engineering
Когда VP of Engineering спрашивает «мы доставляем?», он задаёт сразу несколько вопросов:
- Разработчики активно работают над правильными задачами? (Активность)
- Задачи и фичи действительно завершаются? (Пропускная способность)
- Темп устойчив и стабилен? (Стабильность)
- Оценки улучшаются со временем? (Предсказуемость)
Ни одна метрика не отвечает на все четыре вопроса. Именно поэтому мы создали Delivery Index как составную метрику, учитывающую множество сигналов.
Как работает Delivery Index
Delivery Index в PanDev Metrics рассчитывается на основе нескольких взвешенных компонентов:
| Компонент | Что измеряет | Почему важен |
|---|---|---|
| Activity Time | Часы активного кодирования в IDE | Показывает вложенные усилия — разработчик действительно кодит? |
| Focus Time | Устойчивые непрерывные сессии | Качество усилий — фрагментированная vs. глубокая работа |
| Task velocity | Задачи, завершённые за период | Сигнал результата — дела движутся? |
| Consistency score | Разброс в ежедневной/еженедельной выработке | Устойчивость — стабильный темп vs. цикл бум-спад |
| Planning accuracy delta | Оценочные vs. фактические сроки выполнения | Предсказуемость — команда может надёжно прогнозировать? |
Delivery Index даёт нормализованный балл, учитывающий реалии разработки ПО: некоторые недели — интенсивное кодирование, другие — архитектура и планирование. Здоровый Delivery Index не требует максимального кодирования каждый день — он требует стабильной, предсказуемой поставки.
Математика простым языком
Думайте о Delivery Index как о кредитном рейтинге. Ни один фактор не определяет его единолично. Разработчик, кодящий 4 часа в день, но никогда не завершающий задачи, имеет посредственный Delivery Index. Разработчик, кодящий 1 час в день, но стабильно выпускающий фичи в срок, получает высокий балл. Метрика вознаграждает завершённую работу, поставленную предсказуемо, а не сырую активность.
Что показывают наши данные о скорости
Анализируя данные B2B-инженерных команд, использующих PanDev Metrics, мы видим чёткие паттерны здоровой поставки — паттерны, которые согласуются с выводами McKinsey (2023) о том, что разработчики тратят лишь 25–30% времени на написание кода:
Время кодирования — не то узкое место, которое вы думаете
Медианный разработчик в нашем датасете кодит 78 минут в день. Среднее — 111 минут. Это значит, что «типичный» разработчик проводит примерно 1,5 часа в активном кодировании.
| Диапазон времени кодирования | % разработчиков | Ср. Delivery Index |
|---|---|---|
| < 30 мин/день | 12% | Низкий — часто заблокирован или на слишком многих митингах |
| 30–60 мин/день | 21% | Средний — типично для senior-ролей с обязанностями по ревью |
| 60–120 мин/день | 32% | Высокий — оптимальная зона для большинства IC-ролей |
| 120–180 мин/день | 9% | Высокий — сильные индивидуальные контрибьюторы |
| 180+ мин/день | 27% | Разный — иногда высокая скорость, иногда сигнал выгорания |
Оптимальная зона — 60–120 минут кодирования в день с высоким Delivery Index. Разработчики в этом диапазоне кодят эффективно, завершают задачи в срок и поддерживают устойчивый темп. Превышение 180 минут в день не коррелирует стабильно с лучшей поставкой — в некоторых случаях это сигнал метания или переделок.
IDE и скорость
Наши данные показывают интересные паттерны по трём доминирующим IDE:
| IDE | Пользователи | Всего часов | Ср. часов/пользователь |
|---|---|---|---|
| VS Code | 100 | 3 057 | 30,6 |
| IntelliJ IDEA | 26 | 2 229 | 85,7 |
| Cursor | 24 | 1 213 | 50,5 |
Пользователи IntelliJ показывают больше средних часов на пользователя — вероятно потому, что Java (наш язык №1 с 2 107 часами) преимущественно разрабатывается в IntelliJ, а Java-проекты требуют больше набора из-за многословности языка. Именно поэтому LoC не работает: Java-разработчик, написавший 200 строк, сделал меньше «работы», чем Python-разработчик, написавший 50 строк эквивалентной логики.
Пять антипаттернов, убивающих поставку
Когда Delivery Index падает по всей команде, обычно причина — один из этих паттернов:
1. Смертельная спираль оценок
Команда систематически недооценивает задачи → срывает дедлайны → менеджеры добавляют буфер → оценки становятся бессмысленно большими → Planning Accuracy падает → никто не доверяет дорожной карте.
Сигнал Delivery Index: Компонент Planning Accuracy падает ниже 50%, Task velocity остаётся на месте или снижается.
2. Налог на митинги
Разработчик с 4 часами митингов имеет, в лучшем случае, 4 часа фрагментированного времени. С учётом накладных расходов на переключение контекста это даёт примерно 45 минут реального Focus Time.
Сигнал Delivery Index: Activity Time падает, а количество назначенных задач остаётся прежним. Разработчик «занят», но не кодит.
3. Зависимость от героя
Один сениор-разработчик — бутылочное горлышко для всех код-ревью, архитектурных решений и сессий отладки. Его Delivery Index может выглядеть нормально, но агрегированный показатель команды падает, потому что все ждут его.
Сигнал Delivery Index: Один разработчик показывает высокий Activity Time с низким Task velocity (помогает другим, а не выпускает свою работу). Delivery Index на уровне команды снижается несмотря на индивидуальные усилия.
4. Тихий убийца — расползание скоупа
Задачи растут после оценки. «Фича на 2 дня» превращается в «эпик на 2 недели» через накопленные изменения. Работа выполняется, но не соответствует плану.
Сигнал Delivery Index: Task velocity резко падает, а время кодирования остаётся прежним или растёт. Разработчики усердно работают над задачами, которые никогда не закрываются.
5. Лавина технического долга
Кодовая база настолько хрупкая, что каждая новая фича требует предварительного исправления трёх вещей. Разработка кажется медленной не потому, что разработчики медленные, а потому что среда сопротивляется изменениям.
Сигнал Delivery Index: Высокий Activity Time, высокий Focus Time, низкий Task velocity. Разработчики кодят интенсивно, но прогресс минимален — явный признак трения с кодовой базой.
Как внедрить Delivery Index в вашей организации
Шаг 1: Установите базовую линию (Неделя 1–2)
Разверните отслеживание IDE по всей команде. PanDev Metrics поддерживает VS Code, все IDE JetBrains, Cursor, Visual Studio и другие. Дайте данным накопиться хотя бы за два полных спринта, прежде чем делать выводы.
Шаг 2: Определите паттерны, а не выбросы (Неделя 3–4)
Сначала смотрите на тренды на уровне команды:
| На что обращать внимание | Здоровый сигнал | Тревожный сигнал |
|---|---|---|
| Распределение ежедневного времени кодирования | Медиана 60–120 мин | Бимодальное (< 30 или > 240) |
| Стабильность день ото дня | Низкий разброс | Циклы бум-спад |
| Тренд завершения задач | Стабильный или улучшающийся | Снижение неделя за неделей |
| Точность оценок | В пределах ±30% | Стабильно ошибка в 2x+ |
Шаг 3: Устраните системные проблемы (Месяц 2)
Используйте данные для структурных изменений: снижение нагрузки митингами, перебалансировка работы по команде, декомпозиция крупных задач или выделение времени на сокращение технического долга.
Шаг 4: Отслеживайте улучшения (Постоянно)
Delivery Index должен расти по мере устранения трения. Если нет — вы решаете не те проблемы.
Delivery Index vs. DORA Metrics
DORA Metrics (Deployment Frequency, Lead Time, Change Failure Rate, Mean Time to Recovery) измеряют конвейер поставки. Delivery Index измеряет процесс разработки, который питает этот конвейер.
| Измерение | DORA | Delivery Index |
|---|---|---|
| Что измеряет | Здоровье CI/CD-конвейера | Рабочие паттерны разработчиков и команды |
| Гранулярность | Уровень команды/сервиса | Индивидуальный + командный уровень |
| Опережающий/запаздывающий | В основном запаздывающий (измеряет результат) | Опережающий (измеряет условия для результата) |
| Источник данных | Git, CI/CD-системы | Активность IDE, управление задачами |
| Лучше всего для | Зрелости DevOps | Управления инженерами |
Они дополняют друг друга. DORA говорит, как быстро ваш конвейер доставляет. Delivery Index говорит, насколько эффективно ваша команда разрабатывает. Плохой Delivery Index в конечном счёте проявится в ухудшении DORA Metrics — но к тому моменту вы уже потеряете недели.
Что сказать совету директоров
VP of Engineering часто нужно переводить инженерные метрики на язык бизнеса. Вот как Delivery Index соотносится с бизнес-результатами:
- Высокий Delivery Index + высокая Planning Accuracy → «Мы доставляем то, что обещали, когда обещали.»
- Высокий Delivery Index + низкая Planning Accuracy → «Мы доставляем хорошо, но наши оценки нуждаются в доработке. Даты дорожной карты имеют неопределённость.»
- Низкий Delivery Index + высокая активность → «Команда работает усердно, но есть структурные блокеры — технический долг, зависимости или процессные накладные расходы.»
- Низкий Delivery Index + низкая активность → «У нас проблема со штатом, вовлечённостью или инструментами.»
Ценность Delivery Index — не в самом числе, а в диалоге, который он делает возможным. Вместо «мы продуктивны?» вы можете спросить «что блокирует поставку?» — и иметь данные для ответа.
На основе агрегированных данных PanDev Metrics Cloud (апрель 2026), тысяч часов активности IDE в B2B-инженерных командах. Все данные анонимизированы и агрегированы. Ссылки: SPACE framework (Forsgren et al., ACM Queue, 2021); Fred Brooks, "The Mythical Man-Month" (1975); отчёт McKinsey о продуктивности разработчиков (2023).
Хотите увидеть Delivery Index вашей команды? PanDev Metrics рассчитывает его автоматически на основе данных IDE и задач — без ручного отслеживания, табелей и догадок.