Цель и метрика успеха: как записать «зачем», чтобы на приёмке было с чем сравнить

Функция выпущена и работает. Помогает ли она — не знает никто: цель записали словами «чтобы было удобнее», а замерить, как было до релиза, никто не успел.

В пользовательской истории три части: кто, что и зачем. Третью опускают чаще всего, а когда пишут, пишут так, что проверить её нельзя: «чтобы было удобнее», «чтобы повысить лояльность». Через месяц после релиза никто не может сказать, удалась ли задача. Функция работает — значит, удалась. Но работает она или помогает — разные вопросы.

Цель, задача и метрика

Три понятия, которые в постановках обычно слиты в одно.

Цель — изменение в мире, ради которого всё делается: покупатели реже звонят в поддержку с вопросом «где мой заказ».
Задача — средство: уведомлять покупателя о смене статуса заказа.
Метрика — число, по которому видно, достигнута ли цель: доля обращений «где мой заказ» от числа заказов.

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

Как записать цель, чтобы было с чем сравнить

Цель        покупатели реже спрашивают поддержку, где их заказ
Метрика     обращения «где мой заказ» / заказы за неделю
Сейчас      6 % (замер за 4 недели до релиза)
Ожидаем     не больше 3 % через 4 недели после релиза
Не должно   доля отписок от уведомлений — не выше 2 %
ухудшиться
Кто смотрит владелец процесса, на разборе через месяц

Строка «сейчас» важнее, чем кажется. Исходное значение нужно замерить до релиза: после него сравнивать будет не с чем, а восстановить прошлое по памяти не получится. Если замерить нечем — это тоже находка: в задачу добавляется требование собирать это число.

Метрики, которые обманывают

Ловушка	Пример	Чем заменить
Число нажатий на новую функцию	«Уведомление открыли 10 000 раз»	Изменение в том, ради чего функция делалась
Метрика, которая движется сама	Звонков меньше — но наступил низкий сезон	Доля, а не абсолютное число; сравнение с тем же периодом
Слишком далёкая метрика	«Вырастет выручка»	Ближайшее измеримое следствие задачи
Одна метрика без противовеса	Обращений меньше, потому что номер поддержки спрятали	Метрика «не должно ухудшиться» рядом с целевой

Противовес обязателен. Любую метрику можно улучшить ценой чего-то другого. Вторая строка — что не должно ухудшиться — защищает от решения, которое выполняет цель на бумаге и вредит на деле.

Что делать, если метрика не сдвинулась

Не сдвинувшаяся метрика — не провал, а информация: гипотеза о связи задачи и цели не подтвердилась. Плохо не это, а то, что обычно никто не заметит — смотреть было некому. Поэтому в постановке полезно заранее записать два решения:

когда смотрим — конкретная дата или число дней после релиза;
что делаем, если не сдвинулось — разбираем причину, пробуем другое средство, откатываем.

Решение, принятое до релиза, принимается спокойно. После релиза к функции привыкают, и отказаться от неё становится труднее, даже если она не работает на цель.

Когда метрика не нужна

Не у каждой задачи есть число. Исправление дефекта, требование закона, обновление библиотеки — у них цель очевидна и проверяется фактом. Метрика нужна там, где задача — гипотеза: «если сделаем X, станет лучше Y». Таких задач меньше половины, но именно они дороже всего обходятся, когда не работают.

Признак, что цели не было: через полгода функцию нельзя убрать, потому что непонятно, нужна ли она кому-нибудь.

Проверка за десять минут

Возьмите три задачи текущего спринта, которые что-то меняют для пользователя. Для каждой попробуйте назвать число, которое должно измениться, и его текущее значение. Задачи, где числа нет, — либо очевидные, либо гипотезы, которые никто не проверит.

Что дальше

Цель — верхнее звено цепочки, которая идёт от зачем к что, от что к коду и от кода к проверке. Чтобы эта цепочка не рвалась на стыках, её звенья нужно связать между собой. Это предмет трассировки.