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

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

21 апреля 2026

Справочник

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

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

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

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

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

В системном подходе Деминга важно искать причины проблем в устройстве работы: правилах, стимулах и потоках информации. Если причина в них, замена сотрудников ее не устранит. Новый человек столкнется с теми же ограничениями.

Питер Сендж в «The Fifth Discipline» (1990) описывает learning organization: организацию, которая учится на своем опыте и пересматривает способы работы. Пять дисциплин: личное развитие, работа с мысленными моделями, общее видение, командное обучение и системное мышление. Последнее помогает рассматривать эти практики вместе и замечать последствия решений для всей организации.

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

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

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

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

Функции - вертикальная ось. Это подразделения, сгруппированные по специализации: продажи, маркетинг, продукт, разработка, поддержка клиентов, финансы, 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), которые сами могут замкнуться на собственных задачах.

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

Продуктовая / Stream-aligned. Команда отвечает за продукт или отдельный поток работы: в ней могут быть продукт-менеджер, инженеры, дизайнер и другие специалисты. Состав зависит от задач. Платформенная команда может предоставлять общие сервисы и снижать инфраструктурную нагрузку. Нужна ли отдельная платформа, зависит от масштаба, повторяющихся потребностей и стоимости ее поддержки.

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

Реальная компания обычно гибрид. Типичный вариант для B2B SaaS на 150-300 инженеров: функциональная иерархия (VP of Engineering, VP of Product, VP of Sales) + команды, отвечающие за отдельные потоки работы внутри инженерии + 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 на месяц, чтобы разом их защитить.

Решения:

Стоимость передачи работы

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

IT-специфика

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

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

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

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

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

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

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

Matrix hell

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

Признаки matrix hell:

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

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

Кросс-функциональная интеграция: как современные компании ломают 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.

Объединение операционных функций само по себе не устраняет silos. Важно договориться о модели данных, метриках и порядке совместной работы. Продажи, маркетинг и Customer Success могут оставаться отдельными функциями и при этом пользоваться общими данными.

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 означает изменение структуры команд для поддержки целевой архитектуры. При рефакторинге нужно определить владельцев модулей и порядок совместных изменений. Иногда достаточно уточнить ответственность существующих команд, иногда требуется изменить их границы или состав.

Как это проявляется в разработке:

DDD как словарь границ. Domain-Driven Design предложил инструментарий для определения bounded contexts - явных границ с собственными моделями и терминами. Здесь нас интересует стратегическая часть DDD: бизнес-области, границы моделей и связи между ними. Bounded contexts помогают обсуждать границы ответственности команд. Соответствие между контекстами и командами зависит от масштаба и устройства продукта.

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

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

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

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

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

Личные связи и масштаб организации

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

Что меняется с ростом компании

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

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

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

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

При диагностике стоит проверить, какие изменения произошли в самой работе: сократились ли задержки, понятна ли ответственность, стало ли проще принимать решения.

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

Star Model Джея Галбрейта рассматривает стратегию, структуру, процессы, вознаграждения и людей как связанные стороны организационного дизайна. Это способ организовать обсуждение; по одному симптому нельзя однозначно определить причину.

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

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

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

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

Strategy

Structure

Processes

Rewards

People

Выбор подхода к управлению: Cynefin

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

Cynefin помогает выбирать подход к решению задачи с учетом неопределенности. Из него не следует однозначная структура подразделений: в одной команде могут встречаться задачи с разными свойствами.

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

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

Следующие сигналы помогают выбрать, что проверить в Star Model. Это гипотезы для диагностики: один симптом может иметь несколько причин.

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

От диагностики к изменениям

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

Диагноз. Явное описание проблемы. Не «нам нужна реорганизация», а «поток 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, изменения в метриках, изменения в ритуалах, изменения в инструментах. Даты, ответственные, контрольные точки. Не «внедряем RevOps», а «до 15 апреля - назначение руководителя RevOps; до 1 мая - объединение Sales Ops и Marketing Ops в один отдел; до 1 июня - единая модель данных в CRM; до 1 июля - первый отчет по единой воронке».

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

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

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

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

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

Для IT

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

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