У метрик в разработке странная репутация. Без них легко жить в ощущениях: «вроде делаем много», «вроде кодим хорошо», «вроде стали быстрее». Но стоит начать измерять всё подряд, и процесс быстро превращается в какой-то дневник.

SP, velocity, lead time, cycle time, SLA, количество задач — хорошие инструменты. Проблемы начинаются, когда их используют не чтобы разобраться, а чтобы найти, кому выдать условную двойку.

Метрика должна помогать принять решение

Я не очень верю в метрики «на всякий случай». Если мы что-то считаем, хорошо бы понимать, зачем.

Смотрим lead time — хотим понять, где задача теряет время. Смотрим SLA — проверяем реакцию на проблемы. Смотрим баги после релиза — ищем, где проседает качество.

Если после графика не появляется решения, значит, он просто украшает дашборд.

Velocity — не градусник эффективности

Velocity часто пытаются использовать как главный показатель работы команды: сделали 40 SP — молодцы, сделали 25 — надо ускоряться. Но SP — это оценка сложности внутри конкретной команды.

Если давить через velocity, люди быстро научатся не работать лучше, а оценивать крупнее. Вчера задача была на 3 SP, сегодня уже на 5. График вырос, реальность тихо отошла покурить. Velocity полезна для планирования. Но как KPI она быстро превращается в театр.

Количество закрытых задач тоже обманывает

Можно закрыть десять мелких задач и почти не сдвинуть продукт. А можно закрыть одну неприятную проблему, которая месяц мешала релизам.

По цифрам первый вариант выглядит бодрее. По пользе — не факт. Если оценивать людей только по количеству закрытых тикетов, команда поймёт правила игры: берём простое, короткое и безопасное. Сложное пусть лежит, оно портит статистику.

Время прохождения задачи честнее

Из всех метрик мне больше нравятся те, которые показывают движение задачи. Lead time помогает увидеть путь от появления задачи до результата. Cycle time — сколько она реально была в работе.

Тут появляются вопросы: почему задачи ждут ревью по три дня? Почему после разработки всё застревает на тестировании? Почему задача неделю висит «почти готовой»?

SLA полезен, если не играть в зелёный цвет

SLA хорошо работает там, где есть понятные ожидания: инциденты, обращения бизнеса, поддержка.

Но и его легко испортить. Например, команда отвечает вовремя, но проблему не решает. Или закрывает обращение, чтобы не портить показатель, а потом заводит новое. Формально всё зелёное, а по факту проблема клиента не решена.

Когда начинается театр

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

Руководитель видит зелёный дашборд и получает ощущение контроля. Команда показывает прогресс. Все роли сыграны.

А потом сроки всё равно едут, качество проседает, задачи застревают, и никто не может объяснить, что происходит.

Как я бы смотрела на метрики

Я бы не делала из них систему наказаний. Метрики нужны, чтобы раньше замечать проблемы.

Упала velocity — что изменилось в задачах, составе команды или процессе? Вырос cycle time — где задача теряет время? Стало больше багов — мы плохо описываем требования, слабо ревьюим или торопимся на релиз? Нарушаем SLA — не хватает людей, приоритизации или нормального процесса реакции?

Хорошая метрика не даёт готовый ответ. Она помогает задать правильный вопрос. И самое неприятное — иногда вместо того, чтобы чинить процесс, начинают менять разработчиков. Не потому что новые сотрудники делают больше или качественнее, а потому что они лучше умеют жить внутри этой системы: правильно дробить задачи, красиво закрывать статусы, вовремя подсвечивать «успехи» и не портить графики. В итоге компания теряет сильных специалистов, которые пытались говорить о реальных проблемах, и оставляет тех, кто научился рисовать зелёную картинку. Объём работы тот же, качество спорное, зато дашборд выглядит спокойнее.