Привет! На связи Павел Гонзалес, 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 миллисекунд инициировал не менеджер, а разработчик. Обычный инженер подумал: «А что будет, если наш сайт станет загружаться медленнее? На что это может повлиять?».
Итоги
Итак, мы открыли для себя метрики и выяснили, что они помогают:
Понять модель монетизации продукта.
Понять, как мы можем влиять на продукт.
Стать более заинтересованными в развитии продукта.
Искать и предлагать новые решения и фичи.
Чем это чревато для разработчика?
Рост в ширину. Теперь он приобретает навыки аналитика, которые могут помочь в будущем стать тимлидом или менеджером (если он этого захочет).
Обретение продуктового мышления. Разработчик гораздо глубже понимает, что разрабатывает, и предлагает новые фичи — растёт потенциал для продвижения, минимизируется шанс выгореть.
Ну и в завершении несколько рекомендаций:
Спрашивайте менеджера про продукт, собираемые метрики и их значимость.
Не бойтесь предлагать новые идеи и реализовывать новые фичи.
Не ленитесь обкладывать ваш код аналитикой.
Думайте о продукте, как о своем бизнесе, ведь чем больше пользы вы приносите бизнесу, тем больше он вам платит.
