Антипаттерны в разработке

С метриками разработки легко переборщить.

Пока метрика помогает увидеть проблему — она полезна. Как только метрика становится целью — команда начинает оптимизировать уже не систему, а цифру.

Когда метрика становится целью, она перестаёт быть хорошей метрикой. ❌ Антипаттерн 1. Оценивать разработчиков по системным метрикам

Lead Time, MTTR, Deployment Frequency, Change Failure Rate показывают, как работает система доставки изменений.

Но не то, насколько хорош конкретный разработчик.

Пример: разработчик закончил задачу за день, потом она: 2 дня ждала review; 3 дня ждала стенд; ещё день — релиз. Lead Time плохой.

Но проблема точно не в разработчике.

Командные метрики — для улучшения системы, а не для рейтинга людей. ❌ Антипаттерн 2. Измерять всё подряд

Можно сделать dashboard из 50 графиков. Lead Time. Cycle Time. PR Time. Bugs. Commits. Velocity.

Красиво.

Только непонятно, что исправлять.

Лучше начать с вопроса:

Почему фича едет до прода три недели?

Разложили путь: разработка — 2 дня review — 1 день тестирование — 8 дней релиз — 1 день Проблема уже видна. Не нужно «повышать эффективность разработки».

Нужно понять, почему 8 дней задача проводит в тестировании.

❌ Антипаттерн 3. Локально улучшить — глобально ухудшить

Разработка ускорилась. QA добавил ещё проверок. Архитектура добавила согласования. ИБ добавила ещё один gate. Каждый улучшил свой участок. А общий Lead Time вырос.

Если разработка стала быстрее на 20%, но задача потом неделю лежит в очереди — для бизнеса ничего не изменилось.

Смотреть нужно на весь поток: от идеи до результата. ❌ Антипаттерн 4. KPI ради KPI

Хотим больше релизов — дробим изменения.

Хотим меньше багов — перестаём брать сложные задачи.

Хотим больше story points — story points внезапно становится больше. Цифры растут.

Система — не обязательно. ✅ Хороший паттерн

Сначала проблема. Потом гипотеза. Потом метрика. Потом изменение. И только после этого проверяем, стало ли лучше.

DORA, SPACE, Developer Experience — просто разные инструменты. Один показывает delivery.

Другой — состояние команды.

Третий — насколько удобно разработчику вообще работать. Иногда вместо найма ещё пяти человек достаточно:

ускорить build; убрать лишнее согласование; сделать нормальную DEV-среду; сократить ожидание доступов.

Метрика — не цель. И не способ найти виноватого.

Это просто фонарик.

Подсветили слабое место, исправили и пошли дальше.