Это 2-я часть статьи о фреймворке flOwKRs, из которой вы узнаете о разнице между короткими итерациями и непрерывным потоком, о каденциях и синхронизации, масштабировании, оценке эффективности и др.
Прочитать 1-ю часть статьи можно по этой ссылке.
Короткие итерации или непрерывный поток
Замечали ли вы, что в сообществе Lean-Agile идет война методов между Scrum и Kanban? Нет? Тогда вы многое пропустили!
Существуют две стратегии управления работой, позволяющие быть lean и agile (бережливым и гибким). Первая берет за отправную точку короткие временные рамки и делает всю работу подчиненной каденции итераций. Это способ работы Scrum. Второй принимает за отправную точку непрерывный поток и считает каденции ценными, но необязательными. Это способ работы Kanban. Ни один из подходов не является "лучшим", поскольку их эффективность зависит от контекста.
По умолчанию в системе OKRs используется парадигма временных рамок. Итерации для OKRs обычно длятся три месяца; они начинаются с планирования целей и заканчиваются обзором целей. Во время обзора ваша команда определяет уровень своего успеха. Она говорит: "Так, наше время вышло! Как мы справились?". Если команда не справилась с OKR, она может перенести его на следующую итерацию. Так же работает Scrum.
В качестве альтернативы ваша команда может выбрать непрерывный поток. В этом случае планирование (или обновление) OKR будет происходить в любое время, то же самое относится и к встречам по мониторингу. Желательно установить каденцию для этих встреч, но они не обязательно должны быть фиксированными или синхронизированными с кварталом, их можно проводить чаще. На встречах по мониторингу команда будет постоянно спрашивать: "Мы уже закончили? Мы уже закончили? Мы уже закончили?". Они будут работать над достижением OKR до тех пор, пока не решат, что достигли все цели и могут заменить их другим. Примерно так же работает Kanban.
Во всех книгах и статьях по OKR рекомендуют придерживаться коротким итерациям. Интересно, что многие сторонники метрики Полярной звезды используют непрерывный поток. Я не буду выбирать за вас, потому что лучшая стратегия управления работой зависит от вашего контекста и ваших предпочтений. Не начинайте войну. Просто делайте то, что работает для вас. (Но если вы когда-нибудь окажетесь со мной за чашечкой кофе, возможно, услышите от меня, что непрерывный поток — это довольно круто).
Возьмите инициативы из своего бэклога
Итак, вы согласовали свои OKR с верхним и нижним уровнями корпоративной иерархии и прислушались к обратной связи, полученной от стейкхолдеров и других команд? Отлично! Теперь вы можете связать инициативы с вашими OKR. В зависимости от объема работы и вашей позиции в организации, инициативы могут быть любыми - от задач до целых проектов или этапов производства.
Если вы работаете над продуктом, вы можете взять инициативы из бэклога продукта. Ваша команда должна относиться к бэклогу как к хранилищу идей. Вы не "сжигаете" свой бэклог и не тратите время на определение приоритетов длинного списка идей фич.
Мне кажется, слово "бэклог" - одно из самых глупых слов в agile-сообществе. Изначально оно означало "то, что мы ДОЛЖНЫ сделать и должны были уже сделать" (например, работа с невыполненными заказами). Первоначальное значение этого слова - скорее контрольный список, нежели вишлист.
Связано ли все это каким-то образом с agile-практикой story mapping? Конечно! С помощью карты историй можно визуализировать все, что вы делаете в рамках инициативы. Можно создать основу из "путешествий пользователя" и иметь множество историй в рамках нескольких запланированных релизов. Давайте, прорисуйте все это. Только помните, что все, что вы делаете, должно каким-то образом двигать ваши OKR.
А что насчет эпиков (epics)? Это зависит от того, как вы понимаете этот термин. Слово " бэклог" просто сбивает с толку. Термин " эпик" является весьма спорным. Не существует единого мнения о значении эпиков, поэтому я оставлю это на размышление вам.
Создайте дорожную карту целей
Вполне вероятно, что при выборе своих целей вы должны сказать «нет» некоторым из них. Может быть, даже многим из них! Вероятнее всего, вы скажете, что-то вроде: «Да, но не сейчас». Отложенные цели должны попасть в очередь и стать «целями-кандидатами». Если вы потратите немного времени на их приоритизацию, то сможете рассматривать их как дорожную карту высокого уровня.
Когда вы знаете, сколько времени потребуется для выполнения ваших OKR, вы можете предложить разумные прогнозы своим стейкхолдерам. Сможете ли вы достичь от двух до трех OKR за квартал? Тогда ваш оставшийся список из десяти целей займет у вас еще один год. Ваша пропускная способность составляет примерно один месяц на цель? Тогда вы можете рассчитывать на выполнение остальных десяти задач в течение следующих десяти месяцев. Это простая математика.
Вы можете разграничить цели, которые вы точно выберете следующими, и в которых вы еще не уверены. Тогда у вас будет все необходимое для составления дорожной карты продукта с разделами "Сейчас/Скоро/Позже". Ваши текущие цели - это то, над чем вы работаете сейчас. Те, которые скорее всего будут следующими, обозначены как "Скоро". А все остальные находятся в разделе "Позже".
Помните, что вы не сжигаете свой бэклог. Вы работаете над своими целями.
Check-in – проверка
Возможно, самая большая проблема при постановки целей, заключается в том, что команды в конечном итоге «ставят и забывают». Они не отслеживают свои цели на регулярной основе, чтобы увидеть, как они реализуются. Ключевые результаты должны быть отслеживаемыми, чтобы вы могли постоянно проверять их состояние. То же самое следует делать и с метриками здоровья. (См. ниже.)
Check-in – это то, что команды обычно делают один раз в неделю. Scrum-команды могут проводить check-in в рамках (или между) встреч по обзору спринта и ретроспективы. Конечно, чек-ины OKR должны завершаться незадолго до встречи по планированию в Scrum или пополнению Kanban, чтобы команда имела самую актуальную информацию о том, в каком состоянии находятся ее цели. Это улучшит дальнейшее принятие решений.
Некоторые команды используют “уровни уверенности” (confidence levels), чтобы указать, насколько они считают, что они могут достичь цели. чтобы показать, насколько они верят в то, что смогут достичь цели. Они определяют такие уровни уверенности, как высокий, средний и низкий, или "на пути к цели", "сбились с пути" и "под угрозой". Уровни уверенности подталкивают членов команды рассказывать обо всех возможных проблемах и рисках. Было бы довольно неловко “провалить” OKR, который был помечен высоким уровнем доверия. Провальные OKR не должны быть неожиданностью.
Обзор
В какой-то момент ваша команда перестанет работать над достижением цели, потому что время истекло (если вы придерживаетесь временным рамкам) или потому, что у команды есть причина заменить цель (в случае если у вас непрерывный поток). Затем участники команды решают, преуспели они в достижении OKR или потерпели неудачу. Эту оценку можно определять в рамках регулярных check-ins, но, вероятно, лучше всего это сделать на отдельной встрече с собственной продолжительностью, чтобы у вас было больше времени для обсуждения и рефлексию.
Оценка OKR означает выставление оценки от 0% до 100%, в зависимости от системы измерений ключевых результатов. Во многих случаях это придает немного субъективности. Выручка в день, вероятно, более объективно измеряется и оценивается, чем количество комплиментов в день. Но до тех пор, пока команды самостоятельно оценивают свою эффективность (а не под влиянием топ-менеджеров), у них не будет оснований обманывать систему. (Не вижу причин обманывать свой прогресс в беге на 2 500 километров в этом году. Но если бы кто-то платил мне за достижение цели бонус, у меня мог бы возникнуть соблазн запрыгнуть на скутер, когда устану бежать).
Отказ от цели
В какой момент можно отказаться от OKR?
Эксперты сходятся во мнении, что отказываться от цели не следует слишком легкомысленно. Последнее, чего вы хотите, это чтобы ваша команда относилась к своим целям несерьезно. Приняв на себя обязательства, они должны сделать все возможное для реализации OKR. Однако ничто так не демотивирует людей, как борьба за заведомо проигрышное дело. Да, им разрешается сдаться, но не без хорошей борьбы.
Окружающая среда меняется, контексты меняются, и ваша команда может столкнуться с совершенно новой (возможно, безнадежной) ситуацией, которую они не предвидели. К примеру, Пандемия Covid-19… Вы можете рассматривать это как отмену спринта в Scrum или удаление элемента "В работе" с доски Kanban. Очевидно, что это решение команды. По моему мнению, это должно быть записано как непредвиденная неудача.
Каденции и синхронизация
Независимо от того, используете ли вы подход с временными циклами или непрерывный поток, встречи лучше всего проводить с регулярной каденцией. Стандартная практика OKR заключается в том, чтобы check-ins проходили один раз в неделю, а планирование и обзор происходили один раз в три месяца. Тем не менее, у вашей команды могут быть причины для отклонения от стандарта.
Более короткие каденции позволяют быстрее реагировать на изменения. Однако нужно контролировать затрачиваемые ресурсы на коммуникации, иначе вы обнаружите, что тратите слишком много времени на встречи. Более длинные каденции дадут вам больше времени для выполнения задач, но для этого требуется низкий уровень неопределенности.
Синхронизация – это еще одна область, в которой вы можете идти своим собственным путем. Стандартная практика OKR заключается в том, чтобы все команды синхронизировали недели, в течение которых они проводят свои встречи по планированию и обзору. Очевидное преимущество такого подхода заключается в том, что он облегчает координацию целей между командами. Тем не менее, у независимых встреч также есть свое преимущество. Например, команды разработчиков в среде микросервисов редко синхронизируют планирование и релизы своих API. То же самое касается команд и их OKR. Они могут быть как связаны, так и независимы друг от друга.
Компромиссом может стать синхронизация планирования и обзора целей во всех командах, работающих над одним продуктом или в рамках одного подразделения.
Метрики здоровья
Наконец-то, мы почти у цели!
Я затронул наиболее важные темы, касающиеся OKR. Но для многих организаций сокращение разрыва между текущей и будущей ценностью — это только половина работы. Другая половина заключается в удержании этого разрыва от повторного появления! В этом и заключается смысл метрик здоровья – мониторинг стабильных стабильного уровня производительности.
«OKR и Health Metrics живут бок о бок на дашборде компании. Вы отслеживаете и то, и другое. OKR – это то, что толкает вас вперед к большему росту. Показатели здоровья — это то, что вы защищаете во время роста». – Кристина Уодтке
Для некоторых команд в вашей организации большая часть их ежедневной работы – это операционка (Business As Usual, BAU). Их KPI в основном являются метриками здоровья, которые необходимо отслеживать, чтобы производительность не упала ниже приемлемого уровня. На ум приходят команды по обслуживанию, HR и бухгалтерия. Это не значит, что у них нет OKR, но количество времени, которое они могут потратить на цели и ключевые результаты, вероятно, составляет от 5 до 20% от их общей производительности. В производственных командах все наоборот. От 80% до 95% их работы связано с OKR, но есть еще крошечный процент, который они должны зарезервировать для операционки и поддержки.
Это означает, что у вас есть два вида KPI: ключевые результаты и метрики здоровья.
Представьте себе большой пул показателей эффективности с тысячами способов измерения производительности команд. При создании OKR некоторые из этих показателей повышаются до ключевых показателей эффективности, поскольку они выбираются в качестве ключевых результатов для цели. Вы будете отслеживать их до тех пор, пока OKR не будет считаться выполненным. Затем у вас есть два варианта: вы можете продолжать отслеживать их как KPI, переместив их в метрики здоровья. Или вы можете перестать отслеживать их, и в этом случае они станут обычными (неотслеживаемыми) показателями эффективности.
Вот как вы закрываете разрыв ценности и не даете ему открыться.
Масштабирование вверх и вниз
Я сделал все возможное, чтобы написать эту статью независимо от масштаба. Ваша команда может управлять одним потоком создания ценности в крупном продукте; вы можете быть автономным стартапом; командой, управляющей портфелем, или командой топов многонациональной компании. Это не имеет значения, потому что постановка целей масштабируется как фрактал. Она самоподобна на всех уровнях.
Обсуждение стратегии и тактики требует разного уровня мышления. Стратегические решения принимаются реже и охватывают более длительный период времени, чем тактические решения, поэтому логично, что их обсуждение происходит не так часто. Планирование и обзор стратегических целей может происходить раз в год, с ежемесячными check-ins, в то время как на тактическом уровне они могут организовываться раз в квартал и раз в неделю. (Также стратегические и тактические сессии могут быть организованы как в одной и той же команде, так и на разных уровнях организации).
В любом случае, независимо от того, какие цели выбирает ваша команда, она должна убедиться, что все согласовано с целями более высокого и низкого уровня. Все, что происходит в организации, должно быть подчинено OKR (и метрикам здоровья), а каждое решение должно быть связано с KPI.
Оценка эффективности
И последнее, но не менее важное: я повторю настоятельный совет многих экспертов о том, что ни OKR, ни метрики здоровья не должны быть связаны с бонусами и другими поощрениями. Оценка работы сотрудников никогда не должна быть напрямую связана с процентом достижения OKR или состоянием метрик здоровья.
Одна из причин заключается в том, что ответственность за OKR и метрики здоровья несет команда. Что сделал отдельный участник команды для достижения целей и их выполнения - это другой вопрос. Другая причина заключается в том, что отличные оценки за обязательные OKR (committed) могут нести меньше ценности, чем средние оценки за амбициозные цели (aspirational). Необходимо оценивать людей за их вклад в исследование и выполнение целей.
OKR не задуман как объективный инструмент. Субъективность необходима в начале, когда команды выбирают высшие приоритеты из множества вариантов, и субъективность необходима в конце, когда участники команды оценивают себя, оценивается их эффективность и прошлые достижения. Все начинается с людей, и все заканчивается людьми.
Продолжайте работать над своей системой
В этой статье я предложил вам шаблон процесса, основанного на Целях и Ключевых результатах (OKRs), с использованием метрики Полярной звезды (NSM), Управления на основе доказательств (EBM), соответствия целям (F4P), критериев SMART, метрик здоровья и других моделей постановки целей. Я описал ее таким образом, чтобы она была масштабируемой, и предложил вам различные варианты (например, продукты против портфеля и итерации против непрерывного потока).
Надеюсь, эта статья станет для вас отправной точкой при постановки целей в вашей команде.
Теперь дело за вами – заставьте OKR работать на вас. Но учтите, что система целеполагания важнее одной цели, как ваша рабочая жизнь важнее одного рабочего места.
И продолжайте бежать. 😉🏃🏻
«Смысл постановки целей – одержать победу в игре. Смысл построения систем – продолжить игру. Истинное долгосрочное мышление — это бесцельное мышление. Речь идет не о каком-то отдельном достижении. Речь идет о цикле бесконечного развития и непрерывного совершенствования. В конечном счете, именно ваша приверженность процессу будет определять ваш прогресс». – Джеймс Клир
Изучение и внедрение OKR
Если вы хотите больше узнать об OKR и приступить к внедрению, тогда можете зарегистрироваться на наш тренинг “OKR Certified Professional” в открытом формате (для себя) или корпоративном формате (для компании).
Тренинг “OKR Certified Professional”
Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи:
