Последние два года я работал Program Management Lead в Metamap.com и, среди прочего, помогал выстраивать OKR-фреймворк. OKR редко внедряются легко сами по себе. В нашем случае сложность усиливала распределенная команда: от Филиппин и Сингапура до западного побережья США и Гавайев.
Из этого опыта постепенно сложился список типичных проблем. На бумаге часть из них выглядит очевидно, в реальной работе быстро превращается в хаос: команды по-разному понимают цели, Key Results становятся набором пожеланий, обсуждение прогресса живет отдельно от ежедневной delivery-работы.
Ниже — пять частых ловушек при работе с OKR и agile-практики, которые помогают вернуть систему в рабочее состояние.
Короткое напоминание: что такое OKR
OKR состоит из двух элементов:
- Objective — качественная цель, направление движения, ответ на вопрос «какое изменение мы хотим получить?»;
- Key Results — измеримые результаты, по которым команда понимает, что цель действительно достигнута.
Звучит просто. На практике именно эта простота часто обманывает: компании быстро заводят шаблон в инструменте и затем обнаруживают, что цели записаны, общего понимания нет.
1. Команды слабо понимают OKR
Представьте футбольную команду, где половина игроков уверена, что играет в баскетбол. Все бегут, стараются, тратят энергию, результата нет. С OKR происходит то же самое, когда люди знают аббревиатуру, а механику фреймворка понимают по-разному.
Типичные симптомы:
- Objective записывают как список задач;
- Key Results превращаются в инициативы;
- команды спорят про формулировки, потому что заранее не договорились о смысле;
- руководители ждут стратегического выравнивания, сотрудники видят очередную форму отчетности.
Что помогает:
- провести нормальное обучение по OKR-фреймворку, без формального «вот ссылка на презентацию»;
- отдельно разобрать разницу между Objective как качественной целью и Key Results как измеримыми признаками успеха;
- привлечь OKR-коуча или выделить внутреннего фасилитатора, который помогает командам формулировать рабочие OKR;
- проводить воркшопы с практикой: участники берут реальные цели, переписывают их, проверяют измеримость и связь с приоритетами;
- показывать хорошие примеры OKR из других команд или компаний, чтобы у людей появился ориентир качества.
2. OKR рассинхронизированы между командами
Еще одна распространенная проблема — каждая команда пишет свои OKR в изоляции. На уровне отдельных документов все выглядит разумно. При совместной работе выясняется, что команды тянут продукт в разные стороны.
Это похоже на хор, где каждый участник поет свою песню. Голоса могут быть сильными, гармонии не получается.
Что помогает:
- использовать регулярные agile-события для синхронизации OKR: sprint planning, sprint review, retrospective, portfolio sync;
- во время планирования проверять, как командные OKR связаны с целями компании;
- на sprint review смотреть не только на сделанные задачи — еще и на вклад команды в Key Results;
- проводить общие review для нескольких команд, если они работают на один продуктовый результат;
- отдельно проговаривать зависимости между командами, чтобы OKR не превращались в локальную оптимизацию.
Главная мысль: OKR не должны жить отдельно от delivery-ритма. Если команда обсуждает цели раз в квартал, работу же планирует раз в две недели, эти два контура быстро расходятся.
3. Key Results становятся нереалистичными
Амбициозность — сильная сторона OKR. Проблемы начинаются, когда амбиция превращается в wishful thinking. Команда получает Key Results уровня «долететь до Луны», ресурсов на ракету нет, к концу квартала все делают вид, что так и было задумано.
Нереалистичные Key Results плохо влияют сразу на несколько вещей:
- люди перестают воспринимать цели всерьез;
- прогресс становится невозможно обсуждать честно;
- команда защищается от метрик вместо того, чтобы использовать их для фокуса;
- к концу цикла появляется демотивация: «мы снова не выполнили OKR».
Что помогает:
- использовать agile-принцип постепенного прогресса;
- разбивать большие результаты на промежуточные проверяемые шаги;
- связывать Key Results с ближайшими sprint goals, если команда работает спринтами;
- измерять прогресс после каждого спринта и корректировать ожидания, когда появляются новые данные;
- заранее проверять, есть ли у команды ресурсы, полномочия и поддержка, чтобы реально повлиять на выбранные Key Results.
Хороший Key Result должен напрягать команду, не превращая квартал в театр невозможных обещаний.
4. OKR перегружают и усложняют
Если для одной команды заводят слишком много целей, фокус исчезает. Формально OKR есть, фактически команда получает еще один список всего важного. Такой список не помогает выбирать, он просто повышает тревожность.
Сложные OKR обычно появляются из хороших намерений: хочется учесть все направления, никого не забыть, показать полный объем работы. В результате каждый Objective тянет за собой несколько Key Results, каждый Key Result — пачку инициатив, команда снова живет в режиме «все важно».
Что помогает:
- держать OKR простыми и lean;
- ограничивать количество OKR на команду;
- проверять, что каждый Key Result конкретный, измеримый и ограниченный по времени;
- регулярно упрощать формулировки, если они стали слишком тяжелыми;
- удалять цели, которые не помогают принимать решения.
Практичный тест: если OKR не помогает команде сказать «сейчас это важнее», значит он плохо выполняет свою работу.
5. Прогресс по OKR плохо коммуницируют
OKR быстро теряют смысл, когда прогресс виден только в конце квартала. Еще хуже, если у каждой команды свой источник правды: у одной — таблица, у другой — Jira, у третьей — презентация для руководства.
Тогда обсуждение целей превращается в испорченный телефон. Люди вроде говорят об одном и том же, смыслы постепенно расходятся.
Что помогает:
- использовать ежедневные синки, sprint review и регулярные командные встречи для обсуждения прогресса по OKR;
- держать прозрачный OKR-дашборд, где видны Objectives и Key Results каждой команды;
- обсуждать проблемы по ходу цикла, без большого разбора только в конце квартала;
- просить лидеров активно участвовать в OKR-обсуждениях: давать контекст, убирать неоднозначность, помогать командам принимать решения;
- связывать обновления по OKR с реальными изменениями в продукте, клиентах и delivery-потоке.
Прозрачность нужна не для контроля ради контроля. Она помогает командам раньше увидеть рассинхрон, зависимости и риски.
Вместо вывода
OKR — полезный инструмент, когда он помогает командам договориться о фокусе, измерять прогресс и связывать ежедневную работу с целями компании. Он быстро ломается, если превращается в квартальный ритуал заполнения шаблонов.
В моем опыте лучше всего работает связка OKR и agile-ритма: цели задают направление, sprint planning и review помогают регулярно проверять движение, ретроспективы вскрывают системные проблемы, прозрачные дашборды удерживают общий контекст.
У каждой OKR-системы будут штормы. Вопрос в том, есть ли у команды рабочий компас: общее понимание фреймворка, синхронизация между командами, реалистичные Key Results, простой фокус и регулярная коммуникация прогресса.