Организационная модель для гибких организаций: unFIX

Автор Перевода
Владимир Каленов
Тренер, Методолог, Agile коуч
Автор Перевода
Артем Вегнер
Тренер, Методолог, Agile коуч
Автор Перевода
Андрей Барсуков
Тренер, Методолог, Agile коуч
Перевод оригинальный статьи Jurgen Appelo.
Пришло время для альтернативы SAFe, LeSS, Холакратии, Менеджмента 3.0, инженерной "модели Spotify" и матричной структуры организаций. Нам нужно то, что выведет гибкость на новый уровень и что принимает гибридный формат работы как новую нормальность. Это - мое предложение. Я называю его unFIX.

Мне понадобилось двенадцать лет, чтобы его сформулировать.

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

И давайте начистоту - практически ни одна из этих идей не является моей. Я смог нарисовать и описать эту модель только благодаря идеям, которые я почерпнул из множества источников и которым позволил роиться и перемешиваться в голове многие годы. Давайте посмотрим на некоторые из них.
Динамические команды
Если бы меня попросили назвать "последний кусочек головоломки", это была бы концепция динамической перестройки команд, описанной в одноименной книге Хайди Хелфанда. Эта книга помогла мне осознать, что статические команды не являются Agile-командами. Есть как минимум четыре причины, почему менеджеры должны сделать пересборку команд простой и безболезненной:

  • Ускорившийся темп изменений окружения и вызов, связанный с непрерывной сменой одного кризиса другим, требуют способности быстро формировать команды. Когда ваш бизнес столкнулся с утечкой данных, целенаправленной кибератакой, стратегическим ходом конкурента, или когда COVID поразил половину ваших команд, у новой команды, призванной разрешить ситуацию, нет времени на шестинедельное путешествие по стадиям модели Брюса Такмана (forming, storming, norming, performing).

  • Закон Конвея никак не обойти. Вы как бизнес будете создавать продукты, архитектура которых сходна с вашей оргструктурой. Если вы хотите оставаться гибкими, предоставляя клиентам динамический набор продуктов и услуг, вам необходима подвижная структура команд. Вам надо делать все возможное, чтобы предотвратить образование функциональных колодцев и "окостенение". Только гибкая структура команд способна произвести гибкую архитектуру продуктов.

  • Как показала "Великая Отставка", помимо предоставления превосходного клиентского опыта (Customer Experience, CX), улучшение опыта персонала (Employee Experience, EX) также является вашей ответственностью. Конечно, сотрудникам важно чувство принадлежности, дружбы и лояльности. Но также их мотивируют любопытство, креативность, компетентность (см. 25 драйверов мотивации). Превосходный опыт персонала включает развитие и карьерный рост за пределами единственной команды.

  • Последнее, но не по значению. Благое намерение измерять и вознаграждать производительность команд, а не отдельных людей, легко приводит к субоптимизации на уровне команд. Вы можете столкнуться с конкуренцией между командами! Если вам важно, чтобы команды больше заботились о целостном клиентском опыте, нежели чем о своей локальной производительности, для обеспечения коллаборации команд придётся приложить некоторые усилия.
Не поймите меня неправильно. Я не предлагаю перетасовывать людей каждый месяц. Действительно, стабильные команды имеют существенные преимущества. Но стабильные не значит статичные! Создание, расформирование и изменение команд это возможность, а не риск. Поэтому динамические команды - основной принцип для этой модели.
Топологии команд
https://teamtopologies.com/
Второй источник, заслуживающий внимания - книга Мэтью Скелтона и Мануэля Пэйса "Топологии команд". В своей работе авторы подчеркивают, что ответственность команд никогда не должна превышать когнитивную нагрузку участников команд. Команды должны, в каждый момент, понимать во всех деталях зону своей ответственности, иначе постоянное обучение замедлит её чрезвычайно (С моей ужасной памятью и раздутым портфолио, лично я страдаю от этого каждый день).

Книга описывает четыре фундаментальных типа команд:

  • Stream-aligned team - поточно-ориентированная команда, несущая end-to-end ответственность за весь поток создания ценности;

  • Enabling team - разблокирующая команда, временно помогающая другим командам набрать скорость;

  • Complicated subsystem team - команда сложной подсистемы, объединяющая в себе редкие и уникальные навыки;

  • Platform team - платформенная команда, предоставляющая инфраструктуру или архитектуру как внешний поставщик.
Эти 4 типа настолько же полезны, насколько просты. В своей предыдущей работе я никогда не заходил дальше предложения, что каждая команда или подразделение должны представлять четко определенную ценность своим клиентам (конечным потребителям или другим командам), но язык и визуализация топологий команд внезапно сделали мое смутное представление гораздо более практичным, и я очень благодарен за это.

Я использовал топологию команд как второй направляющий принцип, потому что стандартный совет "каждая команда должна владеть потоком создания ценности" слишком абстрактный, упрощенный и не содержит практических рекомендаций для большинства компаний.
Виртуальный и гибридный
Мой третий источник вдохновения, как ни странно, это концепция из IT. Виртуализация это создание виртуальной версии чего-либо, включая интерфейсы и программное или аппаратное обеспечение. Виртуальная машина - программное обеспечение, имитирующее физическую. Виртуальная команда - группа людей, действующих как если бы они физически находились вместе.

Если вам нужна оргструктура, способная справляться с вызовами 21 века, вы должны убедиться, что разница между физической и виртуальной командой практически отсутствует. Организация должна быть способна создавать виртуальные команды почти мгновенно, выделять в них людей независимо от того, откуда они работают. Объединяющая команды большая группа должна уметь делать команды сплоченными.

Сегодня, с появлением гибридного формата работы, это становится еще более важным. Некоторые участники команды в офисе, тогда как другие работают из дома или откуда-то ещё. Все время кто-то приезжает или уезжает, и работа в офисе никогда не вернется к прежнему режиму. Те, кто считают, что "команды должны быть колоцированы", застряли в до-ковидной эре!

Виртуализация - третий принцип, который я применил в описываемой ниже модели. Ваша оргструктура должна работать и физически, и виртуально, позволяя людям работать в гибридном формате. Каждая из ваших виртуальных команд создается большей группой, и все они могут работать по всей планете.
Ну что, давайте уже перейдем к модели? Поехали!
Экипаж [The Crew] (команда, сквод, ячейка, pod)
В модели unFIX экипаж это команда, обычно состоящая из 3-7 человек. Большее количество возможно в зависимости от контекста, но во многих случая я бы этого не рекомендовал. Как я объяснял в своей первой книге, оптимальный размер команды это пять человек (другие фреймворки предлагают семь, но по-моему, гибридный формат работы требует несколько меньшего размера команды). Участники команды в основном полностью выделены на работу в составе экипажа, но могут резервировать небольшую часть недели на работу в интересах форума или клуба (см. ниже).

Хотя каждый экипаж может быть командой любого типа, обычно большинство команд скорее всего должны быть поточно-ориентированными. Эти самоорганизующиеся, кроссфункциональные команды (в терминах фреймворка LeSS - feature teams) управляют своими встречами (планирование, чек-ин, обзор, ретроспектива). Управляют своей документацией и релизами. Могут действовать в соответствии с командными договоренностями, определяющими идентичность команды, общие правила и что-либо еще. В отличие от LeSS, эта модель допускает не только поточно-ориентированные экипажи. Для существования других трех топологий команд могут быть хорошие основания.
Как автономные команды, эти экипажи отвечают за свои роли, используемые методы, свои цели. За производственные каденции или непрерывный поток, за зависимости от других экипажей. До тех пор пока экипаж берет на себя полную ответственность за производимую ценность, он имеет решающее слово в том, как будет сделана его работа. Никто в организации не знает пользовательский опыт лучше.

Некоторые называют экипажи скводами, подами, ячейками, и это абсолютно нормально. Мне нравится "экипаж", потому что это слово предполагает, что участники управляют путешествием совместно. Экипаж корабля заботится о корабле и его пассажирах. Экипаж самолета отвечает за самолет и его перелет. В IT-компании каждый экипаж отвечает за кодовую базу и релизы. Следуя принципу динамических команд, мы ожидаем, что эти экипажи стабильны, но не статичны. Смена экипажа время от времени не должна быть трудной для людей.
Капитан (лидер, пилот)
Продолжая аналогию с кораблями и самолетами, я вижу необходимость, чтобы один из участников экипажа действовал как его капитан. Не три капитана, не два капитана, только один. Это лицо - основной контакт для внешнего мира, и на нем лежит финальная ответственность за все, что происходит в пути. Это не означает, что капитан дает всем распоряжения. Напротив, в своей прекрасной книге, "Разверните ваш корабль", Дэвид Марке объясняет, что хороший капитан, в действительности, принимает очень мало решений. Хорошо работающий экипаж знает, как самоорганизоваться, а его участники понимают свои зоны ответственности!

В экипаже могут быть другие дополнительные роли, например, Product Lead, Tech lead и т.д. В зависимости от продукта и зависимостей от внешнего мира, разные экипажи могут использовать различные каналы коммуникации. На самом деле, каждый участник экипажа может быть лидером в какой-либо области! В этом нет ничего плохого. Но общая ответственность означает отсутствие ответственности. База (см. ниже) настаивает, чтобы единственное лицо несло ответственность как действует весь экипаж во время своего пути. Это капитан.
На уровне базы могут существовать правила и ограничения относительно того, кто может быть капитаном экипажа, учитывая навыки, синьорность, срок работы в компании и т.д. Капитаны могут назначаться или избираться. Однако у капитана никогда нет функции линейного руководства в экипаже. Капитан НЕ обсуждает карьерное развитие, компенсации, повышения с участниками экипажа. В зависимости от контекста, официальное название должности этого человека может быть менеджер продукта, менеджер проекта, менеджер платформы. В любом случае, он является менеджером путешествия, а не участников экипажа!

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

Примечание: Так проще для капитанов, не обладающий навыками people management, чтобы говорить о зарплатах и повышениях. Я сам грешил тем, что повышал разработчиков до капитанов, и для них было ужасно сложно проводить оценку производительности с командами. Возможно, это не лучшее мое решение.
База (группа, трайб, клан, бизнес юнит)
Все экипажи работают с одной базы в 10 - 150 человек. Такая база содержит некоторое количество экипажей всех четырех стандартных типов, организованных вокруг нескольких потоков создания ценности. База действует как зрелый, независимый бизнес. Она содержит все компетенции, необходимые для того, чтобы придумывать, реализовывать и поставлять продукты, от дизайн мышления до DevOps, от Lean Startup до Lean Manufacturing (если вы можете нанимать людей со всего света, то обеспечить это не составит труда).

У каждого человека только одна база. Это его дом. База предоставляет своим людям чувство предназначения, принадлежности и признания. Она обеспечивает комфорт, личную безопасность, включенность, общую культуру, инструментарий, карьерные возможности для всех сотрудников.
В идеале, база покрывает пользовательский домен, а не технический. Она похожа на трайб в модели Spotify и Agile Release Train в SAFe. Однако, каденции и синхронизация работ опциональны. Модель Spotify не предписывает их, как и моя unFIX. Могут быть веские основания оставить работу всех экипажей асинхронной. Это ваша база и ваше решение.

Критически важная функция базы заключается в том, чтобы непрерывно реорганизовывать себя в зависимости от потребностей пользовательского опыта. Мы знаем, что оргструктура напрямую связана с архитектурой продукта. Когда архитектура должна измениться, организация должна измениться. Следовательно, база делает все возможное, чтобы помочь экипажам оставаться гибкими. Это включает заботу о минимальных стандартах и правилах для всех экипажей, чтобы переформирование команд было настолько безболезненным, насколько возможно.
Шефы (менеджмент, команда лидеров)
Когда я писал свою последнюю книгу, "Startup Scaleup Screwup", я разговаривал со многими стартапами и компаниями в фазе интенсивного роста (в том числе неудачного) по всей европе, включая Spotify, Flixbus, Wise, Typeform, Zalando, Booking, Intercom и Futurice. Среди многих из этих молодых успешных бизнесов я выделил один паттерн, который не включил в книгу - команда шефов, ведущая свой бизнес.
Команда лидеров обычно состоит из Chief Product, Chief Technology и Chief Marketing. Иногда разделение ролей несколько отличается, иногда это команда из четырех или пяти человек, а не из трех. Вне зависимости от должностей и численности, в большинстве случаев шефы обеспечивают линейное руководство всеми в рамках базы. Они - буквально - команда менеджеров. В зависимости от того, как шефы разделяют роли, у каждого из них бывает от трех до двадцати непосредственных подчиненных. Обычно все бэкэнд разработчики подчиняются CTO, все UX-специалисты подчиняются CPO, и т.д. Но что имеет смысл делать, должен диктовать контекст базы.

Основная выгода такого подхода (и многие компании в фазе быстрого роста обнаружили ее гораздо раньше, чем я) в том, что структура подчинения менеджменту базы стабильная, что бы ни происходило с экипажами. Люди могут перепрыгивать из экипажа в экипаж хоть пять раз в год (если этого требует пользовательский опыт или Employee Experience), и при этом никто не сменит менеджера, у менеджмента нет территории, которую имеет смысл защищать! Только шефы ответственны за найм, компенсации, повышения и т.д. В то же время они могут делегировать потоки создания ценности капитанам экипажей, а функциональную согласованность - председателям форумов (см. ниже).

Примечание: включение линейного менеджмента в модель unFIX это разительный контраст "безменеджерского" подхода SAFe. Который намеренно умалчивает о линейных менеджерах, чтобы SAFe было проще внедрять в существующие бюрократические структуры. Тем не менее, перегрузка из-за матричной структуры, которая из-за этого получается, представляет собой потенциальный кошмар!

Как команда лидеров, шефы несут ответственность за продукт, маркетинг и технологию всей базы. Они устанавливают курс на видение, цели, процессы, признание и вознаграждение (хотя, по практике, они настолько заняты, что с радостью делегируют значительную часть этого экипажам и форумам). Тем не менее, как CEO выступает главным C-level менеджером, должен быть один шеф, лидирующий всю команду менеджеров базы. Организации, которая окружает базу, нужен один человек, представляющий базу.
Форум (чаптер, департамент)
Маленькая команда из двух или трех шефов с легкостью может управлять базой в дюжину человек. После этого предела начинаются сложности. Когда база дорастает до 50 или более человек, команда лидеров делегирует значительную часть своей ответственности. Как я указывал выше, вся работа над потоками создания ценности происходит в экипажах, но некоторые вещи в рамках базы должны координироваться по всей функциональной линии.

Форум это опциональная конструкция, состоящая из 2 - 40 человек. В модели Spotify они называются чаптерами, но я предпочитаю название форумы, потому что оно отражает, что их главное предназначение - чтобы одинаково мыслящие сотрудники собирались, говорили и принимали решения вместе. Может быть форум DevOps, форум UX, форум "взломщиков роста" и т.д. В традиционных организациях проектный офис можно сделать форумом, в более гибких компаниях у менеджеров продукта тоже может быть свой форум. Так как у форумов есть формальная роль в оргструктуре, то какие нужны форумы решают шефы.
Шефы могут делегировать работу форумам - например, стандартизацию, шаблоны, инструментарий, персональное развитие, кросс-командую координацию и так далее. Они могут ожидать от каждого сотрудника базы быть участником ровно (либо - хотя бы) одного форума, а также участия в обсуждениях и решениях, важных для функциональных областей сотрудника. Роль форумов - быть соединительной тканью между экипажами.

Теперь, прежде чем вы мне скажете, что это то же самое, что делают чаптеры в модели Spotify, позвольте мне настоять на одном критическом различии - в форуме НЕТ линейного менеджмента! Найм, компенсации, карьерное развитие и обзор производительности НЕ являются частью мандата форума. Предназначение форума - чтобы люди со сходными ролями договаривались о том, как делается их работа в рамках базы путем самоорганизации. Чтобы динамическая пересборка команд была настолько безболезненной, насколько это возможно.

Например, когда производительность двух экипажей страдает из-за того, что два участника захотели поменяться местами, их форум должен выяснить корневую причину и что-то с ней сделать. Им не хватило онбординга? Способы работы в этих командах слишком сильно различались? Культура экипажей перевесила культуру базы? Цель форума - оптимизация на уровне базы, а не на уровне экипажей.
Председатель (модератор)
Председатель это менеджер форума, а НЕ людей. Позвольте мне повторить это, чтобы убедиться что меня правильно поняли. Человек, который модерирует форум ответствен за все активности форума. Он не менеджер людей, принимающих участие в форуме. Роль председателя это работа по совместительству, обычно выполняемая кем-то синьорным из состава базы. Он управляет дискуссией и решениями, но никогда не говорит относительно компенсаций или повышений. Можно сказать, что председатель это "первый среди равных".
Еще раз, Главная причина отсутствия линейного менеджмента на форуме в том, чтобы поддерживать гибкость. Снова внедрить функциональные департаменты это последняя вещь, которую мы хотим! Когда лидеры форумов получают менеджерскую ответственность за людей, люди становятся частью их территории. Из-за этого сжимать, разделять или объединять форумы становится намного сложнее. Помимо этого вы получите матричную организацию. А это совсем не то, чего мы хотим.

Однажды я работал в команде в матричной организации. Мой проектный менеджер был из одной части организации, а функциональный - из другой. В матрице эти два человека часто даже не знают друг друга и работают на совершенно разные цели. С моей точки зрения, их линии управления потерялись за горизонтом в противоположных направлениях. К счастью, я от этого не страдал, но знаю много других людей, которые страдали. Репутация матричных организаций так себе, и на это есть основания.
unFIX - не модель матричной организации. Да, участники разных экипажей принимают участие в разных форумах, их менеджеры могут быть разными шефами. Но не важно, на какой экипаж вы смотрите - шефы всегда работают в одной команде лидеров. У менеджеров общие цели. Если в экипаже конфликт, его можно эскалировать одной команде менеджеров! Прощай, матрица.
Лига (дивизион)
Многие организации больше, чем 150 человек. В таких условиях сотрудникам приходится взаимодействовать с коллегами за пределами одной базы.
Формальный способом для этого - объединение нескольких баз в лигу или дивизион. Лига организована вокруг взаимозависимых потоков создания ценности или связанного клиентского опыта, у нее есть собственная команда менеджмента. Например, несколько B2C баз могут быть объединены в одну лигу, а несколько баз с продуктами B2B - в другую.

Эта конструкция сходна с уровнем большого решения в SAFe, который оборачивает несколько релизных поездов, доставляющих ценность одному или схожим потребителям (модель Spotify такой конструкции не описывает).
Клуб (гильдия, сообщество)
Наконец, стандартным неформальным решением для кросс-базовой коллаборации является то, что часто называют как сообществом практики (Community of Practice, CoP), сообществом по интересам (Community of Interest, CoI), центром экспертизы (Center of Excellence, CoE). Это неформальные клубы, добровольные структуры, позволяющие сотрудникам координировать способ работы за пределами одной базы (и даже между несколькими лигами).
Клубы часто появляются снизу вверх, и часто посвящены функциональным областям, как и форумы. Однако большая разница заключается в том, что форумы формализованы и запускаются сверху вниз шефами баз, тогда как клубы могут появляться спонтанно и снизу вверх, в любое время.

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

А как unFIX по сравнению с указанными выше альтернативами?

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

Рамки SAFe значительно шире, чем модель unFIX. Его целевая аудитория - большие традиционные корпорации. Для меньших и более молодых компаний SAFe слишком большой и бюрократичный. Помимо этого, SAFe намеренно умалчивает о линейном менеджменте. Это значит, что любая имплементация SAFe поверх существующей управленческой структуры открывает приглашение к колоссальному количеству недомоганий в матрице.

Сайт LeSS предполагает колоцированные команды, которые должны "оставаться вместе навсегда", а также не оставляет места разблокирующим командам, платформенным командам и командам сложных подсистем. Гибридный формат работы, топологии команд и динамические команды не получили любви от фреймворка LeSS. Мне кажется, что этот фреймворк не готов к будущему.

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

И наконец, что насчет Менеджмента 3.0? Что ж, в своей ранней работе я никогда не смел предлагать конкретную организационную модель. Кроме предложения, чтобы все команды стали центрами прибыли. Менеджмент 3.0 всегда был философией для менеджмента и набором полезных практик. Но описанная модель наконец предлагает структуру, которой
Менеджменту 3.0 всегда не хватало, и которая сможет связать весь инструментарий воедино.

Заключение
Как я говорил ранее, картина новая; идеи - нет. Я знаю быстро растущие стартапы, а также компании в фазе интенсивного роста, которые уже следуют почти всему, что я описал. Они могут называть базы трайбами, экипажи командами, форумы - функциональными единицами. Терминология не важна. Я предлагаю другие слова, потому что они могут помочь людям различить старое и новое. В конце концов, оргструктура это не про названия. Это про намерение, ответственность и принятие решений.

Я верю, что модель unFIX, как она описана здесь, готова для будущего с динамическими командами, топологией команд и гибридным форматом работы. Она позволяет компании стать истинно гибкой организацией. Может быть, вы уже знаете большую часть этого, потому что видели схожие советы в других местах. Это здорово. Но я уверен, что мои картинки лучше :).

Я предлагаю эту модель командам и организациям, чтобы помочь с само-улучшением, Lean-Agile трансформации и усилиям по вовлечению клиентов. Скачать PDF с этой моделью может любой зарегистрированный пользователь Shiftup.