Роль OKR и KPI в разработке программного обеспечения

Мы уже разобрали, как правильно и как не стоит измерять продуктивность в разработке. Теперь пора выйти за рамки метрик и поговорить о высокоуровневых целях проекта и бизнеса в целом — OKR. Когда они сформулированы, возникает необходимость отслеживать ежедневный прогресс команд с помощью KPI.

Как и в случае с метриками, не менее важно вовлекать инженеров в разработку целей и показателей. Грамотно выстроенные OKR и KPI способны привести команды и компанию к новым проектам и клиентам. Но при неверном подходе те же инструменты станут источником демотивации и падения производительности. В этой статье команда Enji делится своим опытом создания целей и показателей эффективности.

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

OKR (Objectives and Key Results) — это фреймворк целеполагания, с помощью которого компании формулируют конкретные амбициозные цели и отслеживают прогресс через измеримые ключевые результаты. Цель описывает «что» нужно достичь, а ключевые результаты — "как" измерить движение к этой цели.

KPI (Key Performance Indicator) — это метрика, которая показывает, насколько хорошо сотрудник, команда или организация справляются с конкретными операционными задачами.

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

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

Цель: повысить качество приложения.

1. Ключевой результат 1: сократить количество багов, о которых сообщают пользователи, на 50% в течение первого квартала.
2. Ключевой результат 2: увеличить покрытие кода автотестами до 90% в течение шести месяцев.
3. Ключевой результат 3: достичь рейтинга удовлетворенности качеством продукта выше 90% в следующем квартале.

Время выполнения

• Цель: сократить время выполнения до пяти дней к концу Q4.

Время цикла

• Цель: сократить время цикла до трех дней к концу Q4.

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

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

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

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

Разумеется, это не правило, и игнорировать OKR и KPI нельзя. При правильном использовании они приносят очевидную пользу и командам, и руководителям:

• Четкое направление. OKR задают понятный фреймворк для амбициозных целей и помогают командам понять, на чем сосредоточиться.
• Согласованность. OKR и KPI выстраивают усилия команды в соответствии с целями компании, обеспечивая единый вектор работы.
• Измеримый прогресс. KPI дают конкретные данные для оценки производительности и принятия взвешенных решений.
• Ответственность. Четкие OKR и KPI формируют у участников команды чувство причастности к результату.

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

Reddit, безусловно, не является научным источником, но это важная площадка, где специалисты говорят откровенно. Вот на что чаще всего жалуются разработчики в контексте OKR:

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

Схожие претензии звучат и в адрес KPI:

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

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

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

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

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

Создание программного продукта можно разложить на четыре этапа: усилие — результат — эффект — влияние. Рассмотрим на примере финансового приложения для инвестиций.

• Усилие. Работа по созданию приложения.
• Результат. Приложение создано.
• Эффект. Пользователи получают приложение и меняют подход к инвестициям.
• Влияние. Пользователям нравится приложение, появляются положительные отзывы, выручка растет.

Руководство компании хочет повысить производительность и стоит перед выбором: что именно измерять — усилие, результат, эффект или влияние?

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

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

Несколько рекомендаций для тех, кто формирует OKR и KPI для команды разработки. Учитывайте специфику своего бизнеса, но не бойтесь экспериментировать.

1. Не торопитесь. Даже если цели и показатели кажутся очевидными, стоит потратить время на исследование, привлечь стейкхолдеров и выработать идеи, которые действительно будут двигать бизнес вперед.
2. Согласуйте с бизнес-целями. KPI и OKR должны быть напрямую связаны с более широкими задачами компании — например, повышением удовлетворенности клиентов, ускорением выпуска фич или улучшением качества кода.
3. Соблюдайте принцип SMART. KPI и OKR должны быть конкретными, измеримыми, достижимыми, актуальными и привязанными к срокам. Например, KPI по сокращению количества багов должен указывать процент снижения и временной горизонт.
4. Поощряйте постоянное совершенствование. Регулярная оценка через KPI и OKR создает импульс к улучшениям. Если время на код-ревью слишком велико, KPI может отслеживать его сокращение, а OKR — ставить цель улучшить командное взаимодействие.
5. Создавайте прозрачность и ответственность. Четкие KPI и OKR делают зоны ответственности понятными: каждый участник понимает свою роль в достижении ключевых результатов.
6. Развивайте межфункциональное сотрудничество. KPI и OKR в разработке должны стимулировать взаимодействие между разработчиками, тестировщиками и продуктовыми менеджерами. Например, общая цель по улучшению пользовательского опыта объединяет все роли.
7. Отслеживайте прогресс регулярно. Систематическая работа с KPI и OKR позволяет своевременно выявлять проблемы и адаптироваться. Это обеспечивает гибкость бизнеса в ответ на изменения.
8. Разграничивайте опережающие и запаздывающие индикаторы. KPI должны включать и те и другие: опережающие (например, количество фич в разработке) помогают прогнозировать будущее, запаздывающие (например, отток клиентов) — оценивать прошлое.
9. Используйте процент достижения. Оценивайте выполнение цели в процентах: 90% может сигнализировать о том, что что-то помешало команде завершить работу, даже если она двигалась в правильном направлении.
10. Меньше — лучше. Вместо длинного списка целей и показателей стоит потратить время на разработку меньшего числа более качественных идей. Так у команд будет больше возможностей их реализовать.

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

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

Когда цели и показатели сформулированы четко, возникает соблазн использовать их как основу для оценки сотрудников. В такие моменты стоит вспомнить закон Гудхарта: "Когда мера становится целью, она перестает быть хорошей мерой". Оценка продуктивности разработчика требует учета множества факторов и метрик — от DORA до SPACE и других.

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