Вы управляете лучшей командой компании: самое быстрое время цикла, самая высокая точность планирования и наименьшее количество переделок. У вашей команды наименьшее время проверки, больше всего еженедельных развертываний и лучшее соотношение ошибок/KLOC. А потом кто-то из высокопоставленных лиц закрывает ваш проект — что только что произошло?

Выходной парадокс

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

Показатели разработки — это, по сути, набор показателей, которые помогают командам инженеров отслеживать свою скорость (быстро двигаться) и качество (без поломок). Для измерения этих атрибутов могут использоваться различные метрики. Время цикла, количество PR или скорость отслеживания закрытых проблем. Чтобы отслеживать качество, отслеживайте количество дефектов, среднее время устранения или количество развертываний, вызвавших сбой. Каждая из этих метрик даст разное представление об проверяемом атрибуте. Некоторые метрики также помогают анализировать атрибуты прокси. Отслеживайте доработки, чтобы анализировать эффективность, влияющую на скорость. Точность планирования — хороший показатель предсказуемости, который обеспечивает как скорость, так и качество и имеет ценность сам по себе.

Проблема со всеми вышеперечисленными показателями заключается в том, что, хотя они отлично измеряют эффективность, их обычно недостаточно для измерения успеха. Основная причина в том, что они полностью оторваны от бизнес - KPI (ключевых показателей эффективности, еще одного красивого названия метрик). Такое разъединение часто приводит к неэффективной коммуникации между организациями в компании, в основном продуктовой и инженерной. В конце концов, производственная организация (и остальная часть бизнеса) заботится не только о скорости или качестве, поскольку они отслеживают результат . Продуктовая организация обычно заботится о результате — какой доход принесла наша новая функция? Сколько новых пользователей мы привлекли?

Меня, как нового инженера-менеджера, это сбивало с толку. С одной стороны, было ясно, что измерение моей команды на основе показателей разработки, а не бизнес-показателей, приведет к несоответствию с командой разработчиков. С другой стороны, было бы несправедливо оценивать мою команду на основе бизнес-показателей: как они могут повлиять на нее? Это наша работа? Не наступлю ли я на пятки продуктовой организации?

Измеряйте то, что имеет значение

Я совершил прыжок веры и попытался использовать бизнес-метрики в качестве путеводной звезды. Со временем это привело к лучшим результатам.

Во-первых, это упростило общение. вашему партнеру по продукту будет легче понять, почему важно расставлять приоритеты при обновлении БД, когда вы ставите его с точки зрения общего KPI, которому будет нанесен ущерб. Просто потому, что вам ясно, что если вы не уделите приоритетное внимание обновлению БД, следующие несколько пользовательских историй займут в два раза больше времени, и вам придется потратить время на обслуживание, что задержит выпуск функции до момента, когда вы выиграли. Если у вас недостаточно времени для достижения цели использования, которую вы установили в качестве KPI, это не значит, что она понятна вашему коллеге по продукту. Я имею в виду, это много хмеля; почему бы не начать с того, что имеет значение? (нет, это не обновление БД)

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

• Мы можем определить функции, в которых мы можем создать 80% пользовательской ценности за 20% усилий. Это может высвободить ресурсы для еще более быстрого продвижения наших KPI. Для этого команда должна четко понимать бизнес-цели, потребности пользователей и стремление их улучшить.
• Мы можем использовать KPI, чтобы указать, какой технический долг нам следует накопить: пытаемся ли мы получить наших первых пользователей функций, и отказ от функции возможен? Давайте выпустим как можно быстрее, а о техническом долге поговорим позже. Пытаемся ли мы улучшить удержание большой клиентской базы? Давайте обеспечим высокое качество для этого.
• Мы можем предложить решения проблемных вопросов, которые продукт даже не знал, что они могут быть решены, основанные на новых технологиях или инновационном инженерном подходе.
• Мы можем (как это ни раздражает) использовать KPI, чтобы понять, что нет смысла искать конкретное классное технологическое решение, которое мы хотим внедрить, потому что сама проблема не имеет решающего значения для бизнеса.

Как измерить успех?

После перехода к метрикам, важным для бизнеса, мы с моим коллегой по продукту должны были выбрать основу для их измерения. В Epsagon мы использовали структуру OKR . Я не буду вдаваться в подробности, так как в Интернете доступно множество отличных ресурсов для реализации OKR. Суть в том, что это отличный фреймворк для средних и крупных организаций, обычно на этапе пост-рыночного соответствия продукта. Это помогает объединить различные команды, группы и организации в бизнесе для достижения одних и тех же целей, ориентированных на результат.

В Epsagon у нас были OKR для каждой продуктовой команды, и они были целями инженеров, специалистов по продукту и дизайнеров, которые составляли продуктовую команду. После внедрения у нас улучшилось сотрудничество между продуктом и инженерами. Меньше споров о требованиях и больше сотрудничества для решения проблем. Мы также заметили, что увеличение автономии, вызванное постановкой целей над задачами, привело к инновациям и ответственности за результаты. Команды составили дорожную карту, и решения пришли как от инженеров, так и от продуктов.

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

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

Общение является ключевым

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

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

Показатели разработки устарели?

Несмотря на кликбейтинговый заголовок этой статьи, ответ отрицательный — их нужно просто использовать правильно. С одной стороны, показатели разработки — это мощные инструменты для устранения неполадок в ваших бизнес-показателях. Например, снижение удержания пользователей можно объяснить увеличением количества дефектов. В этом случае вы можете использовать метрику разработки в качестве опережающего индикатора: вместо того, чтобы ждать, пока снизится удержание, вы должны отслеживать количество дефектов, чтобы предотвратить его сбрасывание (аналогично тому, как вы отслеживаете использование ЦП, чтобы избежать подсчета ошибок API 5xx). от всплесков и причинения реального вреда вам, пользователям). Еще один вариант использования — метрики разработчиков в качестве основного индикатора опыта и удовлетворенности разработчиков (что, в свою очередь, влияет на удержание разработчиков).

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

Что дальше?

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

• Знаю ли я, какие бизнес-результаты ожидаются от меня?
• Делаю ли я все возможное, чтобы оптимизировать эти результаты?
• Как я отслеживаю успех? Каковы критерии для поднятия флага или изменения моих планов?
• Знает ли моя команда о бизнес-целях и плане их достижения? Каков их вклад в это?
• Какие из моих бизнес-KPI можно улучшить, улучшив какие показатели разработки?