Зачем разработчику бизнес-метрики

Объясняет Frontend Team Lead «Магнита» Павел Гонзалес

Привет! На связи Павел Гонзалес, Frontend Team Lead команды «Гастроном Медиа». В этой статье я расскажу, чем бизнес-метрики помогают разработчику развивать и лучше понимать продукт.

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

Каждый бизнес на определённом этапе развития собирает разные метрики. Для стартапа они одни, а для крупных компаний другие. Но все они сводятся к одной глобальной метрике — деньгам.

Для измерения метрик существуют разные инструменты. Например, Яндекс Метрика или Google Analytics. Если компания большая, то она может разработать и самописное решение: программу, где под капотом часть данных отсылается в Google Analytics, другая — в Яндекс Метрику, часть отчётов уходит в Power BI, MetaBase и в другие системы, а другая часть данных будет проанализирована с помощью внутренних Data Scientists. Почти для всех популярных библиотек и фреймворков есть готовое решение. Например, это может быть библиотека для Vue, Angular или React. В ней мы отправляем какой-то ивент и указываем: что это был за клик, что это за категория, какое это значение и какой это лейбл. Полей может быть сколько угодно — вы получаете их от аналитиков и решаете, откуда подтягивать каждое значение. В ответ аналитикам вы отправляете большой объект, с которым им предстоит провести наедине не один увлекательный рабочий день, и а, может, и вечер.

Определимся с проблемами, которые могут возникнуть у разработчиков, но которые можно пофиксить с помощью метрик.

Бессмысленность задач

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

Не видим ценность нашей работы

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

Скучно на работе

Эта проблема рождается прямо из предыдущего пункта. Мы теряем интерес к работе, потому что не чувствуем сопричастности к бизнесу и наоборот.

Нет роста

Наш потенциал не замечают, нам не дают расти по карьерной лестнице. Потому что менеджер видит в нас исполнителя, который отлично справляется с задачами: пишет код и не задаёт вопросы. Зачем его повышать?

Наполняем смыслом бессмысленное

А зачем нас вообще берут на работу? Конечно, из-за наших навыков! А именно, чтобы код, который мы пишем, приносил деньги бизнесу.

Рассмотрим кейс.

В процессе работы менеджер или аналитик просит в очередной раз поменять блоки местами или перекрасить кнопку. Нам это не нравится. Однако за этим кроется гипотеза — благодаря малозначительному на первый взгляд изменению компания может повысить бизнес-метрики.

Было: старая кнопка розового цвета «Добавить в корзину» и сумма покупки. Стало: новая кнопка зелёного цвета без указания цены.

Кажется, что ничего особого не поменяли, но выглядит чуть-чуть по-другому. Зачем это мы это сделали? Ведь вместо кнопки мы могли написать новый чат или обработчик видео. А делаем такие скучные вещи.

Но мы же обсуждаем метрики! Значит, нужно понять, в чём смысл задачи и на какие метрики повлияло её решение. Спрашиваем менеджера: «Олег, две недели назад мы перекрасили кнопку вместо запуска новой фичи. А что изменилось после?». Оказывается, перекраска кнопки повлияла на метрику add to cart, которую собирают аналитики. И в целом отразилось на общих продажах.

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

Допустим, если средний чек был 2 500 рублей, то после небольшого обновления продажи увеличились на 125 000 рублей.

Теперь мы видим, что после изменения цвета кнопки пользователи стали чаще нажимать на неё. И вот маленькая непонятная задача перестаёт быть бессмысленной.

Но бывает и наоборот. Например, у менеджера есть гипотеза. Он ставит задачу, которая кажется глупой. Команда решает её, а через неделю оказывается, что гипотеза невалидна и провалилась. Менеджер приходит снова и просит откатить код, над которым разработчики так усердно работали неделю или две. И, конечно, это выводит из себя. Но проваливать гипотезы — неплохо! Ведь даже если 10% гипотез провалидировалось, то их можно и нужно продолжить развивать.

Приобретаем чувство ценности

В прошлом пункте мы научились спрашивать менеджера о смысле задач. А что, если мы всегда будем оглядываться на релизы и смотреть, какой business value принесли для бизнеса? Таким образом мы начинаем расширять фокус внимания с кода на остальные части бизнеса. Теперь мы видим не только строчки кода, но ещё и деньги. Вот как это может выглядеть. И вот 5 релизов превращаются в 9 миллионов повышенной прибыли.

Боремся со скукой

Когда мы поняли, как измерять нашу ценность и как работает наш продукт — нам становится интереснее его разрабатывать. Теперь мы знаем, для чего существует каждая задача и какую пользу продукт может принести конечному пользователю. Это в корне меняет мышление в сторону продуктового разработчика. Следовательно, мы не просто пишем код, а думаем о продукте в целом.

Создаём потенциал для роста

Останется ли незамеченным сотрудник, понимающий продукт и предлагающий решения для его развития? Думаю, ответ очевиден. Ваши идеи — ценность для бизнеса. Безусловно, это не 100% причина для повышения, а лишь один из слоёв пирамиды, которая состоит от вовлечённости, инициативности, ваших hard и soft skills, и др.

А ещё продаём рефакторинг

Ну, и немного про рефакторинг. Разработчик всегда видит в нём ценность, а менеджер — не всегда.

Рефакторинг призван убрать изъяны кода: увеличить developer experience, улучшить производительность приложения или сайта. Когда мы занимаемся рефакторингом, то также можем влиять на бизнес-метрики. Это хорошо продемонстрировал Amazon.

В 2006 году Amazon выяснил, что задержка загрузки сайта на 100 миллисекунд влечёт потерю 1% прибыли. Google подскажет, что за 2021 год Amazon заработал 26,9 миллиардов долларов. А если бы разработчики не «перформили» сайт целый год, то компания не дополучила бы 27 миллиардов долларов. Это непростительно много.

Интересно, что гипотезу про 100 миллисекунд инициировал не менеджер, а разработчик. Обычный инженер подумал: «А что будет, если наш сайт станет загружаться медленнее? На что это может повлиять?».

Итак, мы открыли для себя метрики и выяснили, что они помогают:

Чем это чревато для разработчика?

Ну и в завершении несколько рекомендаций: