Вы много сделали, но никто этого не заметил. Как показать, на что повлиял ваш код

Список закрытых задач мало что говорит о вашей работе

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

Инженерную работу долго оценивали по тому, сколько закрыто задач, pull request, багов и сколько вышло релизов. Такой список легко показать, но зачем всё это было нужно, из него не понять.

Сравните две фразы (числа условные). «Мы добавили кеширование» говорит о том, что сделано. «Мы на 40% сократили время ответа при оформлении заказа, и покупатели стали быстрее доходить до оплаты» — о том, что из этого вышло. Работа во втором случае не обязательно была сложнее. Просто видно, как техническое решение связано с тем, что важно пользователю и компании.

Гергей Орош, автор рассылки The Pragmatic Engineer, именно так описывает инженеров с продуктовым мышлением: они сами добираются до данных о пользователях и бизнесе и «считают работу законченной, только когда видят результат в поведении пользователей и бизнес-метриках».

Продуктовые команды давно так думают. В North Star Framework от Amplitude, сервиса продуктовой аналитики, главная метрика показывает, что пользователь получает от продукта. К ней добавляют входные метрики: то, на что команда может повлиять напрямую.

Как это выглядит на деле, Amplitude разбирает на примере музыкального сервиса Anghami. Сначала главной метрикой там было само прослушивание, потом удержание: слушают ли люди музыку месяц за месяцем. На удержание команда влияла через показатели помельче, например долю тех, кто слушает больше определённого числа песен из рекомендаций.

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

Как найти метрику, на которую влияет ваш код

Начать можно с вопроса, какую проблему пользователя решает задача. Допустим, вы ускоряете поиск, и время ответа падает с 800 до 300 мс. Для команды это хороший результат, но продакт-менеджеру эти 300 мс мало что скажут, пока непонятно, что изменилось для пользователя.

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

Проверить себя можно на трёх последних заметных тикетах. Для каждого заполните:

• Тикет: что я сделал, что изменилось в системе?
• Проблема: что это решало?
• Пользователь: кому стало лучше?
• Метрика: какой показатель должен был сдвинуться?
• До: какое было значение?
• После: каким стало и как это проверить?
• Следующий шаг: что я сделал бы иначе теперь?

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

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

Что измерять, если ваша работа не про выручку

С платформой и инфраструктурой каждую задачу лучше не привязывать к удержанию или выручке. У внутренней платформы может вообще не быть пользователей в привычном смысле: с ней работают другие инженеры и команды.

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

DORA — программа Google Cloud, которая изучает, как команды выпускают софт. В её модели сейчас пять показателей: время от коммита до выкладки, частота выкладок, время восстановления после неудачной выкладки, доля выкладок, после которых пришлось срочно вмешиваться, и доля внеплановых выкладок из-за инцидентов.

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

С безопасностью и частью работы над надёжностью так же. Для надёжности годятся метрики восстановления из той же модели DORA. Если у задачи нет разумной продуктовой метрики, вполне подойдёт инженерная: ближайшая к результату работы, а не самая крупная в компании.

Как спорить о приоритетах, если решение не только за вами

Метрики пригождаются и до грейд-ревью: когда команда выбирает, что делать дальше.

Допустим, в очереди три задачи:

1. Переписать старый сервис. Давно пора — архитектура станет чище, поддерживать будет проще.
2. Разобраться с ошибками при оплате. Пользователей это раздражает, часть заказов срывается.
3. Сделать функцию, которую давно просит крупный клиент.

Спор «архитектура важнее новых функций» быстро сводится ко вкусам. С цифрами разговор иной: «За последний месяц ошибка случается в 2,4% попыток оплаты. Если исправление уберёт хотя бы половину, мы вернём примерно столько-то транзакций. У переписывания сервиса понятного эффекта пока нет, кроме того, что поддержка подешевеет». После такой фразы инженер и продакт вместе решают, во что вложить время команды.

У технических задач в таком споре есть слабое место. Рик Кик и Кеннеди Коллинз из консалтинговой компании Thoughtworks пишут на сайте Мартина Фаулера, автора «Рефакторинга»: «Сколько люди пользуются продуктом и сколько он приносит, измерять легко и привычно, поэтому работу, которая на это влияет, чаще ставят первой, а технические задачи откладывают». Авторы советуют найти метрики и для такой работы.

Помогает простая привычка: вместо «это важно» говорить, что именно вы хотите изменить. Допустим, вместо «Нам нужно наконец заняться этим сервисом», сказать: «Сейчас 18% времени команды уходит на поддержку этого компонента. Если инцидентов станет вдвое меньше, освободится примерно столько-то часов в месяц».

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

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

Команда может решить иначе, и это нормально.

Что рассказать на грейд-ревью вместо списка тикетов

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

Например, так: «При оформлении заказа пользователи натыкались на ошибки оплаты. Я нашёл, что часть запросов терялась при повторной попытке, предложил поменять логику повторов и вместе с аналитиком настроил мониторинг успешных платежей. После релиза доля неудачных повторных попыток снизилась с X до Y».

Из такой истории видно, что вы понимаете систему и знаете, как проверить результат. У Эванс пример короче, вообще одной строкой: «основной разработчик новой функции X, которой теперь пользуются 60% наших клиентов».

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

Что почитать и пройти, если хочется большего

Если нужно научиться работать с данными продукта

Курс Product Analytics for Prioritization & Data-Driven Decisions на Coursera разбирает, как размечать события, строить воронки, искать, на каком шаге теряются пользователи, и расставлять приоритеты по данным. Он готовит к работе в продукте и аналитике, так что связывать это со своим кодом придётся самостоятельно.

Покороче

Product Management: Concise Guide to Product Analytics на Udemy. Здесь про момент, когда пользователь впервые получает пользу от продукта, удержание, когорты и A/B-тесты.

Если нужен взгляд именно инженера

Product Thinking for Engineers от O’Reilly — живой онлайн-курс для инженеров и дизайнеров: как выводить из целей продукта приоритеты и выбирать метрики. 

Если хочется понять, как команды перестают просто выпускать функции

Мелисса Перри, бывший преподаватель Гарвардской школы бизнеса, в Escaping the Build Trap пишет о «ловушке разработки», когда функции выпускают к сроку, а задачи клиентов остаются нерешёнными.

Мэтт Лемэй, автор «Product Management in Practice», в Impact-First Product Teams — о том, как продуктовой команде определить, что считать успехом. Обе книги о продуктовой команде в целом: помогут понять, как думает продакт-менеджер, но готовых приёмов для разговора о своём коде в них немного.

С чего начать прямо на этой неделе

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