OKR простыми словами: цели квартала, Key Results и связь со спринтами

Метод пришёл из Intel 1970‑х, распространился через Google в начале 2000‑х и сейчас используется в большинстве крупных технологических компаний, от Amazon и Spotify до Яндекса и VK. Но OKR — не только про большие корпорации. Формат одинаково полезен как для команды из двух человек, так и для продуктовой вертикали из ста. Главная идея — отделить амбицию от плана и сверяться с результатом, а не с процессом.

Из чего состоит OKR

Objective — амбициозная цель

Качественная формулировка того, куда команда идёт в следующем квартале. Objective должен быть вдохновляющим, понятным и достижимым в обозримом горизонте. Примеры: «Стать самым быстрым сервисом ретроспектив на рынке», «Сделать онбординг новых клиентов радостным», «Укрепить внутреннюю инженерную культуру». Заметьте: это не метрика и не задача, а направление. Плохие objectives звучат как операционные тикеты: «Выпустить тариф Team», «Переписать старый модуль». Они не оставляют пространства для решений о том, как именно команда придёт к результату.

Key Results — измеримые исходы

Три‑четыре измеримых индикатора, по которым в конце квартала видно, приблизилась ли команда к цели. Формулировка всегда количественная. Не «улучшить скорость», а «сократить время ответа API с 800 мс до 200 мс на p95». Не «повысить удовлетворённость», а «поднять CSAT с 4.2 до 4.6 по 500+ ответам». Key Results — не список задач, а список наблюдаемых изменений. Их «делают руками» задачи из бэклога, но измеряется не сам факт работы, а исход.

Чем OKR отличается от KPI

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

Как OKR соединяется со спринтами

OKR живёт на квартале, спринт — на одной‑двух неделях. Мост между уровнями — sprint goal, цель отдельного спринта. Обычно один sprint goal — это шаг к одному из Key Results квартала: «В этом спринте закрываем первую половину задач по сокращению времени ответа API». Получается три уровня целей: квартальная (Objective + Key Results), спринта (sprint goal), и задачи бэклога, которые её реализуют.

Такой трёхуровневый ландшафт даёт прозрачность: у каждой задачи в бэклоге есть обозримая причина существования. Она приближает sprint goal, который приближает Key Result, который приближает Objective. Если задача не ложится ни в один sprint goal квартала, это повод её обсудить: либо она не про цель, либо отражает ещё не сформулированный Objective.

Как команда формулирует OKR

Квартал — подходящий горизонт

Три месяца — достаточный срок, чтобы получить значимый сдвиг по метрике, и одновременно достаточно короткий, чтобы не устать от цели и не потерять связь с реальностью. Более короткие OKR (месяц) обычно превращаются в список задач, более длинные (год) — в декларацию намерений. Годовые стратегические OKR компании — исключение. Они не замещают квартальные командные, а встают этажом выше.

Один Objective, три‑четыре Key Results

На команду в 5–10 человек оптимально один Objective и три‑четыре Key Results к нему. Иногда допустимы два параллельных Objective (например, если команда одновременно отвечает за продукт и за инфраструктуру), но три и больше уже означают, что команда ничего не выберет. Каждый Key Result должен быть измеримым. Есть текущее значение, есть целевое, есть способ это измерить.

Каскад от бизнес‑целей

OKR команд не рождаются в вакууме. Обычно они вытекают из OKR продукта или направления, те — из компанийных. Каскад не должен быть механическим (команда не обязана дословно копировать Key Results сверху), но идейная связь обязательна. Если компания в этом квартале фокусируется на удержании клиентов, а команда платформы пишет OKR про внутренние инструменты, стоит объяснить связь или пересмотреть OKR команды.

Примеры

Продуктовая команда

• Objective: «Превратить RetroPoint в выбор по умолчанию для команд из 20+ человек».
• KR1: увеличить долю корпоративных регистраций (почтовые домены с ≥ 20 сотрудниками) с 15% до 40%.
• KR2: сократить время до первой завершённой ретро с 9 до 3 дней после регистрации команды.
• KR3: поднять NPS среди команд 20+ с 28 до 50.

Команда поддержки

• Objective: «Сделать общение с поддержкой радостным, а не обязательным».
• KR1: сократить среднее время первого ответа с 6 до 1 часа в рабочее время.
• KR2: повысить долю обращений, решённых в одном сообщении, с 35% до 60%.
• KR3: получить 100+ упоминаний «отличная поддержка» в отзывах клиентов за квартал.

Команда инфраструктуры

• Objective: «Превратить деплой в невидимое событие для разработчиков».
• KR1: сократить время прогона CI с 24 до 8 минут.
• KR2: снизить долю откатов деплоев с 6% до 1%.
• KR3: довести deploy frequency с 5 до 20 в неделю.

Типичные ошибки

• OKR как список задач. Если Key Results выглядят как «сделать фичу X», «выпустить модуль Y». Это не KR, а план. Перепроверьте: можно ли измерить KR числом в конце квартала, не привязываясь к тому, какими способами туда пришли?
• Цели сверху без обсуждения. OKR, спущенные руководителем без участия команды, обычно не работают. Команда не верит в цифры и не берётся за них всерьёз. Формулировка OKR — коллективное упражнение на полдня, а не почтовое задание.
• Слишком много Key Results. Пять‑шесть KR на один Objective — почти гарантия, что ни один не будет достигнут. Жёсткое правило: 3–4 KR максимум, если не получается, переформулируйте Objective.
• Ошибка «100% или ничего». OKR ставят амбициозно. Достижение на 70% считается здоровым результатом. Если команда регулярно закрывает 100% всех KR, цели слишком скромные, стоит поднять планку.
• Нет ретро по OKR. Квартал закончился, команда пишет новые OKR и забывает про старые. Без коротких еженедельных чек‑инов и честной итоговой ретроспективы OKR превращается в ритуал.
• OKR не видны в работе. Если команда не помнит свои OKR посреди квартала, они не влияют на решения. Держите их в видимом месте — дашборд, закреплённый тред, обложка ретро‑доски.

Ретро в команде с OKR

OKR меняет фокус ретроспективы. В командах без OKR ретро обычно разбирает спринт «от событий»: что случилось, что понравилось, что мешало. Если у команды есть OKR, спринт — это шаг к Key Result квартала, и ретро в первую очередь смотрит на движение по этому шагу.

Для таких команд в RetroPoint есть отдельный формат — Sprint Goal: четыре колонки, где в центре доски — формулировка цели спринта, а остальные колонки фильтруют опыт через неё. Это прямая проекция OKR‑мышления на ретро: вместо «что случилось» — «что двигало или не двигало Key Result».

С чего начать, если OKR ещё нет

• Не пытайтесь сделать OKR сразу для всей компании. Возьмите одну команду, сформулируйте один Objective и 3 Key Results на квартал.
• Договоритесь: OKR не заменяет бэклог и планирование, а надстраивает над ними ещё один слой — «зачем всё это».
• Первый квартал — пробный. Не ждите 100%, ловите ошибки формулировок, учитесь отличать цель от задачи.
• Еженедельно сверяйтесь с Key Results. Даже короткий чек‑ин «где мы по метрикам» держит цель живой.
• По итогам квартала проведите честную ретроспективу: что получилось, что нет, что учтём при формулировке следующих OKR.

На второй‑третий квартал OKR начинает давать ощутимый эффект. Решения проще приоритизируются, дискуссии становятся короче, команда перестаёт тратить энергию на задачи «потому что попросили». А ретроспектива, отвязанная от списка задач и привязанная к цели, превращается из формальности в инструмент развития. Если вы уже работаете с OKR — попробуйте шаблон Sprint Goal в RetroPoint или загляните в каталог ретроспективных техник. Если ещё нет — начните с маленького шага и вернитесь к этому материалу через квартал.