ИИ, проекты и неопределённость: что упускает бизнес

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

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

Парадокс эффективности ИИ

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

Отсюда и новая логика бизнеса. Зачем вообще держать столько подрядчиков, если часть работы можно сделать внутри компании? Нет смысла ждать очереди у IT‑команды, если продуктовый менеджер способен сам собрать первый прототип. Под вопросом оказывается и прежний объём часов внешних команд, который раньше закупался на рынке, если ИИ позволяет небольшой группе делать существенно больше. Для агентств и IT‑компаний вывод зеркальный: те же услуги придётся оказывать быстрее, меньшим составом — и уже на других условиях.

Что говорят исследования и эксперты

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

Если следовать этой логике, то выход из ситуации лежит в плоскости организационной зрелости

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

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

В чем на самом деле проблема

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

Экспертная модель вместо производственного цикла

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

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

Таким способом является экспертная модель, делающая ставку на накопление и обмен знаниями между участниками проекта

В каком виде это уже существует либо только появляется как новые форматы:

1. Продуктовые команды пришли к этой логике раньше других — просто потому, что готовой постановки у них никогда не было. Продукты делают не по ТЗ заказчика, а для рынка, и потому приходится снова и снова возвращаться к вопросу, какую проблему стоит решать и что проверять следующим шагом. Подход «continuous discovery» в этом смысле — не надстройка над разработкой, а ранняя форма экспертной модели. Решение собирается в постоянном взаимодействии замысла, ограничений и обратной связи от пользователей.
2. Совместные ИИ‑центры и Центры компетенций в больших организациях, таких как Сбер или Почта России, показывают ту же механику уже на корпоративном уровне. В зрелом варианте такой центр оказывается не техническим штабом, а способом связать в одном процессе видение бизнеса, технологические решения, ограничения и ответственность за выбор направлений развития.
3. Для отдельных проектов компании могут привлекать независимых продюсеров и проджект‑раннеров. В книге «Метод параноика» эта фигура уже была описана как ключевая для продюсерской модели. Сегодня её необходимость стала только заметнее: ИИ ускоряет исполнение, но не заменяет того, кто собирает участников и организует экспертную работу над новыми задачами бизнеса.
4. Экспертные фирмы делают ту же работу, что и независимые проджект‑раннеры, но уже в институциональной форме. Их главным активом становятся не часы и не штат, а накопленная экспертиза, которую можно переносить из проекта в проект. Например, ThoughtWorks, технологическая консалтинговая компания, известная тем, что один из её руководителей стоял ещё у истоков Agile‑манифеста, принципиально отделяет поиск продуктового решения от технической реализации.

Вывод