Контекст — всему голова: переосмысление domain ownership, роли продакта и «фазы спецификации»
Если вы когда-нибудь писали подробные PRD или тщательно прорабатывали тикеты для команды, то наверняка замечали парадокс: тщательная спецификация задачи — это часто 90% работы, необходимой для её решения. К тому моменту, как вы собрали контекст, продумали граничные случаи, учли пользовательские сценарии и описали ожидаемое поведение достаточно детально для передачи исполнителю, самая сложная умственная работа уже сделана. Перевод этой спецификации в код становится всё более простой частью процесса.
Эта динамика незаметно меняет то, как создаётся софт, как взаимодействуют команды и что вообще значит быть конкурентоспособным разработчиком сегодня.
Смерть модели «разработчик-винтик»
Раньше разработка софта часто работала по конвейерной модели: продакт-менеджер пишет детальную спецификацию, передаёт её техлиду, тот разбивает на подзадачи и раздаёт разработчикам. Работа разработчика заключалась в том, чтобы быть «винтиком»: взять тикет, написать код по спеке, передать в QA.
Эта модель никогда не была идеальной — она плодила разрозненность, отбивала интерес и создавала раздутые циклы коммуникации. Но технически она работала.
Сегодня такой подход не просто неэффективен — он неконкурентоспособен. Когда трение между идеей и реализацией падает, накладные расходы традиционной передачи становятся главным узким местом. Игра в «испорченный телефон» между постановкой задачи и доставкой кода замедляет команды до полной остановки, пока более быстрые, насыщенные контекстом команды обходят их на круг.
Трение «фазы спецификации»
Если написание полной спеки занимает 90% когнитивных усилий, то постоянная передача между «тем, кто думает над задачей» и «тем, кто её реализует» создаёт колоссальное сопротивление.
Именно поэтому domain ownership стал базовым требованием. Когда разработчики по-настоящему владеют доменом — глубоко понимают проблемное пространство, пользователя, архитектуру системы и бизнес-цели — они обходят неловкую, высокозатратную «фазу спецификации». Им не нужен десятистраничный PRD для создания следующей фичи, потому что контекст уже находится у них в голове. Они могут плавно переходить от одной задачи к другой, принимая компромиссные решения и продуктовые решения в реальном времени, не дожидаясь, пока спек будет «испечён».
Переопределение границ между разработчиком и PM
Этот сдвиг не означает исчезновения продакт-менеджеров, но границы ролей становятся гораздо более подвижными:
- Разработчик как PM. Во многих областях разработчик и есть продакт-менеджер. Владея доменным контекстом, он сам определяет, что строить дальше, специфицирует это в уме по ходу работы и поставляет результат.
- PM как строитель. В других сценариях PM может использовать low-code инструменты, скрипты или AI-модели, чтобы довести фичу до 90% готовности — построить работающий прототип, спроектировать потоки данных или заложить начальную структуру. Разработчик затем подключается, чтобы закрыть оставшиеся 10%.
Почему эти последние 10% так критичны? Потому что даже простые фичи требуют глубокого технического анализа: соответствие архитектуре, производительность под нагрузкой, hardening граничных случаев, безопасность и долгосрочная сопровождаемость.
Движущаяся планка «конкурентоспособного софта»
Заманчиво смотреть на текущие тренды и предполагать, что по мере совершенствования моделей и инструментов эти последние 10% просто исчезнут — что софт в итоге будет строиться и поддерживаться сам по нажатию кнопки.
Такой взгляд упускает, как работают рынки программного обеспечения.
Когда генерация сырого кода становится дешевле и быстрее, базовая планка «конкурентоспособного софта» непрерывно поднимается. Фичи, которые раньше требовали трёх месяцев, теперь делаются за три дня — а значит, ожидания клиентов растут соответственно. Линия, отделяющая выделяющийся продукт, смещается к более высокому уровню полировки, более глубоким интеграциям, tighter performance и лучшему пользовательскому опыту.
Последние 10% не исчезают — они просто становятся более нюансированными.
Итог: контекст задачи и стандарты качества
Мы уходим от эпохи, где ценность измеряется объёмом синтаксиса или способностью выполнять жёсткие, заранее упакованные спецификации.
Реальный рычаг в современной программной инженерии сводится к двум вещам:
- Управление контекстом задачи. Способность интернализировать потребности пользователя, бизнес-цели и архитектуру системы, чтобы принимать высокоуровневые решения на лету, не дожидаясь спеки.
- Порог качества. Способность посмотреть на решение, готовое на 90% — созданное AI, коллегой или PM — и точно знать, что ему нужно для пересечения финишной черты: production-ready, масштабируемость и отказоустойчивость.
Инструменты продолжат эволюционировать, а механика написания кода будет меняться. Но инженеры, которые культивируют глубокий доменный контекст и поддерживают бескомпромиссные стандарты качества, не просто останутся конкурентоспособными — они будут задавать темп.