Наверно, многие из моих читателей как раз закончили квартальный (и/или годовой) цикл планирования, так что сейчас будет подходящее время напомнить, что процесс, которым мы пользуемся как стандартом в технологической отрасли, на самом деле — полная чушь. Разумеется, я имею в виду методологию Objectives and Key Results. Давайте же поговорим об OKR, что это такое и откуда они взялись, а ещё о том, почему это ужасная идея.
OKR: заговор Google?
Методология OKR изначально была разработана Google в...
Постойте-ка, я только что прочитал статью Википедии, ссылку на которую дал в предыдущем разделе, и оказалось, что начал статью с распространения дезинформации! Да как я посмел! Ладно, давайте начнём заново.
OKR были введены Эндрю Гроувом из Intel ещё в 1970-х! Он писал о них в книге о менеджменте 1983 года, а позже они появились в Google, вероятно, примерно в начале 2000-х. И хотя Google не изобрела концепцию OKR, она определённо способствовала её популяризации. [Кстати, заголовок этого раздела связан с мыслью, которая встречалась мне несколько раз: что Google намеренно популяризировала методологию OKR как способ саботирования остальной части отрасли и снижения её эффективности. Думаю, к этой мысли можно применить множество принципов, в том числе закон Беттериджа, бритву Хэнлона, бритву Оккама и уверен, что другие тоже.] Теперь куда бы ты ни пришёл, все компании используют OKR. Этот термин превратился во что-то типа слова «ксерокс», его используют для обозначения планирования, насколько бы процесс планирования был непохож на исходную методологию OKR.
Итак, разобравшись с историей, зададимся вопросом: что же такое OKR? Если вкратце, то это способ задания целей и измерения прогресса движения к этим целям. Objective (O) — это ваша цель, а Key Results (KR) — то, что нужно выполнить, чтобы знать, попали ли вы в эту цель. Разумеется, поскольку все мы хотим быть организациями, принимающими решения на основании данных, key results (ключевые результаты) должны быть измеримыми и основанными на метриках.
Обычно предполагается, что OKR должны быть каскадными. Иными словами, CEO (или другой руководитель) устанавливает какие-то OKR для организации в целом, а затем различные структурные подразделений устанавливают OKR, поддерживающие глобальные OKR, а потом каждая команда устанавливает OKR, поддерживающие OKR структурных подразделений; иногда даже у каждого участника команды могут быть его собственные OKR. На каждом уровне должно быть от одной до трёх целей, то есть кратких заявлений о том, «что» вы хотите выполнить за следующий квартал, или год, или любой другой промежуток; каждая цель должна иметь от одного до трёх ключевых результатов, обозначающих успех или неудачу в выполнении цели.
Кроме базовой методологии при установке OKR организации должны использовать ещё и несколько руководящих принципов. Самый (печально) известный из них заключается в том, что нужно устанавливать OKR так, чтобы вы могли достигать только 70% от них. Если вы постоянно выполняете 100% своих целей, это значит, вы недостаточно амбициозны. Во-вторых, следует избегать «двоичных» OKR, то есть OKR, единственная метрика которых — «я это сделал» или «я этого не сделал». В-третьих, OKR не должны охватывать все действия организации: обычная повседневная работа по поддержке, дежурствам и так далее — всё это «дополнительные» вещи, которые не должны учитываться в OKR. [Повседневная монотонная работа недостаточно «вдохновляет» и чтобы вдохновлять людей, нужно использовать OKR.] И, наконец, единственный способ обучения OKR — это работа с OKR.
Возможно, некоторые из вас уже готовы гневно строчить в комментариях, что я всё говорю неправильно и что совершенно не понимаю эту методологию. Это нормально, но моя основная претензия к методологии OKR заключается в последнем пункте: если «единственный способ обучения OKR — это работа с OKR», то это по определению означает, что каждый будет реализовывать OKR по-своему; на практике это приведёт к тому, что методология превращается в то, что вы захотите. Но когда кто-то направляет любую критику на процесс OKR, ему всегда отвечают в стиле классического «ни один истинный шотландец»: «ну, вы просто реализуете OKR неправильно». Но тогда у меня возникает такой вопрос: если никто в отрасли не реализует OKR «правильно», то зачем мы вообще стремимся их делать?
Новый взгляд: я не говорю, что мы не должны иметь целей. Я не говорю, что мы не должны иметь планов и нести за них ответственность. Разумеется, мы должны! Инженеры любят ругать рутину, бюрократию и проволочки, но я первым скажу, что в определённой мере такие процессы важны, особенно в крупных организациях. В этой статье я просто хочу убедить вас, что OKR — это неподходящий процесс.
OKR: путь к куче незавершённой работы
Давайте поговорим о проблемах OKR. Я хочу начать этот раздел, сказав, что работал инженером по инфраструктуре и что многие мои доводы будут с этой точки зрения. Но я слышал похожие жалобы и от людей в продуктовых командах, поэтому считаю, что мои возражения справедливы и для этой области.
Во-первых, начнём со смехотворного утверждения о том, что нужно нацеливаться на выполнение своих OKR на 70%. Даже если отставить в сторону туманность этого определения (нужно ли завершать 70% целей на 100%? Или выполнять 100% целей на 70%?), стоит задуматься о том, что большая часть выполняемой нами работы не имеет никакой ценности, если не сделать её полностью. Возможно, если ваш ключевой результат «увеличить CTR на 100%», а вы повысили его на 70%, то можно сказать, что это всё равно довольно неплохо. Но если ваш ключевой результат — «выполнить миграцию 100% пользователей на новую систему», а вы выполнили миграцию только 70%, то вы догадываетесь, что это значит? Теперь вам постоянно придётся поддерживать две системы. К счастью, в последнее время, похоже, этого принципа особо не придерживаются; мне кажется, люди поняли, что это мотивирует не к тем действиям.
Но это приводит нас непосредственно ко второй проблеме с OKR: измерениям. Кто-то может сказать, что пример с миграцией не подходит, потому что это двоичный OKR — мы или мигрировали, или нет. Это приводит к косвенной разработке метрики, которая по-прежнему означает «я выполнил миграцию», но не в двоичной формулировке. Возможно, вы опрашиваете клиентов и хотите, чтобы 100% были довольны новой системой, но посчитаете успехом, даже если довольны только 70%. Или, возможно, вы изменяете количество сбоев, вызванных новой системой, и ваша цель — это «ноль сбоев». [Я видел, как в разных случаях применялись оба этих подхода, а также множество других техник. Вы бы удивились тому, насколько изобретательными оказываются люди в попытках привязать двоичную переменную к непрерывному множеству.]
Однако здесь возникают дополнительные проблемы: одна из них заключается в том, что вы только что придумали для себя кучу дополнительной работы, потому что есть вероятность, что метрики, которую вы придумали для измерения успеха миграции, раньше не существовало: поэтому прежде чем приступать к основной работе, вам придётся создать инструментарий для сбора метрик, а эти инструментарий и метрики, вероятно, забудут через один-два квартала, когда сменятся приоритеты. Ещё одна проблема заключается в том, что изобретаемые вами метрики не связаны с выполняемой работой — удовлетворённость пользователей зависит от качества проведённой миграции на величину от пяти до нуля процентов, и на 90% связана с тем, насколько хорошо была спроектирована новая система кем-то ещё, кто, возможно, уже даже не работает в компании. Третья проблема — об этих метриках очень сложно рассуждать. Например, в случае метрики «количество сбоев» ваше целевое значение равно нулю, то есть если у вас возникнет любое количество сбоев, то показатель этого ключевого результата окажется неопределённым. Чтобы получить процент, нужно разделить количество сбоев на ноль. Поздравляю! Значение метрики может быть любым на ваш выбор!
Я думаю, что самая большая проблема одержимости OKR измерениями в том, что не всё нужно измерять, даже если это можно сделать! Принятие решений на основании данных (data-driven) — очень модный термин в нашей отрасли. Мы хотим совершенствоваться, хотим видеть, насколько стали лучше и хотим сообщить миру, насколько улучшились, чтобы котировки наших акций росли. Но есть огромный объём работы, который не нужно или нельзя измерить или очень легко интерпретировать ошибочно, если его можно измерить. Мне кажется, очень хорошо об этом сказано в статье Ричарда Марморштейна: be good-argument driven, not data-driven. Для того, чтобы быть data-driven, нужно: а) чтобы у вас были метрики, б) вы знали достаточно статистики для правильной интерпретации метрик, в) вас не волновало всё то, что нельзя измерить.
Последняя претензия к OKR связана с её каскадностью. Наша отрасль по большей мере давно отказалась от разработки в каскадном стиле, а затем с готовностью начала использовать методологию планирования, подталкивающую к каскадной разработке. В методологии OKR нет места для исследований и экспериментов (ведь как вы будете измерять исследования?), поэтому при составлении OKR нужно знать всё в мельчайших подробностях, иначе в противном случае может возникнуть что-то, мешающее завершить OKR (или хотя бы достичь 70%). Но поднимите руку, если вы когда-нибудь записывали все свои OKR, а затем спустя два месяца после начала цикла возникало что-то, делающее неактуальными все цели.
«Но постойте, вы просто делаете всё неправильно. Мы должны использовать Agile! OKR могут меняться! Нужно реагировать на новую информацию!» Ага, всё это я уже слышал раньше. Но гарантирую, что когда настанет время оценки производительности, люди, решающие, были ли вы успешным разработчикам, будут оценивать вас по изначальным целям на год, а если вам пришлось менять их, это будет расценено как неудача. Да, наверно, такое происходит не везде, но чтобы избежать таких результатов, требуется поддержка со стороны культуры компании. Так что, возможно, стоит использовать процесс планирования, в котором изначально есть пространство для изменений, а не пытаться подстраиваться под тот, который попросту не работает.
OKR: это значит, нам нужна ещё одна электронная таблица?
Знаете, о чём я ещё не говорил в этом посте? Об электронных таблицах. Нигде в методологии OKR не говорится, что нужно записывать список всех целей и ключевых результатов в электронную таблицу, а затем каждый месяц сверяться с метриками, изменяя значения в этой таблице. Никто не говорил, что вам нужен эпик JIRA для ваших целей и отслеживание всех тикетов по тому OKR, к которому они относятся. Никто ничего не говорил о «внутренних OKR», отличающихся от «внешних OKR», о роадмэпах, о совещаниях по планированию, о... список можно продолжать.
Тем не менее, могу предположить, что любой менеджер, услышав об OKR, сразу же подумает об электронной таблице. [Уважаемые менеджеры, я вас люблю. Серьёзно, вы занимаетесь трудной работой, за которую я бы ни за что не взялся. Так что спасибо. Даже если иногда вы используете слишком много электронных таблиц.] И я считаю, что это тоже проблема. Видите ли, мы в нашей отрасли объединяем OKR с «планированием», но я не думаю, что их нужно объединять. Даже если забыть обо всех проблемах OKR, о которых я говорил в предыдущем разделе, и вернуться к исходному (точнее к «исходному» в смысле «популяризированному Google») определению, задача OKR — вдохновлять. Именно поэтому появилась это стремление к 70%. Мы хотим устанавливать труднодостижимые цели, вдохновляющие людей работать лучше, а затем признавать, что эти цели были сложно достижимыми, и не наказывать сотрудников за то, что они выполнили их не на 100%.
Но знаете, что? Под таким углом зрения мне нравится OKR! Мы должны стремиться выполнять сложные задачи и не должны наказывать людей за то, что они с ними не справились. Кроме того, у нас должен быть план и мы должны понимать работу, которую будем выполнять следующие несколько недель или месяцев; возможно, нам понадобится электронная таблица, помогающая придерживаться этого плана. Но ради бога, давайте перестанем пытаться запихнуть метрики в эту методологию постановки целей, перестанем пытаться запихнуть методологию постановки целей в ежеквартальный процесс планирования и тратить месяцы на планирование, чтобы потом всё менялось спустя два дня после начала цикла.
Автор:
PatientZero
