Системный менеджмент

Как устроены компании, паттерны и антипаттерны организационного дизайна

21 апреля 2026

Компания - это не оргчарт, а система потоков ценности и принятия решений. Оргчарт описывает, кто кому подчиняется; но работа идёт горизонтально, от запроса клиента до поставленной ценности, и пересекает несколько функций. Структура компании определяет, какие из этих пересечений проходят гладко, а какие превращаются в очереди, эскалации и потерянный контекст. Большинство реорганизаций не работают, потому что меняют оргчарт, не меняя потоки. Статья разбирает классические структуры (функциональная, дивизиональная, матричная, продуктовая, сетевая), типичные антипаттерны (silos, матричный ад, реорганизационный театр), современные альтернативы (Haier, holacracy, pod-модели) и отдельно - специфику IT, где закон Конвея делает структуру буквально материальной.

Компания как система, а не как оргчарт Из чего состоит компания: функции и потоки ценности Пять классических структур и что каждая оптимизирует Silos: универсальный антипаттерн разделения по функциям Матрица: где работает, где matrix hell Кросс-функциональная интеграция: как ломают silos Современные и экспериментальные структуры Специфика IT: закон Конвея Размеры и пороги управляемости Антипаттерны системного менеджмента Как диагностировать свою структуру Рамка действий: от диагноза к изменениям Источники и смежные статьи

Компания как система, а не как оргчарт

Оргчарт описывает формальную авторизацию: кто принимает решения по найму, кто ставит цели, кто утверждает бюджет. Это важный слой, но сам по себе он не объясняет, как компания работает. Работа идёт по потокам ценности, и каждый поток пересекает несколько функций. От первого контакта с клиентом до закрытой сделки - маркетинг, SDR, AE, юристы. От идеи фичи до её adoption - продукт, дизайн, разработка, QA, поддержка, успех клиентов. От инцидента до post-mortem - поддержка, инженерия, devops, product.

Что система действительно производит, определяется не должностями, а тем, насколько эффективно поток проходит через функциональные границы. Если между маркетингом и продажами каждый лид теряет контекст, неважно, какого уровня у вас VP of Marketing; воронка всё равно просядет.

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

Systems thinking Питера Сенджа в книге «The Fifth Discipline» (1990) добавляет к этому идею learning organization: компания, которая умеет наблюдать за собственной системой и перестраивать её, выигрывает у компаний, которые оптимизируют отдельные функции. Пять дисциплин Сенджа - personal mastery, mental models, shared vision, team learning и systems thinking как объединяющее ядро. Ядро именно systems thinking, потому что без него остальные практики применяются локально и не складываются в общий результат.

Анатолий Левенчук в «Системном менеджменте 2023» разделяет управленческую деятельность на четыре роли: бизнесмен (определяет, что компания делает и зачем), оргархитектор (проектирует, как она устроена), организатор (запускает работу), администратор (поддерживает её в рабочем состоянии). В малых компаниях все четыре роли сидят в одном фаундере. Проблемы начинаются, когда компания растёт, а роли не разделяются: бизнесмен продолжает править архитектуру, организатор тонет в административке, оргархитектура вообще никем не ведётся.

Главный антипаттерн этого слоя - «решим через реорг». Видится симптом (медленный delivery, падающая конверсия, рост costs), делается реорганизация: новые названия функций, перетасовка людей, новый оргчарт. Через полгода симптом возвращается, потому что правила, стимулы и потоки остались те же, изменились только подписи в Confluence.

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

Из чего состоит компания: функции и потоки ценности

Любая компания - это пересечение двух измерений.

Функции - вертикальная ось. Это подразделения, сгруппированные по специализации: продажи, маркетинг, продукт, разработка, поддержка клиентов, финансы, HR, юристы, операции. Каждая функция имеет свою экспертизу, свои метрики, свой типичный горизонт планирования и свои карьерные треки. Маркетинг думает кварталами и кампаниями. Продажи - месяцами и квотами. Разработка - релизами и архитектурой. Поддержка - часами и SLA. Горизонты разные, метрики разные, язык разный.

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

Каждый поток пересекает несколько функций. Lead-to-revenue - маркетинг, продажи, юристы, финансы, поддержка. Feature delivery - продукт, дизайн, разработка, QA, devops, поддержка, маркетинг. Incident response - поддержка, инженерия, devops, иногда клиентский успех.

Результат компании - не сумма работы функций, а качество прохождения потоков через их границы. Маркетинг, который сгенерил 10 000 лидов, продажи, которые закрыли 100 сделок, поддержка, которая обработала тикеты за 2 часа - это изолированные метрики функций. Бизнес-результат - сколько лидов стало выручкой за квартал и какой NRR в годовом разрезе.

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

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

Пять классических структур и что каждая оптимизирует

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

Структура Что оптимизирует Когда уместна Типичные проблемы Примеры
Функциональная Глубину экспертизы, экономию масштаба Стабильный продукт, узкая линейка, предсказуемая среда Handoff между функциями, медленные потоки, локальная оптимизация Банки, страхование, классическое производство
Дивизиональная Скорость реакции на рынок, фокус Несколько независимых продуктов или регионов Дублирование функций, внутренняя конкуренция за ресурсы P&G, GE, транснациональные корпорации
Матричная Утилизация дефицитных ресурсов, кросс-функциональность Проекты коротки, ресурсы дорогие, приоритеты ясны Конфликт двух боссов, размытая ответственность, рост эскалаций Консалтинг, R&D в авиации и фарме, NASA
Продуктовая / Stream-aligned Lead time и end-to-end ownership Продукт быстро эволюционирует, обратная связь частая Требует platform-обвязки, сложность на стыках Amazon, современные B2B SaaS, pod-модели
Сетевая / проектная Гибкость, отсутствие overhead Работа проектная по природе, команда рассыпается после проекта Нет долгосрочной стабильности, дорого передавать знания Агентства, кино-продакшен, management consulting

Функциональная структура - исторически первая. Каждое подразделение - это вертикаль специалистов: все инженеры в одной иерархии, все продавцы в другой, все маркетологи в третьей. Работа идёт через функции последовательно: маркетинг приводит лидов - передаёт продажам, продажи закрывают - передают onboarding, onboarding запускает - передаёт support. Это хорошо работает, если продукт стабильный, потоков немного и они предсказуемы. На каждом переходе между функциями - очередь и потеря контекста; если потоков мало, это терпимо.

Дивизиональная - ответ на рост и диверсификацию. Когда продуктов становится больше и у них разные рынки, компания делится на дивизионы, каждый из которых имеет свои функции. P&G исторически устроен так: каждый бренд (Tide, Pampers, Gillette) - отдельный мини-бизнес с маркетингом, R&D, финансами. Плюс - фокус и скорость. Минус - дублирование: каждый дивизион содержит свою HR-функцию, свои IT-сервисы, свою финансовую команду. Появляются корпоративные центры (shared services), которые сами становятся silo-функциями.

Матричная была придумана в NASA и больших инжиниринговых организациях для проектов, где специалистов мало, а проектов много. Один инженер одновременно относится к функциональной вертикали (структурное проектирование) и к проекту (Apollo). У него два босса. Работает, когда два босса явно иерархизированы (проект главнее функции или наоборот), когда проекты коротки и когда эскалации разрешаются быстро. В продуктовой разработке почти всегда ломается: проекты долгие, приоритеты сложные, эскалации уходят на C-level.

Продуктовая / Stream-aligned - современный дефолт для SaaS и многих consumer companies. Команда владеет продуктом или сегментом end-to-end: в ней есть продукт-менеджер, инженеры, дизайнер, иногда маркетинг и CS. Команда отвечает за метрики своего сегмента. Для работы нужна Platform team, которая снимает cognitive load по инфраструктуре. Без платформы каждая продуктовая команда вынуждена держать своих devops, свой CI/CD, свой мониторинг - и это быстро становится невозможным.

Сетевая / проектная структура - стандарт для консалтинга и креативных индустрий. Нет постоянной структуры команд вообще; под каждый клиентский проект собирается команда из пула специалистов, после проекта - возвращаются в пул. Максимальная гибкость, но ноль долгосрочной стабильности и сложно инвестировать в общие активы (продукт, IP, knowledge base).

Реальная компания обычно гибрид. Типичный вариант для B2B SaaS на 150-300 инженеров: функциональный skeleton (VP of Engineering, VP of Product, VP of Sales) + продуктовые команды со Stream-aligned фокусом внутри инженерии + Revenue Operations как объединённая функция Sales-Marketing-CS Ops + Platform team как центральная функция. Вопрос не «какая структура правильная», а «где пройти баланс между вертикальной экспертизой и горизонтальной скоростью потока».

Silos: универсальный антипаттерн разделения по функциям

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

Четыре признака silo:

Sales и Marketing - самый классический silo

Маркетинг оптимизирует MQL: сколько лидов сгенерили, по какой цене, с каким MQL-to-SQL коэффициентом. Продажи оптимизируют закрытые сделки: revenue, average deal size, win rate. Лиды передаются через CRM, и на этом интерфейсе происходит всё самое интересное: качество теряется, контекст обрывается, ожидания не совпадают. Маркетинг «генерит тонны мусора»; продажи «не умеют конвертить». Обе функции правы с точки зрения своих метрик и обе ошибаются с точки зрения общего потока.

Решения, которые работают:

Support и Engineering

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

Решения:

Finance и Legal как gatekeepers

В зрелых компаниях любой проект выше определённого threshold проходит через их согласование. Они не отвечают за бизнес-результат, но отвечают за соответствие правилам. Это превращает их в узкое горло: любая новая инициатива стопорится на согласовании контрактов, соответствии требованиям, корректности расходов. Teams учатся обходить эти функции или копить pull requests на месяц, чтобы разом их защитить.

Решения:

Экономика handoff

В книге «Making Work Visible» Dominica DeGrandis показывает зависимость между загрузкой и временем ожидания в системе очередей: при утилизации выше 80% время ожидания растёт экспоненциально. Каждый handoff между функциями - это очередь; при высокой утилизации каждая передача добавляет дни или недели. Функции, которые работают на 100% загрузки, выглядят эффективными локально, но система в целом становится катастрофически медленной.

IT-специфика

Классический IT-silo - DBA, QA, DevOps, Security как отдельные функции. В 2000-х это было стандартом: отдельный отдел DBA, отдельная команда ручного QA, отдельные operations. Сегодня тренд - shift-left и embedded: security champions в продуктовых командах, QA-инженеры как enabling, SRE как платформенный сервис. Паттерн движения к кросс-функциональным командам универсальный, но в IT он развивался быстрее из-за закона Конвея и скорости delivery.

Silo узнаётся по простому тесту: если функция может отчитаться о хороших результатах, в то время как общий поток деградирует, это silo. Маркетинг приносит рекордное количество MQL, а pipeline revenue падает - silo. Разработка релизит фичи по плану, а retention падает - silo. Инженерия поддерживает 99.95% uptime, а клиенты жалуются на performance - silo на границе SRE и продуктовых команд.

Матрица: где работает, где matrix hell

Матричная структура придумана в 1960-х в NASA и больших инжиниринговых компаниях. Jay Galbraith описал её формально в статье «Matrix organization designs» (Business Horizons, 1971) как ответ на проблему: как распределять дорогих специалистов между несколькими параллельными проектами. В 1973 вышла его книга «Designing Complex Organizations», развивающая эту тему.

Идея матрицы: каждый сотрудник одновременно относится к функциональной вертикали (я инженер по структурному анализу, мой функциональный босс - глава структурного отдела) и к проекту (я работаю над Apollo, мой проектный босс - директор программы Apollo). Функциональный босс отвечает за развитие, стандарты, профессиональный рост; проектный - за результат конкретного проекта.

Типы матрицы различаются балансом силы двух боссов:

Где матрица действительно работает

Matrix hell

В продуктовых компаниях матрица обычно ломается. Сотрудник имеет двух боссов с разными целями и разными горизонтами. Функциональный менеджер хочет, чтобы человек инвестировал в развитие и соблюдал стандарты; продуктовый менеджер хочет, чтобы человек делал фичи. Приоритеты конфликтуют, сотрудник не знает, чью сторону принимать, эскалации уходят всё выше. На C-level накапливаются «матричные проблемы»: два VP-а спорят, кому важнее ресурс этого инженера в этом квартале.

Признаки matrix hell:

Эмпирическое правило: чем длиннее проекты и чем медленнее меняются приоритеты, тем хуже матрица. SaaS-компании на продуктовых стадиях почти все ушли от матрицы к продуктовой структуре с функциональными guilds или chapters для развития (где функциональный «босс» не распоряжается временем человека, а отвечает за карьерную траекторию и стандарты).

Переход от матрицы к продуктовой структуре почти всегда - улучшение для SaaS. Обратный переход оправдан редко, только когда специалисты реально дефицитны и работают коротко на многих проектах.

Кросс-функциональная интеграция: как современные компании ломают silos

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

Pod-модель в B2B SaaS

Pod - это кросс-функциональная команда из 8-15 человек, включающая Account Executive, Customer Success Manager, Product Manager, Engineering Manager, иногда marketing-представителя и solutions engineer. Все работают на один сегмент клиентов (SMB / Mid-Market / Enterprise) или на одну продуктовую линейку. Общая метрика - net revenue retention или чистая выручка сегмента.

Эта модель похожа на Stream-aligned team из Team Topologies, но не ограничена инженерией: продукт принадлежит не только разработке, он принадлежит всей цепочке от продажи до удержания. Классический пример - Gainsight и другие CS-центричные SaaS-компании, ряд сегментов в HubSpot и Atlassian.

Revenue Operations (RevOps)

Объединение Sales Operations, Marketing Operations и Customer Success Operations в одну функцию с единым data stack. Исторически эти три функции существовали отдельно: Sales Ops держал CRM, Marketing Ops держал marketing automation, CS Ops держал успех-tooling. Данные не соединялись, воронка фрагментировалась. RevOps решает эту проблему на уровне данных и процесса: единая customer journey, единые метрики, единая ответственность за pipeline и retention.

RevOps - это не «объединили три silo в одно большое silo». Это структурный фикс на уровне data layer, после которого Sales, Marketing и CS продолжают существовать как отдельные функции, но работают на общих данных и общих метриках.

DevOps как исторический пример

До конца 2000-х infrastructure и software engineering были жёстко разделены: разработчики писали код, operations его деплоили и поддерживали. Передача через ticket, конфликт «throw it over the wall», классический silo. DevOps как движение 2009-2015 слил эти функции: инженеры получили доступ к инфраструктуре, operations стали программировать инфру как код, появилась общая культура continuous delivery. Это не произошло за счёт реорганизации ради реорганизации; это произошло, потому что изменились инструменты (cloud, IaC, containers) и стало возможно стереть границу.

Сейчас похожий процесс происходит с:

PLG-команды

Product-Led Growth перераспределяет ответственность: продукт сам конвертит пользователей (freemium, self-serve onboarding, usage-based pricing), а не продажи. Это меняет структуру: команда Growth внутри продукта отвечает за те же метрики, что раньше принадлежали маркетингу и продажам (activation, conversion, expansion). Slack, Notion, Figma, Linear - примеры PLG-компаний с маленькими sales-командами по сравнению с revenue.

Account-Based Everything

Маркетинг, продажи и CS работают на общий список named accounts. Ранее каждая функция работала с собственной выборкой: маркетинг со всеми, кто пришёл в воронку, продажи с теми, кто в пайплайне, CS с активными клиентами. В ABM - общий список 500-2000 целевых аккаунтов, общий контент, общие ритуалы, общие метрики по каждому аккаунту (engagement, pipeline, closed revenue, expansion).

Общий принцип всех паттернов кросс-функциональной интеграции - не «объединить людей в одну команду», а три элемента одновременно: общие метрики, которые нельзя улучшить в одной функции в ущерб другой; общий контекст через регулярные совместные ритуалы; прямые интерфейсы между функциями вместо передачи через менеджерское звено. Любой из элементов по отдельности недостаточен.

Современные и экспериментальные структуры

Классические структуры - не единственные. За последние 20-30 лет появились альтернативные модели, часть из которых работает в масштабе, часть - только в нишах.

Haier RenDanHeYi

Китайский производитель бытовой техники разделён на примерно 4000 микропредприятий по 10-15 человек. Каждое микропредприятие полностью self-contained: имеет собственный P&L, отвечает за конкретный продуктовый сегмент или функцию, напрямую взаимодействует с клиентами, может самостоятельно нанимать и заключать контракты с внешними партнёрами. Поверх микропредприятий - platform functions (бренд, shared infrastructure, capital allocation) и ecosystems of micro-communities (группы микропредприятий, работающих в смежных областях).

Zhang Ruimin (CEO Haier до 2021, затем honorary chairman) в 2025 году провёл Europe Tour, демонстрируя модель в Италии и Сан-Марино. Ключевая идея: устранить иерархических посредников между сотрудником и клиентом. В традиционной корпорации инженер на 5-м уровне иерархии не видит клиента; в RenDanHeYi каждое микропредприятие имеет прямой контакт с рынком и прямую ответственность за его результаты.

Работает в производстве, где продуктовые сегменты достаточно независимы (стиральные машины, холодильники, кондиционеры - разные клиенты, разные каналы). В SaaS прямой аналог не встречается, но идея микропредприятий с P&L частично реализована в Amazon с two-pizza teams, которые имеют собственные метрики и почти автономные решения.

Holacracy

Формальный framework, разработанный Brian Robertson в 2007. Организация структурирована как вложенные круги (circles), в каждом круге - роли с явно описанными accountabilities. Нет должностей в традиционном смысле; есть роли, которые человек исполняет (один человек может исполнять несколько). Все правила зафиксированы в constitution - публичном документе.

Часто неправильно понимается как «нет иерархии». На самом деле иерархия есть, но это иерархия scope, а не иерархия власти: внешний круг задаёт цели внутреннему, внутренний круг сам решает, как их достигать. Решения принимаются в рамках роли без согласования, если не нарушают constitution. Для решения конфликтов - специальный tension process с фиксированными правилами обсуждения.

Работает для небольших организаций с высокой экспертизой сотрудников: Medium (частично, откатились), ряд consulting-компаний. Плохо масштабируется: в больших организациях constitution становится 100-страничным документом, tension meetings - бюрократией, а решения - не быстрее обычной иерархии. Zappos внедрили с большой публичностью в 2013-2014. В марте 2015 Tony Hsieh предложил сотрудникам ультиматум: принять holacracy или уйти с компенсацией - ушло 18% штата, примерно 260 человек. Через 5 лет Zappos тихо отошли от строгой holacracy.

Beyond Budgeting

Управленческая парадигма, отказывающаяся от фиксированного годового бюджета в пользу rolling forecasts (непрерывные прогнозы на 6-12 месяцев вперёд) и relative targets (цели относительно рынка или peer-группы, а не абсолютные). Практический первоисточник - Jan Wallander, CEO Handelsbanken с 1970 года, открыто отказавшийся от бюджетов как от «бесполезной активности»; с тех пор банк живёт без фиксированных бюджетов и centrally controlled targets. Теоретическая формализация - книги Jeremy Hope, Robin Fraser и Bjarte Bogsnes.

Основные принципы:

Не про IT специально, работает в любой индустрии. Применимо ко всей компании, но чаще всего внедряется в финансовой функции и постепенно распространяется.

Buurtzorg

Нидерландская патронажная медицина, основана в 2006 Jos de Blok. Команды по 10-12 медсестёр полностью самоуправляемы: сами находят клиентов на районе, сами планируют работу, сами нанимают новых членов, сами принимают административные решения. Нет линейных менеджеров; есть центральная поддержка (bekwame coaches), которая помогает, но не распоряжается. Примерно 14 000 сотрудников - один из самых крупных и долгоживущих примеров self-managed organization в больших масштабах.

Morning Star

Калифорнийский производитель томатной продукции, примерно 500 постоянных сотрудников и до 2500 в пиковый сезон. Каждый пишет Colleague Letter of Understanding (CLOU) - личный контракт с коллегами о том, что он будет делать, какие metrics у него, кто его «клиенты» внутри компании. Нет должностей, нет менеджеров; есть роли и контракты. Работает в производстве уже 30+ лет.

Spotify model - как урок, а не рецепт

В октябре 2012 Henrik Kniberg и Anders Ivarsson, работавшие со Spotify как agile-коучи, опубликовали whitepaper «Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds»: squads (продуктовые команды), tribes (группы squads), chapters (функциональные группы внутри tribe), guilds (cross-cutting communities). В 2014 к этому добавились два видео «Spotify Engineering Culture» Part 1 и Part 2. Документ не был официальной публикацией Spotify - Kniberg специально подчёркивал: «это не рецепт, это снимок того, что мы делаем сейчас». Модель стала культурным явлением; её начали копировать тысячи компаний.

Jeremiah Lee, работавший в Spotify в тот период, опубликовал в 2020 эссе «Spotify's Failed #SquadGoals», где показал: модель никогда не работала в Spotify так, как описывалась в whitepaper-ах. Это было aspirational описание, а не фактическое состояние. Компании, которые копировали модель, получили тот же результат, что Spotify - tribes становились слишком большими, chapters не улучшали стандарты, guilds превращались в бесполезные общения, autonomy без alignment вела к хаосу.

Главный урок: копирование labels без принципов не работает. «Мы теперь squads и tribes» не меняет ничего, если остаются те же метрики, те же incentives, та же культура принятия решений.

Специфика IT: закон Конвея и материализация структуры в коде

Основная специфика IT-организаций описана законом Мелвина Конвея. Сам закон сформулирован в статье «How Do Committees Invent?» (Datamation, апрель 1968): любая организация, проектирующая систему, воспроизведёт в структуре системы свою коммуникационную структуру. Термин «закон Конвея» позже закрепил Fred Brooks в «The Mythical Man-Month». Если в компании три команды, система получится из трёх компонентов. Если команды общаются редко - между компонентами будут жёсткие интерфейсы. Если команды слиты - компоненты будут связанными.

В других индустриях это метафора. В IT - буквально материализуется в коде и архитектуре. Монолит растёт под одну команду; микросервисы - под несколько. Структура папок в репозитории повторяет структуру команд. Связность между модулями кода повторяет связность между людьми.

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

Следствия для IT, которые не видны в других индустриях:

DDD как словарь границ. Domain-Driven Design предложил инструментарий для определения bounded contexts - явных границ с собственными моделями и терминами. DDD не про код; DDD про бизнес-области и связи между ними. Bounded context - это то, что должна владеть Stream-aligned команда.

Team Topologies как формат команд. Четыре типа команд (Stream-aligned, Platform, Enabling, Complicated-subsystem) и три паттерна взаимодействия (Collaboration, X-as-a-Service, Facilitating) - современный дефолт для структурирования инженерной организации. Подробности - в отдельной статье по Team Topologies.

AI-специфика. AI-агенты работают с формализованным контекстом: кодом, документацией, тестами. Они не видят того, что существует только в голове инженеров и в устных договорённостях. Размытые границы команд = размытые границы в коде = агент не понимает, куда что относится и кого звать на review. В эпоху AI-assisted разработки чёткие границы bounded contexts становятся не просто хорошей практикой, а условием эффективности агентов.

IT-специфика не отменяет универсальные принципы системного менеджмента из предыдущих секций. Silos в IT - те же silos, что в маркетинге. Матричная структура в IT - тот же матричный ад, что в консалтинге. Но закон Конвея добавляет слой последствий, которых нет в других индустриях: плохая орг-структура материализуется в коде и остаётся там годами, даже после того как организация изменилась.

Размеры и пороги управляемости

Структура, работающая на 10 человек, не работает на 100. Работающая на 100 - не работает на 1000. Между этими размерами - не плавный переход, а несколько порогов, каждый из которых ломает старую модель.

Dunbar-числа

Robin Dunbar (антрополог, Oxford) в 1990-х обнаружил корреляцию между размером неокортекса приматов и размером стабильной социальной группы. Для человека - около 150 стабильных отношений. Число - часть фрактальной последовательности слоёв социальной сети:

Применимо не только к R&D. Продающая команда из 200 человек не работает как одна команда - она работает как несколько команд, даже если формально все подчиняются одному VP of Sales.

Правило Gore-Tex. Bill Gore (основатель Gore & Associates) наблюдал, что в facility на 150+ человек люди перестают знать друг друга по именам. Решение: разделять facility при достижении 150. Это применялось буквально - компания строила новый завод, когда старый подходил к 150. Сегодня Gore использует то же правило для business units.

Пороги перехода

Миф линейного масштабирования. Удвоение штата редко удваивает результат. Обычно результат растёт медленнее: +50-70% при +100% к штату, если повезёт. Причина - рост координационных издержек. Brooks's Law («adding manpower to a late software project makes it later») - частный случай этого правила для IT.

Между 50 и 150 почти все компании проходят кризис роста: структура, которая работала для 30, ломается для 100. Старые сотрудники жалуются, что «бюрократия задушила скорость»; новые - что «никто ничего не знает, процессы сломаны». Оба правы, и оба описывают одну проблему: структура не выросла вместе с компанией.

Антипаттерны системного менеджмента

Паттерны, которые встречаются снова и снова в разных компаниях и индустриях.

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

Как диагностировать свою структуру

Канонический инструмент диагностики организационного дизайна - Star Model Джея Галбрейта (книга «Designing Organizations», 3rd edition 2014). Пять взаимозависимых элементов: изменение в одном требует выравнивания с остальными, иначе откатится. Альтернативы (McKinsey 7S, Burke-Litwin, Weisbord 6-Box) - вариации той же идеи; берите любую, главное - не сводить диагностику только к структуре.

Пять элементов Star Model

Элемент Что это Сигнал проблемы
Strategy Что компания делает, для кого, какое конкурентное преимущество Функции по-разному отвечают на вопрос «что для нас сейчас важно»
Structure Как сгруппированы люди, кто кому подчиняется, сколько слоёв иерархии Размытый ownership, эскалации повторяются по одному типу вопросов
Processes Как идёт работа между группами: потоки ценности, handoff, SLA, ритуалы координации Delivery time растёт, очереди на handoff, рост координационных митингов
Rewards Как стимулируется поведение: метрики, бонусы, повышения, публичное признание Конфликтующие приоритеты между функциями, gaming метрик
People Какие компетенции в компании, как растут, как набираются, как уходят Дефицит ключевых ролей, текучка senior-уровня, проседающий онбординг

Главный антипаттерн системного менеджмента - менять только Structure. Реорганизация без выравнивания Processes (как теперь идёт работа?), Rewards (на что теперь вознаграждаем?) и People (нужны ли новые компетенции на новых ролях?) откатывается за квартал. Звезда работает только когда все пять элементов согласованы между собой и со Strategy.

Практические вопросы по каждому элементу

Strategy. Какие 3-5 вещей компания должна сделать в этом году? Согласны ли с этим лидеры основных функций? Можете ли вы показать связь от текущей работы команды до этих приоритетов?

Structure. Какие группы существуют? Кто кому подчиняется? Сколько слоёв между junior-сотрудником и CEO? Какие решения требуют C-level одобрения, хотя могли бы приниматься на уровне линейного менеджера?

Processes. Какие 5-7 главных потоков ценности (lead-to-revenue, feature-delivery, incident-response, customer-onboarding, hiring, и т.д.)? Сколько функций каждый поток пересекает? Где стоят очереди и сколько они стоят в днях ожидания? На каждом ли handoff есть SLA и ответственное лицо?

Rewards. Какие метрики у каждой функции? Какие из них напрямую конфликтуют с метриками соседних функций? Есть ли общая метрика на уровне потока (lead-to-revenue conversion, NRR, time-to-resolution), и кто за неё отвечает? Какие стимулы привязаны к метрикам - бонусы, повышения, публичное признание?

People. Где сейчас дефицит ключевых компетенций? Как происходит рост - есть ли явная карьерная лестница, есть ли calibration? Какова текучка по уровням и функциям; уходят ли senior-сотрудники быстрее, чем приходят? Каков фактический срок онбординга нового человека до productivity?

Тип сложности: Cynefin как линза

Перед тем как чинить структуру, полезно понять, в каком режиме сложности она работает. Dave Snowden предложил в 1999 году в IBM Cynefin framework - пять доменов принятия решений: clear (правильный ответ известен, действовать по best practice), complicated (нужна экспертиза, действовать по good practice), complex (причина-следствие видна только постфактум, нужен probe-sense-respond), chaotic (нужно действовать сразу для стабилизации) и confusion (не понимаем, в каком домене находимся).

Структурное следствие: разные домены требуют разной структуры. Clear и complicated работа хорошо ложится на функциональную структуру с регламентами; complex - на маленькие автономные команды, которые могут экспериментировать; chaotic - на временный command-and-control. Попытка применить функциональную структуру к complex-работе (например, к продуктовому discovery) даёт паралич: регламенты не работают, потому что причинно-следственные связи проявляются только постфактум.

Cynefin не заменяет диагностику структуры, но помогает выбрать стиль управления. В одной компании разные потоки могут жить в разных доменах: клиентская поддержка типовых запросов - clear, инцидент-менеджмент - chaotic, продуктовое discovery - complex. Структура должна это учитывать, иначе единый стиль работы будет одним функциям мешать, а другим - недодавать поддержки.

Сигналы, что структура не справляется

Каждый сигнал указывает на конкретный элемент Star Model - это помогает не путать симптом с диагнозом.

Один сигнал на один элемент Star Model - локальная проблема, чинится точечно. Два-три сигнала на разные элементы - системный disalignment, нужна согласованная программа изменений по нескольким элементам сразу. Сигналы по всем пяти элементам одновременно - сигнал кризиса, требующий стратегической переоценки.

Рамка действий: от диагноза к согласованным изменениям

Структурные изменения - это не одно событие, а процесс. Полезная рамка - та же, что для инженерной стратегии: диагноз, принципы, согласованные действия (см. Инженерную стратегию).

Диагноз. Явное описание проблемы. Не «нам нужна реорганизация», а «поток lead-to-revenue занимает 180 дней, конверсия MQL-to-SQL 15%, причина - Sales и Marketing работают на разные метрики, качество лидов не обсуждается, SLA нет». Диагноз должен быть проверяемым: если мы решим эту проблему, мы увидим снижение lead time до 90 дней и рост конверсии до 25%.

Принципы. Что мы делаем и чего не делаем. Не «мы хотим сильную культуру», а «мы объединяем Sales Ops, Marketing Ops и CS Ops в единый RevOps под одним руководителем; все три функции продолжают существовать, но работают на единых данных; основная метрика квартала - pipeline-to-revenue conversion, не MQL». Принципы - это компромиссы, которые вы готовы делать публично.

Согласованные действия. Конкретные шаги: изменения в orgchart, изменения в метриках, изменения в ритуалах, изменения в инструментах. Даты, ответственные, checkpoints. Не «внедряем RevOps», а «до 15 апреля - nomination главы RevOps; до 1 мая - объединение Sales Ops и Marketing Ops в один отдел; до 1 июня - единая data model в CRM; до 1 июля - первый отчёт по единой воронке».

Правила изменения структуры

Связь с универсальными инструментами:

Ни один из этих инструментов не заменяет другой; они решают разные задачи. Выбор зависит от диагноза.

Источники и смежные статьи

Первоисточники (универсальные, не про IT)

Для IT

Modern кейсы и блоги

Смежные статьи блога