Чаще всего, когда в компании начинаются проблемы с управляемостью, первая реакция, обычно, улучшить процессы:
добавить прозрачности
ввести новые правила
усилить контроль
И на короткой дистанции это действительно работает, но затем происходит парадокс: чем больше компания "улучшает" процессы, тем хуже становится управление:
решения начинают приниматься дольше
появляются лишние роли
команды теряют скорость
И в какой-то момент становится очевидно, что проблема не в процессах. На практике это почти всегда означает конфликт операционной модели и пока он не осознан, любые попытки "улучшить процессы" только усугубляют ситуацию.
Что такое операционная модель
Перед тем как раскрыть проблему, важно определить термин. Когда я говорю "операционная модель", я не имею в виду 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 недели достаточно, чтобы понять модель.
Я обычно смотрю на три вещи:
Как принимаются решения
централизованно (CEO)
через роли (CPO / CTO)
через процессы (приоритизация, SLA)Где реально проходит приоритизация
в системе (backlog, roadmap)
или в чатах/встречахКто несёт ответственность за результат
есть ли owner
или ответственность "размазана"
Дополнительный быстрый тест:
Если завтра CEO уедет на 2 недели/месяца, система продолжит работать? Если нет, то перед вами founder-driven модель.
Заключение
Один из самых неожиданных инсайтов:
не существует универсально правильного управления
То, что работает в одной компании, может разрушить другую. Проблема редко в процессах,
чаще в несовпадении модели и ожиданий. И это главный сдвиг в мышлении:
не "какие процессы внедрить"
а "в какой системе они вообще должны работать"
Если вы сейчас чувствуете, что процессы начали мешать, то скорее всего, дело не в них.
Напишите в комментариях, какая модель у вас сейчас доминирует.
Интересно разобрать реальные кейсы.
P.S. Я занимаюсь управлением инженерными и операционными системами на уровне CTO/COO и пишу про практику масштабирования и управления.
