unFix — оргструктура, как Лего. Как собрать, разобрать и обратно собрать компанию

Каждые несколько лет в индустрии появляется очередная модель, которая обещает навести порядок в организации. SAFe. LeSS. Spotify Model. Holacracy. Все они приходят с одним и тем же посылом: «внедрите это целиком, и будет хорошо».

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

Юрген Аппело, автор Management 3.0, сделал штуку, которая принципиально отличается от всего перечисленного.

unFIX — это не фреймворк. Это библиотека паттернов, конструктор, набор Лего деталек для организационного дизайна. Берёшь только то, что нужно прямо сейчас. Остальное не трогаешь — ничего обязательного.

Приготовьтесь, далее все будет похоже, будто Вы читаете правила настолки

---

Чем unFIX не является

Прежде чем разбираться, что это такое, проще начать с того, чем это точно не является. Автор сам на этом настаивают — и правильно делает.

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

Здесь нет процессов. unFIX покрывает только организационный дизайн и структуру. Как именно работать внутри этой структуры — Scrum, Kanban, что-то своё — решаете вы сами. Процессных практик хватает и без unFIX.

Это не только для IT. В библиотеке паттернов нет встроенного предположения, что вы разрабатываете софт. Всё то же самое можно применить к маркетингу, производству, сервисным подразделениям — к чему угодно.

Это не сверху вниз. В отличие от некоторых моделей, которые начинаются с «перестройте всю компанию», unFIX предлагает начинать с малого. Снизу. С одной команды. Нельзя построить что-то большое сразу — начинайте с маленького.

Это не замена. unFIX не требует выбросить всё, что у вас работает. Идея в том, чтобы «размонтировать» то, что мешает, и оставить то, что помогает.

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

---

Экипажи: базовая единица всего

Центральный элемент unFIX — экипаж (Crew). Это команда из 3-7 человек, идеально — 5. Самоорганизующаяся, кросс-функциональная.

Участники в основном работают только в своём экипаже. Допускается небольшая часть времени на участие в форуме (об этом ниже), но основная привязка — к экипажу.

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

---

Семь типов экипажей

Экипаж потока ценности (Value Stream Crew)

Это главный тип. В нормальной компании большинство экипажей должны быть именно такими.

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

Доставка ценности может быть регулярными релизами продукта или обновлениями сервиса. Внутри экипаж сам решает, как работать — Kanban, Scrum, что-то своё. Управленческая команда или форум могут задать ограничения или предложить рекомендации, но детали процесса — дело самого экипажа.

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

Именно из-за передач между командами бизнес становится невыносимо медленным. Один экипаж разрабатывает, другой тестирует, третий деплоит, четвёртый поддерживает — и каждая передача это потеря контекста, ожидание в очереди и размывание ответственности (и еще постоянно жалобы на блокеров). Экипаж потока ценности убирает всё это.

Экипаж содействия (Facilitation Crew)

Иногда нужна команда, которая не создаёт ценность сама, а помогает другим экипажам работать хорошо.

У такого экипажа нет своего потока ценности. Его задача — чтобы экипажи потока ценности в базе (об этом ниже) работали гладко. Классический пример — команда скрам-мастеров или коучей.

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

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

Экипаж компетенций (Capability Crew)

Бывает, что в компании есть специалисты с редкими навыками, которых невозможно раздать по всем экипажам. Машинное обучение, кибербезопасность, анализ данных — у вас восемь потоков ценности, а таких специалистов трое. Троих на восемь команд не растянешь.

Решение — экипаж компетенций. Люди с продвинутыми навыками объединяются в отдельный экипаж. Их задача — помогать другим командам, когда нужна их экспертиза. Специалисты временно работают в экипажах потока ценности как гостевые участники. Похоже на то, как внешние консультанты с глубокими знаниями подключаются к проекту на время.

Платформенный экипаж (Platform Crew)

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

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

Экипаж клиентского опыта (Experience Crew)

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

Решение — экипаж, который смотрит на весь путь клиента целиком. Его задача — оптимизировать клиентский опыт в точках, где он пересекает несколько продуктов и каналов.

Экипаж партнёрств (Partnership Crew)

Роль почти идентична экипажу клиентского опыта, но фокус другой. Вместо клиентов и пользователей — поставщики, партнёры, фрилансеры, сотрудники, подрядчики. Любой человек или организация, с которыми компания заключает контракты — через закупки или HR.

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

Управленческий экипаж (Governance Crew)

Это команда управленцев. Состоит из нескольких руководителей (Chiefs), которые являются менеджерами всех людей в базе. Если база — это вся компания, то управленческий экипаж — это совет директоров.

У него две ответственности.

Первая — лидерство. Задать видение и цель для базы. Определить бизнес-модель и домен. Выработать стратегию. И сделать всё, чтобы каждый сотрудник чувствовал причастность и признание.

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

Важно: руководители задают рамки, но не управляют каждым шагом. Это сервис для самоорганизации, а не командная вертикаль.

---

Капитан

Каждый экипаж может иметь капитана (Captain). Но это не начальник в привычном смысле.

Капитан не занимается оценкой сотрудников, зарплатой и карьерным ростом. Он отвечает за направление, связь с внешним миром и помогает экипажу двигаться вперёд. Это именно сервисная роль — лидерство как услуга для команды, а не власть над ней.

---

База

Все экипажи работают из базы (Base). Это группа от нескольких человек до нескольких сотен.

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

У каждого человека есть база. Это его дом. База даёт людям цель, причастность и признание. Обеспечивает комфорт, безопасность, связанность, общую культуру, общие инструменты и карьерные возможности.

Главная задача базы — постоянно реорганизовывать себя в зависимости от потребностей клиентского опыта.

Мы знаем, что организационная структура напрямую связана с архитектурой продукта (закон Конвея* работает в обе стороны). Когда архитектура меняется — организация тоже должна меняться. Поэтому база делает всё, чтобы экипажи оставались гибкими. Включая поддержание минимальных стандартов и правил, чтобы пересборка команд проходила максимально безболезненно.

Это и есть размонтирование. Не раз в год на страт-сессии, а постоянно, как часть нормальной работы.

*Закон Конвея (сформулированный Мелвином Конвеем в 1967 г.) гласит, что организации проектируют системы, которые копируют структуру коммуникаций в этой организации. Проще говоря, архитектура программного обеспечения неизбежно отражает организационную структуру команд, которые его создают, так как коммуникационные барьеры между людьми становятся барьерами в коде

---

Форумы: горизонтальная координация без матрицы

Форум (Forum) — это группа из людей разных экипажей. Главная цель — чтобы специалисты со схожими интересами могли собраться, обсудить и принять решения вместе.

Может быть форум по DevOps, по UX, по Growth Hacking. В традиционных компаниях проектный офис (PMO) можно превратить в форум. В более гибких компаниях продуктовые менеджеры могут иметь свой форум.

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

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

Форумы — это соединительная ниточка между экипажами, без матрицы, без двойного подчинения и без безумных согласований. Человек остаётся в своём экипаже, а через форум координируется с коллегами из других команд по функциональной теме.

---

Масштабирование: фрактальная модель

unFIX масштабируется через самоподобие. Те же самые паттерны повторяются на каждом уровне.

Лига (League) — десятки баз работают вместе. Внутри лиги базы могут формировать кластеры (Cluster) — по аналогии с тем, как люди формируют экипажи. Один кластер может быть кластером потока ценности, другой — платформенным, третий — кластером компетенций. У лиги есть свой управленческий кластер, и она организована вокруг взаимозависимых потоков ценности.

Координация между базами идёт через ассамблеи (Assembly) — по аналогии с форумами на уровне экипажей. Представители баз координируют способы работы через границы одной базы.

Толпа (Crowd) — ещё уровень выше. Десятки лиг формируют толпу. Лиги внутри самоорганизуются в коалиции (Coalition) и координируются через конгрессы (Congress).

Все паттерны повторяются на каждом масштабе:

Это фрактальная модель. Она самоподобна на любом масштабе — от стартапа из 15 человек до корпорации из 15 000.

---

Чем отличается от всего остального

Моделей организационного дизайна хватает. Поэтому логичный вопрос, зачем нужна еще одна.

Классическая иерархия и матрица. Жёстко зафиксирована структура и отчётность. Ты принадлежишь отделу, у тебя один (или два, в матрице) начальника, и чтобы что-то поменять — нужно пройти через реорганизацию. Матрица добавляет двойное подчинение, от которого люди сходят с ума: «кому я сейчас отчитываюсь — функциональному руководителю или проектному?» В unFIX нет обязательной структуры отчётности. Есть экипажи, базы и форумы. Человек принадлежит экипажу (это его дом) и участвует в форуме (это координация). Никакого двойного подчинения.

Holacracy. Красивая идея: убрать менеджеров, заменить их конституцией с чёткими правилами, ролями и кругами. На практике — получается жёсткая бюрократическая машина, только вместо начальников — формальные процедуры. Каждая роль прописана, каждое решение идёт через определённый ритуал. unFIX не навязывает ни конституции, ни обязательных ролей. Нет абстрактной машины, которую нужно запускать целиком.

SAFe (Scaled Agile Framework). Огромный фреймворк с десятками ролей, процессов, церемоний и уровней. Отлично продаётся консультантами, но на практике частенько превращается в тяжёлую бюрократию, которая душит подушкой ту самую гибкость, ради которой всё затевалось. В unFIX нет процессов вообще. Только структурные паттерны. Как работать внутри — решаете сами.

LeSS (Large-Scale Scrum). Проще, чем SAFe, но всё равно привязан к Scrum как обязательной основе. Если у вас не Scrum — LeSS не ложится. unFIX не предполагает никакого конкретного процесса.

Spotify Model. Tribes, Chapters, Guilds, Squads — звучит! Но по-простому, это обычная матрица с красивыми словечками. Chapter Lead — это функциональный менеджер. Squad — проектная команда, и ты снова в двойном подчинении. unFIX осознанно избегает матричных проблем. Форумы — это не Chapters, у них нет «лидера», который одновременно твой менеджер.

*Если интересно, могу подготовить статьи с подробным объясненим этих фреймворков/практик

Если свести в таблицу:

unFIX убрал все и оставил полезные лего детальки.

---

Другие паттерны из библиотеки

Экипажи, базы и форумы — это структурные паттерны, они самые известные. Но библиотека unFIX шире. Там есть паттерны для разных аспектов организационной жизни.

Паттерны пересборки команд (Dynamic Reteaming)

Одна из ключевых идей unFIX — команды не должны быть вечными. Продукт меняется, архитектура меняется, рынок меняется — и состав экипажей должен меняться вместе с ними.

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

Здесь же живёт паттерн виртуализации (Virtualization) — когда человек временно участвует в другом экипаже, не покидая свой основной. Не «двойное подчинение», а осознанное, ограниченное по времени подключение к задаче.

Паттерны принятия решений

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

unFIX предлагает набор паттернов для принятия решений — от простого делегирования до групповых форматов. Идея в том, чтобы решения принимались на уровне, где есть контекст, без лишних согласований.

Паттерны целеполагания

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

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

Паттерны роста и эволюции

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

Карточки для воркшопов

Для всех паттернов есть готовые карточки — физические или цифровые. Их можно буквально раскладывать на столе и собирать свою организационную структуру как конструктор.

---

Завершаем

unFIX — это не серебряная пуля. Он не решит проблемы за одну ночь. У него нет сертификации за 2 дня и армии консультантов, которые внедрят его за полгода.

Но в этом и суть. Библиотека паттернов, которую можно открыть, посмотреть и взять то, что подходит.

Размонтировал то, что мешает. Собрал то, что нужно. Пошёл дальше.

Подобные и другие вещи из мира IT я также разбираю в своем телеграмм канале «На Дерево«, всех жду!

---

Официальный сайт: unfix.com