Все статьи
OKR как катализатор согласованности на всех уровнях компании
Дата: 06.02.2021
История Xsolla о том, как увязать портфель с корпоративной стратегией и при этом замотивировать команды на достижение согласованных целей с помощью Objectives and Key Results (OKR) и Scaled Agile Framework® (SAFe®).
Доклад на конференции Enterprise Agile Russia 30 ноября 2020 года.
Артемий Анцупов (модератор конференции): Мы переходим к заключительному докладу наших больших друзей и частых участников нашей конференции — компании Xsolla, Александра Сайфуранова и Арсения Коротаева. Александр, Арсений, добрый вечер, всем привет! Рады снова видеть вас на наших мероприятиях.
Арсений Коротаев: Меня зовут Арсений Коротаев, сегодня на выступлении со мной мой коллега Александр Сайфуранов. Мы работаем в компании Xsolla. Наша компания существует на рынке уже более 15 лет, и мы занимаемся разработкой инструментов для монетизации и продвижения онлайн-игр.
Те из вас, кто знаком с игровой индустрией, наверное, знают, насколько это сложный и трудоемкий процесс. Так вот, миссия нашей компании – как раз упростить процессы разработки монетизации онлайн-игр. В рамках данного доклада мы расскажем о первой фазе нашей Agile-трансформации, когда мы были по Waterfall, и как мы перешли к Agile, потом к SAFe, как внедрили его на Essential-уровне, базовом уровне. Расскажем о том, как мы масштабировали разработку без снижения качества, потом, как мы перешли к портфельному управлению SAFe, далее к OKR, к постановке целей компании по OKR, как мы обеспечили синхронизацию среди всех команд и маркетинга, и затем как выполняли гибкую корректировку приоритетов.
Базовый SAFe (Essential SAFe) предоставляет минимальный набор элементов, необходимых Agile Release Train (ART) для поставки решений, и является самой простой отправной точкой для внедрения.
Objectives and Key Results (OKRs), Цели и Ключевые Результаты — это методика организации совместной работы для постановки четких целей и измеримых результатов.
Наша компания занимается, как я уже сказал, инструментами для разработки монетизации игр. Мы работаем в трех офисах: в Лос-Анджелесе, Сеуле и Перми. Вся разработка у нас находится в Перми, в Лос-Анджелесе — топ-менеджмент, в Сеуле — отдел продаж.
Немного о нас. Я являюсь директором проектного офиса нашей компании. Александр Сайфуранов — директор по исследованиям и разработке и также он выполняет роль Release Train Engineer. Александр, тебе слово.
Александр Сайфуранов: Всем добрый день, мы бы хотели сегодня рассказать об OKR. Однако мы к этому подойдем достаточно издалека, то есть мы хотим рассказать о всем нашем пути, как мы трансформировали разработку, как начали Agile-трансформацию, как перешли к продуктовой разработке, загрузили Scrum-команды и дальше сделали синхронизацию на уровне SAFe. Подойдем через наш опыт к OKR, и тогда, наверное, станет более понятно, зачем мы вообще это делали и как.
Мы начали с того, с чего начинает любая IT-компания, — с подразделений в виде функциональных колодцев. У нас шесть команд, и, как и у любой компании с функциональными колодцами, у нас были типичные проблемы. Если озвучить это одной фразой, мы делали то, что устаревало к моменту завершения проекта.
В августе 2017 года мы поняли, что так дальше жить нельзя, что нам необходимо что-то менять, и мы пригласили консультантов и начали обучение — буквально всех разработчиков, все команды. В ноябре 2017 года мы одномоментно поменяли дизайн команд, то есть пересадили всех из функциональных в продуктовые команды. У нас на тот момент получилось шесть продуктовых команд, а также шесть сервисных команд, которые остались за периметром Agile-трансформации.
Нашей самой главной целью было зарелизить к июню 2018 года семь новых продуктов. При этом важно сказать, что к августу 2017 года у нас был только один core-продукт. К счастью, у нас всё получилось. Мы вот таким образом смогли значительно ускорить Time-to-Market этих семи новых продуктов и короткими Scrum-итерациями, через постоянное взаимодействие всех участников, доставить. Конечно, они были в разной степени готовности: где-то было MVP, где-то прямо была уже такая хорошая версия продукта.
Release Train Engineer (RTE) или «машинист поезда» — это лидер-слуга и коуч в Agile Release Train (ART), который проводит мероприятия и помогает в реализации процессов, а также поддерживает команды в поставке ценности.
Самое главное, что мы научились работать со стейкхолдерами и быстро доставлять продукты и фичи.
Конечно же, есть моменты, которые у нас получились не очень. Самый важный негативный аспект — команды начали изолироваться друг от друга: они начали уходить в себя, фокусироваться на продукте, на своей команде. Это очень здорово, однако начали возникать барьеры между командами, и команды начали изобретать собственные велосипеды. Это начало отражаться даже в том, что в каждой команде начал появляться свой техстек, своя архитектура. В какой-то момент времени мы поняли, что нам пора что-то с этим делать и поверх Scrum-команд внедрить что-то еще для общей синхронизации.
Мы смотрели разные фреймворки и в итоге остановились на SAFe. Почему? Самое главное, что нас привлекло, — это очень гибкий и очень мощный фреймворк, при этом он позволяет внедрять свои элементы поэтапно. В общем, мы решили, что «почему бы и нет?», и стартовали.
Те команды, которые у нас на тот момент были, — а у нас было уже десять команд — мы рассадили по трем «поездам», то есть по трем Value Streams. В каждой команде у нас были разработчики, QA, Product Owner, Scrum Master и бизнес-аналитик. В то время мы не смогли передать в команды компетенции системных администраторов, технических писателей, дизайнеров, юристов, маркетологов. Однако, это не явилось серьезным блокером, и мы успешно запустились.
Скрам в SAFe (SAFe Scrum) — это Agile-метод, применяемый командами ART для поставки ценности клиенту в короткие сроки. Скрам-команды в SAFe используют итерации, Канбан-систему и Скрам-события для планирования, выполнения, демонстрации и ретроспективы своей работы.
Владелец Продукта (Product Owner) — член Agile-команды, основная ответственность которого в максимизации ценности, поставляемой командой, что он обеспечивает соответствием Бэклога Команды потребностям клиентов и заинтересованных лиц.
Скрам-мастер/Коуч Команды (Scrum Master/Team Coach, SM/TC) — это лидер и коуч Agile-команды, который помогает в реализации командных процессов, мероприятий и поставке ценности.
Сейчас у нас идет уже седьмой программный инкремент, который через две недели заканчивается. Я хочу сказать, что мы очень здорово эволюционировали за это время, поскольку постоянно работаем над улучшением процессов и ритуалов, и сейчас, в принципе, каждый человек в командах понимает их ценность.
Самый важный достигнутый итог — у нас получилось синхронизировать команды по доставке общих решений. Я здесь специально вывел нашу программную доску. Так она выглядит после заполнения на PI Planning, мы с ней работаем каждый две недели, на каждом ART Sync проверяя блокеры и риски. Мы научились доставлять решения, которые затрагивают несколько продуктов, что бывает достаточно часто, если в этом решении заинтересован Enterprise или Mid-tier партнер. Особенно показательны случаи успешной синхронизации работы команд в достижении общих целей, если крупный партнер заинтересован в сразу нескольких решениях. Я считаю, что это одно из самых главных достижений внедрения SAFe.
Доска Планирования ART (ART Planning Board) — это визуализация сроков поставки фич, зависимостей между командами и вех в рамках PI.
PI-планирование (PI Planning) — это регулярно повторяющееся мероприятие всего ART, которое согласовывает команды и заинтересованных лиц вокруг общей миссии и концепции.
Синхронизация ART (ART Sync) — это мероприятие, которое совмещает Синхронизацию Владельцев Продукта (PO Sync) и Синхронизацию Коучей (Coach Sync).
Хотел бы еще с гордостью поделиться цифрами предсказуемости поставки. Наша поставка сейчас стала гораздо более предсказуемой для стейкхолдеров. Конечно, тут возникает важный вопрос постановки правильных бизнес-целей, и мы об этом обязательно скажем чуть позднее. Однако, что касается поставки, 80% запланированных целей мы доставляем вовремя и с нужным качеством. На графике видно, что наши постоянные улучшения процессов постепенно вывели доставку на цифры более 80%.
Зачем и как мы внедряли портфельный уровень
Арсений Коротаев: К началу 2020 года мы подошли с хорошо внедренным SAFe на уровне Essential, но у нас остался ряд проблем и неразрешенных вопросов.
Первое, наш бизнес построен таким образом, что мы работаем от партнеров, и интеграции этих партнеров сильно меняли планы команд; командам приходилось перепланировать свои цели, иногда полностью. Бизнес построен так, что к нам приходил Business Developer тогда, когда у него уже был подписан контракт, когда у него уже был определен объем работ, у него была дата поставки, и это все нам здорово портило предсказуемость поставки.
Вторая проблема — хотелось иметь более глубокую обоснованность экономической деятельности команд. Изначально в 2018 году мы сформировали семь продуктов, постепенно они дошли до зрелой стадии. Стандартный подход — когда мы просто перетряхивали бэклоги команд и выходили на квартальное планирование — уже не работал, продукты стали дороже, поддерживать их стало дороже, разработка функционала стала дороже. Потребовался такой инструмент, который позволил бы экономически обосновывать затраты на разработку больших фичей и инициатив.
Параллельно с этим у нас начала расти несогласованность работы маркетинга и разработки — часто они существовали как два отдельных мира.
Четвертое, команды хотели лучше понимать свой вклад в развитие компании, продукта, как та функциональность, которую они делают сейчас, вносит свой вклад в конечный доход компании.
Внедряя портфельное управление, мы ставили следующие цели:
- мы хотели иметь согласованность инвестиций, целей компании, целей команд;
- мы хотели иметь больше фокусировку на экономике, это использование IRR, WSJF;
- мы хотели выполнять корректировку приоритетов на уровне портфеля;
- хотели иметь возможность гибко менять дизайн и бюджет наших бизнес-направлений, используя Lean budgeting.
Как мы формировали портфель? Элементы портфеля мы решили назвать инициативами. В начале 2020 года, в первом квартале, мы решили, что второй квартал мы запланируем по новым правилам. Инициативы мы решили брать продолжительностью от 6 до 12 месяцев. Каждое бизнес-направление в течение первого квартала готовило инициативы, описывали их в формате Epic Hypothesis Statement (как регламентирует SAFe), а также считали расходную и доходную часть. Дополнительно коллеги посчитали IRR, в русской литературе это внутренняя норма доходности.
Приоритизацию мы решили осуществлять на основе IRR, рассчитанного на два года. Мы выбрали данную метрику несмотря на то, что знаем рекомендацию SAFe использовать метод WSJF. Однако мы остановились все-таки на IRR, потому что бизнес хотел оперировать более конкретными цифрами, чем абстрактные цифры WSJF, особенно при принятии такие важных решений, как редизайн бизнес-направлений.
Как более детально выглядела подготовка инициатив? Первым этапом маркетинг, разработка, в первую очередь владельцы продуктов или лидеры команд оценивали стоимость разработки данных инициатив. Затем представители бизнеса — это лидеры бизнес-направлений, финансовый департамент, отдел продаж — оценивали, какую потенциальную прибыль мы можем получить от реализации данного функционала. Потом это все сводилось в денежный поток, и на основе денежного потока считалась внутренняя норма доходности на 24 месяца. Мы отбирали только те инициативы, внутренняя норма доходности которых превышает 30%. Данный показатель выбран, исходя из планов компании относительно желаемых темпов роста. Также все эти финансовые модели собираются в единый квартальный портфель и обновляются каждый квартал.
Портфель (Portfolio) — это набор потоков ценности, который обеспечивает непрерывный поток ценных решений для клиентов в рамках общей модели финансирования и управления.
Бэклог Команды (Team Backlog) — это Канбан-система для хранения и управления пользовательскими Историями и Энейблерами для развития Решения.
Weighted Shortest Job First (WSJF) — модель приоритизации «Более Ценная и Короткая Работа Сначала» для упорядочивания работ с достижением максимальной экономической выгоды. В SAFe WSJF оценивается делением стоимости задержки на относительную длительность реализации.
Epic Hypothesis Statement (Декларация Гипотезы Эпика) — это структурированный формат, используемый для сбора, организации и передачи ключевой информации и предположений об Эпике.
Lean Budgets (Lean-бюджеты) — это подход к финансовому управлению, который финансирует потоки поставки ценности вместо проектов, ускоряя доставку ценности и снижая накладные расходы, связанные с традиционным учетом затрат на проект.
Для портфеля были выработаны свои метрики. Здесь на слайде в таблице представлены используемые метрики. Это стоимость разработки, бюджет, который есть на разработку, бюджет, который есть на маркетинг, суммарный бюджет, средний бюджет, который мы тратим на каждую инициативу, и два важных показателя. Первый называется Project Ratio (вычисляется в процентах) — это то, какой процент бюджета необходим для реализации инициативы. На данном слайде у меня написано 130%, это означает, что на эту цифру стоит обратить внимание, она должна быть 100%. Данное бизнес-направление взяло инициатив больше, чем оно может сделать, и здесь возможны варианты. Либо надо отказываться от части инициатив, либо надо им выделять больше бюджета, либо как раз нужно сделать перегруппировку внутри «поезда», добавить им людей из других «поездов», из других команд, чтобы они смогли справиться с теми инициативами, которые у них запланированы.
Также метрика Operation Ratio, она показывает, какой процент бюджета у нас тратится на цели типа Run, о целях данного типа будет сказано чуть позднее.
Жизненный цикл инициатив у нас выглядит следующим образом. Мы адаптировали стандартное портфолио Kanban. В статус Funnel у нас попадают любые идеи, которые соответствуют стратегическим целям компании. Затем в статусе Review уточняется описание, считаются первые финансовые модели, потом инициатива переходит в статус Analyzing, там по ней составляется Lean бизнес-кейс, как это регламентирует SAFe, и принимается решение, делаем мы данную инициативу либо нет. Если принимается решение делать, то инициатива попадает в бэклоги команд и на следующем PI Planning берется в реализацию, потом она проходит стандартный Lean Startup Cycle.
Что нам удалось достичь, внедряя портфельное управление? Мы получили возможность гибко распределять бюджет среди наших «поездов» и направлять деньги туда, где наиболее важные для компании и финансово выгодные цели. Мы обеспечили согласованную работу с запросами от партнеров, так как появился отдельный отдел, который курирует проекты с партнерами, его задача – уведомлять о новых интеграциях, объявлять об изменениях в этих интеграциях и обеспечить то, что все интеграции партнеров попадают на квартальное планирование с правильным объемом работ.
Также у нас появилась возможность прозрачного инвестирования для бизнеса, то, куда уходят деньги, и какой от них полезный эффект.
Однако остался ряд нерешенных проблем. Несмотря на то, что мы хотели как можно больше людей вовлечь в оценку дохода, так или иначе, нам не удалось достигнуть нужного охвата, в частности, отдел продаж пока слабо вовлекается в данный процесс.
Оформление инициатив оказалось очень трудоемким процессом, возникло много бюрократии. Данную проблему мы планируем решать с помощью автоматизации создаваемых документов.
В части продуктов не оказалось технической возможности, чтобы получить информацию о доходе от реализации данной инициативы. Тут надо дорабатывать продукты, планировать в квартал задачи, которые позволят изменить архитектуру продуктов так, чтобы новый функционал был более измерим с финансовой точки зрения, чтобы было понятно, как конкретный функционал приносит ту или иную выручку.
Также у нас из фокуса выпали инициативы сервисных команд, это технические писатели, системные администраторы и ряд других команд; задача следующих кварталов – сделать так, чтобы задачи данных команд попали также в общий процесс по работе с инициативами.
Инициативы и портфели – это только часть общего процесса. Вторая большая часть – это OKR.
Александр Сайфуранов: Собственно, мы подошли к самой главной части нашего доклада — к пониманию, почему мы пришли к OKR. Начнем этот рассказ с того, как мы внедряли OKR. Если все-таки подытожить, то у нас сейчас есть процесс постановки целей на уровне команд, мы знаем, как ставить цели на уровне бизнес-направлений, также есть цели на уровне компании. Однако было не всегда прозрачно, как связать эти цели так, чтобы каждому в компании было понятно, как его личное участие в работе команды сказывается на общем результате.
Также мы хотели сделать так, чтобы процесс постановки целей органично вписался в SAFe или SAFe вписался в OKR; сделать так, чтобы у нас были сбалансированы между собой процессы развития и оперирования нашей компании. И, конечно, мы хотим, чтобы в этом участвовали все сотрудники компании.
Первое, наверное, с чего начинают все компании, которые внедряют OKR, — это то, как «подружить» их с KPI. То есть, как эти процессы влияют друг на друга, как устанавливать цели и метрики. Мы, на самом деле, не стали изобретать велосипед, мы подглядели стратегию, которая сочетает в себе два подхода, это Run и Change. Run – это то, что направлено на оперирование, то есть на поддержку текущего статус-кво, текущих партнеров, их запросов, текущего бизнеса. Change – это то, чем станет компания через полгода, год, два, — собственно, это ее развитие.
Идея в том, чтобы поддерживать эти два потока задач одновременно, то есть грамотно перераспределять ресурсы между двумя этими потоками задач. На самом деле, там ничего сложного нет, просто нужно смотреть на статистику, смотреть на цифры. При этом в зависимости от того, насколько зрелый продукт, насколько зрелая команда, распределение между развитием и оперированием может быть очень разным. У нас есть core-продукт, которому больше десяти лет, там распределение 50/50. И есть совершенно новые, не так давно запущенные продукты, там распределение 10/90 — 10% на оперирование и 90 на развитие.
Канбан Портфеля (Portfolio Kanban) — это метод, используемый для визуализации и управления потоком Эпиков Портфеля от идеи до анализа и реализации.
Упрощенное Финансовое Обоснование (Lean Business Case, LBC) — это структурированный формат для описания Эпиков, их MVP и прогнозируемой бизнес-ценности.
Ключевые Показатели (Key Performance Indicators, KPIs, Ключевые Показатели Эффективности) Потока Ценности — это численные метрики, используемые для оценки того, насколько Поток Ценности соответствует своим бизнес-целям.
Как это технически выглядит? У каждого продукта есть общий продуктовый бэклог, и из него задачи на планировании распределяются на два потока: первый идет в Scrum спринты, то есть то, что направлено на итеративную поставку продукта, развитие продукта, развитие компании. Второй же поток идет на Kanban-доску — доску, где вытягиваются задачи по поддержке.
Здесь я привел график сжигания одной из наших команд. Слева – это то, как у них было до того, как мы этот подход применили. Видно, что все срочные задачи попадают непосредственно в спринт, он раздувается, и команды в принципе никогда не доставляли все задачи спринта, то есть цель спринта не была никогда достигнута.
Справа – это та же самая команда, тоже их график сжигания, уже после того, как мы применили этот подход для распределения усилий между Run и Change. Анализируя метрику committed versus completed capacity, мы всегда можем понять, какой поток задач — Run или Change — в данный момент времени требует больше ресурсов, что позволяет гибко перераспределять усилия.
На этом слайде я хотел показать кумулятивную диаграмму потока этой же команды. Они берут на себя обязательство протаскивать через «трубу» определенный поток задач, связанных с поддержкой. Здесь мы анализируем Throughput и Cycle Time. На основе метрик мы разделили два потока задач, балансируя между ними нагрузку, таким образом обеспечивая гарантированную поставку и для развития, и для поддержки.
Хорошо, с KPI мы разобрались. Теперь, как мы будем ставить цели? Мы договорились, что у нас будут три уровня OKR, ни больше, ни меньше, то есть это: уровень компании, уровень бизнес-направления и уровень команды. Также мы договорились, что у нас постановка целей будет по принципу W. Я думаю, тут нет смысла останавливаться подробнее, так как этот принцип постановки целей большинство знает.
Мы договорились, что каждый следующий уровень будет являться декомпозицией целей предыдущего уровня, то есть более высоко стоящего. Мы решили не добавлять на каждом следующем уровне свои цели, потому что это достаточно сложно делать на начальном этапе. Вообще, в принципе, постановка правильно сформулированных целей, которые мотивируют, которые амбициозны, но при этом достижимы, — это очень сложная задача. Мы до сих пор улучшаем саму постановку целей, пока это не всегда получается, но мы стараемся совершенствоваться.
Дальше, мы договорились о, казалось бы, таком банальном принципе, но тем не менее, который нам важно было озвучить внутри компании, что OKR – это для постановки и отслеживания целей, а KPI – это текущие метрики здоровья, то есть как двигаются команды, как они работают, нет ли каких-то серьезных препятствий. Мы договорились о том, что будем горизонтально выравниваться, то есть о том, как усилия смежных команд, работающих над общими целями, будут достигать глобальных целей. На этом уровне мы вовлекаем маркетинг и оперирование.
Очень важный момент, о котором, наверное, не то чтобы многие забывают, но откладывают на потом — это процессы. Если не будет процессов, то, собственно, это ничего работать не будет. Нужно договориться в самом начале, а нужно сказать, что мы этого не сделали, и немного процесс постановки целей у нас пострадал. Нужно договориться, кто, когда, с какой периодичностью, что именно делает, то есть: когда формирует цели, отслеживает их и оценивает достижения. Тут обязательно нужно делать замеры и рефлексировать; если этого не будет, то процесс внедрения OKR либо замедлится, либо вообще умрет.
Достижения. Самое главное, я считаю, что нам удалось сделать вертикальное и горизонтальное выравнивание. Вертикально — теперь у нас каждый человек знает, как его усилия влияют на бизнес компании. Горизонтально — мы теперь все меньше занимаемся так называемым «перекидыванием проблем через забор» — перекладыванием задач и ответственности по доставке общего релиза на смежные команды. Такого сейчас становятся все меньше, то есть мы стараемся ставить общие бизнес-цели, которые иногда могут даже замедлять развитие отдельных продуктов в пользу общих результатов.
Мы теперь фокусируемся только на самых важных целях, не распыляя ресурсы. Теперь команды действительно выровнены друг с другом — мы знаем, что делают смежные команды, как они участвуют в процессе поставки ценностей, и, в общем, можем еще более конструктивно договариваться о совместных работах.
Мы, конечно же, по старой нашей доброй привычке провели опрос коллег, чтобы выяснить отношение к OKR. В нем, к сожалению, приняло участие не так много человек, как мы бы хотели, то есть из 200 человек ответило примерно 30. Мы задали три важных вопроса: «Коллеги, как вы теперь оцениваете, насколько лучше вы стали понимать цели компании, свои личные цели и ваш вклад в достижения команды? Насколько лучше вы понимаете вообще, зачем OKR?» Примерно половина сказала, что в принципе их понимание не изменилось, но более трети ответило, что это понимание улучшилось. Я считаю, что это хорошее достижение.
В завершение я бы хотел сказать что, мы сегодня провели вас по нашей истории трансформации — того, как менялись наши процессы, наши команды и наше целеполагание. Мы попытались показать, почему мы шли от одного этапа нашего развития к другому, что было причиной начала изменений, какие положительные моменты мы в этом находили, какие негативные аспекты оставались, какой у нас на текущий момент накоплен опыт. Я надеюсь, что этот опыт будет вам полезен.
