*Часть 2 из 5 серии [The Human Inversion](/posts/series/the-human-inversion). Предыдущий: [Инверсия](/posts/the-human-inversion) · Следующий: [Специалисты по Async Parallel](/posts/the-human-inversion-async-parallel-specialists)*

---

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

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

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

Консультации по найму стартапов долгое время действовали в двух направлениях. Основатели Canonical обычно призывают к медленному найму сотрудников: книга Сэма Альтмана [YC Startup Playbook](https://playbook.samaltman.com/) открывает раздел о найме словами «мой первый совет при найме — не делайте этого», и большинство партнеров YC уже десять лет высказывают одно и то же. В то же время материалы по оперативному масштабированию — колоды инвесторов, консультанты по масштабированию, эссе «Как масштабировать ваш стартап» — дают противоположный совет: [нанимайте на опережение](https://growth.eladgil.com/book/chapter-4-building-the-executive-team/hiring-executives/), сформируйте команду для того, куда вы собираетесь, потому что найм персонала занимает месяцы, а недоукомплектование кадрами происходит быстрее, чем переукомплектование штатами. Большинство основателей усваивают некоторое сочетание этих двух позиций, причем сочетание варьируется в зависимости от опыта и того, что они недавно читали.

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

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

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

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

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

## При изменении триггера

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

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

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

Основание и обзор выигрывают от интеграции контекста в одной главе, а не от разделения на несколько глав.

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

> **Бюджет внимания нынешней команды исчерпан на человеческий вклад в ИИ и анализ его результатов.**

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

1. Создавать фундаментальные артефакты с достаточной тщательностью, чтобы ИИ мог эффективно с ними справиться.
2. Анализ результатов ИИ с достаточной плотностью, чтобы качество не ухудшалось.
3. Принятие стратегических решений, определяющих, что будет строиться дальше.

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

## Как выглядит потолок

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

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

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

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

## Возражения

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

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

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

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

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

## Что это означает на практике

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

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

## Ловушка поверхностного расширения

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

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

Риск состоит в том, что организации увидят расширенную личность и придут к выводу, что дисциплины слились, а затем перестанут развивать глубину ни в одной из них. Я писал об [одной версии этого в мире PM](/posts/the-argument-cagan-already-won), где самый влиятельный голос в этой дисциплине определил роль прототипирования правильно, поскольку прототипирование стало товарным видом деятельности. Сложные затраты возникают, когда достигается потолок внимания, и команде нужны специалисты, чье суждение никогда не культивировалось, потому что эта роль никогда не рассматривалась как отдельная вещь.

В [Части 4](/posts/the-human-inversion-the-conciler-and-the-rubric) есть что сказать об инфраструктуре, которая делает это переопределение прочным для организации; В [Части 5](/posts/the-human-inversion-how-the-architecture-bends) есть что сказать о поверхностях, где переопределение происходит медленнее. Ни один из постов не делает индивидуальный опыт безболезненным. Оба предполагают, что командам приходится ориентироваться в реальном опыте, а не в мимолетном настроении.

[Следующий пост](/posts/the-human-inversion-async-parallel-specialists) посвящен тому, как на самом деле выглядят команды за пределами потолка внимания — когда приходят специалисты, и возникает вопрос, как им работать вместе, не внося повторно затраты на координацию, которые инверсия должна была устранить.

---

*Продолжить чтение: [Часть 3 — Специалисты по асинхронному параллелизму](/posts/the-human-inversion-async-parallel-specialists)*