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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типичные ошибки:

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

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

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

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

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

Дальше

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