{"id":14271,"url":"\/distributions\/14271\/click?bit=1&hash=51917511656265921c5b13ff3eb9d4e048e0aaeb67fc3977400bb43652cdbd32","title":"\u0420\u0435\u0434\u0430\u043a\u0442\u043e\u0440 \u043d\u0430\u0442\u0438\u0432\u043e\u043a \u0438 \u0441\u043f\u0435\u0446\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0432 vc.ru \u2014 \u043d\u0430\u0439\u0434\u0438\u0441\u044c!","buttonText":"","imageUuid":""}

Альтернатива OKR — метод управления продуктами Spotify Rhythm, как он работает и для каких компаний подойдёт

Компания Spotify известна не только тем, что при своём почтенном возрасте и количестве подписчиков почти вдвое большем, чем у Apple Music, её доходы растут вместе с убытками. И не только тем, что уже пять лет как она пытается и всё никак не выйдет официально на наш рынок. Есть надежда, что это вот-вот произойдёт.

В среде менеджеров и разработчиков компания Spotify обросла историями и легендами, касающимися рекомендательных алгоритмов, корпоративной культуры и методов разработки.

Оставим на самостоятельное ознакомление то, что в мире agile известно как Spotify Model. В данной статье мы расскажем о методе управления продуктами Spotify Rhythm. Он пришёл на смену методу OKR (Objectives and Key Results, цели и ключевые результаты) и синхронизирует личные задачи и цели с задачами и целями компании.

В статье компания объясняет, почему на индивидуальном уровне OKR не показал для них хорошего результата. Spotify пишет, что они отказались от этой практики в 2013 году, чтобы люди сосредоточились на работе бизнеса, а не на работе OKR. Три причины, которые привели к этому решению:

  1. Это тормозило компанию, не прибавляя ценности.
  2. Главный вопрос, на который отвечает OKR — «как», фокус компании был и есть в ответе на вопрос «почему».
  3. Некоторое из того, что входит в концепцию OKR, устарело.

Ниже я приведу сжатый перевод выступления Хенрика Книберга на шведской конференции Agila Sverige. Некоторое время этот специалист работал коучем по agile- и lean-методологиям в Spotify и Lego. Написал на тему agile несколько книг. Он был тем, кто помог компании прийти к созданию и внедрению подходов Spotify Rhythm и Spotify Model.

Когда в одно и то же время происходит слишком много всего, и мы мечемся, как обезглавленные курицы, — этот процесс не масштабируется. Возможно, это и хорошо, когда в компании вас 20 и меньше, но это точно доставит трудности при расширении компании. И чем дальше, тем хуже.

Рассинхронизация процессов приводит к переполнению стека текущих задач, к возникновению недопонимания. Опишем это метафорой «две команды строят дорогу друг к другу через реку, и выясняется, что первые строили туннель, а вторые — мост».

Spotify перепробовала ряд методов, чтобы справиться с трудностями роста. В начале 2010-х этим методом стал OKR, затем первый собственный фреймворк P&A (Priorities and Achievements, приоритеты и достижения) и, наконец, Spotify Rhythm (который, по словам спикера, на 2016 год прекрасно справлялся со своими задачами. И, вероятнее всего, до сих пор справляется, с некоторыми изменениями — прим. автора).

Систематизация модели Rhythm. Простите, картинки другого качества нет Spotify
  • В центре модели — убеждения компании. Они отражают изменения, которые наша компания может дать миру в перспективе трёх-пяти лет. Их формируют основатели компании на основе фактов и инсайтов о мире вокруг нас и о наших юзерах.
  • «Полярная звезда» — всеобъемлющее утверждение о видении будущего, которое используется для определения направления компании. Эти цели амбициозны и служат метриками успеха, которого мы можем достичь, если правильно соизмерим убеждения и пути использования нашего времени и энергии. Именно от «полярной звезды» зависит, примут ли то или иное решение на основе того, насколько это решение приближает компанию к «звезде».
  • Ставки — сущность модели, крупные проекты либо кросс-организационные инициативы, исходящие и курируемые стратегической командой. Они не содержат всё, что делает компания, но позволяют двигаться по направлению к «полярным звёздам».

Functional Bets (функциональные ставки) — это большие проекты определённых функций, задаваемые и курируемые функциональными лидерами. Эти ставки часто апеллируют к более высоким ставкам компании, но могут быть независимыми. И те и другие возникают в комбинации планирования сверху вниз и снизу вверх.

В свою очередь Market Bets (ставки на рынок) — это инициативы или инвестиции, которые связаны с первыми двумя видами ставок, но при этом ориентированы на разные рынки или его сегменты.

Теперь вспомним стандартную систему приоритизации — высокий, средний, низкий приоритет. Всё это работает не очень замечательным образом.

В Rhythm используется ранжированный стек — что-то более, что-то менее важно, но всё идет по порядку и только одна вещь может быть самой важной. Хенрика не приводит точного описания, как в Spotify управляют приоритизацией (можно для примера взглянуть на метод RICE — прим. автора), видением и долгосрочными целями, вместо этого он предлагает посмотреть на то, как они реализуют процесс.

Итак, видение даёт им основу для определения первоочередных вещей. Если бы мы могли выбрать только одну из двух задач, какую бы мы выбрали? Далее стеки помещаются на доску, похожую на ту, что применяется в стстеме канбан. В ней только три столбца: Now, Next, Later. На столбце «Сделано» внимание не концентрируют.

На практике это выглядит как таблица в «Google Таблицах», к которой есть доступ у каждого сотрудника. Здесь каждая задача — ставка со своими спонсорами.

Для каждой ставки есть двухстраничный бриф, также в «Google Документах». На одном описаны метрики успеха и ответственные лица. Data Insight Belief Bet — вот на чём автор делает акцент.

В этом документе четыре колонки, первая — «Данные и факты», которые мы имеем, с которых мы начинаем создавать свою ставку. Следующая колонка — «Инсайты», то, что эти данные могут сказать нам о меняющемся мире. Третья колонка — «Убеждения» («Вера). Если это то, что мы думаем о мире, то какое место здесь может занять Spotify? Наконец, «Ставка» — если мы думаем, что именно там мы должны быть, то что нам нужно для этого сделать?

Эту цепочку мы называем Argument Framework, каждый из этапов можно обсуждать и оспаривать. Опыт в конечном счёте может быть разным, положительным или отрицательным, но каждый раз мы что-то узнаём. Затем мы возвращаемся с новыми данными и инсайтами в самое начало. Это способ сделать agile-процессы более кросс-функциональными.

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

Таким образом решается проблема соотношения внутренних целей и внешних. Потребность в таком решении возникла как раз по причине расширения штата. Рассматривая ставки как своего рода центры тяжести, все команды могут синхронно направиться на достижение общей цели.

Благодаря чёткому определению приоритетов на разных уровнях вы упрощаете все переговоры и решения. Для синхронизации используются стендапы и спринты.

Также в компании есть команда по стратегии. Это группа из 20 человек, включая руководящий комитет, выполняющий управленческие функции. Группа собирается для обсуждения главных ставок и решает, на чём следует сосредоточиться. Доска ставок может меняться с течением времени, обычно это происходит каждый квартал.

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

Они позволяют гибко и быстро перенастраивать ставки. (Всё вместе это звучит так же хорошо, как ритмический рисунок песни We Are Family группы Sister Sledge — прим. автора.)

Каждая ставка на таких собраниях приобретает статус в виде стандартных цветов: зелёного, жёлтого и красного.

Зелёный означает, что всё движется с нормальной скоростью и у нас есть всё, что нам нужно, мы можем просто продолжать двигаться. Жёлтый означает, что мы немного застряли, возможно, есть проблема, красный — что застряли совершенно.

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

Каждая модель имеет свои недостатки и вызовы. Чтобы синхронизировать команды, необходимо «боковое» отслеживание процессов.

С помощью этой методологии мы хотим достичь такого равновесия, при котором команды смогут эффективно сотрудничать и оставаться при этом автономными. В этом цель.

Нам не нужно указывать, что им делать, они видят контекст, по которому они определяют, как и с помощью чего они могут вносить свой вклад в общее дело. Чёткий контекст очень важен, без него команды не смогут быть автономными, будут идти в разные стороны и сталкиваться друг с другом.

Данный материал переведен и опубликован мной в рамках прохождения акселератора Product University. Надеюсь, он пригодится менеджменту растущих компаний, которые столкнулись с теми же проблемами, а также любым другим специалистам. Частично или полностью этот метод можно использовать в других сферах жизни.

Источники:

Переведено на русский Алексем Пыжовым.

0
5 комментариев
Ruslan Fazlyev

Интересная статья, спасибо!
Посыл вначале сомнительный: "Альтернатива OKR". Это не другая принципиально система, это скорее "мы внедрили OKR и вот во что оно у нас трансформировалось".

Ответить
Развернуть ветку
Раися Вперде
В Rhythm используется ранжированный стек — что-то более, что-то менее важно, но всё идет по порядку и только одна вещь может быть самой важной.

Миллениалы придумали critical chain

Ответить
Развернуть ветку
Elarvil

выглядит интересно. кто-нибудь из российского сегмента пробовал на себе такой подход к реализации целей?

Ответить
Развернуть ветку
Aleksey Pyzhov
Автор

Знаю, что компания Semrush адоптирует у себя этот подход. Возможно есть кто-то ещё.

Ответить
Развернуть ветку
Anton Sazhin

Мы используем подобный подход - coreapp.ai ) но со спецификой: есть анализ стейкхолдеров. Есть то, что мы хотим, а есть то, что хотят закрывать Заказчики. Но это скорее разница в продуктовом и проектном подходе и одновременной работе с обоими сущностями.

Ответить
Развернуть ветку
2 комментария
Раскрывать всегда