OKR

OKR однієї команди на квартал — готові

Більшість тих, хто шукає OKR, хоче побачити добрий набір. Ось один — для команди клієнтського досвіду інтернет-магазину зі сторінок про WBSWBSWork Breakdown Structure — обсяг проєкту у вигляді дереваДерево всього, що проєкт має створити, розкладене, доки кожен шматок не стане досить малим, щоб його оцінити й віддати одному власникові, — і, за визначенням, нічого, чого проєкт не створює. Діти мають складати рівно свого батька, і саме це робить його межею обсягу, а не списком задач.Докладніше в статті →Усі терміни та епіки, на один квартал. Кожну ціль позначено як committed чи aspirational у момент, коли її пишуть. Кожен key result має початкове значення й ціль. Захисні метрики та ініціативи записано поруч, і їх не оцінюють. Наступні розділи посилаються на рядки за номерами.

1. 1.Ціль 1 — Купувати повторно легко (aspirational)

   1. 1.1Повернення на 2-му тижні з 18% до 25%
   2. 1.2Медіанний час від входу до оплаченого повторного замовлення з 4 хв 10 с до менш ніж 1 хвилини
   3. 1.3Частка замовлень від постійних клієнтів з 41% до 50%

2. 2.Ціль 2 — Оплата не підводить клієнта (committed)

   1. 2.1Частка успішних оплат щонайменше 97,5% у кожному тижні кварталу — зараз 96,8%
   2. 2.2Клієнти, з яких списали гроші без замовлення: нуль на тиждень, зараз 11
   3. 2.3Самооцінку PCI DSS підписано до 15 серпня

3. 3.Захисні метрики — не мають погіршитися; не оцінюються

   1. 3.1Частка повернень коштів лишається нижчою за 2%
   2. 3.2Відписки від листів-нагадувань — менш ніж 0,5% за розсилку
   3. 3.3Звернення в підтримку — не більше 6 на 100 замовлень

4. 4.Ініціативи — робота, яка, на нашу думку, їх зрушить; у беклозі, а не в OKR

   1. 4.1Повторне замовлення з історії — епік зі сторінки про епіки
   2. 4.2Збережені кошики
   3. 4.3Листи-нагадування про повторне замовлення
   4. 4.4Автоматичний повтор і повернення після тайм-аутів платіжного провайдера

Що насправді написали Ґроув, Дорр і Google

Метод має коротке задокументоване походження. Пітер Друкер описав управління за цілями (management by objectives) 1954 року: керівники й ті, хто їм звітує, погоджують цілі, і роботу оцінюють відносно них. Енді Ґроув перебудував це в Intel у 1970-х і наполіг на другій половині: кожна ціль у парі з вимірюваними key results, які переглядають щокварталу. Він описав це на кількох сторінках книжки «High Output Management» (1983). Його тест для key result, як цитує Джон Дорр: «Key result має бути вимірюваним. Але наприкінці ви можете подивитися — і без жодних суперечок: я це зробив чи ні?»

Дорр засвоїв метод молодим інженером в Intel 1975 року. 1999-го він презентував його засновникам Google — тоді компанії з кількох десятків людей, — а 2018-го описав у книжці «Measure What Matters» з шаблоном в одне речення, який варто запам’ятати: «Я зроблю [ціль], що вимірюється [цим набором key results]». Якщо чернетка не вкладається в це речення, з нею щось не так.

Власний OKR Intel, другий квартал 1980 року

Дорр наводить один із корпоративних OKR Intel — з кампанії проти Motorola, описаної в кейсах нижче. Ціль: «Утвердити 8086 як найпродуктивнішу родину 16-розрядних мікропроцесорів, що вимірюється» — і далі чотири key results, кожен з оцінкою, яку він отримав наприкінці кварталу.

Варто помітити три речі. Середнє — 0,625, а квартал пам’ятають як успішний. Один key result отримав нуль, і метод це пережив: нуль був інформацією, а не вироком. І всі чотири key results — це результати роботи: опублікувати, перепакувати, запустити, видати зразки. За правилом, яке обстоює наступний розділ, кожен із них — output.

Що додав Google

Опубліковані рекомендації Google на сайті re:Work задають робочий діапазон: «оберіть лише три-п’ять цілей», приблизно по три key results, середня оцінка 0,6–0,7, OKR відкриті для всіх — і найважливіше речення: «OKR — не синонім оцінювання працівників». Внутрішній посібник Google, опублікований командою Дорра, додає поділ, який попередня версія цієї сторінки описувала лише наполовину: committed OKR — ті, яких, «як ми погоджуємося, буде досягнуто», з оцінкою відносно 1,0; aspirational OKR «описують, яким ми хотіли б бачити світ», із середньою оцінкою 0,7.

Key results вимірюють outcome — і мають захисну метрику

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

Редизайн із правої колонки не заборонений. Це ініціатива — робота, яка, на вашу думку, зрушить key result, — а ініціативам місце в беклозі, як групу 4 тримають окремо в наборі вище. Саме розділення дозволяє команді покинути ініціативу на півдорозі, не покидаючи цілі. Якщо листи-нагадування (4.3) за три тижні нічого не дають для повернень, команда перестає їх надсилати, а key result 1.1 лишається недоторканим.

Дванадцять key results, як їх пишуть команди

Захисні метрики — і навіщо група 3

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

Committed чи aspirational — і як рахують оцінку

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

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

Як порахувати оцінку

Key result оцінюють за тим, де він приземлився між початковим значенням і ціллю: пройдена відстань, поділена на заплановану. Key result 1.1 почався з 18%, цілився в 25% і завершив квартал на 22,9%: 4,9 пункту із 7 — це 0,7. Key result 1.2 іде в протилежний бік — з 250 секунд до 60 — і завершився на 1 хвилині 57 секундах: заощаджено 133 секунди із 190 запланованих, теж 0,7. Оцінка цілі — зазвичай середнє її key results.

Committed key result читають інакше. Рядок 2.1 вимагає 97,5% у кожному тижні; дванадцять добрих тижнів із тринадцяти — це не 0,92, а зірване зобов’язання, яке потребує пояснення. Тому committed-ціль потребує стількох key results, щоб вони визначали її повністю, — шоста пастка нижче, — і тому committed key results часто мають лише два стани: виконано чи ні.

Шість класичних пасток Google

Посібник Google називає шість способів погано написати OKR. Кожен легко впізнати, щойно в нього є назва, і кожен трапляється в дванадцяти рядках вище.

Узгодження — і квартал тиждень за тижнем

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

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

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

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

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

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

Книжка Крістіни Водтке «Radical Focus» (2016) дала щотижневій перевірці найчастіше копійовану форму: сторінка з чотирьох квадратів — пріоритети цього тижня, оцінка впевненості з десяти для кожного key result, великі шматки роботи на найближчі тижні та метрики здоров’я, які не можна втратити. Зобов’язання беруть у понеділок, перемоги показують у п’ятницю. Найкорисніше тут — число впевненості: воно падає раніше, ніж сам key result, — саме тоді, коли ще є час діяти.

На графіку — рядок 1.3 з набору вище. На 4-му тижні маркетинг запустив знижку на перше замовлення, і замовлення нових клієнтів подвоїлися. Постійні клієнти й далі замовляли більше, але їхня частка в усіх замовленнях упала, і впевненість команди щодо 1.3 знизилася до двох. На огляді посеред кварталу команда переписала його як кількість замовлень на постійного клієнта на місяць, з 1,2 до 1,4, — число, яке рухають лише постійні клієнти, — і пояснила маркетингу чому. Перша версія не була провалом команди. Це було відношення, знаменник якого належав комусь іншому, і огляд існує саме для того, щоб помітити таке, поки є час діяти.

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

OKR поруч із KPI — і межа з оплатою

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

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

Межа з оплатою

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

Дослідження постановки цілей ріжуть в обидва боки, і важливі обидві половини. Едвін Локе і Ґері Летем 2002 року підсумували тридцять п’ять років досліджень: конкретні й складні цілі стабільно дають кращий результат, ніж вказівка «зробіть усе можливе». Це аргумент за aspirational OKR. 2009 року Ліза Ордоньєс, Моріс Швайцер, Адам Ґалінскі й Макс Базерман відповіли статтею «Goals Gone Wild»: постановку цілей прописують як нешкідливу добавку, хоча вона має систематичні побічні ефекти. Локе і Летем відповіли, що побічні ефекти виникають від неправильного застосування. Читайте правила OKR як інструкцію з дозування, про яку сперечалися обидві сторони.

Чотири кейси і правило, яке показує кожен

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

Operation Crush почалася наприкінці 1979 року, коли Intel дійшла висновку, що програє ринок 16-розрядних процесорів Motorola 68000, який багато інженерів вважали кращим чипом. Замість переробляти продукт, Intel змінила те, що продавала: інструменти розробки, підтримку, дорожню карту й обіцянку наступних поколінь. Річна ціль — 2 000 design wins, тобто зобов’язань клієнтів вбудувати родину 8086 у власні продукти, — а квартальні OKR, як той, що наведено вище, були обраними кроками до неї. Власна історична сторінка Intel налічує майже 2 500 design wins. Одним із них була невелика команда IBM, що будувала персональний комп’ютер; IBM PC, випущений 12 серпня 1981 року з процесором 8088, зробив цю архітектуру стандартом галузі на наступні сорок років. Оцінки кварталу були змішаними. Кампанію оцінювали за річним outcome над ними.

Wells Fargo — кейс захисної метрики. Роздрібний банк нарощував перехресні продажі під ціллю — вісім продуктів на домогосподарство («вісім — це чудово», як висловився генеральний директор) — зі щоденними цілями продажів для працівників відділень і прив’язаними до них бонусами. 8 вересня 2016 року Бюро фінансового захисту споживачів, Управління контролера грошового обігу й місто Лос-Анджелес оштрафували банк на 185 мільйонів доларів через близько 1,5 мільйона депозитних рахунків і 565 000 заявок на кредитні картки, які, можливо, не були санкціоновані клієнтами; банк звільнив близько 5 300 працівників. Цілі продажів продуктів для працівників роздрібної мережі скасували з січня 2017 року; власне розслідування ради директорів, оприлюднене того ж квітня, поклало провину на культуру продажів; перевірка того ж серпня підняла кількість, можливо, несанкціонованих рахунків до 3,5 мільйона; а в лютому 2020 року банк погодився сплатити 3 мільярди доларів Міністерству юстиції та Комісії з цінних паперів і бірж. Кожне число, за яким стежив банк, росло. Ніщо поруч із ним не вимірювало, чи клієнт про це просив.

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

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

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

Чесна межа в тому, що OKR можуть змусити зробити вибір і зробити його видимим; зробити його правильним вони не можуть. Команда з бездоганно написаним набором — outcome з початковими значеннями, захисні метрики, кожна ціль позначена — однаково може обрати хибну ціль, і метод покаже на ній добру оцінку. Ціль — це судження про те, що важливо, а жоден формат не перевіряє суджень. Що метод гарантує, якщо цикл працює, — що хибний key result помітять за тижні, а не наприкінці року, як помітили рядок 1.3.

Практична перевірка займає годину. Прочитайте кожен key result і спитайте: чи має він початкове значення; чи можна виконати всі key results і однаково не досягти цілі; чи не є котрийсь із них тим, що команда випустила б і так. Знайдіть захисну метрику для кожного. Перевірте позначку на кожній цілі. Потім з’ясуйте, чи читає хтось оцінки на перегляді зарплат, — якщо так, виправте це першим, бо ніщо інше на цій сторінці цього не переживе.

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

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

• МенеджментЕпіки, фічі, задачіЕпіки, фічі й задачі — це рівні ієрархії роботи: від ставки, яку керівник робить на квартал, до кроку, який інженер робить сьогодні. Жоден стандарт їх не визначає: у Scrum Guide немає жодного з цих трьох слів, а Jira, Azure DevOps і SAFe ставлять епік на різний розмір. Сторінка починається з усіх рівнів на одному екрані й одного епіка, розкладеного до задач; далі — звідки ці слова, для чого кожен рівень, епік як ставка з виходом, фічі, enabler-и й задачі, чому підсумовані оцінки вводять в оману, п’ять епізодів з історії ієрархії і де все це вироджується.
• МенеджментМетрики та KPIМетрика — це число із записаним визначенням, за яким команда керує, а KPI — одна з небагатьох метрик, за якими команда чи компанія погодилася, щоб її оцінювали. Майстерність — у тому, щоб збудувати ланцюг від того, що команда може зрушити цього тижня, до того, що потрібне бізнесу цього року, тримати кожне число чесним під тиском і читати його, не обманюючи себе. Сторінка починається з готового набору метрик однієї команди; далі — слова й ланцюг, як записати визначення, закон Гудхарта й захисні метрики, одне число нагорі й дерево під ним, як читати число, чотири числа, що ввели в оману своїх власників, і де все це вироджується.
• МенеджментAgileAgile — це чотири цінності й дванадцять принципів розробки софту, записані 2001 року, які ставлять навчання на робочому продукті вище за дотримання плану. Це не методологія: Scrum, Kanban і Extreme Programming — методології, збудовані поверх нього, — і власних зустрічей, ролей чи артефактів у нього немає. Сторінка починається з Маніфесту повністю, пронумерованого, щоб на рядок можна було послатися; далі — шар, який він займає, на що міняє кожна цінність, ставка на вартість змін, петлі зворотного звʼязку як справжній механізм, кожен принцип як перевірка, яку можна провести у своїй команді, шість програм, долю яких він вирішив, і де все це вироджується в театр.