Эволюция целеполагания с помощью OKR — путь Reg.ru

Эта статья является стенографией доклада на онлайн-конференции OKR Russia 20 апреля 2020 года.

Артур Нек, Reg.ru, Новосибирск, Agile Coach

C 2009 года участвовал в Agile-проектах в различных ролях. С февраля 2019 года стал Agile-лидером в Reg.ru — крупнейшем российском хостинг-провайдере и регистраторе доменов.

Этот доклад мы подготовили с нашим Scrum-мастером Викторией Катана.

Я Agile-коуч в компании Reg.ru. Занимаюсь гибкими подходами в компании. Я аккредитован по Kanban, а также занимаюсь Scrum и классическим проектным управлением.

Reg.ru — это компания из более чем 500 человек. У нас реализовано движение инициатив в 2 стороны. Снизу и сверху. Сонаправленный поток. В середине они встречаются и происходит коммуникация от топ-менеджеров до офис-менеджеров. Нет человека, которого обошёл бы OKR нашей компании. При этом все мы живём на «удалёнке». Это накладывает свою специфику, как именно мы это делаем.

Мы достаточно сильно выросли с 2006 года, когда это была компания из 3 человек. Сейчас почти 600. Мы прошли разные этапы, о которых я вам сейчас расскажу.

Мы за этот взрывной рост начали сильно рассинхронизироваться. Работа команд стала не прозрачна. Команд в компании стало очень много: Agile-команды и сервисы, которые работают по Kanban. Стало не понятно, кто и как движется.

Когда мы запускали OKR, у нас было простое и маленькое желание — синхронизировать движение клиентских служб с командами разработки. Клиентские службы находятся на фронте и понимают всю боль пользователя, и пытаются её донести до команд разработки. Команды разработки немного «отмахивались» и занимались своими важными делами. Мы хотели выровнять эту ситуацию, но получили гораздо больше.

Как сейчас у нас это устроено. Стратегическая цель у нас ставится на год. Ближайшая — на полгода. У нас существует общий реестр целей, куда включены все цели компании и всех подразделений, участвующих в деятельности. Они ставят свои цели на квартал.

Перед постановкой OKR у нас происходит несколько целей, обычно за месяц встречаются представители команд, а ещё раньше представители топ-менеджмента выбирают стратегическую цель. Команды выбирают свои цели, которые сонаправлены в движении к стратегическим. Дальше выбор конкретных значений. И ещё одна встреча, когда представители команд в рамках одной цепочки создания ценности встречаются между собой и договариваются, кто какие значения зафиналит, как будет выставлена взаимосвязь подразделений. После этого происходит внесение значений в реестр. И во втором квартале, например, 1 апреля, происходит фиксация целей. В следующий раз их можно будет поправить через месяц или через квартал.

Чекины у нас происходят один раз в месяц. Обычно это конец первой недели следующего месяца. Если сейчас апрель, то следующий в начале мая, где абсолютно все подразделения расскажут про прогресс своих целей. Вносим прогресс — смотрим на прогресс. Начинаем с ревью, если говорить про Scrum-команды, либо про Kanban-команды, у которых есть каденции, то мы начинаем с обзора метрик. Это встраивается в нашу постоянную деятельность. У любой команды вы сможете посмотреть, какие они себе цели ставили и как они продвинулись. Тем самым достигается некоторый регулярный обзор того, как мы движемся. Это влияет на бэклог спринта в конкретной команде.

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

У нас произошло следующее. Культура экспертности стала уходить. В большей степени диалог строится вокруг цифр, когда, если ты хочешь какую-то инициативу продвинуть, ты обязан её посчитать и оценить эффект. Недостаточно твоего весомого мнения, как руководителя. Приведи цифры, покажи, как это связано со стратегией, покажи, ка это связано с целями конкретных команд. Команды могут не брать задачи, если они не соответствуют целям команд или стратегической цели.

В случае, если мы меняем цель, а такие развороты бывали, мы очень быстро начинаем перестаиваться к этой новой цели. Тем самым достигается эффект бизнес-гибкости. Мы можем перестроить взаимодействие всех команд и при этом не будет сопротивлений и супертяжёлых движений. Примерно за 1 месяц мы развернём этот корабль, идущий к светлому будущему.

Как это всё происходило. До 2017 года мы занимались выстраиванием компании самостоятельно. В 2017-2018 году появился в компании внешний коуч, который помогал внедрять Agile, появились Agile-команды.

С 2019 по 2020 год появился в компании я, как внутренний коуч. И мы стали заниматься ревью процесса, здоровья команд, здоровья подразделений. В 2019 году в марте мы провели саммит разработчиков. Так как мы все удалённые, то мы собрали всех в одной локации и рассказали им подход OKR. Провели воркшоп, который занял 2 дня, на котором мы «накидывали», какие это могут быть цели, взаимодействовали между собой, давали обратную связь, по тому, как могут быть выстроены OKR в компании. Это был старт OKR. В апреле месяце следом за саммитом разработчиков, мы провели саммит руководителей, где представители руководителей, в том числе и тех самых разработчиков, финалили OKR на год. Этот воркшоп занял у нас 1 день.

В сентябре у нас возник некоторый кризис, когда поначалу все думали, что всё будет легко и просто, но всё оказалось не совсем так. Ситуация в компании была весьма интересная: некоторые говорили, что нужно OKR отменить, может быть они не работают, может быть они не для нас. Но мы сохраняли своё стремление в использовании данного подхода и продолжали двигаться.

Отдельным пластом работ идёт вовлечённость команды топ-менеджмента в работу с OKR: ревью, коучинг команд, коучинг руководителей, поиски механик и методологий расчётов. У нас большая поддержка команды топ-менеджмента. Больший вклад в работу и результаты даёт не столько сам OKR, как последствия решений, принятых менеджментом на основании очередного чекина или метрики.

Первый звонок, фаза ноль — это была цель, анонсирована на саммите 2018 года, все были заряжены, появилась сформулированная цель. Но полгода спустя прогресса не было от слова «совсем».

Сейчас будут некоторые фазы того периода, когда у нас появился OKR в компании, когда мы перешли на этот фреймворк, начали работать со стратегией, декларировать стратегию. Рекомендую использовать это, как некоторое руководство к тому, как надо запускать OKR в вашей компании. Как проживать один эволюционный цикл за следующим без революции для людей.

Фаза 1 — это командные цели. Это то, что появилось у нас сразу после саммита разработчиков и руководителей. Мы шли с абсолютной уверенностью, что все знают, что делать, в плане разработок и нет необходимости в какой-то синхронизации. Нужно просто взять, поставить и вуаля – через 1-2 месяца мы достигнем стратегических целей. Полгода-год — слишком долго. Зачем растягивать? Мы итак достигнем OKR-подразделений. На этом этапе я рекомендую позволять командам использовать OKR в качестве задач, когда у вас есть возможность. «Да/нет» — я сделаю этот OKR или не сделаю этот OKR. Мы тогда совершили некоторое допущение: мы пошли через путь счётных результатов, через отсутствие процентов и использование абсолютных чисел. Это было достаточно резким скачком для уровня, когда преобладал экспертный подход. Мы тогда жили без процентов и задач — у нас были суровые конкретные метрики. Это был большой скачок для эволюции в командах.

Процедура выглядела просто: команда собиралась с Product Owner, вместе они дискутировали, выбирали цель, которую можно поставить, дальше накидывали, как эту цель можно померить, какие ключевые результаты будут отражать достижение цели, вместе финалили после расчёта. Позже мы изменили этот подход совместного обсуждения. Check-in происходили онлайн. У нас есть таблица, где пять параллельно идущих потоков, в каждом потоке есть тайм-кипер, который следит за временем и «зарубает» обсуждения, которые вываливаются за тайминг, и коуч. Коуч — это представитель команды топов, который задаёт вопросы на развитие команды, на правильность подхода и методов, гипотез. Тайминг жёсткий — по 15 минут. Но нам его хватает. За эти 15 минут команды сообщают про инициативы, которые видят на ближайший месяц, препятствия в достижении OKR, отвечают на вопросы. Всё происходит точно вовремя, до минуты. Это сделано для того, чтобы представители любой команды могли прийти посмотреть. Check-in некоторых команд собирают по 80 человек. В этот период очень важно накидывать обратную связь, делиться цифрами, рассказывать про то, как строятся те или иные отчёты, знакомить с методиками расчётов. Не скрывайте цифры. Мы поливали цифрами компанию, как дождём. Это давало много выгоды. Люди стали понимать, почему те или иные решения были приняты в компании. Важно, когда есть не просто субъективность, а есть цифры. В этот же квартал у нас случился кризис у продажников, когда они попробовали и «запихнули» все свои KPI в OKR, при этом продолжили двигаться также, как двигались до этого в надежде на то, что что-то поменяется. Им было очень не просто выработать OKR. Им была непонятна связка KPI и OKR, им было тяжело.

Здесь мы постепенно подошли к фазе 2 — повышение определённости. Определённости в компании стало больше. Мы стали понимать, что стратегия от отдельных инициатив не сдвинется. Необходимо согласованное действие. Необходимо взаимодействие между участниками. Фраза Рея Далио, которую процитировал наш генеральный директор: «Если вы будете продолжать всё, что вы делаете, вы получите тот же эффект. Надо менять подход». Это был щелчок в головах у людей, что надо что-то менять. Во-первых, мы стали обнаруживать «слонов». Это большие проблемы в компании, которые существуют много лет, все про них знают, но также все научились их обходить и не замечать. Главное, что мы обнаружили, что это «слоны» мешают нам достигать стратегических целей, мешают качественно изменить подход. Только, если начать «распиливать слона» и выносить его их офиса, только в этом случае мы получим значимое изменение. Тут же мы задались вопросом: чем управляют менеджеры? В чем подход? Управление людьми? Это надсмотрщик на галере, а не менеджер. Управление пожарами? Бегаете от одного пожара к другому? Это пожарник, а не менеджер. Управляете метриками и знаете, как изменить значение той или иной метрики? Это по-настоящему менеджерский подход. Какие тогда у час есть метрики? Как вы их обрабатываете? Как вы их собираете вместе? Какая между ними зависимость? Может быть управляете рисками? Это тоже хорошая часть менеджерской зоны компетенций. Знание риска и метрики риска позволят вам улучшить свои результаты.

Здесь у каждого руководителя начали зарождаться Dashboard индикаторов: ключевые метрики его процесса, который позволит увидеть, а хорошо ли работает то или иное подразделение. Какие-то из этих метрик мы выбирали в OKR. Изменение их стало качественным улучшение работы подразделения. Какие-то оставались KPI и влияли на зарплатную часть. Важно было их развязать. Если вы всё завязываете в KPI, то у вас нет рычагов влияния на процесс. Вы начинаете думать только про KPI. Делайте KPI максимально приближенные к выручке отдела, либо те, которые нельзя накрутить прямым образом. А всё остальное можно заложить в OKR. Это будет инструментом, через изменение которых вы получите больший вклад в KPI.

Менеджер начал обладать Dashboard, понимает рычаги влияния, знает риски, которые он минимизирует, и обладает свободой для изменения своего процесса. У него не связаны руки. Он начинает двигаться к улучшениям.

Тут же мы стали отмечать трендовые значения. Стали просчитывать, к чему приведёт та или иная метрика, какое значение она получит на конец квартала. И стало понятно, занимается подразделение тем же самым или оно качественно изменило свой подход и пробивает значения выше тренда. Это важный поинт в использовании OKR.

Также наши эксперименты показали, что нет необходимости «пушить» проект или инициативы внутрь команд. Надо системно менять внутреннюю работу подразделения. Тогда вы достигнете эффекта. Все «пушинговые» проекты вносят смуту, но не дают эффекта для бизнеса. Дают только больший пожар для менеджмента компании. Избегайте «пушинга».

В случае, если в каком-то подразделении всё всегда перманентно хорошо, они ставят, например, одни и те же значения, то их лучше всё равно «челенджить». Искать варианты того, чтобы они начали развиваться. В случае изменения стратегической цели, либо состояния на рынке, быстро такие подразделения не перестроятся. Надо искать варианты метрик, которые будут их двигать вперёд. Например, у нас была ситуация с системными администраторами, у которых отказоустойчивость всегда была 99,9%. Мы нашли вариант с помощью соревнования между администраторами в надёжности инфраструктуры, и они стали биться за строчки в этих показателях.

Фаза 3. Мы стали собирать разные подразделения в цепочку того, как они формируют ценность, влияют на конечный результат и стратегию для компании. Мы стыкуем OKR в подходах, представители команд задают друг другу вопросы, сравнивают значения, появляются зеркальные метрики, которые берут одни и те же подразделения с одинаковыми значениями, но, если они будут работать по отдельности, то они не достигнут их. А когда команды работают совместно, они балансируют друг друга и достигают больших результатов.

Здесь мы столкнулись с кризисом золотоискателей. Например, когда наши клиентские службы генерили много багов, которые необходимо было обрабатывать, либо генерилось большое количество идей для продукта, но мы понимали, что большая часть этого (70%) — это пустой песок, который не приносит золота, удовлетворённости клиента, качественного прироста в деньгах по продуктам. Поэтому в некоторых командах мы выкинули большую часть бэклога для того, чтобы собирать только «золотую часть». Начали сокращать структуру, издержки от взаимодействия команд, где-то добавлять людей, где-то перестраивать передачу информации. Суть была в том, чтобы сократить количество блокировок и ожидание выпуска между разными командами.

Фаза 4 — Управление рисками. Мы сейчас в начале этого пути, поэтому подробно рассказывать не буду. Основное — это предугадывать, что будет происходить дальше, минимизировать риски и «быстрее находить золото». Здесь нужно было ставить OKR без процентов и задач. Мы изменили процесс таким образом, что Product Owners или менеджеры по продукту стали приносить цель команде, а команда начала формировать ключевые результаты. Диалог пошёл интересным образом: кто-то остался в старой схеме, кто-то взял новую и это был глоток хорошего свежего воздуха. Стыковка с бизнесом стала проще.

В каких случаях использование OKR – это не то, что заявлено? Когда нет стратегической цели. Если вы попробовали запустить OKR в одной команде и считаете, что запустили OKR, то это так не работает. Только, когда вы соберёте весь поток поставки ценности и целиком в рамках бизнеса запустите OKR, тогда это даёт реальный profit бизнесу. В остальных случаях это полумеры.

Всем ли нужны метрики? Мы не спускались до уровня персональных OKR, потому что координационные затраты по стыковке очень большие, особенно когда люди работают в рамках одной компании. Они могут быть очень «классными» в рамках личных метрик, но по факту, находясь внутри компании, они будут в красной зоне и будут двигать всю компанию не туда. В том числе мы отказались от метрик линейных отделов. Например, начальник отдела тестирования, поставив сотрудникам OKR, потащил, хоть и из благих намерений, весь отдел не в ту сторону, чем вызвал конфликт с Product Owner. Ставим цели только для кросс-функциональных команд, так как все сотрудники работают в кросс-функциональных командах.

Инструменты, с которыми мы работаем: Google-таблицы, GoToMeeting/Hangouts, Kaiten. Это позволяет нам собирать практически любые схемы взаимодействия подразделений. С помощью инструментов Google мы ведём реестр целей.

И в окончании: используйте OKR — они позволяют ставить крутые цели. Мы с их помощью запланировали следующий год. Это драйвер и столб, вокруг которого строится большая часть деятельности в нашей компании!