*Часть 1 из 5 серии [The Human Inversion](/posts/series/the-human-inversion). Далее: [Потолок внимания](/posts/the-human-inversion-the-attention-ceiling)*

---

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

- Раньше команды организовывались вокруг **выполнения** (спецификация → дизайн → код); **фундамент** и **обзор** раньше хронически недополучались, потому что календарь опускался в середину.
- Когда ИИ поглощает производство артефактов посередине, **люди концентрируются на концах** — более богатое позиционирование, системы и архитектура с одной стороны; более глубокие проверки качества и соответствия с другой стороны.
- Удаление человеческого посредника устраняет **неявный перевод**, который использовался для согласования дисциплин; Тогда **междисциплинарная согласованность** должна основываться на четких стандартах, устойчивых артефактах и ​​конечном суждении, а не на передаче в коридоре.
- Инверсия является **экономически вынужденной**, а не факультативной, но она напрягает специалистов, чей авторитет был привязан к исполнительскому мастерству, пока суждения снова не станут разборчивыми.
- **Агенты в цикле** (асинхронная работа агентов на стороне сервера) — это то, как выглядит поглощение середины на системном уровне; только синхронный ИИ удерживает людей посередине в качестве триггера для каждого шага выполнения.

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

Разбейте процесс на три части:

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

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

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

Это имело последствия с обеих сторон:

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

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

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

Затем ИИ изменил экономику.

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

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

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

## Люди теперь движутся до конца

Со стороны фундамента:

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

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

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

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

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

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

## Как ощущается переход изнутри

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

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

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

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

Столь же распространена и обратная путаница: тяга к навыкам, которые ИИ только что сделал доступными, а не к тем, которые он сделал дефицитными.

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

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

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

## Проблема, которой не было в старой организации

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

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

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

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

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

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

## Претензия

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

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

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

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

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

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

[Следующий пост](/posts/the-human-inversion-the-attention-ceiling) посвящен триггеру найма. Когда вы на самом деле добавляете человека в команду, выполнение которой контролируется ИИ? Ответ не в том, что предлагает современная мудрость стартапов, и ошибиться — самая дорогая ошибка на этом переходном этапе.

---

*Продолжить чтение: [Часть 2 — Потолок внимания](/posts/the-human-inversion-the-attention-ceiling)*