Бизнес-метрика, а не метрика выпуска

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

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

Выпуск измеряет тебя, бизнес-результат — пользователя

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

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

Как выбрать бизнес-метрику

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

Хорошая метрика проходит три проверки. Привязана к пользователю — описывает его поведение или его результат, а не твой выпуск. Двигается в обозримый срок — иначе по ней нельзя рулить. И её трудно накрутить, не решив проблему по-настоящему: если метрику можно «улучшить» хитростью, не помогая пользователю, она плохая.

Про «обозримый срок» стоит сказать точнее, потому что без ориентиров эта проверка не работает. Срок диктуется не вашим терпением, а двумя вещами: как часто происходит само событие и как быстро человек меняет привычку.

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

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

И признак, что метрика проверку не прошла: вы не можете назвать срок вообще. Это почти всегда значит, что метрика накопительная («всего зарегистрировано») или слишком далёкая от того, что вы делаете. Тогда рядом с ней ставят более быструю, по которой можно рулить, а далёкую оставляют как проверку направления.

Часто полезно держать одну бизнес-метрику как главную и пару страховочных рядом, чтобы не оптимизировать одно за счёт другого. Время до первой продажи можно «улучшить», впуская мусорный каталог, — поэтому рядом смотрят на качество карточек или возвраты. Главная метрика задаёт направление, страховочные не дают срезать угол.

Практически это выглядит так: до того как взяться за задачу, записать одним предложением «Мы поймём, что решили проблему, когда...». Это короткое упражнение часто обнаруживает, что проблема сформулирована размыто — потому что договориться о метрике трудно ровно там, где нет ясности в самой проблеме. Тогда лучше вернуться к формулировке проблемы и уточнить её, а не двигаться дальше с нечёткой метрикой.

Пример: экспорт отчёта

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

Вводная: отдел аналитики в B2B-сервисе каждую пятницу тратит несколько часов на то, чтобы вручную перенести данные из системы в Excel и собрать сводный отчёт для руководства. Продукт-инженер слышит эту боль, понимает проблему и берётся сделать кнопку «Экспортировать в Excel».

Фича готова. Что мерить? Первый порыв — считать нажатия на кнопку. Удобно: событие логируется, данные видны с первого дня. Но нажатие не равно решённой проблеме. Аналитик может нажать, открыть файл, обнаружить неудобный формат дат — и всё равно потратить час на ручную правку. Метрика «кнопка нажата» зафиксировала бы «успех» при провале.

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

Третий вариант — опросить аналитиков через две недели после запуска. Честно, но медленно и ненадёжно: опросы дают самооценку, а не факт. Люди склонны отвечать то, что кажется правильным, а не то, что делают на самом деле.

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

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

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

Через месяц основная метрика показала 63% — двадцать пятниц из тридцати двух. Неплохо, но в остальных двенадцати отчёт всё равно доделывали вручную. Пошли разбираться: оказалось, формат дат в экспорте не совпадал с тем, что ждёт сводная таблица в шаблоне руководства. Правка формата заняла день, и за следующий месяц метрика поднялась до 91% — двадцать девять из тридцати двух. Такой скачок на маленькой базе уже трудно списать на случайность. Без ориентации на бизнес-результат фича считалась бы закрытой после первого деплоя, и причина недовольства осталась бы невидимой.

Обратите внимание на структуру выбора: сначала отвергли удобные метрики (нажатия, скачивания), потом сформулировали прокси-метрику, максимально близкую к реальному поведению, и добавили страховочную. Именно страховочная позволила бы заметить, если бы главная метрика росла за счёт качества отчёта, а не его скорости.

Эту структуру стоит воспроизводить каждый раз: список кандидатов → тест на каждого («можно накрутить, не решив проблему?») → выбор главной → страховочные. Занимает полчаса, экономит месяц работы в никуда.

Ловушки измерения

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

Вторая — мерить то, что удобно для отчёта, а не то, что важно. Выпуск попадает в эту ловушку первым: его легко посчитать, поэтому им и отчитываются. Удобство измерения не должно решать, что измерять.

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

У этого наблюдения есть имя — закон Гудхарта, сформулированный экономистом Чарльзом Гудхартом в семидесятые про экономическую политику и с тех пор подтверждённый везде, где людей меряют числами. Короткая формулировка: как только показатель становится целью, он перестаёт быть хорошим показателем. Знать название полезно не ради ссылки: в разговоре, где просят «поставить цель по метрике», это готовый аргумент за то, чтобы цель ставили по проблеме, а метрику держали как показание прибора.

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

Что это значит на практике

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

• Метрику выбирают после выпуска. Когда фича уже в проде, признать, что она ничего не сдвинула, психологически тяжело — и метрика незаметно подбирается под уже принятое решение. Формулировать её нужно до начала работы, пока ещё нет соблазна подтвердить потраченное время.
• Слишком короткий горизонт. «Посмотрим за первую неделю» для медленно меняющегося поведения даст шум, не сигнал. Нужно заранее договориться, через сколько времени ждать движения и что считается значимым изменением.
• Одна метрика без страховочных. Любую метрику можно оптимизировать в ущерб смежному: скорость регистрации — в ущерб качеству данных, число экспортов — в ущерб тому, использует ли кто-то файл. Одна-две страховочных метрики рядом держат баланс.
• Метрику забывают пересмотреть. Через полгода продукт меняется, поведение пользователей меняется — а метрика остаётся прежней и уже описывает не боль пользователя, а привычку команды отчитываться именно этим числом.
• Путают метрику процесса с бизнес-метрикой. «Скорость разработки выросла» или «деплоев стало больше» — это метрики процесса: они описывают эффективность команды, а не пользу для пользователя. Бизнес-метрика всегда про то, что изменилось на стороне пользователя, а не на стороне разработки.

Бизнес-метрика против метрики процесса

Это различие стоит отдельного разбора, потому что подмена происходит незаметно и потому что метрики процесса — не мусор. Они полезные, просто отвечают на другой вопрос.

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

Бизнес-метрика измеряет, что изменилось у пользователя. Задача стала решаться, шаг исчез, ошибка перестала случаться, человек стал возвращаться.

Различить их можно одним вопросом: кто является подлежащим в формулировке? Если в предложении действует команда или система — это процесс. Если действует пользователь — это бизнес-результат.

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

Где происходит подмена. Три узнаваемых места:

• В отчёте наверх. Метрики процесса приятнее: они всегда двигаются и зависят только от нас. Отчёт, состоящий из них, выглядит убедительно и не говорит ничего о пользе.
• Когда бизнес-метрика не сдвинулась. Соблазн показать вместо неё «зато мы стали быстрее выкатывать». Это честный факт и неверный ответ на заданный вопрос.
• Когда бизнес-метрику нечем измерить. Тогда её тихо заменяют ближайшей доступной, а доступны обычно как раз метрики процесса. Что делать в этом случае — в разделе ниже.

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

Когда мерить нечем

Вся статья исходит из того, что данные есть: папка с отчётами, события, логи. Для одиночки это часто неверно — аналитики нет, доступа к хранилищу нет, продукт внутренний, пользователей десять. Отказываться от измерения в этом случае нельзя, но и притворяться, что есть аналитика, бессмысленно.

Порядок действий — от самого дешёвого.

1. Проверить, что уже есть. Почти всегда есть больше, чем кажется, и это ничего не стоит:

Запрос к базе раз в неделю, записанный в файл, — полноценная метрика. Она не хуже дашборда, просто менее красивая.

2. Поставить два-три события руками. Не аналитическую систему, а именно два-три события вокруг проверяемой гипотезы: «операция начата», «операция завершена», «операция упала». Их достаточно, чтобы ответить на главный вопрос — пользуются ли вообще и доходят ли до конца. Как это делают минимальными средствами, разобрано в статье про выпуск и замер, в разделе про аналитику руками.

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

4. Считать наблюдаемый факт, а не измеряемое число. Метрика не обязана быть числом из системы. Рабочие формы для случая «мерить нечем»:

• Исчезновение действия. «Никто больше не присылает мне таблицу на проверку» — проверяется по переписке, и это результат.
• Отсутствие обращений. «За месяц ни одной жалобы на этот шаг, до выката было восемь» — считается по поддержке.
• Наблюдение за работой. Посмотреть, как человек делает работу, через месяц после выката: делает по-новому или вернулся к обходному пути. Это самый надёжный сигнал из всех и самый редко используемый.
• Прямой вопрос с конкретикой. Не «стало удобнее?», а «сколько времени ушло на отчёт в эту пятницу?». Самоотчёт слабее факта, но на малой базе он лучше отсутствия данных.

Чего делать нельзя: объявить, что измерить невозможно, и закрыть срез по факту выката. Это и есть возврат к измерению выпуска, только с оправданием. Минимум, который доступен всегда: назвать до работы один наблюдаемый признак того, что проблема снята, и через назначенный срок пойти и посмотреть. Один признак и один поход — уже измерение.

И отдельно про честность на малой базе. Когда замеров десятки, а не тысячи, легко принять шум за сигнал. Защита простая: смотреть только на крупные сдвиги (в разах или в десятках процентов) и требовать, чтобы сдвиг подтверждался вторым независимым признаком — числом и наблюдением, например. Пара процентов на тридцати замерах не значит ничего, и говорить о них как о результате — самообман.

Держать бизнес-результат в фокусе одному

Когда весь путь ведёт один человек, бизнес-метрика — это его руль и его совесть. Некому со стороны спросить «а стало ли лучше?» — спрашивать должен он сам, и до выпуска, и после. До — чтобы решить, стоит ли вообще делать: какой бизнес-результат мы ждём и как поймём, что он наступил. После — чтобы замкнуть петлю: посмотреть, сдвинулась ли метрика, и если нет — не праздновать отгруженную фичу.

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

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

Глубже: бизнес-результат в рубляхрасширенное

«Бизнес-результат» в статье ни разу не посчитан в деньгах, а решение «делать ли» и «сколько на это тратить» принимается именно в них. Считают на салфетке, с точностью до раза, но считают.

Ценность. Метрика, которую сдвигает срез, переводится в деньги через то, за что платит бизнес: обращения в поддержку стоят времени оператора (40 % меньше обращений это 200 обращений в месяц по пятнадцать минут, около пятидесяти часов), конверсия в оплату умножается на средний чек и число попыток, отток умножается на пожизненную ценность клиента, ошибка в расчёте умножается на число расчётов и цену одной ошибки (штраф, возврат, ручное исправление). Не все метрики переводятся честно; тогда пишут «не знаем, но не меньше X», и X берут из самой консервативной оценки.

Стоимость. Часы на срез (свои и агента) по внутренней ставке, инфраструктура (новый компонент это его эксплуатация, о чём статьи про цену второй базы), поддержка после выпуска и цена того, что не сделали вместо этого. Стоимость ошибки решения тоже сюда: если гипотеза не подтвердится, что потеряно, кроме времени.

Сравнение. Ценность за год против стоимости за год, и порог «делаем», если разница в разы, а не на проценты, потому что обе оценки ошибаются в разы. Срез, у которого ценность посчитана в тысячах, а стоимость в сотнях тысяч, не делают независимо от того, как громко его просят; срез с обратным соотношением делают первым. Это и есть арифметика приоритизации из соседней статьи, и она же аргумент в разговоре с бизнесом, где «пользователям удобнее» проигрывает «сто часов поддержки в месяц».

Глубже: как мерить пользу агента, не скатываясь в метрики выпускарасширенное

Фаза учит отличать бизнес-результат от выпуска и тут же оперирует «в пять-десять раз больше кода», а это метрика выпуска в чистом виде: код это затраты, а не результат. Как мерить пользу агента честно.

Не считать. Строки кода, число pull request, число коммитов, долю кода от агента: всё это растёт от применения агента само по себе и ничего не говорит о пользе; агент, который пишет втрое больше кода для той же задачи, вреден.

Считать по результату. Время от названной проблемы до проверенного бизнес-результата на похожих срезах до и после: если срез, который занимал две недели, стал занимать неделю при том же исходе, это польза. Доля переделок: сколько срезов вернулось из приёмки или потребовало исправления после выпуска; агент, который ускоряет выпуск и удваивает переделки, польза сомнительная. Дефекты, дошедшие до пользователей, на срез. Стоимость среза целиком, часы плюс токены, против ценности из раздела выше.

Честное сравнение. Похожие срезы, а не «этот с агентом, тот без»; период в месяцы, а не спринт; и признание, что часть эффекта это не агент, а то, что ради агента написали спецификации и тесты, которых раньше не было. Это тоже польза, просто с другой причиной.

Что говорит сам инженер. Один вопрос раз в месяц: на что ушло время, которое освободилось? Если на разговоры с пользователями и приёмку, рычаг сработал; если на приёмку в десять раз большего объёма правок, рычаг съел сам себя.

Коротко

• Выпуск измеряет команду, бизнес-результат измеряет пользователя; метрика выводится из названной проблемы и выбирается до работы.
• Ловушки: метрика после выпуска, короткий горизонт, одна метрика без страховочных, метрика процесса вместо бизнеса.
• Одному бизнес-метрика служит рулём: до выпуска решает, делать ли, после отвечает, что изменилось у пользователя.
• В деньгах: ценность через то, за что платит бизнес (часы поддержки, конверсия, отток, цена ошибки), против стоимости среза с эксплуатацией; делают, если разница в разы.
• Пользу агента меряют временем от проблемы до результата на похожих срезах, долей переделок и дефектов, стоимостью среза с токенами; строки кода и число pull request не считают.
• Деформация метрики, ставшей целью, — это закон Гудхарта: как только показатель становится целью, он перестаёт быть хорошим показателем.
• Срок для метрики называют до работы и в числе повторов события, а не в календарных днях: часы для отказов, сутки-двое для массового действия, недели для недельного цикла, месяцы для длинного; невозможность назвать срок означает, что метрика слишком далёкая.
• Процесс от результата отличает подлежащее: действует команда — метрика процесса, действует пользователь — бизнес-результат; процесс ставят себе как условие работы и как множитель на число попыток, результат — на каждый срез.
• Когда мерить нечем, считают по логам, обращениям, базе и файлам, ставят два-три события руками, считают случаи вместо процентов и берут наблюдаемый признак: исчезновение действия, отсутствие жалоб, наблюдение за работой через месяц.

Что почитать дальше

Выбранная бизнес-метрика работает в паре с двумя соседними шагами: она задаёт, что и в каком объёме стоит строить, и она же проверяется после выпуска и первого контакта с реальностью. А исходная формулировка проблемы — это то, откуда метрика выводится: без неё она повисает в воздухе.