OKR с AI: от размытых целей к измеримым Key Results за 30 минут

74% компаний, внедривших OKR, не достигают заявленных Key Results. Исследование Perdoo (2023, 600+ компаний) называет главную причину: проблема не в исполнении, а в формулировках. Key Results либо неизмеримы (“улучшить пользовательский опыт”), либо подменяют метрику активностью (“провести 10 встреч с клиентами”), либо оторваны от Objective настолько, что выполнение всех KR не приближает к цели.

Традиционный процесс постановки OKR занимает 2-4 недели: стратегическая сессия, каскадирование по командам, согласование между отделами, несколько раундов правок. Квартал начинается с устаревшими целями, а формулировки отражают компромисс между участниками, а не реальные приоритеты.

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

Анатомия хорошего OKR

Objective отвечает на вопрос “куда движемся”. Key Results отвечают на вопрос “откуда узнаем, что пришли”. Два правила нарушают чаще всего.

Objective — качественный, амбициозный, вдохновляющий. Без цифр. Objective — это направление, не метрика. “Стать лидером по скорости доставки в регионе” — Objective. “Сократить время доставки до 2 часов” — уже Key Result.

Key Result — количественный, ограниченный по времени, проверяемый. Формула: глагол + метрика + от [текущее значение] до [целевое значение]. Результат, который проверяется без субъективной оценки.

Плохие OKR vs хорошие OKR

Плохой OKR	Проблема	Хороший OKR
O: Улучшить продукт	Размыто, нет направления	O: Сделать онбординг настолько простым, что пользователи не обращаются в поддержку
KR: Провести 15 пользовательских интервью	Активность, не результат	KR: Снизить количество тикетов поддержки по онбордингу с 120 до 30 в месяц
KR: Улучшить UX	Неизмерим	KR: Увеличить completion rate первой сессии с 34% до 70%
KR: Запустить новую фичу	Бинарный output	KR: Достичь 40% adoption rate новой фичи среди активных пользователей за 6 недель

Три паттерна плохих Key Results:

Activity-based. “Провести 10 встреч”, “написать 20 постов”, “запустить 3 кампании”. Это задачи, не результаты. Встречи можно провести впустую, посты могут не принести трафик.
Binary. “Запустить мобильное приложение”, “внедрить CRM”. Либо да, либо нет. Нет шкалы прогресса, нет сигнала о частичном достижении.
Vanity metrics. “Увеличить просмотры страницы до 100K”. Просмотры без привязки к конверсии или retention — шум, не сигнал.

Промпт для генерации OKR из стратегического контекста

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

Роль: ты — опытный OKR-коуч с 10-летним стажем в технологических компаниях.

Контекст компании:
- Продукт: [описание продукта, стадия, бизнес-модель]
- Размер команды: [число людей, структура]
- Текущие метрики: [MRR, MAU, churn, NPS, conversion — всё что есть]
- Стратегические приоритеты на квартал: [1-3 приоритета]
- Ограничения: [бюджет, технический долг, зависимости от других команд]

Задача: сгенерируй 3 Objectives с 3-4 Key Results каждый на [Q_ 20__].

Требования к Objectives:
- Качественные, без цифр
- Амбициозные, но достижимые (70% вероятность выполнения)
- Привязаны к стратегическим приоритетам
- Формулировка от первого лица команды ("Мы...")

Требования к Key Results:
- Формат: [глагол] + [метрика] + от [текущее] до [целевое]
- Каждый KR измерим без субъективной оценки
- Никаких activity-based KR (не "провести", "запустить", "написать")
- Никаких бинарных KR (не "да/нет")
- Baseline (текущее значение) обязателен — если неизвестен, укажи "[уточнить]"
- Для каждого KR укажи источник данных (где проверить метрику)

Антипаттерны (избегай):
- KR, которые контролируются внешними факторами (курс валют, действия конкурентов)
- KR без связи с Objective
- Больше 4 KR на один Objective
- Метрики тщеславия (vanity metrics)

Формат вывода:
## Objective 1: [формулировка]
- KR 1.1: [формулировка] | Baseline: [X] → Target: [Y] | Источник: [где проверить]
- KR 1.2: ...
- KR 1.3: ...
Связь со стратегией: [какой приоритет закрывает]

Пример заполненного промпта

Контекст компании:
- Продукт: B2B SaaS для управления проектами, стадия growth, подписная модель
- Размер команды: 18 человек (8 инженеров, 3 продукт, 4 маркетинг, 3 саппорт)
- Текущие метрики: MRR $85K, MAU 2,400, churn 6.2%/мес, NPS 38, trial-to-paid 12%
- Стратегические приоритеты на квартал: снижение оттока, рост конверсии триала
- Ограничения: нет бюджета на paid acquisition, техдолг в модуле интеграций

Задача: сгенерируй 3 Objectives с 3-4 Key Results каждый на Q2 2026.

Типичный результат после этого промпта:

Objective 1: Мы превращаем триальных пользователей в лояльных клиентов

KR 1.1: Увеличить trial-to-paid конверсию с 12% до 20% | Источник: Stripe Dashboard
KR 1.2: Сократить time-to-first-value с 4.2 дней до 1.5 дней | Источник: Mixpanel
KR 1.3: Достичь 60% activation rate (создание первого проекта + приглашение коллеги) с текущих 28% | Источник: Product analytics

Objective 2: Мы делаем продукт настолько полезным, что клиенты не уходят

KR 2.1: Снизить monthly churn с 6.2% до 3.5% | Источник: Stripe/ChartMogul
KR 2.2: Увеличить NPS с 38 до 50 | Источник: квартальный NPS-опрос
KR 2.3: Увеличить weekly active usage с 3.1 до 4.5 сессий/пользователь | Источник: Amplitude
KR 2.4: Снизить время ответа саппорта с 4 часов до 1 часа (медиана) | Источник: Intercom

Objective 3: Мы выстраиваем органический growth engine, который работает без рекламного бюджета

KR 3.1: Увеличить органический трафик с 8,200 до 15,000 визитов/мес | Источник: Google Analytics
KR 3.2: Достичь 15% referral rate (приглашения от существующих пользователей) с текущих 4% | Источник: Product analytics
KR 3.3: Опубликовать 8 кейсов с клиентами, каждый с конверсией в trial > 2% | Источник: GA + UTM

Промпт для проверки существующих OKR

Команды, которые уже составили OKR вручную, получают больше пользы от ревью-промпта, чем от генерации с нуля. LLM находит слабые формулировки за секунды.

Роль: OKR-аудитор. Проверь следующие OKR по критериям качества.

OKR для проверки:
[вставить текущие OKR]

Проверь каждый Key Result по чеклисту:
1. Измеримость: можно ли проверить без субъективной оценки? (да/нет)
2. Тип: outcome (результат) или output (активность)?
3. Baseline: указано текущее значение? (да/нет/неизвестно)
4. Амбициозность: вероятность достижения ~70%? (заниженный/нормальный/нереалистичный)
5. Связь с Objective: достижение всех KR = достижение Objective? (да/частично/нет)
6. Контролируемость: команда контролирует результат? (полная/частичная/внешняя)
7. Конфликты: противоречит ли какому-то другому KR? (нет/указать какому)

Для каждого слабого KR предложи улучшенную формулировку.

Итого:
- Оценка набора OKR: [1-10]
- Критические проблемы: [список]
- Рекомендации: [список]

Этот промпт выявляет четыре типичные проблемы.

Activity-based KR, замаскированные под результаты. “Внедрить систему автоматического онбординга” звучит как результат, но это output. LLM предложит замену: “Увеличить долю пользователей, завершивших онбординг без обращения в поддержку, с X% до Y%”.

Отсутствие baseline. KR “увеличить конверсию до 25%” бесполезен без текущего значения. Если сейчас 24% — это не амбициозная цель. Если 5% — нереалистичная.

Несвязанность KR с Objective. Objective про удержание клиентов, а один из KR про количество публикаций в блоге. LLM отмечает разрыв и предлагает связать через метрику: “Увеличить repeat visit rate из блога с X% до Y%”.

KR-конфликты. “Сократить time-to-market” и “увеличить test coverage до 90%” в одном наборе создают напряжение. LLM не решит, что важнее, но покажет конфликт.

Промпт для каскадирования OKR по командам

Компания поставила верхнеуровневые OKR. Каждая команда создаёт свои, поддерживающие общие. Этот процесс согласования — самое затратное место во всём OKR-цикле.

Контекст:
Компания поставила следующие OKR на [квартал]:
[вставить company-level OKR]

Команда: [название, функция, размер]
Зона ответственности команды: [что контролирует команда]
Текущие метрики команды: [специфичные метрики]

Задача: сгенерируй 2 Objectives с 3 Key Results для этой команды,
которые поддерживают company-level OKR.

Требования:
- Каждый team-level Objective должен явно поддерживать один company-level Objective
- KR должны быть в зоне контролируемости команды
- Укажи связь: Team KR → Company KR (какой именно)
- Избегай дублирования с другими командами

Формат:
## Team Objective 1: [формулировка]
Поддерживает: Company Objective [N]
- KR 1.1: [формулировка] | → влияет на Company KR [X.Y]

30-минутный процесс OKR-сессии

Полный процесс от стратегических приоритетов до готовых OKR укладывается в 30 минут.

Минуты 0-5: сбор контекста

Зафиксировать входные данные для LLM:

Стратегические приоритеты (не больше 3)
Текущие метрики (все доступные)
Ограничения и зависимости
Результаты прошлого квартала (что достигнуто, что нет)

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

Минуты 5-15: генерация черновика

Использовать промпт генерации из раздела выше. Запустить 2-3 раза с разной температурой или переформулированными приоритетами. Это даст 6-9 Objectives и 18-27 Key Results. Избыток намеренный.

Минуты 15-25: фильтрация и доработка

Из сгенерированных вариантов выбрать 2-4 Objective. Для каждого оставить 3 KR. Критерии отбора:

Стратегическое соответствие. KR приближает к стратегическому приоритету напрямую, а не через три посредника.
Измеримость на практике. Метрика существует в текущих инструментах. KR “увеличить customer lifetime value” бесполезен, если CLV не считается.
Контролируемость. Команда может повлиять на метрику своими действиями за квартал.
Отсутствие конфликтов. KR не противоречат друг другу внутри набора.

Прогнать финальный набор через промпт аудита. Исправить найденные проблемы.

Минуты 25-30: финализация

Зафиксировать итоговые OKR с baseline, target и источником данных. Определить частоту check-in (еженедельно или раз в две недели). Назначить ответственного за каждый KR.

Промпт для mid-quarter ревью OKR

OKR без регулярной проверки — декорация. Mid-quarter check-in определяет, нужна ли коррекция курса.

Текущие OKR и прогресс:
[вставить OKR с текущими значениями метрик]

Прошло [X] недель из [Y] (квартал).

Для каждого Key Result определи:
1. Статус: on track / at risk / off track
2. Прогноз: текущая траектория приводит к [X]% выполнения к концу квартала
3. Если at risk или off track:
   - Возможные причины (сформулируй как гипотезы)
   - 2-3 конкретных действия для коррекции курса
   - Стоит ли пересмотреть target (и почему)

Общая оценка набора OKR:
- Какие OKR стоит сохранить без изменений?
- Какие стоит скорректировать?
- Есть ли новые приоритеты, которые не отражены в текущих OKR?

Типичные ошибки при генерации OKR с AI

Принимать первый результат без фильтрации. LLM генерирует правдоподобные формулировки, но не знает реального контекста бизнеса. KR “достичь NPS 70” звучит хорошо, но если текущий NPS — 25, это нереалистично за квартал. Каждый KR требует проверки на адекватность.

Подавать слабый контекст. “Сгенерируй OKR для SaaS-стартапа” даёт generic результат. Чем конкретнее метрики, ограничения и приоритеты на входе, тем точнее OKR на выходе.

Игнорировать baseline. LLM часто генерирует KR без текущего значения: “увеличить retention до 85%”. Без baseline невозможно оценить амбициозность. Всегда требуйте формат “от X до Y”.

Использовать AI для замены обсуждения. OKR — инструмент alignment. Если команда не обсуждает цели, а получает готовые OKR из ChatGPT, теряется главная ценность: общее понимание приоритетов. AI генерирует черновик и проверяет формулировки. Решение о приоритетах остаётся за командой.

Ставить слишком много OKR. LLM легко генерирует 10 Objectives с 40 Key Results. Это не помогает. Оптимум для команды: 2-4 Objectives, 3 KR на каждый. Больше — потеря фокуса.

Чеклист качества OKR

Финальная проверка перед фиксацией OKR. Каждый пункт бинарный (да/нет). Если хотя бы один “нет” — доработать.

На уровне Objective:

Формулировка качественная (без цифр)
Понятно направление движения
Амбициозный, но достижимый
Привязан к стратегическому приоритету

На уровне Key Result:

Формат “глагол + метрика + от X до Y”
Измерим без субъективной оценки
Указан baseline (текущее значение)
Указан источник данных
Результат, не активность
Команда контролирует метрику
Не конфликтует с другими KR

На уровне набора:

2-4 Objectives, 3 KR на каждый
Выполнение всех KR = достижение Objective
Нет дублирования между Objectives
Назначены ответственные
Определена частота check-in

Интеграция с существующими процессами

Quarterly planning. OKR ставятся в начале квартала. AI-генерация ускоряет процесс, но не отменяет стратегической сессии. Промпт генерации используется до сессии (подготовка черновика) или во время (быстрая итерация).

Sprint planning. Задачи спринта привязываются к KR. Каждая задача отвечает на вопрос “какой KR это приближает?”. Задачи без привязки к KR — сигнал о рассинхронизации.

Weekly check-in. Обновление прогресса по KR. Автоматизируется: метрики подтягиваются из аналитических инструментов и подаются в промпт mid-quarter ревью.

Retrospective. В конце квартала — скоринг OKR (0-1.0) и анализ. Промпт для ретроспективы:

Результаты квартала:
[OKR с финальными значениями метрик, скоринг 0-1.0]

Проанализируй:
1. Паттерны: какие типы KR систематически перевыполняются / не достигаются?
2. Причины: что помогло / помешало?
3. Рекомендации для следующего квартала:
   - Какие KR стоит продлить
   - Какие OKR закрыты и не нуждаются в продолжении
   - Какие новые приоритеты появились

Что дальше

OKR — один элемент операционной системы компании. Генерация целей с помощью AI работает лучше в связке с другими процессами: SOP-документацией для фиксации процессов, которые поддерживают KR, и context engineering для подачи правильного контекста в каждый промпт.

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

FAQ

Через сколько OKR-циклов AI-генерация становится стабильно полезной?

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

Какие метрики использовать в Key Results: опережающие (leading) или запаздывающие (lagging)?

Оба типа, но сбалансированно. Lagging-метрики (отток, MRR) показывают, был ли Objective в итоге достигнут; leading-метрики (activation rate, time-to-first-value) дают ранние сигналы в течение квартала. Хорошо структурированный набор OKR обычно содержит 1-2 lagging KR и 1-2 leading KR на каждый Objective. Чисто lagging KR делают коррекцию курса невозможной в середине квартала; чисто leading KR можно выполнить, пока базовый бизнес-результат так и не достигается.

Что делать, если важный KR не имеет текущего baseline?

Отметить явно как “[уточнить]” в выводе промпта — именно такое соглашение используется в шаблонах этой статьи. Не пропускать KR и не угадывать baseline. Первое действие после OKR-сессии — установить базовое измерение: инструментировать событие, получить исторические данные или провести недельный sprint по измерению. KR без baseline — это обязательство без отправной точки: невозможно понять, является ли цель амбициозной или тривиальной, и осмысленно отслеживать прогресс.