BizOpsDev321 — Атлас321

Полная интеллектуальная родословная, эмпирические основания и теоретическая архитектура — для практиков и скептиков.

Это Слой 3 документации BizOpsDev321. Для краткого обзора (что делать) см. Введение. Для управленческого введения (почему это работает) см. Обоснование (Слой 2). Настоящий документ содержит полное теоретическое и эмпирическое обоснование для тех, кому необходимо понять практику на глубинном уровне.

Часть I: Основополагающий вопрос

Что есть организация?

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

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

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

Два слоя правил

Каждая организация функционирует через два взаимосвязанных слоя:

1. Неписаные правила — культура, привычки и модели взаимодействия, живущие в КО организации: совокупность неявного знания, имплицитных норм и коллективных представлений.

2. Писаные правила — формализованные и зафиксированные в документах, процедурах и регламентах.

Лишь малая доля КО может быть когда-либо зафиксирована в документах или автоматизирована. Это не ограничение технологий — это фундаментальное свойство неявного знания, установленное моделью SECI Нонаки (Икуджиро Нонака — модель преобразования знания между неявной и явной формами) и работами Сноудена (Дэйв Сноуден — исследования разрыва между неявным и явным знанием) о разрыве между неявным и явным.

Уникальный язык каждой организации

Каждая организация говорит на своём уникальном языке (ubiquitous language, в терминологии Эванса (Эрик Эванс — Domain-Driven Design, предметно-ориентированное проектирование)) — набор понятий, значений и терминов, описывающих её работу, процессы и задачи.

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

Часть II: Домен сложности — почему традиционный менеджмент терпит неудачу

Фреймворк Cynefin как точка входа

Фреймворк Cynefin: Complex (задать направление), Ordered (задать цели), Chaotic (использовать ограничения) — Фреймворк Cynefin — © Dave Snowden

Фреймворк Cynefin, разработанный Дэйвом Сноуденом (фреймворк осмысления для различения сложно-технической (complicated) и сложно-адаптивной (complex) областей), даёт наиболее доступное объяснение того, почему традиционное управление ИТ стабильно терпит неудачу. В модели Cynefin всё цифровое — код, данные, информация и люди вокруг них — находится только в двух возможных доменах: сложно-техническом (complicated) или сложно-адаптивном (complex).

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

Но цифровая работа — не материя. В данном контексте — это антиматерия. Разработка и сопровождение ПО не аналогичны производственному конвейеру или строительной площадке. Ближайшая аналогия — научно-исследовательская лаборатория. Это различие неочевидно — даже для большинства ИТ-специалистов — и является коренной причиной большинства ИТ-провалов.

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

Cynefin как ступенька, а не конечная точка

Фреймворк Cynefin — это инструмент осмысления для индивидуального лица, принимающего решения. Он помогает одному человеку оценить, в каком домене он работает, и выбрать соответствующую стратегию реагирования. Это ценно, но ограниченно.

Функционирующая Команда321 действует на принципиально ином уровне. Это не индивид, помещающий проблему в правильный домен, — это коллективная когнитивная сущность (КО), которая обитает в сложности как социальный организм. Команда не просто «реагирует на» сложность — она навигирует в сложности через распределённое познание, общее неявное знание и эмерджентное коллективное поведение, которое ни один отдельный участник не способен воспроизвести в одиночку.

Это различие существенно:

Cynefin объясняет, почему процессная инженерия и проектное управление терпят неудачу в цифровой работе — это инструменты сложно-технического домена, применённые к проблеме домена сложности. Это верно и полезно для управленческой аудитории.
Но Cynefin не полностью схватывает то, что происходит внутри функционирующей Команды321. Динамика команды лучше описывается теориями коллективного разума (Вейк) (Карл Вейк — теория осмысления и коллективного разума в организациях), социальной сложности (Стейси) (Ральф Стейси — сложность и менеджмент, теория респонсивных процессов) и передачи неявного знания (Нонака) — все они оперируют на групповом, а не индивидуальном уровне.

Для вводных целей Cynefin остаётся лучшим объяснительным инструментом. Для более глубокого понимания необходима полная теоретическая архитектура, описанная в настоящем документе.

Измерение Деминга

Работы У. Эдвардса Деминга (W. Edwards Deming — основоположник философии управления качеством, автор 14 принципов менеджмента и Системы глубинного знания) обеспечивают ещё одну опору критики. Деминг напрямую оспорил предположение, которым руководствуется большинство корпоративного менеджмента:

«Если вы не можете это измерить, вы не можете этим управлять.»

Деминг называл это неверной теоремой:

«Самые важные потери и приобретения не поддаются измерению — и тем не менее ими необходимо управлять.»
— У. Э. Деминг, 11 июля 1990

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

Попытка «управлять только тем, что измеримо» приводит к лавине KPI, отчётности, формальных процедур, автоматизированных шаблонов и метрик. Организация перестаёт управлять тем, что действительно важно, и начинает управлять только тем, что помещается в таблицу или отчёт. Это фундаментальная причина бюрократизации, утраты живых практик и постепенного разрушения КО.

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

Риски избыточного регулирования и автоматизации

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

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

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

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

Часть III: Когнитивное Облако — центральное понятие

Когнитивное Облако, Кодовая База и Инструменты — три элемента Команды321 с весами 3-2-1 — Когнитивное Облако (3) > Кодовая База (2) > Инструменты (1)

Определение и природа

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

Глубокого взаимного знакомства между участниками команды — как они работают, думают и общаются.
Глубокого знания настраиваемой Кодовой Базы — не только самого кода, но его истории, особенностей, проектных решений и встроенной в него бизнес-логики.
Вытекающего из этого владения Инструментами (технологическим стеком) — которое естественно следует из понимания Кодовой Базы, построенной поверх них.

Метафора «Когнитивное Облако» намеренно противопоставлена термину «когнитивная нагрузка» (Cognitive Load), широко используемому в ИТ-индустрии (популяризирован книгой Team Topologies (Мэтью Скелтон и Мануэль Паис — командно-ориентированная архитектура доставки ПО), берёт начало в педагогической психологии с работ Джона Свеллера в 1980-х). Там, где когнитивная нагрузка описывает индивидуальное напряжение и рост «информационного давления» на специалиста, КО подчёркивает коллективную, распределённую и поддерживающую природу организационного знания.

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

Иерархия приоритетов 3-2-1

Относительная важность для организации:

3 — Когнитивное Облако (команда и её коллективное знание)
2 — Кодовая База (программы, автотесты, пользовательские данные, документация)
1 — Инструменты (технологический стек)

Это означает, что наличие Команды321, контролирующей Кодовую Базу, в 5 раз важнее выбора технологического стека.

Веса не претендуют на научную точность. Это визуальный инструмент коммуникации с менеджментом — призванный мгновенно передать иерархию приоритетов и напрямую противостоять исторической тенденции менеджмента оценивать значимость в обратном порядке: фиксация на инструментах («платформы», «готовые решения», «системы промышленного класса»), при этом уникальная Кодовая База и уникальная команда воспринимаются как источники рисков и расходов. Когнитивное Облако как понятие, как правило, вообще отсутствует в лексиконе топ-менеджмента.

Что происходит без Когнитивного Облака

Без команды, несущей КО, Кодовая База становится непрозрачной. А непрозрачная Кодовая База — это по определению legacy (унаследованная система) — независимо от того, насколько современен технологический стек под ней. Всё превращается в кирпичи legacy.

Вот почему фиксация менеджмента на замене инструментов («давайте мигрируем на новую платформу») стабильно не решает основную проблему. Замена инструментов без сохранения или восстановления КО просто создаёт новую груду legacy-кода на другом технологическом стеке.

Можно ли увидеть Когнитивное Облако?

Да — в частности, его ИТ-проекцию.

Закон Конвея (Мелвин Конвей, 1967: архитектура системы отражает коммуникационную структуру организации, которая её создала) прямо утверждает: архитектура ИТ-системы отражает коммуникационную структуру организации.

Архитектура, структура интеграций, размещение модулей, границы доменов и потоки данных — всё это визуализированная проекция КО. Со временем эта ИТ-проекция начинает напоминать «Большую Глину №4» (a.k.a. Big Ball of Mud, Residues) — объект, сформированный внутренними и внешними воздействиями и их комбинациями, в полном соответствии с Теорией Остаточности (Residuality Theory) Барри О'Рейли (Barry O'Reilly — системы выживают благодаря остаточным структурам, а не изначально задуманной архитектуре).

Когнитивное Облако vs. когнитивная нагрузка — намеренное переосмысление

Понятие когнитивной нагрузки давно в обращении (берёт начало в педагогической психологии с работ Джона Свеллера в 1980-х). Team Topologies активно продвигали его применение в контексте проектирования команд: команды должны быть сформированы так, чтобы их когнитивная нагрузка оставалась управляемой. Это верно и ценно.

BizOpsDev321 вводит Когнитивное Облако как дополняющее позитивное понятие. Тогда как когнитивная нагрузка спрашивает «сколько эта команда может нести?», КО спрашивает «что эта команда коллективно знает, и покрывает ли её знание ту Кодовую Базу, за которую она отвечает?»

Визуализация на стр. 6 оригинального вводного документа делает это сразу наглядным: круг КО должен полностью содержать и круг Кодовой Базы, и круг Инструментов. Когда это не так — когда КО меньше Кодовой Базы — непокрытые области являются, по определению, непрозрачным legacy. Кольцо ПКП-автотестов (обсуждается в Части VI) — это механизм восстановления покрытия.

Самые опасные интервенции

Самые опасные интервенции — те, что приходят под видом помощи. Назначение выделенного проектного менеджера, перевод ключевого специалиста на другой проект, отделение тестирования от разработки, введение отдельной роли QA — каждое из этих действий выглядит рациональным и заботливым. Каждое разрушает КО. Словарь «снижения когнитивной нагрузки» и «повышения эффективности» нередко оказывается языком уничтожения команды.

Часть IV: Ключевой сдвиг — Зона ответственности → Команда

Контраст парадигм

Если свести всю практику BizOpsDev321 к единственному контрасту, он будет таким:

Традиционный менеджмент: Есть задача → есть ответственный и срок. На операционном уровне — конвейерное ИТ: процессы как стержень, люди как функции на станциях.

BizOpsDev321: Есть зона ответственности → есть Команда321. На операционном уровне — автономная команда владеет полным циклом.

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

BizOpsDev321 назначает постоянную зону ответственности постоянной Команде321. Команда не собирается под проект и не расформировывается — она живёт со своей зоной ответственности годами и десятилетиями. Она владеет КО, Кодовой Базой и Инструментами. Она решает, что делать, в каком порядке и как.

Всё остальное в BizOpsDev321 — три модификации, структура 321, кольцо автотестов, модель масштабирования — вытекает из этого основополагающего сдвига.

Три модификации — одна команда

Модификация №1 (Biz-): Ключевые бизнес-специалисты и пользователи становятся постоянной частью ИТ-команды. Без посредников. На равных. Внутри процесса.

Это устраняет разрыв между «тем, что нужно бизнесу» и «тем, что ИТ поставляет» — самый устойчивый и дорогостоящий режим отказа в корпоративном ИТ. Принципиально важно, что этот разрыв невозможно закрыть ИТ-шным Product Owner'ом или бизнес-партнёром (ИТ-специалистом, встроенным на стороне бизнеса). Это роли посредников — переводчиков между двумя мирами, не принадлежащих полностью ни одному. Ключевые специалисты (КС) в Команде321 — это реальные пользователи и доменные эксперты на операционном уровне — люди, которые выполняют фактическую работу, сталкиваются с реальными проблемами и понимают бизнес-логику изнутри. Стык бизнес–ИТ — самая проблемная точка сопряжения в корпоративном ИТ, и BizOpsDev закрывает его, помещая подлинную операционную экспертизу непосредственно внутрь команды.

Модификация №2 (-OpsDev-): Сопровождение и разработка объединены в одной команде, одни лица. Кто строит — тот и эксплуатирует.

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

Вся Команда321 и вся практика BizOpsDev321 (включая app321) может быть усилена ИИ-инструментами. Это отражено в следующей версии практики, называемой BizOpsVibe.

Модификация №3 (-321): Часть команды, отвечающая за эксплуатацию и разработку, распределена между 2–3 независимыми организациями через долгосрочные отношения Команда-как-сервис. Это механизм выживания — подробно обсуждается в Части V.

Размер команды: 7±2

Рекомендуемый размер команды — 7±2 человек. Это не произвольно — это обосновано:

Числа Данбара — исследования когнитивных пределов устойчивых социальных связей, устанавливающие естественные пороги для группового взаимодействия.
Team Topologies (команды, ориентированные на поток) — признанная интерпретация этих когнитивных ограничений, применённая к командам доставки ПО.
Agile-практика — широко принятое правило 7±2 для размера команды, производное от тех же фундаментальных исследований.

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

Часть V: Структура 321 — механизм выживания

Проблема, которую она решает

BizOpsDev-команды, замкнутые внутри одной организации, как правило, не выживают дольше ~5 лет. Озвучиваемые причины различаются:

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

Независимо от озвучиваемых причин, диагноз один: BizOpsDev внутри одной организации долго не живёт.

Решение: распределение между организациями

Обязательное разделение команды между 2–3 независимыми организациями — это наиболее характерный и контринтуитивный элемент BizOpsDev321. Он выглядит как структурное ограничение, наложенное на самоорганизующуюся команду. В реальности это — механизм выживания самоорганизации.

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

Это перекликается с Четвёртым принципом Деминга (У. Эдвардс Деминг: прекратите практику присуждения контрактов только на основе цены — стройте долгосрочные отношения, основанные на доверии) из его 14 Принципов менеджмента: минимизируйте совокупные затраты, работая с одним поставщиком в долгосрочных отношениях лояльности и доверия.

Мембранный эффект (Орг-мембрана)

Организационная граница между участвующими организациями функционирует как селективная мембрана (орг-мембрана):

Достаточно прозрачная, чтобы Команда321 работала как единое целое — общий контекст, общие цели, общее КО.
Достаточно защитная, чтобы оградить от двух критических угроз:
- Одностороннее уничтожение: внутренняя культура любой отдельной участвующей организации может «мгновенно» разрушить только свою часть команды, но не всю. Команда321 в целом выживает.
- Внутренняя коррупция: орг-мембрана пропускает только публично декларированные цели и задачи. Распределённую команду труднее кооптировать внутренней политикой, потому что тонкая граница между организациями действует как естественный фильтр.

Следовательно, фрагментации КО не происходит. Коллективные знания, навыки и межличностные отношения команды остаются едиными через организационные границы. Это подтверждается 35+ годами практического опыта с долгосрочными клиентами, где распределённые Команды321 функционировали как единые когнитивные единицы, пересекающие организационные линии.

Метафора легирования (Орг-легирование)

На практике часть Команды321 от подрядчика, встроенная в клиентскую организацию, начинает функционировать как легирующий элемент (орг-легирование), превращающий железо в сталь. Она становится центром притяжения — «инородным» включением, которое сам бизнес начинает защищать, потому что осознаёт структурную прочность, которую оно обеспечивает. Это не теоретическое предсказание — это наблюдаемый паттерн в долгосрочных BizOpsDev-партнёрствах.

Принцип снежинки

Нет двух одинаковых организаций — как нет двух одинаковых снежинок. Распределённая команда (особенно «BizOpsDev для трёх») наследует сильные стороны и многообразие нескольких организационных культур. У разных организаций разные режимы отказа, что означает — у распределённой команды есть естественная устойчивость, недостижимая для команды, замкнутой в одной организации.

Это напрямую связано с формулой отказоустойчивости (2N+1): команда, состоящая только из внутренних сотрудников, — это организационная единая точка отказа. Управленческий сбой внутри организации — и всё рушится. Распределение 321 обеспечивает архитектурную отказоустойчивость: ни одна точка не может парализовать работу или допустить снижение качества и эффективности. Работоспособность сохраняется даже при фатальных сбоях на любой из сторон.

Поддержание незаметных границ

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

Доказательства и честные оговорки

«BizOpsDev для двух» эмпирически подтверждён 35+ годами практики с долгосрочными клиентами (Омскводоканал с конца 1980-х, Банк Открытие, Банк Уралсиб). Самая долгоживущая Команда321 функционирует 40+ лет; несколько других — 30+ лет.

«BizOpsDev для трёх» остаётся рабочей гипотезой — подкреплённой элементами практики, но пока не полностью подтверждённой в масштабе. Рабочая гипотеза автора состоит в том, что, начиная с уровня «для трёх», модель становится не только более эффективной и значимой, но и более устойчивой и самовоспроизводящейся. Это рубеж, на котором активно ищутся внешние партнёрства и сотрудничество.

Лёгкая постоянная бизнес-системная консультация (LPBS)

На управленческом уровне стартовый шаг — настоятельно рекомендуемый Демингом — это переход к распределённому принятию решений через внешнего, малого, но независимого консультанта или команду, выполняющую роль Второго Мнения.

Это управленческая версия распределённого формата 321: тихая внешняя точка отсчёта, которая уменьшает слепые зоны, повышает качество решений и даёт организации возможность видеть то, что невозможно увидеть изнутри.

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

Часть VI: Технические практики — на службе Когнитивного Облака

Все конкретные технические практики, упоминаемые в документации BizOpsDev321, являются средствами для единственной цели: формирования и поддержания КО Команды321. Они не являются целями сами по себе.

Браунфилд — это норма

Для практически всех средних и крупных организаций ситуация гринфилда (разработка «с нуля» на чистом поле) осталась в прошлом. Существующие КО команд, как правило, не покрывают существующую Кодовую Базу. Это нормальная стартовая точка.

Кольцо ПКП-автотестов

В ситуации браунфилда КО любой новой или реформированной Команды321 изначально не покрывает существующую Кодовую Базу. Команда наследует системы, которые она не полностью понимает, — что является нормальным состоянием дел для большинства ИТ-организаций.

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

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

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

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

Цикл настраиваемой Кодовой Базы

Любая система — независимо от того, как она начиналась (готовое решение, заказная разработка или гринфилд) — в конечном итоге становится настраиваемой кодовой базой, которую медленно и дорого менять. Это универсальная траектория:

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

Выживаемость таких систем определяется Теорией Остаточности (Residuality Theory, Барри О'Рейли): системы выживают не благодаря задуманной архитектуре, а благодаря остаточным структурам, сохраняющимся через последовательные волны изменений.

Инструменты: низший приоритет ≠ необязательны

Иерархия 3-2-1 помещает инструменты на последнее место по важности, но это не означает, что они не нужны. КО нуждается в Кодовой Базе для работы, а Кодовая База — в Инструментах для исполнения. Все три элемента необходимы — иерархия определяет приоритеты при принятии решений, а не наличие или отсутствие компонентов.

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

Поскольку подход BizOpsDev не является доминирующим в индустрии, мейнстримных инструментов, спроектированных для его обслуживания, не существует. Существующие корпоративные платформы (крупные ERP, CRM, BPMS) построены для мышления «сложно-технического домена» — процессная инженерия, потоки создания ценности, конвейерный подход. Они архитектурно враждебны к самоорганизующемуся подходу домена сложности, который требует BizOpsDev.

Это создаёт практическое обязательство: недостаточно критиковать — нужно также предлагать. app321 и Kafka не предписываются как «правильные инструменты» в абсолютном смысле. Они предлагаются как примеры того, как выглядят инструменты, спроектированные для обслуживания Команды321, а не для её ограничения.

app321 и компактная Кодовая База — аналогия со стволовыми клетками

app321 реализует третий путь (разработка с нуля), предоставляя минимальный универсальный бизнес-шаблон — компактную кодовую базу, содержащую базовую функциональность систем CRM, BPMS и ERP (контрагенты, управление задачами, документооборот, каталог продуктов, сделки с прогнозированием денежных потоков и отслеживанием маржинальности).

Лучшая аналогия — стволовые клетки. Изначально app321 «слишком» прост — он недифференцирован, универсален, почти лишён специфики. Но, как у стволовой клетки, эта простота — его сила. Он прост в смысле Закона Галла321 (Джон Галл, 1975: работающая сложная система всегда развивалась из работающей простой системы — никогда не проектируется с нуля): работающая простая система, способная эволюционировать. Со временем, благодаря работе команды, app321 дифференцируется и становится конкретно нужным, специализированным модулем для конкретной Команды321 и её бизнес-домена. Как стволовая клетка становится нейроном или мышечной клеткой в зависимости от среды, app321 становится конкретной системой, нужной бизнесу, — сформированной КО команды, которая его взращивает.

Принципиально важно, что дифференцированный результат должен сам оставаться простым — в идеале не более ~100 тыс. строк кода (см. замечание об ориентировочных границах в разделе о Законе Галла321). Стволовая клетка не вырастает в кита; она вырастает в одну хорошо определённую клетку, выполняющую конкретную функцию. Аналогично, настроенный модуль app321 не должен накапливать безграничную сложность. Он должен оставаться достаточно малым, чтобы КО его Команды321 полностью его покрывало. Если бизнес-домен требует больше функциональности, ответ — не больший модуль, а больше модулей, каждый из которых прост, каждый принадлежит Команде321, чьё КО покрывает его полностью. Так legacy предотвращается навсегда, а не просто откладывается.

Ключевое преимущество: кодовая база остаётся достаточно малой, чтобы КО полностью её покрывало. Именно это предотвращает деградацию системы в непрозрачное legacy.

У компактной кодовой базы есть и дополнительное современное преимущество: она значительно лучше подходит для эффективного взаимодействия с ИИ-инструментами. Большие, непрозрачные кодовые базы сопротивляются ИИ-ассистированной разработке; малые, хорошо понимаемые — приветствуют её.

Миграция через асинхронную интеграцию

Когда Кодовую Базу необходимо мигрировать на новый технологический стек, BizOpsDev321 рекомендует начинать с минимальной кодовой базы (такой как app321 или эквивалентное решение с открытым кодом) и асинхронной интеграции (Kafka) для временного объединения с существующей кодовой базой на период перехода.

Это обходит жёсткое ограничение Закона Галла для сложных ИТ-систем. BizOpsDev321 формулирует собственную операционную версию:

Закон Галла321: Работающая сложная система (команда + кодовая база) всегда развивалась из работающей простой системы — через цепочку работающих состояний, каждое из которых не превышает 4 человеко-лет разработки или 6 месяцев работы команды (эмпирическая граница между простой и сложной системой/улучшением). Сложная система, созданная с нуля, или сложное улучшение — никогда не будут работать. Придётся начать с работающей простой системы или простого улучшения уже работающей системы.

Оригинальный Закон Галла гласит, что работающая сложная система развилась из работающей простой системы. Версия 321 добавляет три критических расширения:

Эмпирическая граница (4 человеко-года / 6 месяцев) — практический порог между простым и сложным.
Система включает команду — система — это не просто код, а код + люди, несущие его КО.
Триада код–данные–люди. Закон Галла321 определяет простоту как состояние, при котором код, данные и КО команды остаются в зоне взаимной когнитивной досягаемости — когда каждый участник Команды321 способен рассуждать о всей системе, включая её данные.
Простота как постоянный режим, а не начальное условие. В традиционной модели вы начинаете просто и неизбежно усложняетесь — система накапливает код, КО не успевает, и вы получаете legacy. Неявное допущение в том, что сложность — это пункт назначения. BizOpsDev321 отвергает это. Не только app321 должен начинать простым (менее ~100 тыс. строк кода), но каждый настроенный модуль для каждого конечного заказчика должен оставаться простым — постоянно в пределах границы Закона Галла321, постоянно покрытым КО своей Команды321. Legacy никогда не образуется, потому что потолок сложности никогда не пробивается.

Примечание: числовые границы здесь (4 человеко-года, 6 месяцев, ~100 тыс. строк) — это ориентировочные маркеры, полученные из практического опыта, а не результаты формального статистического анализа. Они служат для передачи порядка величины и направления мышления, в соответствии с позицией Деминга, что самые важные вещи не поддаются точному измерению — и тем не менее ими необходимо управлять.

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

Часть VII: Масштабирование — научная гипотеза

Модель клеточного деления (Орг-деление)

По мере роста нагрузки каждая Команда321 удваивается в размере, затем разделяется на две независимые команды (орг-деление). Критерии разделения нагрузки и функциональности определяются локально, в соответствии с контекстом роста ИТ-нагрузки. Удвоение Команд321 возможно каждые шесть месяцев.

Метафора биологическая: живой многоклеточный организм, растущий через митоз, при котором клеточное деление сохраняет ДНК. В аналогии BizOpsDev КО — это ДНК, которая должна быть сохранена при каждом разделении.

Честная оговорка

Модель масштабирования никогда не была проверена на практике. Несмотря на десятилетия работы с долгосрочными клиентами, команды BizOpsDev оказывались настолько эффективными, что одна команда всегда справлялась с нагрузкой. Потребность в разделении ни разу не возникала.

Это, пожалуй, сильнейшее косвенное подтверждение центрального утверждения практики: Команда321, работающая на принципиально ином уровне эффективности, просто не упирается в стену масштабирования, с которой традиционные подходы сталкиваются регулярно. Это перекликается с 10-м принципом Agile Manifesto: «Простота — искусство максимизации объёма невыполненной работы — существенна.» Команда321, в силу своего КО и единого владения, естественным образом максимизирует объём невыполненной работы — устраняя нерелевантные задачи, избегая ненужных координационных накладных расходов и разрешая проблемы прежде, чем они перерастают в проекты.

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

Для крупных существующих ИТ-подразделений

Для организаций с крупными существующими ИТ-подразделениями (сотни или тысячи сотрудников): на старте создаётся отдельная Команда321 для каждого значимого центра доходов и затрат, работающая в режиме «единого окна». Дальнейшая трансформация Команд321 и других команд в рамках более широкой ИТ-организации происходит по ходу работы. (Примеры других типов команд см. в книге Team Topologies.)

Для слишком малых организаций

Для организаций, слишком малых, чтобы включать 2–3 разработчиков: используйте услуги подходящей команды от ИТ-подрядчика в режиме Команда-как-сервис, начиная с подписки на одного универсального виртуального специалиста.

Часть VIII: Психологический барьер

Реальное препятствие

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

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

Вы уже это видели

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

А затем, как правило, в течение 3��5 лет, организация «дозревает» её до смерти: формализует роли, отделяет Ops от Dev, вводит проектное управление, привносит «правильные» инструменты, масштабирует команду в отдел. КО фрагментируется. Живое становится процессом.

Вполне возможно, что каждая технологическая компания начинала как BizOpsDev-команда. Более того, до перехода через «Пропасть» (в терминологии Джеффри Мура из книги Crossing the Chasm — модель жизненного цикла принятия технологий) эти компании фактически работали в режиме «BizOpsDev для двух» — сплочённая команда основателей, работающая с первыми клиентами в отношениях, функционально неотличимых от Команды-как-сервис. Именно переход через Пропасть — выход на массовый рынок — как правило, запускает организационное «дозревание», которое разрушает изначальную BizOpsDev-динамику: формализация, департаментализация, процессная инженерия и фрагментация КО.

BizOpsDev321 не просит менеджмент создать что-то чужеродное. Он просит прекратить уничтожать то, что возникает естественно, — и защитить это структурой 321, чтобы оно пережило собственный иммунный ответ организации.

Часть IX: Доказательства и методология

Правильный вид доказательств

Критика о том, что BizOpsDev321 не имеет «надлежащих» доказательств, предполагает, что доказательства — это количественные кейсы с KPI, расчётами ROI и метриками «до/после». Но сам Деминг — одна из интеллектуальных опор этой практики — напрямую оспорил это предположение.

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

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

Лабораторная работа, а не статистические исследования

Практику автора — охватывающую 35+ лет работы с конкретными долгосрочными клиентами — лучше всего понимать как лабораторную работу: глубокое, длительное погружение в ограниченное число случаев, дающее детальное понимание, а не статистическую широту.

Практика не претендует на валидацию через масштабные контролируемые исследования. Она претендует на валидацию через десятилетия повторного применения в реальных организационных контекстах, с реальными командами, при реальных ограничениях. Самая долгоживущая Команда321 функционирует 40+ лет; несколько других — 30+ лет. Это не анекдоты — это длительные эксперименты с наблюдаемыми, устойчивыми результатами.

Личная исследовательская траектория

Траектория автора сама является частью доказательств: начало в физической научно-исследовательской лаборатории (сверхпроводящие СКВИД-сенсоры, рецензируемая публикация в Physica B, 1991), переход к созданию банковских ИТ-систем с нуля в 1992 году, изучение финансовой инженерии в Университете Лидса в 1994 году и три десятилетия в консультационных ролях на уровне правления в банках и коммунальных предприятиях. Сквозной исследовательский вопрос на протяжении всего пути: «Что есть организация?»

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

Теория без практики мертва; практика без теории слепа

Практика явно исповедует эту двойственность. 35+ лет лабораторной работы обеспечивают эмпирическое обоснование. Интеллектуальная родословная обеспечивает теоретический каркас. Ни одно из них по отдельности не было бы достаточным:

Одна теория (Cynefin, Деминг, наука о сложности) объясняет, почему традиционные подходы терпят неудачу, но не говорит, что строить взамен.
Одна практика (35+ лет клиентской работы) говорит, что работает, но не объясняет, почему это работает и как это обобщить.

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

Часть X: Интеллектуальная родословная

Инновация через комбинацию, а не изобретение

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

Каждый элемент интеллектуальной родословной усиливает остальные:

Cynefin объясняет, почему традиционный менеджмент терпит неудачу с цифровым.
Данбар объясняет, какого размера должна быть команда.
Деминг объясняет, почему организационное разделение работает и почему управление по числам деструктивно.
Теория Остаточности объясняет, как legacy-системы выживают и эволюционируют.
Закон Конвея объясняет, как организационная структура проявляется в архитектуре систем.
Закон Галла объясняет, почему невозможно заменить работающую сложную систему спроектированной.
Нонака объясняет, как неявное знание передаётся внутри команд и между ними.
Вейк объясняет, что такое коллективный разум и как он работает.
Team Topologies объясняет, как проектировать команды с учётом когнитивных ограничений.
35+ лет практики подтверждают, что именно эта конкретная комбинация даёт устойчивые результаты там, где отдельные подходы этого не обеспечивают.

Дисциплинарные источники

Наука о сложности:

Джон Холланд (John Holland) — сложные адаптивные системы, эмерджентность, адаптация
Стюарт Кауффман (Stuart Kauffman) — самоорганизация, ландшафты приспособленности
Мелани Митчелл (Melanie Mitchell) — синтез теории сложности
Ральф Стейси (Ralph Stacey) — сложность и менеджмент, респонсивные процессы
Илья Пригожин (Ilya Prigogin) — диссипативные структуры, неравновесные системы

Управление знаниями:

Икуджиро Нонака (Ikujiro Nonaka) — модель SECI, преобразование неявного и явного знания, знание-создающие организации
Хиротака Такеути (Hirotaka Takeuchi) — соавтор фреймворка создания знания
Дэйв Сноуден (Dave Snowden) — фреймворк Cynefin, слои ограничений, нарративное управление знаниями

Организационная теория:

Карл Вейк (Karl Weick) — коллективный разум, осмысление, организационное конструирование
Крис Арджирис и Дональд Шён (Chris Argyris & Donald Schön) — организационное обучение, одинарная/двойная петля обучения
Никлас Луман (Niklas Luhmann) — теория социальных систем, аутопоэзис в организациях
Эрик Трист и Фред Эмери (Eric Trist & Fred Emery) — проектирование социотехнических систем

Управление качеством:

У. Эдвардс Деминг (W. Edwards Deming) — 14 Принципов менеджмента, критика управления по числам, Система глубинного знания

Архитектура программного обеспечения:

Мелвин Конвей (Melvin Conway) — Закон Конвея (архитектура системы отражает коммуникационную структуру организации)
Эрик Эванс (Eric Evans) — Domain-Driven Design, уникальный язык, ограниченные контексты
Барри О'Рейли (Barry O'Reilly) — Теория Остаточности (системы выживают благодаря остаточным структурам, а не задуманному дизайну)
Мартин Фаулер (Martin Fowler) — рефакторинг, доменный язык

Проектирование команд:

Мэтью Скелтон и Мануэль Паис (Matthew Skelton & Manuel Pais) — Team Topologies, команды, ориентированные на поток, когнитивная нагрузка как ограничение проектирования, принцип «команда прежде всего»

Системное мышление:

Джон Галл (John Gall) — Закон Галла (работающая сложная система развилась из работающей простой)
Элинор Остром (Elinor Ostrom) — институциональные правила, управление общими ресурсами
Брайан Артур (Brian Arthur) — зависимость от пути, возрастающая отдача

Замечание о языке и терминологии

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

Ричард Фейнман выразил ту же мысль: «Если вы не можете объяснить это студенту первого курса, вы сами недостаточно хорошо это понимаете.»

Карл Вейк писал, что «сложные явления раскрываются только через интерпретацию.»

Илья Пригожин подчёркивал, что язык сложных систем «не может быть зафиксирован; он должен создавать новые формы выражения для самих процессов.»

Дэйв Сноуден неоднократно отмечал, что в работе со сложностью «описание всегда частично, контекстуально и требует собственного нарратива.»

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

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

Приложение 1: Таблица соответствий — термины Практики321 → научные понятия

A. Основные термины практики → научные понятия и авторы

Термин Практики321	Научные понятия	Источники
Когнитивное Облако	неявное знание, коллективный разум, эмерджентные ментальные модели	Нонака (SECI), Вейк, Сноуден, Стейси
Неписаные правила	неформальные нормы, неписаные правила	Сноуден (ограничения), Стейси, Арджирис и Шён
Писаные правила	явное знание, институциональные правила	Нонака, Остром, Луман
Технологический слой	встроенные ограничения, социотехнические артефакты	Трист и Эмери, Луман
Уникальный язык	общий доменный язык (ubiquitous language)	Эрик Эванс (DDD), Фаулер, Вейк
ИТ-проекция Когнитивного Облака	структурное сопряжение	Конвей, Луман
Теория Остаточности	остаточные ограничения, зависимость от пути	О'Рейли, Брайан Артур, Стейси
«Большая Глина №4» (метафора)	архитектурная седиментация, Big Ball of Mud	паттерн аккреции legacy
Иерархия 3-2-1	теория когнитивной нагрузки, принцип «команда прежде всего»	Team Topologies, Данбар
Зона ответственности → Команда321	команда, ориентированная на поток, постоянное владение	Team Topologies, социотехническое проектирование
Кольцо ПКП-автотестов	страховочная сеть для эмерджентного понимания	хаос-инженерия, непрерывное тестирование
Орг-мембрана	селективная проницаемость, граничные объекты	организационная теория, Четвёртый принцип Деминга
Орг-легирование	структурное укрепление через разнообразие	аналогия из материаловедения
Орг-деление (масштабирование)	биологический митоз, сохранение ДНК	наука о сложности, самоорганизация
Закон Галла321	эмпирическая граница сложности системы (4 человеко-года / 6 месяцев), триада код–данные–люди	Галл, расширено практикой
Аналогия со стволовыми клетками (app321)	недифференцированная → специализированная через среду	аналогия из биологии развития
До-Пропасть = BizOpsDev для двух	стартап-команды основателей, работающие как Команда-как-сервис с первыми клиентами	Джеффри Мур (Crossing the Chasm)

B. Понятия науки о сложности → где используются в BizOpsDev321

Понятие	Применение в BizOpsDev321	Источники
Сложная адаптивная система	Организация как адаптивная социальная система	Холланд, Кауффман, Митчелл, Стейси
Эмерджентность	Когнитивное Облако, неписаные правила	Стейси, Вейк, Сноуден
Нелинейность	Разные значения терминов внутри разных организаций	Стейси, Кауффман
Разрыв неявное → явное	«Лишь малая доля может быть формализована»	Нонака, Сноуден
Слои ограничений	Неписаные → писаные → автоматизированные	Сноуден, Холланд
Зависимость от пути	Теория Остаточности, ИТ-legacy	Артур, О'Рейли
Социотехническое сопряжение	ИТ-проекция Когнитивного Облака	Трист и Эмери, Луман, Конвей
Самоорганизация	Команды321 как автономные единицы в домене сложности	Стейси, Кауффман, Сноуден
Аутопоэзис	Самовоспроизводящиеся команды (гипотеза «321 для трёх»)	Луман, Матурана и Варела

Приложение 2: Рекомендуемая литература

Основное (начните здесь)

Team Topologies — Мэтью Скелтон и Мануэль Паис. Наиболее доступная точка входа для понимания команд, ориентированных на поток, когнитивной нагрузки и командно-ориентированного проектирования.
Out of the Crisis — У. Эдвардс Деминг. Основополагающий текст о том, почему управление по числам терпит неудачу и что делать вместо этого.
The Cynefin Framework — Дэйв Сноуден (доступно в виде статей и видео на cognitive-edge.com). Фреймворк осмысления, объясняющий, почему цифровая работа принадлежит домену сложности.
Crossing the Chasm — Джеффри Мур. Жизненный цикл принятия технологий; проясняет, почему BizOpsDev-динамика естественно существует до Пропасти и разрушается после неё.

Наука о сложности и организационная теория

Strategic Management and Organisational Dynamics — Ральф Стейси. Наиболее обстоятельное рассмотрение сложности в применении к менеджменту.
The Knowledge-Creating Company — Икуджиро Нонака и Хиротака Такеути. Модель SECI и разрыв между неявным и явным.
Sensemaking in Organizations — Карл Вейк. Коллективный разум, конструирование и то, как организации осмысляют свой мир.
Social Systems — Никлас Луман. Теория систем в применении к социальным организациям (плотный, но фундаментальный труд).

Архитектура программного обеспечения и системы

Domain-Driven Design — Эрик Эванс. Уникальный язык, ограниченные контексты и доменное моделирование.
Residues — Барри О'Рейли. Теория Остаточности — как системы выживают не благодаря задуманному дизайну, а благодаря остаточным структурам.
Systemantics / The Systems Bible — Джон Галл. Закон Галла и поведение сложных систем (на удивление читабельная книга).

Работы автора

Вводный документ BizOpsDev321 (PDF) — оригинальное 8-страничное русскоязычное введение (версия 11.10.2025), доступно на bush10.org и hardsoft321.org.
bush10.org — весь этот сайт, в т.ч. Что есть Организация?, Словарь321, Блог.
«Бизнес на app321» — блог-пост, описывающий жизненный цикл настраиваемой кодовой базы и роль app321.
«Бизнес на app321 — демонстрация» — видео-обзор (5:37) работающего экземпляра: CRM, задачи, BPMS, ERP в одной кодовой базе.
Публикация в Physica B (1991) — физическая научная деятельность автора (сверхпроводящие СКВИД-сенсоры).

BizOpsDev321: команды, которые нельзя «оптимизировать». С 1990 года.

Этот документ — часть трёхслойной системы документации BizOpsDev321:
Слой 1 — Введение (что делать)
Слой 2 — Обоснование (почему это работает)
Слой 3 — Атлас321 (настоящий документ — полная интеллектуальная родословная)

Дата: Февраль 2026