OKR: что это, примеры ключевых результатов и отличие от KPI и SMART

Коротко

OKR — это одна качественная цель (Objective) и два-пять ключевых результатов (Key Results), по которым видно, достигнута ли цель. Цель отвечает на вопрос «куда идём», ключевые результаты — «как поймём, что дошли».

• Ключевой результат описывает изменение в поведении пользователей или в бизнесе, а не работу команды. «Запустить онбординг» — задача, «доля новичков с отчётом в первую неделю с 38% до 45%» — результат.
• У хорошего KR есть точное определение, базовое значение, целевое значение, источник данных и срок. Без базы цель невозможно оценить, без источника — проверить.
• OKR отличается от KPI ролью: KPI следят постоянно, OKR ставят на квартал, чтобы что-то сдвинуть. SMART — набор критериев к формулировке одной цели, а не система целей.
• В Google ключевые результаты оценивают от 0 до 1. Для амбициозных OKR нормальный итог — около 0,7, для обязательных ожидают 1,0.
• Аналитик отвечает за три вещи: чтобы KR можно было посчитать одним способом, чтобы цель не тонула в шуме и чтобы его нельзя было выполнить, не сдвинув продукт.

Что такое OKR простыми словами

Objective — короткая формулировка того, чего команда хочет добиться за период, обычно за квартал. Она качественная и должна быть понятна без расшифровки: «новички в первую неделю получают готовый отчёт и возвращаются». Key Results — измеримые признаки того, что цель достигнута: доля, число, время, сумма с базой и целевым значением.

Джон Дорр, который принёс методику в Google, сводит её к формуле «я добьюсь (цели), что будет измерено (ключевыми результатами)». Из формулы видно главное: ключевые результаты — это не план работ, а способ измерить цель. План работ существует отдельно, его называют инициативами.

Сколько их нужно? Google в руководстве re:Work советует ставить три-пять целей и около трёх ключевых результатов на каждую. Для продуктовой команды обычно хватает одной-двух целей на квартал: если целей пять, они начинают делить одних и тех же людей.

Откуда взялись OKR: Энди Гроув, Intel и Google

Методику придумал Энди Гроув, руководитель Intel. Его вариант вырос из управления по целям (management by objectives) Питера Друкера, и Гроув называл его iMBOs — Intel Management by Objectives. Отличия от исходной схемы, которые потом стали частью OKR: цели ставили на квартал, а не на год, и не связывали с оплатой труда. Гроув описал подход в книге «High Output Management».

Джон Дорр работал в Intel, научился методике у Гроува и позже, уже как инвестор, представил её основателям Google на рубеже 1999 и 2000 годов (у Дорра и в материалах Google даты немного расходятся). Само сокращение OKR, по данным сайта Дорра whatmatters.com, придумал он. В 2018 году вышла его книга «Measure What Matters»: в ней Дорр рассказывает историю методики и примеры её применения.

Google открыто описывает свой подход в руководстве re:Work: шкала оценки от 0 до 1, публичность OKR внутри компании и прямое правило, что OKR не равны оценке эффективности сотрудника. К этим трём пунктам мы вернёмся ниже — на них держится вся механика.

OKR, KPI и SMART: в чём разница

Три слова часто звучат на одном планировании и смешиваются. Разница в том, на какой вопрос отвечает каждое.

SMART — критерии формулировки одной цели. Аббревиатуру предложил консультант Джордж Доран в статье журнала Management Review в ноябре 1981 года. В оригинале буквы означали Specific (конкретная), Measurable (измеримая), Assignable (есть исполнитель), Realistic (реалистичная), Time-related (привязана ко времени). Вариант Achievable, Relevant, Time-bound появился позже. Сам Доран оговаривал, что не каждая цель будет отвечать всем пяти критериям и не всякую цель разумно переводить в числа.

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

Как написать ключевой результат: от результата, а не от задачи

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

Вторая ошибка — результат без базы. «Поднять удержание до 25%» звучит конкретно, но если сейчас 24,6%, это шум, а если 15%, это очень смелая цель. Пока не посчитано текущее значение тем же способом, которым будут считать в конце квартала, цель взята с потолка.

• Метрика и её определение: событие, окно, знаменатель, исключения. Два аналитика должны получить одно число.
• Базовое значение, посчитанное тем же способом на последних зрелых данных.
• Целевое значение и срок: к какой дате и по каким когортам оцениваем.
• Источник: таблица или дашборд, где число будет пересчитываться, и кто за этот источник отвечает.
• Контрольная метрика: что не должно ухудшиться, пока растёт KR.

Пример: OKR продуктовой команды на данных «Маяка»

«Маяк» — учебный сервис отчётов из Симулятора SQL-аналитика: регистрации с 1 июня по 29 августа 2026 года, события, платежи и подписки. Допустим, команда онбординга формулирует цель: «Новички в первую неделю получают от Маяка готовый отчёт и возвращаются». Цель условная, а базовые значения ниже — настоящие числа базы.

Кандидаты в ключевые результаты — три метрики: доля новичков, создавших отчёт в первые 7 дней; D7 retention (доля, которая была активна ровно на седьмой день после регистрации, как в статье про churn и retention); доля оплативших в первые 30 дней. Главное в запросе — зрелость когорт. Выгрузка обрывается 30 августа, поэтому 7-дневные метрики считаем по регистрациям до 22 августа включительно, а 30-дневную оплату — только по июню и июлю. Для августа запрос возвращает пустое значение, а не заниженное число.

По месяцам картина такая: отчёт за 7 дней — 43,6% в июне, 36,5% в июле, 38,0% в августе. D7 — 24,6%, 19,0% и 22,1%. Оплата за 30 дней — 27,1% в июне и 22,3% в июле. За всё время 38,8%, 21,4% и 24,1%, но среднее за весь период — плохая база, и вот почему.

with cohort as (
  -- у всех регистраций по 22 августа прошли 7 полных дней
  select user_id, signup_date, extract(month from signup_date) as month
  from users
  where signup_date <= date '2026-08-22'
),
per_user as (
  select c.user_id, c.signup_date, c.month,
         max(case when e.event_name = 'report_created'
                   and e.event_time < c.signup_date + 7 then 1 else 0 end) as report_7d,
         max(case when e.event_time::date = c.signup_date + 7 then 1 else 0 end) as active_d7
  from cohort as c
  left join events as e on e.user_id = c.user_id
  group by c.user_id, c.signup_date, c.month
),
paid as (
  select distinct c.user_id
  from cohort as c
  join payments as p
    on p.user_id = c.user_id
   and p.paid_at < c.signup_date + 30
)
select
  u.month,
  count(*) as signups,
  round(100.0 * avg(u.report_7d), 1) as report_7d_pct,
  round(100.0 * avg(u.active_d7), 1) as d7_pct,
  -- 30 дней прошли только у регистраций по 31 июля
  round(100.0 * count(p.user_id) filter (where u.signup_date <= date '2026-07-31')
        / nullif(count(*) filter (where u.signup_date <= date '2026-07-31'), 0), 1) as paid_30d_pct
from per_user as u
left join paid as p on p.user_id = u.user_id
group by u.month
order by u.month;

Какое значение взять за базу

В июне отчёт за неделю создавали 43,6% новичков, в июле — 36,5%. Продукт не ухудшился: с 1 июля в базе появился канал paid_search. Он дал 28,8% регистраций июля и 27,5% августа, а отчёт за 7 дней у этих людей создают 23–24%, тогда как у органики, рефералов и партнёров — от 33% до 49%. Если взять базой всё лето, в неё попадёт июнь без платного трафика, и цель окажется частично выполненной ещё до старта — просто потому, что состав трафика другой.

Поэтому базу берут по последнему зрелому периоду с текущим составом трафика: для отчёта и D7 — август (38,0% и 22,1%), для оплаты — июль (22,3%). Второе правило — смотреть на шум. Отчёт за 7 дней по неделям регистрации колеблется от 33,7% до 49,4%, а с июля — от 33,7% до 40,9%. Цель «+3 п.п.» при таком разбросе нельзя оценивать по одной неделе: только по месячным или квартальным когортам.

Три ключевых результата и их контрольные метрики

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

Как ключевые результаты накручивают и что делает аналитик

Доля — удобная метрика, но у неё два входа: числитель и знаменатель. Её можно поднять, не меняя продукт, если убрать из знаменателя тех, кто тянет показатель вниз. Проверим на августе: по всем каналам отчёт за 7 дней создали 529 человек из 1391, это 38,0%. Если отключить paid_search, останется 436 из 1008 — уже 43,3%. Ключевой результат вырос на 5,3 п.п., а людей с отчётом стало на 93 меньше.

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

У KR2 другая уязвимость. В учебной базе после первой недели записывается только вход в приложение, поэтому D7 здесь — это «открыл Маяк на седьмой день». Такой показатель поднимается пуш-уведомлением, которое заставит открыть приложение и сразу закрыть. В реальном продукте D7 для OKR лучше считать по ключевому действию, а если это невозможно — держать рядом долю активных, которые сделали что-то кроме входа.

У KR3 — скидки. Первый платёж легко купить промокодом, но если человек не продлил подписку, выручки не прибавилось. Из 493 первых платежей, сделанных по 30 июля, через 30 дней продлили 283, или 57,4%. Это и есть контрольная метрика: рост оплат при падении продлений — сигнал, что KR выполнили за счёт качества.

with cohort as (
  select user_id, signup_date, channel
  from users
  where signup_date between date '2026-08-01' and date '2026-08-22'
),
per_user as (
  select c.user_id, c.channel,
         max(case when e.event_name = 'report_created'
                   and e.event_time < c.signup_date + 7 then 1 else 0 end) as report_7d
  from cohort as c
  left join events as e on e.user_id = c.user_id
  group by c.user_id, c.channel
)
select
  count(*) as signups,
  sum(report_7d) as with_report,
  round(100.0 * avg(report_7d), 1) as kr_all_channels,
  count(*) filter (where channel <> 'paid_search') as signups_no_paid,
  sum(report_7d) filter (where channel <> 'paid_search') as with_report_no_paid,
  round(100.0 * avg(report_7d) filter (where channel <> 'paid_search'), 1) as kr_no_paid
from per_user;

Контрольная метрика для оплаты: продления

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

select
  count(*) as first_payments,
  count(r.payment_id) as renewed,
  round(100.0 * count(r.payment_id) / count(*), 1) as renewal_pct
from payments as f
left join payments as r
  on r.user_id = f.user_id
 and r.payment_type = 'renewal'
 and r.paid_at = f.paid_at + 30
where f.payment_type = 'first'
  and f.paid_at <= date '2026-07-30';

Как отслеживать прогресс OKR: оценка от 0 до 1

Google оценивает каждый ключевой результат по шкале от 0 до 1, а оценку цели получают как среднее по её KR. В руководстве re:Work нормальной зоной названы 60–70%: если команда стабильно получает 1,0, цели поставлены слишком низко. Во внутреннем плейбуке Google, который опубликован на whatmatters.com, OKR делят на два вида. Обязательные (committed) должны быть выполнены полностью, ожидаемая оценка — 1,0, а промах разбирают. Амбициозные (aspirational) описывают, где команда хотела бы оказаться; для них ожидаемая средняя оценка — 0,7 с большим разбросом.

Для метрик с базой удобно считать долю пройденного пути. Допустим, к концу квартала KR1 дошёл до 42,2%, KR2 — до 23,0%, KR3 — до 25,0% (условные значения). Тогда оценки: (42,2 − 38,0) / (45 − 38,0) = 0,6; (23,0 − 22,1) / (25 − 22,1) ≈ 0,31; (25,0 − 22,3) / (26 − 22,3) ≈ 0,73. Средняя по цели — около 0,55. Ниже амбициозной нормы, и разбор нужно начинать с KR2: он почти не сдвинулся.

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

Чем OKR опасны

Методика ломается предсказуемо, и почти всегда об этом можно договориться заранее.

• Закон Гудхарта. Как только по числу оценивают работу, его начинают двигать самым дешёвым способом — через знаменатель, определение или окно. Подробнее о механике — в статьях о KPI и о том, почему метрика обманывает. Защита — определение, зафиксированное до начала квартала, и контрольная метрика у каждого KR.
• KR-задачи. «Запустить», «провести», «внедрить» превращают OKR в план работ. Квартал выполнен на 1,0, продукт не изменился.
• Слишком много OKR. Пять целей по четыре KR — двадцать чисел, и команда незаметно выбирает те, что проще сдвинуть. Во внутреннем плейбуке Google среди ловушек отдельно названы цели, которые команда выполнит, ничего не меняя в работе, и цели с запасом мощности.
• Привязка к премии. В версии Гроува OKR были отделены от оплаты труда, а Google в re:Work прямо пишет, что OKR не равны оценке эффективности сотрудника. Если от оценки 1,0 зависят деньги, амбициозных целей не будет: все поставят то, что точно выполнят.
• Ключевые результаты, которые не складываются в цель. Если все KR выполнены на 1,0, а цель не достигнута, KR выбраны неверно. Проверка — дерево метрик: каждый KR должен стоять в ветке, ведущей к главной метрике продукта.
• Шум вместо результата. Цель «+2 п.п.» при недельных колебаниях в 7 п.п. оценивается подбрасыванием монетки. Размер цели сверяют с разбросом метрики до того, как её утвердить.

Как OKR связаны с метриками, гипотезами и экспериментами

Ключевые результаты удобно брать из дерева метрик: North Star наверху, под ней множители, ещё ниже — то, на что команда влияет напрямую. KR онбординга из примера — это узлы ветки активации; как выбрать событие для неё, разобрано в статье про activation rate.

Инициативы под OKR — это гипотезы. Каждую имеет смысл проверять отдельно, по HADI-циклу или A/B-тестом, где ключевой результат становится основной метрикой, а контрольная — guardrail-метрикой. Тогда к концу квартала команда знает не только итоговую оценку OKR, но и какая из инициатив её сдвинула.

Частые вопросы об OKR

Итог

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

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