Рано или поздно каждому руководителю разработки задают один и тот же вопрос со стороны вышестоящих: «Насколько продуктивна команда?» И любой честный ответ начинается с внутреннего вздрагивания, потому что большинство доступных под рукой чисел — не те. Строки кода, коммиты в день, сожжённые story points, залогированные часы — их легко нанести на график и легко подделать, и в тот момент, когда команда узнаёт, что её оценивают по одному из них, это число перестаёт что-либо значить.
Проблема не в измерении. Проблема в том, что мы измеряем суету вместо поставки. Команда может быть отчаянно занята — коммиты летят, стендапы заполнены, все загружены на 100% — и при этом не выпускать ничего значимого. У метрик, которые выдерживают столкновение с реальной командой, есть одно общее свойство: они описывают систему, а не отдельного человека, и их трудно улучшить, не улучшив саму работу.
Вот короткий список того, что стоит вынести на дашборд, более длинный список того, что стоит удалить, и как читать и то, и другое, не превращая команду в мастеров накрутки чисел.
Четыре, которые действительно что-то значат
Эти четыре тесно перекликаются с проверенными исследованиями DORA и flow, но чтобы их обосновать, вам не нужен фреймворк. Каждая отвечает на вопрос, который реально волнует стейкхолдера, и каждую по-настоящему трудно накрутить.
- Cycle time (время цикла) — сколько времени задача проходит путь от «начата» до «сделана». Не от создания (это включает загнивание бэклога, которое вы не контролируете), а с момента, когда кто-то берёт её в работу. Это единственное самое полезное число, за которым может следить инженерная команда. Оно растёт, когда работа слишком крупная, когда застревают передачи или когда ревью простаивают. Именно эта метрика показывает, где течёт ваш процесс.
- Deployment frequency (частота деплоев) — как часто вы выкатываете в продакшн. У команды, которая релизит ежедневно, принципиально иные петли обратной связи, чем у той, что релизит раз в месяц, независимо от численности. Рост частоты почти всегда означает, что размеры партий уменьшились, а уверенность выросла.
- Change failure rate (доля неудачных изменений) — какая доля деплоев приводит к инциденту, откату или хотфиксу. Это противовес частоте. Быстро релизить бессмысленно, если половина ломается. Наблюдаемые вместе, эти две метрики не дают накрутить ни одну из них.
- Throughput (пропускная способность) — количество завершённых задач в неделю. Намеренно считайте штуки, а не поинты. Поинты провоцируют театр оценивания; сырой подсчёт завершённой работы труднее раздуть, и, усреднённый за несколько недель, он даёт стабильный вход для планирования.
Обратите внимание, чего здесь нет: ничего, что измеряется на человека. Все четыре — уровня команды, и в этом весь смысл. В тот момент, когда вы ранжируете людей по любой из них, вы научили самых умных инженеров оптимизировать метрику вместо продукта.
Пять, от которых стоит отказаться уже сегодня
| Метрика | Почему кажется полезной | Почему бьёт по команде |
|---|---|---|
| Строки кода | «Выхлоп», виден в каждом диффе | Больше кода — это издержка, а не победа; поощряет раздувание, наказывает удаление |
| Коммиты в день | Легко вытащить из git | Поощряет дробление коммитов; ничего не говорит о поставленной ценности |
| Завершённые story points | Ощущается как velocity | Поинты относительны и раздуваемы; команды тихо переопределяют базу |
| Залогированные часы / загрузка | Соответствует «усилиям» | 100% загрузка гарантирует нулевой запас — очереди взрываются |
| Индивидуальный счёт тикетов | «Кто тянет воз» | Наказывает сеньора, который разблокировал четырёх человек вместо закрытия тикетов |
Метрика загрузки заслуживает отдельного упоминания, потому что она самая соблазнительная. Кажется очевидным, что полностью занятая команда — это эффективная команда. На практике система, работающая на 100% мощности, не имеет запаса, чтобы поглощать разброс, поэтому каждая неожиданность превращается в очередь — и cycle time раздувается. По той же логике работают WIP-лимиты: ограничение параллельной работы часто быстрее, чем выжимание её на максимум. Мы писали об этом компромиссе в статье WIP-лимиты, которые действительно работают, и это тот же урок в другой шляпе.
Читайте тренд, а не число
Cycle time одной недели не говорит вам почти ничего. Сигнал всегда в форме кривой во времени.
- Растущий cycle time при неизменном throughput означает, что работа застревает, а не становится мельче. Ищите столбец-бутылочное горлышко на доске — обычно это ревью или QA.
- Всплеск change failure rate после скачка частоты означает, что вы стали релизить быстрее, чем смогла растянуться ваша страховочная сетка. Притормозите или вложитесь в тесты, прежде чем поднимать частоту дальше.
- Throughput, который дико скачет от недели к неделе, обычно означает непоследовательное дробление работы, а не непоследовательную команду. Разбивайте крупные задачи.
Именно для этого нужны burndown (диаграмма сгорания), velocity (скорость команды) и диаграммы кумулятивного потока, и именно поэтому Отчёты в your.team по умолчанию рисуют их как тренды, а не как заголовочные баллы. Диаграмма кумулятивного потока делает растущую очередь визуально очевидной — полоса «в работе» толстеет ещё до того, как cycle time покажет это в таблице. Вы ловите застой на неделю раньше.
Сделайте метрику побочным продуктом, а не задачей
Быстрее всего отравить метрику — заставить людей вводить данные специально ради неё. Если отслеживание cycle time означает, что инженеры должны помнить переместить карточку и залогировать таймстамп, данные будут запоздалыми, неверными и вызывающими раздражение. Хорошие метрики выпадают из работы, которую люди и так делали.
В этом весь замысел того, чтобы держать учёт ориентированным на клавиатуру и в контексте. Когда перемещение задачи по доске — это одно нажатие клавиши внутри инструмента, в котором вы уже живёте, таймстампы точны, потому что о них никому не пришлось думать. То же и с данными спринта: если планирование спринта и его исполнение происходят в одном месте, velocity и burndown вычисляются из реального состояния, а не из статус-митинга, который кто-то потом законспектировал.
Быстрая проверка на вменяемость для любой метрики, которую вы рассматриваете: может ли команда улучшить это число, не улучшив продукт? Если да — как со строками кода, коммитами или залогированными часами — откажитесь от неё. Если единственный способ сдвинуть число — по-настоящему релизить лучше и быстрее, оставьте.
Дашборд, который не стыдно показать наверх
Когда этот вопрос приходит сверху, сдержите желание построить дашборд из двенадцати виджетов. Честно на него отвечают четыре графика:
- Cycle time в тренде за последние 8–12 недель
- Deployment frequency, то же окно
- Change failure rate, то же окно
- Throughput в неделю, сырым подсчётом
Этого достаточно, чтобы рассказать правдивую историю: становимся ли мы быстрее, остаёмся ли стабильными и держится ли объём. Это устойчиво к накрутке, никого не выделяет и указывает на процесс, когда что-то не так — а именно там почти всегда и живёт исправление. Всё остальное — украшательство, а украшательство — это место, где умирает доверие.
Продуктивность никогда не была настоящим вопросом. Настоящим вопросом была предсказуемая, устойчивая поставка. Измеряйте её — и разговор «насколько мы продуктивны» станет намного короче и намного честнее.
Хотите графики burndown, velocity и кумулятивного потока, которые читаются как тренды, а не как табло? Посмотрите, что умеют Отчёты, изучите тарифы и начните бесплатно — ваши первые четыре метрики в одном нажатии клавиши.
