Чаще всего, когда в компании начинаются проблемы с управляемостью, первая реакция, обычно, улучшить процессы:

• добавить прозрачности

• ввести новые правила

• усилить контроль

И на короткой дистанции это действительно работает, но затем происходит парадокс: чем больше компания «улучшает» процессы, тем хуже становится управление:

• решения начинают приниматься дольше

• появляются лишние роли

• команды теряют скорость

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

Что такое операционная модель

Перед тем как раскрыть проблему, важно определить термин. Когда я говорю «операционная модель», я не имею в виду Scrum, Kanban или набор процессов. Операционная модель — это более фундаментальный уровень. Это ответ на вопросы:

• как принимаются решения

• кто реально обладает властью

• как формируются приоритеты

• как распределяется ответственность

• как действия команд связаны с бизнес-результатом

Процессы являются всего лишь инструментом внутри этой модели и если они не соответствуют модели, то они не работают.

Какие операционные модели встречаются на практике

Если упростить, чаще всего я вижу несколько типов: Founder-driven, Functional, Product / Value-stream, Governance-driven, Portfolio.Однако важно отметить, что ни одна из этих моделей не является “правильной”.

Выбор операционной модели, это всегда выбор компромиссов.

Если упростить:

• Founder-driven даёт скорость, но ломает масштаб

• Process-driven даёт контроль, но замедляет

• Portfolio даёт связь с деньгами, но требует зрелости

Вопрос не «что лучше», а «что сейчас нужно бизнесу». Если попробовать упростить, все операционные модели можно разложить так:

Как этим пользоваться на практике:

• определите, какая модель у вас реально доминирует

• не пытайтесь сразу «исправить процессы»

• сначала выровняйте execution под модель

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

• конфликты

• замедление

• потеря управляемости

Где ломается «правильное управление»

Один из самых показательных кейсов у меня был уже на уровне операционного управления.
Компания готовилась к продаже и под это начали выстраивать «правильную» модель:

• прозрачность

• процессы

• приоритизация

• управляемость

Всё выглядело логично, но сделка не состоялась и дальше произошло то, что на первый взгляд выглядело как хаос:

• фаундеры вернулись к прямому управлению

• управленческий слой начал «схлопываться»

• процессы начали игнорироваться

Первая реакция, конечно, усилить операционку. Сделать больше контроля. Добавить ещё прозрачности. Структурировать. И это была ошибка.

Настоящая проблема: конфликт моделей

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

• процессной (под инвесторов)

• founder-driven (под текущую реальность)

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

мы пытаемся исправить процессы, не понимая, в какой модели они вообще должны работать

Когда процессы начинают мешать

В founder-driven модели процессы начинают восприниматься как:

• замедление

• бюрократия

• ограничение контроля

И что делает операционная функция?
Начинает усиливать давление: ещё отчёты, ещё правила, ещё контроль.
И получает в ответ: игнор, раздражение, откат.

На практике это выглядело так:

• время принятия решений выросло в несколько раз

• количество пересогласований увеличилось

• предсказуемость релизов снизилась

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

Второй кейс: когда рост ломает систему

Но есть и противоположный сценарий.

В другом проекте (iGaming, проект демонстрировал быстрый рост x2-3 ежегодно) мы столкнулись с другой проблемой. Я прошёл путь от разработчика до CTO, и в какой-то момент всё управление фактически оказалось на мне:

• инженерия

• операционка

• продукт

Очевидным решением казалось масштабирование и мы ввели роль CPO. На бумаге всё выглядело правильно.

На практике:

• роли не были определены

• зоны ответственности пересекались

• решения принимались в обход

Дополнительно:

• появились роли без реального value

• нагрузка осталась на лидах команд

• начались конфликты

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

• увеличивалось количество ролей без понятного value

• возрастала нагрузка на тимлидов

• решения принимались медленнее

Это классический пример, когда рост команды не равен росту управляемости.

Главный инсайт про масштабирование

Этот кейс дал очень жёсткий, но полезный урок:

масштабирование — это не добавление людей, а формализация власти и ответственности

Если этого нет, то каждая новая роль не добавляет value, а создаёт конфликт. Это выглядит примерно так:

Что меняется в мышлении

После этих кейсов у меня сильно поменялся подход.

Раньше:

задача = внедрить правильную систему

Теперь:

задача = понять, какая система уже выбрана и только потом усилить или менять

Тогда в чём роль COO

Если упростить:

COO это не человек процессов.

Это человек, который:

• понимает текущую модель

• видит её ограничения

• выравнивает execution под неё

И только потом, если это действительно нужно бизнесу, меняет её.

Практический вывод

Если вы видите «хаос», то не начинайте с процессов.

Сначала ответьте:

• какая модель реально работает?

• совпадает ли она с целями бизнеса?

• есть ли спрос на изменения?

И только потом действуйте.

Как диагностировать операционную модель за 2 недели

Если вы заходите в новую компанию, первые 1-2 недели достаточно, чтобы понять модель.
Я обычно смотрю на три вещи:

1. Как принимаются решения
   централизованно (CEO)
   через роли (CPO / CTO)
   через процессы (приоритизация, SLA)

2. Где реально проходит приоритизация
   в системе (backlog, roadmap)
   или в чатах/встречах

3. Кто несёт ответственность за результат
   есть ли owner
   или ответственность «размазана»

Дополнительный быстрый тест:

Если завтра CEO уедет на 2 недели/месяца, система продолжит работать? Если нет, то перед вами founder-driven модель.

Заключение

Один из самых неожиданных инсайтов:

не существует универсально правильного управления

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

• не «какие процессы внедрить»

• а «в какой системе они вообще должны работать»

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

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

P.S. Я занимаюсь управлением инженерными и операционными системами на уровне CTO/COO и пишу про практику масштабирования и управления.