OKR

Дві половини

Objective — коротке якісне формулювання того, куди ви прагнете дістатися. Воно має добре запам’ятовуватися і трохи лякати: таке, що команда може повторити напам’ять і чим пишалася б, досягнувши. Чисел у ньому бути не повинно — числа є справою другої половини.

Key Results — це два-п’ять вимірювань, які переконали б скептика, що ціль справді досягнуто. Кожне потребує числа й дедлайну. Якщо можна виконати всі key results і все одно не досягти цілі — key results сформульовані хибно. Цей тест, промовлений уголос до початку кварталу, ловить більшість поганих OKR приблизно за хвилину.

Механізм не новий. Енді Ґроув побудував його в Intel на основі управління за цілями, додавши вимогу, щоб цілі йшли в парі з вимірюваннями й переглядалися коротким циклом. Джон Дорр приніс це в Google 1999 року й стиснув усе в одне речення, варте запам’ятовування: «Я зроблю [ціль], що вимірюється через [key results]». Якщо чернетка OKR не вкладається в це речення, з нею щось не так.

Key results — це наслідки, а не результати роботи

Саме цей збій тихо вбиває більшість програм OKR. Output — це те, що ви зробили; outcome — те, що змінилося внаслідок цього. Outputs повністю під вашим контролем, і саме тому вони роблять key results комфортними та безвартісними.

Зверніть увагу: праву колонку можна виконати повністю, а бізнес не отримає нічого. Це не гіпотетичний сценарій, а звичайний наслідок вимірювання output: команда, яку оцінюють за випуском, випускатиме — незалежно від того, чи це допомагає.

Редизайн із правої колонки не заборонений — він просто є ініціативою, роботою, яка, на вашу думку, зрушить key result. Ініціативам місце в беклозі; key results — в OKR. Саме розділення цих двох речей дозволяє покинути редизайн на півдорозі, не покидаючи цілі, — і в цьому вся практична користь фреймворку.

Захисні метрики

Будь-яке одне число можна зрушити способом, якого ніхто не хотів. Удвічі зменшити звернення щодо білінгу, сховавши посилання на підтримку; підняти реєстрації, ускладнивши скасування. Стандартний захист — захисна метрика: показник, який ви зобов’язуєтеся не погіршити, опублікований поруч із key results. «Підняти реєстрації з 4% до 6% за умови, що частка повернень лишається нижчою за 2%» — це ціль, яку неможливо виграти шахрайством, і коштує вона одного зайвого рядка.

Committed та aspirational OKR

Пораду «цільтеся в 70%» повторюють так часто, що її застосовують і до цілей, де вона просто хибна. Власні рекомендації Google ділять OKR на два види з різними правилами, і їх змішування — надійний спосіб отримати сварку наприкінці кварталу.

Позначайте кожен OKR як один чи інший тоді, коли ставите, а не коли оцінюєте. Дедлайн відповідності, контрактна поставка й усунення вразливостей за природою є committed — казати такій команді, що 70% нормально, безглуздо. Десятикратне покращення активації за природою є aspirational, і вимога 1,0 гарантує, що цілі наступного кварталу будуть боязкими.

Узгодження — це не каскадування

Інтуїтивний спосіб масштабувати OKR — каскадувати їх: CEO ставить цілі, кожен VP бере одну як свою, кожен директор — одну з їхніх, і так до команди. Це охайно, це те, що більшість організацій пробує першим, — і власні рекомендації Google радять цього не робити.

Причина практична, а не філософська. Каскадування триває стільки, скільки глибока оргструктура, тож поки квартальні цілі дійдуть до команди, квартал уже почався. Воно також відкидає знання тих, хто найближче до роботи: команда, якій продиктували її key result, не може запропонувати той, що вона реально бачить.

Рекомендація, що випливає з досвіду Google, — приблизний баланс: близько половини OKR мають народжуватися в командах, а не спускатися згори. Керівництво задає напрямок; команди пропонують key results, які, на їхню думку, його зрушать, і ці два боки узгоджуються в розмові, а не через ієрархію. Це узгодження — справжня робота: саме там команда каже «цей key result не в нашій владі, а от цей — так», і напрямок стає чіткішим.

Один наслідок дивує: OKR команди не мусить бути підмножиною OKR її керівника. Дві команди можуть мати спільний key result, а команда може володіти key result, що належить цілі іншого відділу. Працює це завдяки відкритій публікації всіх OKR: узгодження тут виникає з того, що кожен може прочитати цілі кожного, а не зі структури дерева.

Цикл, який змушує це працювати

OKR, поставлені в січні й відкриті в березні, — це вправа з діловодства. Фреймворк окупається лише тоді, коли цикл справді працює, а в циклі є чотири моменти. Жоден не забирає багато часу, і саме середній пропускають.

Дорр доповнює весь цикл практикою, яку скорочує до CFR: conversations, feedback, recognition — розмови, зворотний зв’язок і визнання. Суть у тому, що OKR відповідають за цілі й ні за що більше: постійна розмова один на один про те, як людині ведеться, зворотний зв’язок між колегами й публічне визнання доброї роботи — це те, що потрібно системі оцінювання людей, і воно свідомо тримається окремо від оцінок OKR.

Оцінювання і межа з оплатою

OKR оцінюють від 0 до 1, зазвичай як середнє з оцінок key results. Для aspirational OKR здорова зона приземлення — приблизно 0,6–0,7. Стабільні 1,0 на aspirational-цілях не означають, що команда чудова: це означає, що цілі поставили там, де успіх був відомий наперед.

Це працює лише тоді, коли оцінки не впливають на зарплату чи підвищення. Щойно оцінка OKR потрапляє в performance review, кожна раціональна людина ставить цілі, яких точно досягне, — і організація втрачає єдине, заради чого фреймворк існував. Це не культурна делікатність, а арифметика стимулів, і вона працює однаково в кожній організації, що це пробувала.

OKR — це не KPI

Ці два поняття постійно зливають, зазвичай запхавши наявний дашборд у шаблон OKR. Вони відповідають на різні питання, і потрібні обидва.

Практичний зв’язок такий: KPI, що поплив не туди, часто є причиною поставити новий OKR, а KPI, який не має рухатися, часто стає захисною метрикою при ньому. Натомість перетворення всього дашборда KPI на OKR дає двадцять цілей, нуль фокуса й квартал, у якому нічого не обрали.

Як це виявляється в реальній поставці

Робочий OKR змінює те, чому команда каже «ні». Якщо key result кварталу — утримання на 4-му тижні, а стейкхолдер просить фічу, яка явно його не зрушить, OKR дає команді мову для відмови, що говорить про ціль, а не про завантаженість. OKR, через який ніхто ніколи ні від чого не відмовився, є декорацією.

Де вони вироджуються

• Key results, які насправді є замаскованою дорожньою картою: кожен — це щось випустити до дати.
• Прив’язка оцінок до бонусів гарантує безпечні цілі вже за один цикл.
• Десять цілей на команду — це беклог під новою назвою і без фокуса.
• Кожен OKR як розтяжка — тоді зобов’язальні дедлайни тихо стають необов’язковими.
• Поставили в січні, відкрили в березні — без перевірки посеред кварталу немає й корекції курсу.
• Одне число без захисної метрики запрошує знайти найдешевший спосіб його зрушити.
• Наявний дашборд KPI, скопійований у формат OKR, не обирає нічого.

Коли це застосовувати

Пов’язані сторінки

• МенеджментЕпіки, фічі, задачіЕпіки, фічі й задачі — це рівні ієрархії роботи, і вони існують тому, що різні люди ухвалюють рішення на різних горизонтах часу. Епік — це ставка, яку керівник робить на квартал; задача — крок, який інженер робить сьогодні. На цій сторінці — для чого кожен рівень, скільки їх реально потрібно і чому ті самі п’ять слів означають різне в Jira, Azure DevOps і SAFe.
• МенеджментUser StoriesUser story — це короткий опис потреби з погляду користувача, написаний, щоб почати розмову, а не замінити її. Шаблон — найменш важлива частина; справжня навичка полягає в нарізанні роботи так, щоб кожна історія давала користувачеві щось справді придатне до використання. На цій сторінці — три C, критерії приймання, шість способів розділити історію, story mapping, spike та призначення story points.
• МенеджментAgileAgile — це спосіб створювати софт, який припускає, що ви в чомусь помиляєтесь, і планує дізнатися про це рано. Agile не є процесом, який «встановлюють», і не є набором зустрічей — це невелика група переконань, записаних 2001 року, на яких побудовано з десяток різних методологій. На цій сторінці ми розберемо ці переконання, усі дванадцять принципів за ними і те, що насправді змінюється в команді, яка сприймає їх серйозно.