*Часть 3 из 5 серии [The Human Inversion](/posts/series/the-human-inversion). Предыдущий: [Потолок внимания](/posts/the-human-inversion-the-attention-ceiling) · Следующий: [Примиритель и рубрика](/posts/the-human-inversion-the-conciler-and-the-rubric)*

---

## Ключевые выводы

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

[В предыдущем посте](/posts/the-human-inversion-the-attention-ceiling) утверждалось, что триггер найма изменился: команды должны оставаться небольшими до тех пор, пока узким местом не станет внимание основателей, а не требование исполнения. Этот пост о том, что происходит после срабатывания триггера — когда вам действительно нужно добавить специалистов, и возникает вопрос, как они будут работать вместе, не вводя повторно налог на координацию, который должна была устранить инверсия.

Два уточнения перед аргументом:

Во-первых, «специалист» здесь означает *глубокий*, а не *узкий* в смысле небольшого, хрупкого кусочка ответственности. Узкость — это то, насколько мало вы затрагиваете проблему; Глубоко то, насколько сильно вы осуждаете то, что у вас есть.

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

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

## Старая модель координации

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

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

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

Удалите середину, и вместе с ней пойдет обоснование.

## Новая проблема сцепления

Вот что на самом деле делают специалисты на концах:

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

Это фундаментальные артефакты. Они долговечны. Они управляют тысячами последующих решений. В старой модели ими пренебрегали, потому что исполнение съедало календарь. В новой модели они являются основной работой.

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

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

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

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

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

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

## ИИ как координационный субстрат

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

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

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

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

[Следующий пост](/posts/the-human-inversion-the-conciler-and-the-rubric) посвящен этому. Краткая версия: одного перевода недостаточно; вам также необходима целостность записи базовых артефактов, чтобы ошибки перевода можно было проверить постфактум, а сами артефакты можно было бы считать текущими, а не незаметно перемещать.

Вот почему сейчас возможна работа специалистов по асинхронному параллельному ведению, чего не было пять лет назад. Ограничением никогда не было то, что специалисты *не могли* работать параллельно; дело в том, что параллельная работа без перевода в реальном времени приводила к бессвязности в течение нескольких недель. ИИ как субстрат перевода устраняет это ограничение. Специалисты могут углубляться в свои знания, создавать основополагающие артефакты, используя свой родной словарный запас, и верить, что другие специалисты смогут действовать в соответствии с последствиями этих артефактов, не требуя встречи для их раскрытия.

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

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

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

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

## За пределами трио

Все выше написано так, как будто команда — это ПМ плюс дизайнер плюс инженер. Это классическое трио, и оно полезно для объяснения, но это также и упрощение. Настоящие организации, занимающиеся разработкой программного обеспечения, включают в себя отделы маркетинга, юриспруденции, обеспечения соответствия требованиям, эксплуатации, обеспечения успеха клиентов, проектирования продаж, обеспечения безопасности, обработки данных и поддержки. Эти функции исторически были связаны с продуктом через особую категорию встреч: встречи по согласованию. Обзор запуска. Юридическое подписание. Передача возможностей маркетинга. Проверка готовности ОП. Проверка безопасности перед отправкой.

Эти встречи существовали по той же причине, по которой существовали обзоры спецификаций — межфункциональный контекст не был разборчивым за пределами дисциплины, поэтому люди переводили в реальном времени — но у них была дополнительная патология. Дисциплины, не связанные с продуктом, не способствовали возникновению артефакта; они *закрывали* это. Маркетинг заставил продукт упаковать его для всего мира после того, как люди, занимающиеся продуктом, уже решили, что это такое. Юридическая служба получила одобрение на продукт после того, как проектировщики и инженеры уже определились с формой. Операционный отдел получил продукт, чтобы его можно было развернуть после того, как архитектура уже была выбрана. Эти дисциплины почти полностью существовали на фундаменте (сборники правил, политики, позиционирование) и проверке (готовность к запуску, соответствие требованиям, возможность развертывания), но они были изгнаны к воротам, а не интегрированы на концах. Их опасения касались последних десяти процентов временной шкалы, скорее, как блокаторы, а не как входные данные.

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

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

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

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

## Вопрос о встрече, прямо

Действительно ли инверсия приводит к резкому сокращению количества совещаний, или это всего лишь последняя версия обещания, которое индустрия давала и нарушала в течение многих лет?

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

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

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

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

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

## Диагностика

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

Вторичная диагностика выполняется на уровне просмотра. Сколько времени рецензент тратит на *проверку того, что ИИ утверждает, что он сделал*, а не на *повторное определение того, что ИИ должен был сделать*? Команды с подходящей инфраструктурой склоняются к первому варианту: короткая проверка структурированного заявления, при этом тяжелая работа остается за поверхностями, которые агент пометил как непроверенные. Команды, у которых его нет, застревают на втором: холодном чтении различий, потому что рассуждения агента не фиксируются нигде, что можно подвергнуть сомнению. Соотношение меняется медленно, но когда оно меняется, это сильный сигнал о том, что уровень целостности записи, который описывает [следующий пост](/posts/the-human-inversion-the-conciler-and-the-rubric), на самом деле существует, а не является желаемым.

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

[Следующий пост](/posts/the-human-inversion-the-conciler-and-the-rubric) посвящен нерешенной проблеме: когда специалисты работают асинхронно параллельно, что-то все равно должно улаживать противоречия между их независимой работой, прежде чем эти противоречия перерастут в несогласованность продукта.

---

*Продолжить чтение: [Часть 4 — Примиритель и рубрика](/posts/the-human-inversion-the-conciler-and-the-rubric)*