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 или загляните в каталог ретроспективных техник. Если ещё нет — начните с маленького шага и вернитесь к этому материалу через квартал.