Сначала назовите решение

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

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

Таблица применимости

Ситуация

План

KPI

OKR

Что сочетать

Результат и путь известны

Основной инструмент

Контроль срока/качества

Обычно не нужен

План + guardrail KPI

Нужно держать стабильный сервис

Рутинные улучшения

Основной инструмент

Только для заметного изменения

KPI + backlog действий

Нужен новый outcome, путь неясен

Initiatives после выбора

Guardrails и baseline

Основной инструмент

OKR + KPI + план экспериментов

Разовый обязательный проект

Milestones и acceptance

Немного health metrics

Только если цель — изменение outcome

План + risk review

Нет надёжного источника данных

Сначала data task

Не вводить фальшивый KPI

Не писать числовой KR

План создания измерения

Команда из нескольких ролей зависит друг от друга

Обязательства и handoffs

End-to-end health

Shared outcome при необходимости

Один owner каждого элемента

Таблица — редакционная методика, а не стандарт. Она помогает задать вопросы, но решение зависит от зрелости данных, риска и длительности обратной связи.

Когда достаточно обычного плана

План подходит, когда можно назвать конкретный output, критерий приёмки, владельца, зависимости и срок. Его единица — обязательство, а не активность ради активности. Строка «заняться онбордингом» не годится; строка «утвердить и проверить процесс онбординга на согласованных сценариях» имеет результат и acceptance.

  • Outcome или output: что должно существовать или измениться.

  • Acceptance: кто и по каким признакам принимает результат.

  • Owner: один ответственный за завершение.

  • Dependencies: входы и решения других ролей.

  • Milestones: точки, после которых меняется риск, а не календарный декор.

  • Risk/assumption: что может сделать план неверным.

  • Review: когда пересмотреть scope, а не молча передвинуть дату.

Когда нужен KPI

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

Поле карточки KPI

Содержание

Purpose

Какое решение поддерживает показатель

Definition

Событие, объект, включения и исключения

Formula

Числитель, знаменатель, единица и окно

Source

Система, таблица, запрос и owner качества данных

Baseline/target

Фактическая точка отсчёта и согласованная цель

Cadence

Когда данные обновляются и когда принимается решение

Guardrails

Что нельзя ухудшить ради основной метрики

Change log

Когда и почему менялись definition или source

Baseline и target нельзя придумывать по рынку. Если данных нет, первая управленческая задача — создать определение и получить начальный период наблюдений. До этого показатель имеет статус DATA_REQUIRED, а не удобное круглое значение.

Когда уместен OKR

OKR нужен, когда команда хочет заметно изменить outcome и должна сфокусировать поиск. Objective описывает ценное направление; Key Results показывают, что изменилось; Initiatives — выбранные действия. Выполнение инициативы не доказывает достижение Key Result.

Формулировка без вымышленных чисел может выглядеть так: Objective — «Сделать первый результат клиента предсказуемым и понятным». KR-шаблон — «Сократить медианное время до принятого результата с [подтверждённого baseline] до [обоснованного target] при guardrail [метрика качества]». Initiative — «Перепроектировать handoff и проверить новый процесс». Квадратные поля заполняют только после измерения.

  • Necessity: каждый KR действительно нужен для Objective?

  • Sufficiency: вместе KR достаточно описывают желаемое изменение?

  • Controllability: команда может влиять на результат, не скрывая внешние зависимости?

  • Data readiness: definition, source, owner и baseline существуют?

  • Guardrails: какое качество, доверие или безопасность нельзя обменять на прогресс?

  • Check-in: какое решение принимается при отставании или неверной гипотезе?

Слой из трёх инструментов

Не заставляйте один формат решать всё. Например, стабильный support-процесс имеет KPI здоровья. Команда ставит OKR на изменение клиентского outcome. Для экспериментов и миграций ведёт обычный план. KPI не становится автоматически KR: один и тот же показатель можно использовать как baseline или guardrail, но его роль должна быть подписана.

На общем обзоре проходите слои в порядке риска: сначала guardrails и критические KPI, затем прогресс outcome, затем ближайшие обязательства. Так выполненный список задач не перекрывает ухудшение системы, а красный KPI не уничтожает разговор о проверяемой гипотезе.

Примеры исправления формулировок

Слабая запись

Проблема

Рабочая форма

Внедрить CRM

Действие без принятого результата

План: настроить согласованный pipeline и пройти acceptance scenarios

Сделать клиентов счастливее

Нет observable outcome

Objective + KR с определённой клиентской метрикой и baseline

Отправлять больше предложений

Output может вредить качеству

KPI/plan только вместе с eligibility и acceptance guardrail

Провести пять встреч

Количество активности

Initiative; KR измеряет изменение знания или результата

Держать всё зелёным

Неясны definition и решение

Короткий KPI-набор с owner, source и action threshold

Review без механического статуса

Check-in — это обновление evidence и решения, а не цветной отчёт. Зафиксируйте actual, источник, изменение assumptions, препятствие и следующее действие. Если definition изменилась, не склеивайте ряд без пометки. Если target потерял смысл, сохраните исходную версию и причину пересмотра.

В конце периода отделите outcome от causal story. Изменение показателя не доказывает, что его вызвала конкретная initiative. Для причинного вывода нужен отдельный дизайн оценки; обычный OKR review не заменяет его.

Когда отказаться от OKR

  • Нет выбранного outcome или данных, но есть конкретные обязательные работы.

  • Команда не может влиять на KR и не имеет shared owner зависимости.

  • Период короче естественной обратной связи результата.

  • Все KR фактически являются списком initiatives.

  • Система в аварийном режиме и сначала требует восстановления guardrails.

  • Руководство собирается использовать score как псевдоточную оценку человека без отдельной performance policy.

Практический следующий шаг

Возьмите один текущий список целей. Для каждой строки поставьте P, K или O: plan commitment, KPI health либо OKR change. Заполните карточку определения для каждой метрики, удалите неподтверждённые числа, разделите Key Results и initiatives. Оставьте только те элементы, по которым на обзоре можно принять конкретное решение.

  • BUS-17 — шаблон процесса, для которого выбираются health metrics.

  • BUS-19 — delegation contract и owner управленческого элемента.

  • BUS-08 — финансовый план и сценарии вместо подмены прогнозом.

  • BUS-20 — договорённости партнёров о решениях и review.

Граница vendor-документации

Viva Goals прекращён 31 декабря 2025 года. Ссылки Microsoft Learn ниже нужны только для проверки того, как vendor описывал структуру OKR и check-in. Они не означают, что продукт доступен или рекомендован. Таблица выбора, карточка метрики и примеры в статье не требуют Viva Goals и реализуются в любом согласованном рабочем инструменте.

Что читать дальше

Источники и дата проверки

Источники проверены 26 июля 2026 года. Microsoft Learn — vendor guidance по OKR; GAO, ONS и UK government используются для различения monitoring, evaluation, indicators and outcomes, а не как обязательный стандарт частной компании.

Write effective OKRs that inspire action and deliver results — Официальная документация продукта: определения Objective, Key Result и Initiative, necessity/sufficiency tests; не независимое доказательство эффекта OKR.

Configure your OKR rules in Viva Goals — Показывает, что модель и правила OKR конфигурируются под процесс организации; vendor-specific settings.

Check in and update OKRs — Официальное guidance о check-ins, источнике данных и reflection; не устанавливает универсальную cadence.

Performance Measurement and Evaluation: Definitions and Relationships — Официальный glossary различает постоянное performance measurement и отдельную evaluation, включая impact evaluation.

ONS Evaluation Strategy — Official strategy: indicators brief/proportionate/relevant, baseline, target, source and ownership.

Performance and Monitoring — Актуальное government guidance о KPIs/milestones, longer-term outcomes, regular review и proportionality; grant scope ограничивает прямой перенос.

Magenta Book: Central Government guidance on evaluation — Официальная evaluation guidance о inputs, outputs, outcomes, monitoring data and theory of change; требует адаптации к малой команде.

Viva Goals retirement FAQ — официальный статус продукта: прекращён 31 декабря 2025 года; ссылка фиксирует ограничение применения vendor-документации.