Практический гайд по настройке OKR в компании

Версия: 2.0.4 · Дата: 2026-09-23

Введение

Этот гайд — единый практический документ по внедрению и ведению объективов и ключевых результатов (OKR). Он подготовлен как:

1. методический материал по OKR;
2. инструкция по проектированию OKR-системы;
3. сценарий квартального планирования;
4. инструкция для фасилитатора;
5. справочник по ролям, встречам и артефактам;
6. основа для ведения OKR в таблицах или специализированной системе.

Для кого

• руководители компаний и бизнес-направлений;
• владельцы продуктов;
• руководители команд;
• OKR-мастера и Agile-коучи;
• внутренние консультанты;
• фасилитаторы стратегических и квартальных сессий.

Как устроен гайд

Движение от теории к практике — восемь частей:

1. Часть I — основы подхода: что такое OKR, OKR и KPI, OKR и SAFe;
2. Часть II — проектирование системы: зачем OKR компании, дизайн и роли;
3. Часть III — формирование приоритетов: от стратегии к квартальному фокусу, Objectives, Key Results и проработка рисков достижения;
4. Часть IV — инициативы как гипотезы и WSJF-приоритизация;
5. Часть V — мощность, единая очередь и решения о запуске инициатив в работу;
6. Часть VI — квартальное планирование: подготовка, сценарий сессии, ведение в таблице;
7. Часть VII — исполнение цикла: чекины, обзоры и ретроспектива;
8. Часть VIII — запуск и развитие: пилот, обучение, метрики процесса, автоматизация, масштабирование.

Глоссарий — в Приложении О, шаблоны и чек-листы — в Приложениях А–М, реестр рисков — в Приложении Н. Каждая глава ссылается на связанные главы; в собранном HTML перекрёстные ссылки работают как гиперссылки.

Соответствие вопросов структуре гайда

Язык и терминология

Основные термины даны с русскими эквивалентами при первом упоминании.

I. Основы OKR

Глава 1. Что такое OKR

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

Объектив (Objective, цель) описывает значимое желаемое изменение или состояние. Ключевые результаты (Key Results, KR) — измеримые критерии, по которым команда понимает, достигла ли она цели. Цель отвечает на вопрос «куда идём», ключевые результаты — «как поймём, что дошли».

Для одной цели обычно определяют от двух до пяти ключевых результатов. Количество одновременно ведомых целей сознательно ограничивают: практика подтверждает, что фокус — главный ресурс. Ориентир сообщества практиков — около трёх целей и 15 ключевых результатов на контур

Источник:

• Показатели устойчивости OKR-процесса — OKR Russia

Короткая история подхода

OKR появились в Intel благодаря Энди Гроуву: Джон Дорр, пришедший в Intel в 1970-х, взял прообраз системы и позже перенёс его в Google в 1999 году. Классический исторический пример — кампания Intel «Operation Crush» по возвращению лидерства на рынке микропроцессоров: цели и ключевые результаты стали общим «кличем» компании и помогли выиграть конкурентную схватку без изменения продукта.

Технологические компании, включая Google, LinkedIn, Amazon и Microsoft, используют OKR как инструмент согласования целей и культуры ответственности. Методика набирает распространение и в российских компаниях: подборка статей, книг, видео и тренингов по OKR сведена в едином навигаторе сообщества

Источник:

• OKR на русском: статьи, книги, видео и тренинги — OKR Russia

Свойства хорошо работающих OKR

• Фокус. OKR напоминают, что важно сейчас, и дают право сказать «нет» отвлекающей работе.
• Прозрачность. OKR открыты внутри организации: каждый видит цели других команд и понимает, как его работа связана с общими приоритетами.
• Амбициозность. OKR не гарантия плана, а натянутая цель. Достижение около 70% от запланированного считается успехом, и это осознанно отличается от логики гарантированных показателей.

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

Источник:

• Исследование OKR в России 2026 — OKR Russia

Что OKR не является

• OKR — не метод оценки персонала и не прямая привязка к премии; привязка бонусов заставляет занижать амбиции.
• Objective — не список проектов, не показатель и не поручение.
• Результат выполнения задач не равен автоматическому достижению цели (см. Главу 9 и Главу 11).

Практический контур работы с OKR в российских компаниях описан в материалах и исследованиях сообщества практиков (см. Главу 4)

Источник:

• База знаний OKR Russia

Глава 2. OKR и KPI

KPI (Key Performance Indicators, ключевые показатели эффективности) — метрики, показывающие состояние и здоровье существующей системы: как компания исполняет текущие процессы. Любой KPI можно представить как светофор: красный — срочно нужно воздействие, жёлтый — допустимая зона, зелёный — работа идёт отлично.

OKR описывают значимое изменение, которого организация хочет добиться. Это центральное различие гайда: KPI — про стабильность бизнеса (Run-деятельность), OKR — про его развитие (Change-деятельность)

Источник:

• Качели OKR и KPI: баланс развития и стабильности бизнеса — OKR Russia

Как не спутать системы

Как использовать совместно

• KPI — «приборная панель» операций; OKR — «навигация» для рывка. Одна и та же метрика может быть и KPI, и KR — в зависимости от управленческой роли.
• Не противопоставляйте KPI и OKR: здоровая компания ведёт оба контура — стабильную операцию и целенаправленные изменения.
• KPI, который объективно необходимо изменить принципиально иным способом, — сильный сигнал для постановки OKR: превратите амбицию в Objective и спроектируйте KR под изменение.

Идеальный режим — когда KPI встроился в ключевые результаты: например, отдел продаж имеет KPI на норму продаж, а команда разработки влияет на него через KR «увеличить конверсию посетителей в покупателей». Балансировка стабильности и развития на практике разобрана в статье сообщества

Источник:

• KPI и OKR: балансировка стабильности и развития крупных компаний в SAFe — SAFe Russia

Глава 3. OKR и SAFe

SAFe (Scaled Agile Framework) — фреймворк для масштабирования Agile в крупных организациях. Отношение к OKR внутри SAFe зависит от редакции фреймворка, и это важно не смешивать.

OKR в концепции Core SAFe

В классической версии SAFe OKR — опциональный, но рекомендованный практический инструмент. Обязательный формат OKR здесь один: стратегические темы портфеля (Strategic Themes), которые формулируются в виде OKR и задают стратегическое направление для всех программ (ART). Внутри этих тем работа идёт через эпики и биз-кейсы, а на уровне поездов и команд действуют другие инструменты формирования целей.

Ключевые условия успеха OKR в SAFe:

• инкрементальное планирование и поставка, когда команда может реагировать на обратную связь от метрик;
• разделение OKR и PI-целей: OKR применяются для стратегических тем и общих результатов, а поэтапные цели PI (PI Objectives) остаются краткосрочным контрактом на планирование;
• понимание типовых сценариев использования OKR: стратегическое согласование портфеля, управление эпиками (Lean Business Case), цели улучшения самой трансформации.

Источник:

• Цели и ключевые результаты (OKR) в SAFe — SAFe Russia

OKR в AI-Native SAFe

В модели AI-Native SAFe OKR усиливаются и становятся обязательным контуром целеполагания на всех уровнях: формируется дерево бизнес-эффектов от портфеля через ART к командам, и каждый уровень получает свои OKR, измеримые через бизнес-эффекты. Такой подход делает цели прозрачными вдоль всей цепочки поставки ценности. Практика построения деревьев бизнес-эффектов и связь OKR с портфельной инвестиционной стратегией разобраны в статьях сообщества

Источники:

• Бизнес-эффекты ART в AI-Native SAFe — SAFe Russia
• Бизнес-эффекты портфеля и инвестиционная стратегия — SAFe Russia

Как выбрать риторику

• если компания внедряет классический SAFe — следуйте Core SAFe: OKR обязательны для стратегических тем и используются выборочно, не подменяя PI-цели;
• если цифровая трансформация строится на AI-Native SAFe — закладывайте OKR на всех уровнях с самого проектирования системы (см. Часть II).

Взаимосвязь деталей работы с целями описана в Части VI (квартальное планирование) и Части V (решения о запуске инициатив).

II. Проектирование OKR-системы

Глава 4. Зачем компании OKR

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

Признаки, что OKR актуальны

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

Когда OKR подходят с ограничениями

• компания работает в стабильном, регламентированном контуре без явного запроса на изменение — там доминируют KPI (см. Главу 2);
• нет управленческой поддержки и готовности пересматривать цели — без этого система вырождается в отчётность.

Свидетельства практики

Исследование сообщества показывает зрелую практику российских компаний. Основные цифры исследования (2026):

• 76% участников гордятся поставленными целями;
• 78% считают цели достижимыми при серьёзных усилиях;
• 67% отмечают, что для достижения целей пришлось менять привычные способы работы;
• средний индекс качества OKR — 20,37 из 23 (Objective — 9,38 из 10; KR — 6,73 из 8; качество OKR в целом — 4,25 из 5);
• треть поставленных OKR приходится на ИТ-отрасль.

Это означает, что базовые практики постановки целей в сообществе освоены, а резерв роста — в качестве формулировок и ключевых результатов

Источник:

• Исследование OKR в России 2026 — OKR Russia

Глава 5. Дизайн OKR-системы

OKR-система — это не отдельный документ, а связка «уровни целей → роли → встречи → артефакты → ритм». Проектирование идёт сверху вниз: сначала решают, для какого контура ставится система, затем проектируют механику.

Уровни управленческого решения

Не смешивайте уровни в одной процедуре:

1. выбор стратегического фокуса (что меняем в принципе);
2. выбор Objectives (в направлении какого изменения движемся в цикле);
3. разработка Key Results (как измерим достижение);
4. выбор инициатив (чем будем воздействовать на KR);
5. планирование поставки (когда и как доставим инициативы);
6. управление исполнением (регулярное отслеживание и корректировка).

Смешение этих уровней — частая причина «сломанных» OKR, когда цели подменяются задачами и поставками (см. Главу 9 и Главу 11).

Каденции

Различайте:

• стратегическую каденцию — годовой ритм пересмотра стратегического фокуса и долгосрочных направлений;
• тактический цикл — период, на который ставятся OKR (обычно квартал, но не обязательно);
• операционную обратную связь — регулярные чекины и встречи по прогрессу.

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

Источник:

• Как сформировать качественные OKR — OKR Russia

Базовые элементы системы

• уровни целей: компания → направление → команда (без жёсткого каскадирования по оргструктуре);
• роли: спонсор, владелец цели, OKR-мастер, фасилитатор (см. Главу 6);
• артефакты: реестр целей, таблицы инициатив, реестры рисков и зависимостей (см. Приложения);
• встречи: квартальная сессия, чекины, промежуточный и итоговый обзоры, ретроспектива.

Артефакты и их эволюция «от простой таблицы к системе» описаны в материалах сообщества; шаблоны стоит выращивать под свою компанию, а не копировать чужие целиком

Источник:

• База знаний OKR Russia

Глава 6. Роли и ответственность

Для работы OKR-системы достаточно минимального набора ролей. Роли — это зоны ответственности, а не новая структура штата.

Владелец OKR (OKR Owner) несёт ответственность за достижение цели перед заинтересованными лицами, вовлекает их в ключевые мероприятия OKR, эскалирует блокеры и поддерживает бэклог команды в актуальном состоянии. OKR-мастер отвечает за внедрение, поддержку и развитие OKR в подразделении или компании: фасилитирует плановые сессии, чекины, обзоры и ретроспективы, интегрирует процесс работы над целями в существующие процессы компании. Эта ролевая модель описывается в программах подготовки OKR-мастеров (см. Главу 28)

Источник:

• Ролевая модель OKR — OKR Russia

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

Источник:

• Как в «Росгосстрахе» ставят и синхронизируют годовые OKR всего бизнеса — OKR Russia

III. Формирование приоритетов

Глава 7. От стратегии к квартальному фокусу

Первая работа на цикл — определить стратегическое направление движения и превратить его в квартальный фокус. Фокус — это осознанный выбор нескольких целей и отказ от остального.

Стратегическое направление описывается на уровне стратегии компании или портфеля. В SAFe такой формат — стратегические темы (Strategic Themes), которые формулируются в виде OKR и задают направление всем программам (см. Главу 3). Стратегическое целеполагание в SAFe разобрано в статье сообщества

Источник:

• Стратегические цели в SAFe — SAFe Russia

Чтобы перейти от стратегии к квартальному фокусу:

1. сведите стратегию к 3–5 ясным темам года;
2. для каждой темы определите главное изменение, ожидаемое за цикл;
3. отберите 1–3 цели цикла, которые концентрируют усилия;
4. договоритесь, от чего отказываемся на этот цикл.

Отказ — обязательная часть фокуса: если не зафиксировано «чего не делаем», фокус не состоялся.

Градиент детализации: от слов к структурированным сущностям

При переходе от стратегии к фокусу растёт степень структурированности описания. Это градиент, а не прыжок:

• просто словами (в документах и презентациях) остаются: стратегический контекст, фокус года, направления и принципы — это материал для обсуждения, его не заносят в таблицы;
• структурированными сущностями (в таблицах и реестрах) становятся: Objectives, Key Results, инициативы, риски, зависимости, жёсткие обязательства и решения о запуске инициатив в работу — по ним система хранит атрибуты, владельцев и статусы.

Правило простое: формулировка живёт в документе, сущность — в таблице. Сначала обсуждаем словами, затем регистрируем в реестрах. Детализация растёт от Главы 8 к Главе 20: Objective → паспорт KR → карточка инициативы → таблица инициатив.

Глава 8. Выбор Objectives

Objective — значимое желаемое изменение или состояние. Он задаёт направление, объясняет, чего команда хочет добиться, и не является:

• списком проектов;
• показателем или метрикой;
• поручением «выполнить работу»;
• автоматическим каскадированием оргструктуры.

Критерии хорошего Objective

Качественная цель отвечает на четыре вопроса (ориентиры сообщества):

1. Легко ли запомнить цель? Формулировка ясная и лаконичная.
2. Отвечает ли цель текущим вызовам бизнеса? Она актуальна именно сейчас.
3. Отвечает ли цель стратегии компании? Связь с фокусом года прямая (см. Главу 7).
4. Верите ли вы в достижимость цели? Цель амбициозна, но команда верит в неё.

Дополнительные признаки из практики SAFe: Objective вдохновляет; он понятен и запоминаем; осознанно помечен как Committed (обязательный) или Aspirational (амбициозный); описывает «работу над изменениями», а не «выполнение работы».

Как выбирать Objectives

Для выбора Objectives не применяйте WSJF автоматически (см. Главу 12). Критерии выбора цели:

• стратегическая значимость;
• масштаб ожидаемого изменения;
• актуальность проблемы или возможности именно сейчас;
• доступность обратной связи в течение цикла;
• межфункциональность — цель может собирать усилия нескольких команд;
• управляемость в выбранном горизонте;
• существенные риски и обязательства.

Примеры формулировок

Финансовые цели. Для компаний, где финансовый результат — первичный драйвер, деньги могут быть прямо в формуле цели. Тогда Objective формулирует управляемое командой изменение бизнес-показателя в деньгах:

Важно: деньги в цели — не плановая цифра «достичь выручки N», а измеримый эффект, на который команда реально влияет и может видеть прогресс на чекинах. Если связь с действиями команды не прослеживается — цифра остаётся индикатором уровня компании, а не Objective команды.

Если используется матрица либо голосование, это инструмент обсуждения, а не автоматическая формула управленческого решения. Конструктор Objective — в Приложении А, чек-лист качества — в Приложении М

Источники:

• Как сформировать качественные OKR — OKR Russia
• Цели и ключевые результаты (OKR) в SAFe — SAFe Russia

Глава 9. Разработка Key Results

Key Result — измеримый критерий достижения Objective. Для каждого KR по возможности фиксируйте поля (паспорт KR — Приложение Б):

• метрику: уже существующий показатель (часто KPI) может стать KR (см. Главу 2);
• исходное значение и целевое значение;
• единицу измерения и срок;
• источник данных и владельца;
• частоту обновления и уровень уверенности;
• балансирующее ограничение при необходимости.

Не называйте инициативы, поставки и задачи ключевыми результатами: цель-«выпустить фичу» измеряет поставку, а не изменение результата (см. Главу 11).

Правила расчёта прогресса

• прогресс KR считается по отношению между исходным и целевым значением;
• логика должна работать и на рост, и на снижение показателя;
• дискретные KR должны иметь однозначный критерий достижения;
• прогресс ограничиваем диапазоном 0–100%, если не оговорено иное;
• прогресс Objective рассчитывается по KR, а не по субъективному ощущению;
• рядом с прогрессом всегда есть отдельный индикатор уверенности.

Опережающие показатели

Разница между опережающими и запаздывающими показателями и правила их совместного использования разобраны в статье сообщества.

Источник:

• Опережающие и запаздывающие показатели — OKR Russia

Запаздывающие (lagging) показатели отражают уже случившийся результат (например, выручка квартала). Опережающие (leading) показывают движение к результату заранее и чаще: рост конверсии, доля клиентов, перешедших на новый тариф, число команд, использующих инструмент еженедельно. Хороший набор KR смешивает оба типа: опережающие дают раннюю обратную связь для чекинов, запаздывающие подтверждают итоговый эффект

Источник:

• Цели и ключевые результаты (OKR) в SAFe — SAFe Russia

Балансирующие метрики

Балансирующая метрика не даёт оптимизации одного аспекта сломать другой. Примеры:

• ускоряем поставку → держим стабильность (например, ограничение «аварийность не выше N»);
• растем → не теряем качество сервиса;
• меняем процесс → не роняем текущие KPI (Run не страдает от Change).

Это встраивается в KR полем «балансирующее ограничение» (паспорт KR). Идеальный режим — когда KPI встраивается в KR и на чекине мы одновременно видим движение OKR и состояние KPI по светофору: если по OKR динамики нет, а KPI в красной зоне, сначала решаем операционные проблемы

Источник:

• Качели OKR и KPI: баланс развития и стабильности бизнеса — OKR Russia

В кризисной ситуации баланс стабильности и развития становится условием выживания: как команда сохранила OKR как инструмент управления рисками при резком изменении контекста — Антикризисные OKR: как мы искали выход из кризиса — OKR Russia

Глава 10. Риски достижения OKR

Риски достижения OKR ведём отдельно от общих реестров рисков. Различайте:

• риск Objective — достижение цели в принципе невозможно в горизонте;
• риск KR — конкретная метрика не движется в нужную сторону;
• риск инициативы — работа не даст ожидаемого эффекта;
• уже возникшую проблему (факт, который надо решать);
• препятствие — внешняя зависимость или блокер;
• допущение — предположение, при котором план справедлив.

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

Источники:

• Совместное формирование квартальных OKR на сотни человек — OKR Russia
• Инструменты формирования OKR #7: Big Room Planning — OKR Russia
• Антикризисные OKR: как мы искали выход из кризиса — OKR Russia
• Показатели устойчивости OKR-процесса — OKR Russia

Выявление рисков на сессии планирования

Существенные риски выявляются на сессии планирования — на этапах согласования зависимостей и проверки баланса (Глава 19). Ключевые приёмы.

Прямой вопрос команде. «Чего вы боитесь? Почему боитесь взять ответственность за эти цели?» — сомнения участников превращаются в конкретные риски и задачи, а не остаются невысказанными. Готовность к целям проверяется голосованием пятернёй: в среднем 4 — план готов, 3 и меньше — план дорабатывается. Источник: Совместное формирование квартальных OKR на сотни человек — OKR Russia.

Доска зависимостей. Подразделения часто являются источниками рисков друг для друга; совместное планирование в начале цикла позволяет увидеть нестыковки и зависимости заранее, а не в середине стрессового квартала. Источники: Показатели устойчивости OKR-процесса — OKR Russia; Игра на формирование квартальных OKR — «Ив Кошер» — OKR Russia.

Риск → задача. Риск превращается в конкретную задачу и презентуется в привязке к цели или KR: так бизнес охотнее помогает с блокерами, потому что видит, какому результату мешает препятствие. Источник: Инструменты формирования OKR #7: Big Room Planning — OKR Russia.

Приоритизация по ценности и риску. Для выбора инициатив используется карта «ценность–риск» (формат сессии Risk–Value Studio, оценка «ценность–риск»): команда размещает идеи и обсуждает, что развивать, отложить или пересмотреть. Цель-ограничение задаёт рамку для смелых действий (Глава 8), а в составе KR полезно держать метрику на ценность и метрику на риск (Глава 9). Источник: OKR — осознанная система фокуса и гибкости — OKR Russia.

Обсуждение рисков по модели ROAM. На общем разборе риски поднимаются по одному, рассматриваются честно и прозрачно и получают одну из четырёх категорий решения — Resolved, Owned, Accepted, Mitigated. Категория фиксируется в реестре (Приложение Н) и определяет, как риск ведётся дальше (см. «Категории ROAM» ниже). Практика заимствована из PI-планирования SAFe, где риски и блокеры ART разбираются в широком контексте управления поездом, а не внутри отдельной команды. Источник: Быстрый старт в RTE #3 — Фасилитация PI-планирования — SAFe Russia.

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

Оценка и реестр рисков

Для каждого существенного риска фиксируйте: описание, связанную цель/KR/инициативу, причину, возможное последствие, вероятность, влияние, уровень риска, ранний индикатор, действие по снижению, владельца, категорию ROAM, срок, остаточный риск и статус. Используйте простую практичную шкалу (например, низкий/средний/высокий), если в организации не задана иная.

Уровень риска определяется сочетанием вероятности и влияния. Ранний индикатор — это измеримый признак того, что риск начинает реализовываться; он строится как опережающий (leading) показатель и связывается с чекином: если индикатор сработал, риск обсуждается на следующей прогресс-встрече. Подробно про выбор опережающих показателей — см. «Опережающие показатели» в Главе 9. Шаблон реестра — Приложение Н.

Каждый риск привязывается к конкретной цели, KR или инициативе; реестр рисков OKR ведётся отдельно от общих корпоративных списков рисков.

Категории ROAM

На сессии планирования и в реестре каждому существенному риску присваивается одна из четырёх категорий ROAM — практика из SAFe PI-планирования, где риски по одному поднимаются на общее обсуждение и классифицируются на месте:

Категория ROAM — это решение о судьбе риска, а не ещё один статус: она дополняет жизненный статус реестра (открыт / в работе / снят / реализовался). Риски Mitigated и Owned ведутся до снятия, Accepted пересматривается на промежуточном и итоговом обзорах (Глава 23, Глава 24), Resolved закрывается.

Про работу с рисками по ROAM

Снижение рисков

Риск снижается действием, а не обсуждением. Для каждого существенного риска назначаются владелец, срок и проверяемое действие; риск превращается в инициативу или отдельную задачу, привязанную к цели. Такие риск-снижающие инициативы конкурируют в единой очереди наравне со всеми остальными (Часть V), без отдельной квоты: резервируется только то, что объективно нельзя не сделать (снижение рисков с неприемлемыми последствиями) — см. Главу 13.

Риск не является поводом снимать амбицию — он сигнал управлять ею. Балансирующие метрики защищают от оптимизации одного аспекта в ущерб другому (Глава 9); в кризисных ситуациях именно работа с рисками и пересмотр целей позволяет сохранить OKR как инструмент, а не бросить его

Источник:

• Антикризисные OKR: как мы искали выход из кризиса — OKR Russia

Мониторинг и пересмотр рисков

Риски живут в каденции цикла:

• Чекин (Глава 22) — короткий ритм: по каждому существенному риску проверяется ранний индикатор, обновляются статус и действия по снижению. Сработавший индикатор выносится на встречу отдельной строкой.
• Промежуточный обзор (Глава 23) — пересмотр всех рисков и уровня уверенности: что реализовалось, что снято, какие индикаторы приближаются к срабатыванию.
• Итоговый обзор и ретроспектива (Главы 24–25) — извлечение уроков: какие риски не были замечены вовремя, какие ранние индикаторы сработали, какие действия по снижению оказались эффективными. Выводы становятся входом для реестра следующего цикла

Источник:

• Инструменты ретроспективы в OKR — OKR Russia

В кризисном режиме риски прорабатываются интенсивнее: цикл сокращается, контроль ведётся в два уровня (еженедельные чекины команд и регулярные сессии с руководством), а в середине цикла делается остановка — выявляются буксующие подходы, обновляются инициативы, при необходимости переписываются отдельные KR и проводится сессия риск-менеджмента. Уроки кризисной практики: цель без сильного владельца рассыпается на локальные задачи, а стабильность и развитие балансируются как условие выживания

Источники:

• Антикризисные OKR — OKR Russia
• Что такое антихрупкость и причем тут OKR? — OKR Russia

IV. Инициативы и WSJF

Глава 11. Инициативы как гипотезы

Инициатива — это гипотеза воздействия на один или несколько KR. Выполнение инициативы не означает автоматического достижения KR: цель-результат достигается, если изменилась измеряемая метрика, а не если выполнен объём работы.

Различайте три категории:

• activity — выполняемая активность («провести интервью»);
• output — созданный результат работы («выпущена версия приложения»);
• outcome — изменение поведения, состояния системы или бизнес-результата («сократился цикл поставки»).

Задачи, поставки и проекты остаются в плане инициатив и бэклоге. Они не подменяют критерии успеха. Подход «инициатива → гипотеза → KR-изменение» смещает фокус с объёма работы на результат. Похожая логика описана в чек-листе качества OKR, где связь работы и KR проверяется вопросом «ваша работа имеет связь с изменением KR?»

Источник:

• Как сформировать качественные OKR — OKR Russia

Карточка инициативы

Для инициативы фиксируйте (шаблон — Приложение В):

• связанный Objective или KR;
• стратегическое обоснование;
• гипотезу эффекта;
• ожидаемую выгоду;
• критерии приёмки;
• тип работы;
• владельца;
• зависимости;
• требуемую команду и дефицитные роли;
• размер работы;
• статус решения о запуске инициативы в работу;
• ключевое допущение;
• риск недостижения эффекта;
• способ ранней проверки;
• триггер остановки или изменения.

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

Источник:

• Дайджест OKR Russia — Лидеры изменений

Глава 12. Приоритизация инициатив через WSJF

Перед тем как инициативы начнут двигать Key Results, нужно решить, какие из них делать первыми: именно здесь OKR обычно «спотыкаются» — цели поставлены, а бэклог инициатив по-прежнему определяется громкими голосами и «короткими деньгами». Глава объясняет, почему приоритизация — управленческий процесс, а не заполнение таблицы, как выбрать метод и как приоритизировать инициативы через WSJF (Weighted Shortest Job First — Более Ценная и Короткая Работа Сначала), чтобы каждая из них работала на KR.

Глава полезна руководителям компаний и направлений, владельцам продуктов и портфелей, PO/PM в SAFe, Agile-коучам и фасилитаторам сессий приоритизации, а также руководству команд, отвечающих за достижение OKR.

WSJF применяется к единицам работы, конкурирующим за общую мощность: инициативам, фичам, экспериментам, гипотезам. Не применяйте WSJF автоматически к Objectives — выбор целей делается по стратегической значимости, а не по формуле приоритизации (см. Главу 8).

12.1 Зачем приоритизировать инициативы

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

Когда прозрачного процесса приоритизации нет, возникают типичные поломки:

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

Вывод для OKR: если инициативы отбираются вне прозрачного процесса, приоритеты фактически определяют «короткие деньги» и громкие голоса, а не вклад в KR.

Источник:

• Коварство простоты или приоритизация бэклога — Enterprise Product Management

12.2 Какие способы приоритизации есть

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

Для приоритизации инициатив в OKR мы рекомендуем WSJF, потому что:

• систематизирует весь бэклог единовременно, а не по одному элементу: задачи оцениваются по одному параметру за проход, и в каждом параметре есть эталон — самый малозначимый элемент (1);
• учитывает и ценность, и срочность, и риск, и размер работы — то есть экономику, а не голосование «по ощущениям»;
• в отличие от ICE и RICE, где шкалы заданы произвольно, сравнивает элементы бэклога относительно друг друга.

Источники:

• Коварство простоты или приоритизация бэклога — Enterprise Product Management
• Более ценная и короткая работа сначала: Weighted Shortest Job First (WSJF) — SAFe Russia

12.3 Подробнее про WSJF

В основе WSJF — простая формула: WSJF = стоимость задержки ÷ размер работы. Стоимость задержки (CoD) показывает, что теряет бизнес, если работа опаздывает; размер работы (JS) — сколько её нужно сделать. Принцип: чем ценнее работа на единицу размера, тем раньше её берут.

Такая постановка сразу даёт практический смысл, и для обычных обсуждений не нужно раскрывать стоимость задержки на компоненты: достаточно сравнить инициативы по самой сути — «что теряем от задержки» и «сколько работы». Дальше разбираем компоненты CoD для тех, кому нужна детализация.

Стоимость задержки (Cost of Delay, CoD)

Центральное понятие WSJF — стоимость задержки (Cost of Delay, CoD): деньги, которые компания теряет при задержке или невыполнении работы за определённый период времени. Пример: если фича приносит 100 000 $ в месяц, а задержка составляет три месяца, CoD — 300 000 $.

Оценивать итоговую стоимость ещё не реализованной работы сложно, поэтому CoD раскладывают на три компонента:

Здесь и далее в главе используются BV, TC и RR/OE. Формула CoD:

CoD = BV + TC + RR/OE

Расчёт CoD в деньгах

Когда данные есть, стоимость задержки можно посчитать в деньгах за 15 минут без привлечения финансового директора. Задержка фичи никогда не бывает бесплатной: если её не считать, решения принимаются «на ощущениях».

У потерь от задержки три слоя:

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

Полная формула в деньгах учитывает месячную ценность, срочность и ФОТ команды:

CoD/день = (BV + TC + RR/OE) / 30 дней + ФОТ команды / 22 рабочих дня

Относительная оценка, когда денег нет

Посчитать CoD в рублях получается не всегда: стартап без выручки, внутренний инструмент, новое направление без исторических данных, медиабизнес, где ключевая метрика — охват и MAU. Это не значит, что задержка бесплатна: нужен другой инструмент — относительная оценка.

Используется модифицированная шкала Фибоначчи: 1, 2, 3, 5, 8, 13, 20. Числа нелинейны намеренно: разрыв между 13 и 20 больше, чем между 3 и 5. Это заставляет команду думать и различать элементы, а не выставлять всем восьмёрки.

Вариации шкал: в публикациях встречаются близкие модификации ряда — например, 21 вместо 20 или расширенный ряд с ½ и 100. Вариации допустимы, если согласованы внутри команды; не смешивайте их в одной таблице.

Правила относительной оценки:

• оценивайте инициативы по одному параметру за проход;
• в каждом параметре сначала выберите относительный минимум и присвойте ему 1;
• остальные инициативы сравнивайте с этим ориентиром;
• в каждой колонке должна быть хотя бы одна единица.

Чтобы перевести относительные оценки обратно в деньги, берётся одна задача, по которой все согласны: «это точно важно». Допустим, она стоит примерно 300 000 ₽/мес — присвойте ей BV = 8. Тогда задача с BV = 4 стоит примерно 150 000 ₽/мес, а задача с BV = 13 — около 490 000 ₽/мес. Это не точность бухгалтерии, но достаточно для принятия решений.

Формула WSJF и размер работы

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

WSJF = CoD / JS

где JS (Job Size) — размер работы. Длительность выполнения сложно определить заранее: неизвестно, кто именно будет её делать и каким будет распределение ресурсов. Хороший аналог длительности — размер работы: если передний двор в три раза больше заднего, он займёт примерно в три раза больше времени.

JS оценивается по той же относительной шкале, что и компоненты CoD: у самого маленького элемента — 1, остальные сравниваются с ним.

Размер — плохой аналог длительности, когда:

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

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

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

Видео по теме (материалы сообществ «Лидеры изменений»):

Как приоритизировать работу по формуле WSJF — Лидеры изменений

Стоимость задержки и размер работы в WSJF — Лидеры изменений

Источники:

• Более ценная и короткая работа сначала: Weighted Shortest Job First (WSJF) — SAFe Russia
• Как посчитать стоимость одного дня задержки вашей фичи — Enterprise Product Management

12.4 Примеры расчёта

Пример 1. Цена одного дня задержки

Новая функция онбординга: ожидаемый прирост конверсии +4%. Релиз задерживается, команда просит 10 дней на доработки. Нужно показать, что выгоднее: ускорить или передоговориться.

Исходные данные (берутся у аналитиков за 10 минут): 2 000 лидов в месяц; ожидаемый прирост конверсии +4%; средний доход с пользователя (ARPU) 150 000 ₽; команда 6 человек с ФОТ 1,2 млн ₽/мес.

Конкурентный фактор 20% — консервативная оценка рыночных потерь сверх прямых: часть потерянного дохода не возвращается, потому что за время задержки клиенты успели уйти к конкуренту или привыкнуть к альтернативе. Брать ровно 20% не обязательно: при сильной конкуренции долю можно поднять до 30–50%, при слабой — снизить до 0–10%. Главное — явно зафиксировать допущение и использовать его одинаково при сравнении инициатив.

10 дней задержки = 5 345 000 ₽.

Какое решение принять. Нужны три альтернативы и их полная стоимость.

Решение «дорабатывать 10 дней» оправдано, если дополнительные 10 дней дают подтверждённую выгоду больше 5,345 млн ₽. Например, за 10 дней команда устраняет критичный дефект, без которого:

• конверсия не вырастет на ожидаемые 4%;
• возникнут потери клиентов, возвраты или заметная репутационная проблема;
• появится риск нарушения безопасности, закона или обязательств перед клиентами;
• запуск приведёт к дорогому ручному сопровождению.

Иначе говоря, вопрос к команде должен звучать так: какую измеримую потерю не менее 5,345 млн ₽ предотвращают эти десять дней? Если ответа нет — перенос экономически не обоснован.

Решение «ускорять» оправдано, если есть конкретный способ сэкономить дни, и его предельная стоимость ниже 534 500 ₽ за каждый спасённый день. Например:

• дополнительный QA и разработчик позволяют сократить задержку с 10 до 4 дней;
• значит, сокращаем 6 дней;
• предотвращённая стоимость задержки: 6 × 534 500 = 3 207 000 ₽.

Если дополнительная команда, подрядчик, оплата сверхурочной работы и риск последствий обходятся менее 3,207 млн ₽, ускорение выгодно. Если дороже — нет.

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

Вероятный итог в этом кейсе. Если доработки не устраняют критический риск, выпускать нужно сейчас — возможно, с ограниченным MVP, фича-флагом и быстрым планом исправлений. Причина: перенос на 10 дней стоит примерно 5,345 млн ₽, а в условии не сказано, что доработка даёт сопоставимую дополнительную ценность.

Если функциональность в текущем виде не способна дать заявленные +4% конверсии или несёт серьёзный риск, лучше не «передоговориться на 10 дней», а искать самый дешёвый способ снять критическое ограничение: уменьшить scope, отключить проблемный сценарий фича-флагом, выпустить для сегмента пользователей, вручную закрыть крайние кейсы или временно перераспределить специалистов.

Пример 2. Сравнение инициатив по WSJF

Команда оценила три инициативы по одному столбцу за проход на шкале Фибоначчи. Минимум в каждом столбце — 1.

Формулы: CoD = BV + TC + RR/OE; WSJF = CoD ÷ JS.

Инициативы выполняются в порядке убывания WSJF: первая — Фича Б (6,0), затем Фича А (2,6), затем Фича В (1,3). Первой делается не самая «дорогая», а самая ценная работа в пересчёте на единицу размера: именно короткая высокоценная работа даёт лучшую экономическую отдачу.

Источники:

• Как посчитать стоимость одного дня задержки вашей фичи — Enterprise Product Management
• Более ценная и короткая работа сначала: Weighted Shortest Job First (WSJF) — SAFe Russia

12.5 Типичные сложности и как их обойти

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

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

12.6 Пошаговая инструкция и шаблон

Семь шагов приоритизации инициатив для достижения OKR:

1. Соберите пул инициатив и привяжите к OKR. Каждая инициатива — карточка-гипотеза (шаблон — Приложение В): связанный Objective или KR, стратегическое обоснование, гипотеза эффекта («если сделаем X, изменится метрика Y»), ожидаемая выгода, владелец, зависимости, команда и дефицитные роли, размер работы, риск недостижения эффекта, способ ранней проверки, триггер остановки. Большие инициативы разбейте на сопоставимые единицы.
2. Определите участников и владельцев параметров. Бизнес отвечает за BV и TC, технический лидер — за RR/OE и размер, владелец продукта — за целостность процесса.
3. Выровняйте контекст. Разошлите материалы заблаговременно, объявите правила голосования и не допускайте к нему неподготовленных. Договоритесь о частоте и порядке пересмотра.
4. Оцените параметры по одному столбцу за проход. BV, затем TC, затем RR/OE, затем JS — по шкале Фибоначчи, с минимумом 1 в каждом столбце. Если данные есть — начните с CoD в деньгах и используйте её как отправную точку.
5. Посчитайте и отсортируйте. CoD = BV + TC + RR/OE; WSJF = CoD ÷ JS. Очередь — инициативы в порядке убывания WSJF.
6. Сопоставьте с мощностью и скажите «нет». Сначала зафиксируйте жёсткие обязательства (регуляторика, договоры, аварии) и резерв на предсказуемый внеплан. Проходите очередь сверху вниз до заполнения ёмкости команд. Высокий WSJF даёт место в очереди, но не гарантирует включение в цикл — решают линия мощности и решение о запуске инициативы в работу (см. Часть V).
7. Пересматривайте регулярно. CoD не статичен: пересчитывайте при изменении метрик рынка, запуске фичи конкурента, после разворота и в регулярной каденции сессий; учитывайте альтернативную стоимость — команда, которая тянет инициативу А, не делает инициативу Б.

Шаблон таблицы WSJF

Рабочий шаблон таблицы для копирования — Приложение Г: приоритизация идёт по одному столбцу за проход, минимум в каждом столбце — 1. Формулы: CoD = BV + TC + RR/OE; WSJF = CoD ÷ JS. Сортировка — по убыванию WSJF.

Чек-лист сессии приоритизации

• Пул собран: каждая инициатива привязана к Objective или KR, есть карточка-гипотеза.
• Участники определены, за каждый параметр отвечает конкретный человек.
• Материалы разосланы, все в едином контексте; правила голосования объявлены.
• Оценка по одному столбцу за проход, в каждом столбце есть минимум = 1.
• CoD и WSJF посчитаны, очередь отсортирована по убыванию WSJF.
• Жёсткие обязательства и резерв зафиксированы; линия мощности проведена; есть решения «нет».
• Бэклог проверен по горизонтам H0–H3.
• Результаты обсуждены и зафиксированы; назначены владельцы и сроки пересмотра.

Источники:

• Коварство простоты или приоритизация бэклога — Enterprise Product Management
• Управление сбалансированным портфелем — компетенция SAFe® — SAFe Russia

V. Мощность и портфель

Эта часть — авторская интеграция практик постановки целей, потоковой экономики и портфельного управления. Практическая схема обобщает подходы, описанные в материалах SAFe Russia: WSJF-приоритизацию, управление сбалансированным портфелем и OKR в портфеле

Источники:

• WSJF — SAFe Russia
• Управление сбалансированным портфелем как компетенция SAFe — SAFe Russia
• Цели и ключевые результаты (OKR) в SAFe — SAFe Russia

Глава 13. Ограничения и доступная мощность

Модель мощности: Ограничения → единая очередь → линия мощности → проверка баланса.

Шаг 1. Ограничения. Сначала зафиксируйте работу, которую объективно нельзя не сделать:

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

Это входное ограничение квартала, а не «корзина с квотой».

Шаг 2. Мощность для выбора. Определяется как:

доступная мощность команд − жёсткие обязательства − резерв на предсказуемый внеплан

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

Глава 14. Единая очередь инициатив

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

Тип работы сохраняется как аналитический атрибут, но по умолчанию не даёт автоматического права на отдельную долю мощности. Базовый режим — единая очередь без заранее заданных долей: доли создают «вторую» систему приоритетов и маскируют реальную ценность работы (см. Главу 12).

При этом заранее заданные доли по типам (например, 60% продукт / 20% техдолг / 10% поддержка / 10% исследования) могут быть осознанным решением конкретной компании: явная политика руководства на период, объявленная и пересматриваемая. Такие доли — исключение, а не дефолт, они не заменяют единую очередь, а ограничивают её явно. Скрытые квоты и «корзины с процентами», введённые без явного решения, остаются антипаттерном.

Глава 15. Линия мощности

Проходите по инициативам сверху вниз в порядке WSJF. Инициатива получает статус Committed, только если:

1. есть связь с Objective или KR, либо явное стратегическое обоснование;
2. доступна необходимая команда и дефицитные компетенции;
3. ключевые зависимости выполнимы в течение цикла;
4. инициатива не перегружает узкое место или критический поток.

Если инициатива заблокирована, вместо насильственного включения:

• включите работу по снятию зависимости;
• уменьшите объём;
• выделите MVP;
• замените поставку discovery (исследованием) или пилотом;
• переведите инициативу в Aspirational;
• перенесите в Not now.

Глава 16. Решения о запуске инициатив в работу

Используйте статусы:

• Committed — берём в цикл, работа обеспечена мощностью;
• Aspirational — желаем сделать при появлении мощности;
• Discovery — исследуем, прежде чем решать;
• Not now — осознанно отложено.

Для каждого решения зафиксируйте основание и условия пересмотра. Решение о запуске инициативы в работу фиксируется в итоговой таблице инициатив (Глава 20, Приложение З).

Глава 17. Проверка баланса

Проверяйте сформированный набор принятых инициатив:

• достижимость ключевых KR;
• покрытие существенных рисков (Глава 10);
• наличие инвестиций в снижение неопределённости;
• создание будущих возможностей;
• отсутствие чрезмерной концентрации дефицитной мощности;
• реализуемость по командам, ролям и зависимостям.

Если набор принятых инициатив несбалансирован — меняйте состав конкретных инициатив: остановите или перенесите слабую работу, уменьшите объём, выделите MVP, замените поставку пилотом или discovery, включите снятие блокирующей зависимости, пересмотрите оценки ценности, срочности, риска или размера.

Не исправляйте дисбаланс введением скрытых квот.

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

VI. Квартальное планирование

Глава 18. Подготовка к сессии

До сессии планирования:

1. соберите итоги прошлого цикла: оценки KR, ретроспективу, выводы (Часть VII);
2. подготовьте стратегический контекст: фокус года, показатели, ограничения;
3. соберите кандидатов в инициативы и результаты предварительной приоритизации;
4. зафиксируйте жёсткие обязательства и ожидаемые резервы мощности (Глава 13);
5. рассчитайте доступную мощность команд по ролям;
6. назначьте даты, участников и фасилитатора, разошлите материалы заранее.

Подготовка определяет качество сессии: без входа от прошлого цикла и без явного стратегического контекста команды уходят в «свои» темы

Источник:

• Как сформировать качественные OKR — OKR Russia

Глава 19. Сценарий квартальной сессии

Сценарий включает 17 этапов. Для каждого этапа заданы девять управляющих параметров. Фасилитатор ведёт сценарий по этому регламенту и помогает группе фиксировать результаты в таблице (Глава 20).

Логика последовательности

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

1. Содержание (этапы 1–4). Стратегический фокус года задаёт Objectives, Objectives — измеримые KR, а KR позволяют увидеть кросс-командные зависимости. До фокуса бессмысленны цели, до целей — KR, до KR — связи команд.

2. Кандидаты раньше оценки (этапы 5–7). Инициативы собираются до приоритизации — иначе оценочные споры подавят брейншторм. Затем формулируются гипотезы эффекта каждой инициативы, а параллельно фиксируются жёсткие обязательства: они занимают мощность вне конкурса WSJF.

3. Взвешивание и срез (этапы 8–12). WSJF применим только к полному списку кандидатов (этапы 5–7). Мощность считается отдельно (этап 9). Единая очередь (этап 10) и проход линии мощности (этап 11) превращают «хотим всё» в «сделаем в этом квартале». Проверка баланса (этап 12) держит под контролем результат среза по покрытию целей и рисков.

4. Согласование и ритм (этапы 13–17). Защита командных OKR → голосование уверенности (Fist of Five, порог ≥3) → фиксация решений с владельцами → назначение расписания → ретроспектива сессии: план становится исполнением цикла (Часть VII).

Сценарий опирается на сочетание практик целевой постановки и встреч по прогрессу, описываемых в программах подготовки OKR-мастеров (см. Главу 28)

Источник:

• Школа «Мастер OKR» — тренинги Лидеры изменений

Глава 20. Планирование в таблице

На старте системы ведите OKR в Google Таблицах, Яндекс Таблицах или Excel. Этот контур быстрый, прозрачный и не требует покупки ПО; автоматизация позже переезжает на специализированные системы (Глава 30).

Готовые шаблоны для старта:

• Простой трекер OKR — базовая таблица: цели, ключевые результаты и значения по неделям;
• Продвинутый трекер OKR — годовые и квартальные цели, реестры рисков и инициатив, трекер квартальных OKR.

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

Листы таблицы

Таблица состоит из логических разделов (отдельных листов или блоков):

1. Цели и KR — целевые результаты всех уровней.
2. Инициативы — единая очередь с WSJF.
3. Принятые инициативы — итоговая очередь с решениями и статусами (итоговая таблица инициатив).
4. Риски — реестр рисков OKR (Приложение Н).
5. Зависимости — кросс-командные связи.
6. Мощность — загрузка команд и ролей.

Правила заполнения

• Цели и KR. Обязательные поля: Objective, KR, метрика, исходное значение, целевое значение, единица, срок, владелец, прогресс, % и уверенность. Значения выбираются из списков, где это возможно: статус, тип работы, владелец.
• Инициативы. Обязательные поля по карточке (Прил. В) и оценки BV, TC, RR/OE, JS. Прогресс и уверенность KR обновляет владелец по факту.
• Формулы. Прогресс считается автоматически: (текущее − исходное) / (целевое − исходное), с учётом направления (и рост, и снижение). Для дискретных KR прогресс — 100% при выполнении критерия, иначе 0%. Прогресс ограничивается 0–100%.
• Риски и зависимости фиксируются в своих реестрах (Приложение Н, Приложение Ж) и привязываются к целям/KR/инициативам.
• Линия мощности проводится в итоговой таблице инициатив по статусам (Глава 15).
• Решения о запуске инициатив в работу записываются в колонке «Решение» с основанием.

Итоговая таблица инициатив:

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

Источник:

• Показатели устойчивости OKR-процесса — OKR Russia

Глава 21. Действия после сессии

После сессии:

1. разошлите итоговую таблицу инициатив и командные OKR всем участникам;
2. зафиксируйте расписание чекинов, обзоров и ретроспективы;
3. подтвердите владельцев целей и KR;
4. обеспечьте видимость OKR для всех команд (прозрачность — базовое свойство подхода, Глава 1);
5. согласуйте, что вносится в таблицу между встречами.

VII. Исполнение цикла

Глава 22. Регулярный check-in

Чекин (progress-встреча) — короткая регулярная встреча команды по прогрессу целей. Чекин не превращается в статусное совещание: новости о выполнении задач собираются в отчётах, а здесь обсуждается движение к результату.

Используйте четыре вопроса:

1. Что изменилось в данных?
2. Насколько команда уверена в достижении цели?
3. Какие препятствия мешают?
4. Какие инициативы нужно начать, остановить или изменить?

В ходе чекина обновляются: фактические значения KR; уровень уверенности; препятствия и зависимости; решения по инициативам и статусам инициатив; действия по существенным рискам из реестра (Глава 10). Регулярный короткий ритм чекинов поддерживает систему живой; прогресс на встречах обсуждается не по ощущениям, а по метрикам. Практика прогресс-встреч описывается в программах подготовки OKR-мастеров

Источник:

• Тренинг «Мастер OKR» — тренинги Лидеры изменений

Чек-лист чекина — в Приложении И. Связь чекина с реестром рисков — см. Главу 10.

Глава 23. Промежуточный обзор

В середине цикла проводится обзор системы в целом:

• сравнение фактического прогресса по KR с целевой траекторией;
• пересмотр существенных рисков и уровня уверенности (Глава 10);
• пересмотр статусов инициатив и решений о запуске инициатив в работу (что остановить, что ускорить);
• корректировка целей, если обстоятельства существенно изменились.

Цели не «трогают» по любому поводу: изменение OKR должно быть решением, а не дефолтом. Промежуточный обзор — естественное место для осознанной коррекции и переговоров по зависимостям. Шаблон — Приложение К.

Глава 24. Итоговый обзор

В конце цикла команды дают честную оценку прогресса по каждому KR (от 0 до 100% или по шкале 0–1). Оценка опирается на фактическое значение метрики, а не на самооценку «мы старались». Прозрачные оценки целей — часть дисциплины подхода; на обзоре в конце квартала фиксируется процент достижения целей

Источник:

• Показатели устойчивости OKR-процесса — OKR Russia

Итоговый обзор:

1. фиксирует итоговые значения KR и достижение целей;
2. определяет, какие цели переходят в следующий цикл (со скорректированными KR);
3. собирает доказательства того, что изменилось и что не сработало;
4. передаёт материал в ретроспективу (Глава 25).

Глава 25. Ретроспектива цикла

Ретроспектива отвечает на вопросы: что в системе OKR работало, что нет и что меняем в следующем цикле. Обсуждаются процесс, качество целей, качество KR, приоритизация и встречи — а не достижение как таковое.

План ретроспективы: собрать факты и оценки → провести обсуждение по темам → сформировать действия на следующий цикл. Полезно отдельно уточнить, что команда узнала о рисках: какие риски реализовались и почему, какие ранние индикаторы сработали, какие действия по снижению оказались эффективными. Именно выводы ретроспективы становятся входом для следующей сессии планирования (Глава 18). Практика ретроспектив и работы с инсайтами описана в материалах сообщества.

Источники:

• Инструменты ретроспективы в OKR — OKR Russia
• База знаний OKR Russia

VIII. Запуск и развитие

Глава 26. Запуск пилота

Пилот — внедрение OKR в опытном контуре: в одном направлении или в 1–2 командах, с явными задачами и ограничением по времени. Задачи пилота:

1. проверить, что цели действительно связаны со стратегией;
2. отработать ритм чекинов и обзоров;
3. настроить артефакты (таблицы, реестры);
4. выявить трудности формулирования KR и приоритизации;
5. обучить первых владельцев на реальной практике.

Правила пилота: одна-две команды; цели от 1 до 3 на команду; короткий горизонт проверки (до 90 дней с первой сессии); явный спонсор. Прозрачность пилота даёт материал для решений о масштабировании. Опыт первых команд и подводные камни начала описаны в сообществе практиков и на конференциях; крупные кейсы публикуются как разборы внедрений

Источники:

• Конференция OKR Russia
• Как в «Росгосстрахе» ставят и синхронизируют годовые OKR всего бизнеса — OKR Russia

Глава 27. План первых 90 дней

Индивидуальные дорожные карты внедрения и разборы практик публикуются в сообществе

Источник:

• Дайджест OKR Russia — Лидеры изменений

Глава 28. Обучение и развитие компетенций

Однодневный воркшоп по OKR — это ознакомление, а не подготовка к ведению системы. Системное обучение включает:

• роли, встречи и инструменты гайда (Части II, VI–VII);
• управленческий контур: стратегический фокус и приоритизация целей (Части I, III);
• практику постановки качественных KR (Глава 9);
• наставничество первых циклов;
• разделение треков для руководителей, команд и OKR-мастеров.

Обзор программ обучения

Программа	Формат	Фокус
Быстрый старт в OKR	бесплатный онлайн-курс самообучения (4 модуля)	первые шаги: что такое OKR, критерии успеха, цикл планирования и отслеживания
Обзор OKR	бесплатный онлайн-семинар (~2 часа)	общий обзор и ответы на вопросы: отличия от KPI, уровни и ритмы постановки OKR
Практик OKR	тренинг (онлайн)	навыки постановки OKR и план запуска у себя в компании, сертификация OKR Russia
Владелец OKR	тренинг (онлайн)	роль OKR Owner: постановка целей, вовлечение, управление бэклогом
Мастер OKR	тренинг (онлайн, 2 дня)	внедрение и поддержка OKR: фасилитация сессий, чекинов, обзоров, оценка качества целей
Школа Мастер OKR	программа (6 недель)	практика ведения OKR-команд с поддержкой тренеров и экспертов, сертификация OKR Russia

Перед обучением на роль мастера рекомендуется пройти базу («Практик OKR» или опыт использования OKR в компании). Полный список тренингов по OKR с материалами, тренерами и расписанием — на карте тренингов: Карта тренингов по OKR — Лидеры изменений

Глава 29. Метрики OKR-процесса

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

Качество формулировок.

• индекс качества OKR: средняя зрелость формулировок по чек-листу сообщества (шкала в 23 пункта);
• доля целей с измеримыми KR;
• показатели исследования: гордость за цели, достижимость при усилиях, изменение способов работы (см. Главу 4).

Работа процесса.

• регулярность чекинов и обновления данных;
• процент достижения OKR по итогам цикла;
• процент уверенности, с которым команды выходят с планирования;
• покрытие цикла событий (сколько чекинов, обзоров и ретроспектив фактически проведено);
• оценки участников качества проводимых событий.

Экономика процесса.

• стоимость процента уверенности от планирования (норматив — не более ~0,1–0,3 часа на процент уверенности);
• доля квартального фонда оплаты труда, которую занимает OKR-процесс;
• перераспределение усилий консультанта с прямой помощи на подготовку внутренних OKR-мастеров.

Публичный кейс показывает динамику: в квартале без системной работы над процессом достижение составило 29%, а при восстановлении планирования, чекинов и фокуса — 76% при меньших затратах

Источник:

• Показатели устойчивости OKR-процесса — OKR Russia

Ориентиры по качеству формулировок и типичному профилю компаний даёт исследование сообщества: понимание типичного профиля помогает сверять собственную систему с практикой отрасли

Источник:

• Исследование OKR в России 2026 — OKR Russia

Глава 30. Автоматизация

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

Сценарий 1. Таблицы как система. Цели, KR и инициативы ведутся в Google/Яндекс Таблицах; автоматизация — формулы, сводные листы, срезы, шаблоны.

Сценарий 2. Специализированная система. Переезд на OKR-платформу при необходимости: учёт обновлений и владельцев, панели прогресса и уверенности, интеграция с бэклогом и данными, сводные обзоры бэклога инициатив, ограничения ролей.

Сервисы российского рынка со своими возможностями (по публичным описаниям партнёров сообщества):

1. OKRSana — ведение OKR с элементами автоматизации;
2. TeamStorm — работа с целями и проектами, защита данных;
3. Shtab — трекинг целей и задач;
4. Яндекс.Трекер — управление задачами и целями в едином контуре;
5. Directum Targets — управление целями в корпоративном контуре;
6. OKRBuilder — OKR-шаблоны для Google Таблиц.

Сценарий 3. OKR в общем таск-трекере. Если команда уже ведёт работу в трекере задач и не готова вводить отдельную платформу, OKR можно вести в нём же. Это промежуточный вариант: он даёт привычный интерфейс, но не автоматику OKR-контура (сводные обзоры, проверку владельцев, линию мощности), поэтому по мере роста стоит переходить на специализированную систему.

На примере Atlassian Jira: Objective и Key Result заводятся как задачи верхнего уровня, прогресс KR хранится в собственном поле или считается по связанным задачам, связи «KR ↔ инициатива/задача» задаются связями между задачами, обзор прогресса и владельцев дают дашборды по фильтрам.

Варианты для других популярных решений:

Актуальный список и описание возможностей — на странице партнёров сообщества: Партнёры OKR Russia

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

Глава 31. Масштабирование

Предпосылки масштабирования:

• спонсор и хозяин системы работают системно;
• пилот показал достижимые KR и рабочую приоритизацию;
• команды подтверждают пользу чекинов;
• качество целей держится на уровне (Глава 29).

Масштабирование идёт волнами: обучение новых команд → сессии планирования по общему сценарию → подключение к общим реестрам рисков и зависимостей → общий бэклог инициатив (Часть V). Рост количества команд без усиления OKR-мастеров быстро вырождает систему в отчётность. Кейсы тиражирования и ограничения масштаба видны в исследовании по доле компаний с целями на нескольких уровнях

Источник:

• Исследование OKR в России 2026 — OKR Russia

Глава 32. Антипаттерны

Типичные ошибки внедрения:

• слишком много целей одновременно — теряется фокус;
• нематериальные KR — «ощущения вместо метрик»;
• подмена KR задачами и поставками (Глава 9);
• смешение OKR с оценкой и премированием персонала;
• жёсткое каскадирование целей по оргструктуре вместо согласования направлений;
• отсутствие стратегического контекста — команды формулируют цели без связи с компанией;
• введение скрытых квот и «корзин» по типам работ вместо единой очереди (Глава 14);
• правки целей по любому поводу — падение доверия;
• QA в конце цикла вместо честных обзоров.

Как не превратить внедрение OKR в «битву» и сохранить живым процесс — практические истории публикуются в сообществе

Источник:

• Одна большая маленькая битва за OKR — OKR Russia

Приложения

Приложение А. Конструктор Objective

Чтобы сформулировать Objective, ответьте последовательно:

1. Какое состояние мы хотим получить вместо текущего через два-три цикла?
2. Что изменится в поведении клиента, команды, продукта или рынка?
3. Какое изменение достойно амбиции, а не инкремента?
4. Как другие заметят изменение извне?

Проверка: цель задаёт направление («стать понятным лидером на рынке Х»), не число и не список работ.

Приложение Б. Паспорт Key Result

Приложение В. Карточка инициативы

Приложение Г. Таблица WSJF

Оценки — относительные по шкале 1, 2, 3, 5, 8, 13, 20; минимальную единицу принимаем условно за 1. Не путать с деньгами и днями (Глава 12).

Приложение Д. Реестр жёстких обязательств

Приложение Е. Таблица мощности команд

Приложение Ж. Реестр зависимостей

Приложение З. Итоговая таблица инициатив

Правила заполнения — Глава 20.

Приложение И. Шаблон чекина

Вопросы: 1) Как изменились данные по KR? 2) Насколько уверены в достижении? 3) Какие препятствия? 4) Какие инициативы начать/остановить/изменить? Плюс: обновлённые значения и уверенность, действия по рискам (Глава 22).

Приложение К. Шаблон промежуточного обзора

• Фактический прогресс по каждому KR против траектории;
• пересмотр рисков и уверенности;
• решения по инициативам и статусам;
• скорректированные цели (только осознанные изменения).

Приложение Л. Шаблон итогового обзора

• Оценка каждого KR (0–100% или 0–1) по фактической метрике;
• достижение/недостижение Objective;
• переход целей в следующий цикл (с новыми KR);
• доказательства изменений — вход в ретроспективу.

Приложение М. Чек-лист качества OKR-системы

• [ ] Objectives амбициозны и задают направление, а не поставки
• [ ] 1–3 цели на цикл на уровне команды/направления
• [ ] KR измеримы, есть исходное и целевое значения
• [ ] прогресс и уверенность обновляются в ритме чекинов
• [ ] инициативы связаны с KR и описаны гипотезой
• [ ] приоритизация инициатив — по WSJF в единой очереди
• [ ] жёсткие обязательства фиксированы, резерв учтён
• [ ] линия мощности проведена, статусы определены
• [ ] риски и зависимости ведены в реестрах (Приложение Ж, Приложение Н)
• [ ] OKR не связаны с премированием жёстко
• [ ] чекины, обзоры, ретроспектива стоят в календаре
• [ ] цели прозрачны для всех команд

Приложение Н. Реестр рисков OKR

Заполняется на сессии планирования и обновляется на чекинах (Глава 10).

Правила ведения:

• [ ] каждый существенный риск привязан к Objective, KR или инициативе
• [ ] у каждого риска есть категория ROAM (Resolved / Owned / Accepted / Mitigated), присвоенная на обсуждении
• [ ] у каждого риска есть ранний индикатор, проверяемый в ритме чекинов
• [ ] у каждого риска есть владелец и срок
• [ ] действие по снижению оформляется как задача или инициатива в единой очереди (Часть V)
• [ ] статус обновляется на чекинах (Глава 22) и пересматривается на промежуточном обзоре (Глава 23)

Приложение О. Глоссарий

• Aspirational — цель/инициатива-желание при появлении мощности.
• CoD — стоимость задержки (BV+TC+RR/OE).
• Committed — инициатива, обеспеченная мощностью; обязательная для исполнения в цикле.
• Check-in — короткая регулярная прогресс-встреча команды по достижению OKR.
• Discovery — исследование перед решением о включении инициативы.
• JS — размер работы, относительная оценка.
• KR — ключевой результат, измеримый критерий достижения цели.
• Not now — осознанно отложенная инициатива.
• Objective — амбициозная цель, задающая направление.
• OKR — цели и ключевые результаты, подход к постановке амбициозных целей.
• WSJF — Более Ценная и Короткая Работа Сначала, приоритизация по CoD/JS.
• Инициатива — гипотеза влияния на KR.
• Уверенность — субъективная оценка достижимости результата.