Чего 40 руководителей попросили у ИИ – и где они промахнулись

Вендоры рассказывают, что ИИ поменяет всё. Блогеры – что он бесполезен. Редко кто спрашивает у самих руководителей, какую задачу они хотят ускорить прямо завтра. У нас накопились 40 таких ответов. Половина сошлась в три предсказуемые группы, а самое полезное в этих данных – не они.

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

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

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

Три группы, в которые сошлась половина спроса

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

Чего 40 руководителей попросили у ИИ – и где они промахнулись

Самая крупная группа – постановка задач разработчикам и качество требований. Каждый четвёртый ответ был про это: улучшить качество требований в постановках от аналитиков, составить ТЗ, проверить описание задачи перед передачей в разработку, стандартизировать постановки, написать user stories по схемам аналитика, собрать тест-план по требованиям. Разные роли, одна боль – превратить размытую мысль в структуру, которую не стыдно отдать команде.

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

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

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

Почему именно эти задачи ложатся на сильные стороны ИИ

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

Постановка задач разработчикам – это работа с текстом в чистом виде. У менеджера или аналитика в голове есть понимание, что нужно, но оно не оформлено. Модель не придумывает требования за человека – она помогает их выгрузить, структурировать и проверить на полноту. Это та задача, где ИИ закрывает не творческую часть, а трудоёмкую: оформление, выравнивание формата, поиск пропущенных пунктов.

Отчётность устроена похоже. Исходные факты у менеджера уже есть – в переписке, в трекере, в заметках. Задача не в том, чтобы их добыть, а в том, чтобы собрать в читаемую форму под конкретного адресата. Это переупаковка, и модель в ней сильна.

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

Разрыв между «помогает с текстом про данные» и «считает сами данные» – одна из главных ловушек ожиданий. Человек видит, что ИИ бодро рассуждает про аналитику, и делает вывод, что ему можно доверить расчёт. Доверять можно рассуждению о методе, проверять нужно каждую цифру.

Выбросы, которые ценнее средних ответов

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

Один хотел список документов для оформления гражданства. Другой – научиться делать фильмы. Третий прислал свою дату рождения и просил её «проанализировать» (цифры опускаю). Четвёртый – засечь реальное время пробега на дистанции. Пятый – заносить товарно-материальные ценности в учётную систему.

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

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

Выбросы – это не глупость аудитории. Это отсутствующая ментальная модель. И ровно её даёт практика: пара неудачных заходов с понятным объяснением, почему не сработало, стоит десяти статей про «возможности ИИ». Любопытно, что исследования фиксируют похожее поведение в командах: люди скрывают, как пользуются ИИ, именно потому, что не уверены в своей карте его возможностей.

Простая диагностика на три корзины

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

Чего 40 руководителей попросили у ИИ – и где они промахнулись

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

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

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

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

Граница между первой и второй корзиной – это и есть навык, который отделяет случайную удачу от стабильного результата. Сформулировать задачу так, чтобы модель не додумывала, проверить ответ в правильном месте, понять, где доверять нельзя. Этот навык передаётся, но не появляется сам от факта установки приложения.

Готовый шаблон для самой частой задачи

Раз постановка задач разработчикам оказалась запросом номер один, имеет смысл дать под неё готовый промпт – конкретный инструмент, который вставляешь и адаптируешь.

Ниже – шаблон, который берёт размытую формулировку задачи и превращает её в структурированное ТЗ с критериями приёмки. Главное в нём – он не позволяет модели додумывать требования за вас. Если чего-то не хватает, шаблон заставляет ИИ задать вопрос, а не сочинить ответ. В промпт уже вставлен пример – размытая заявка про подсветку срочных тикетов, можно запустить как есть.


Ты – опытный системный аналитик. Я дам тебе черновую формулировку задачи для команды разработки – она может быть размытой и неполной. Преврати её в структурированную постановку строго по формату:

1. Цель – одно-два предложения: какую проблему пользователя или бизнеса решаем и зачем. Не «сделать кнопку», а «зачем эта кнопка нужна».

2. Контекст – где в продукте это находится, кого затрагивает, что есть сейчас.

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

4. Критерии приёмки – проверяемые условия в формате «когда [условие], то [результат]». По таким критериям тестировщик должен однозначно сказать, готова задача или нет.

5. Что НЕ входит в задачу – явно вынеси за рамки то, что легко спутать с этой задачей.

6. Открытые вопросы – перечисли всё, чего не хватает в моей формулировке для полноты постановки. Это самое важное: не угадывай недостающее, а спроси.


Если по моему тексту нельзя заполнить пункт, напиши «недостаточно данных» и вынеси вопрос в пункт 6. Не выдумывай требования, сроки и метрики.

Вот черновая формулировка:

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

Обратите внимание на пункт с открытыми вопросами. Большинство проблем с ТЗ не в том, что они плохо написаны, а в том, что в них есть дыры, которые автор не заметил. Модель, которой запрещено додумывать, эти дыры подсвечивает – и это часто полезнее самой структуры.

Когда первый проход даст результат, попробуйте короткий второй промпт – проверку готового ТЗ на полноту перед передачей в разработку. В роли скептичного техлида модель ищет дыры, а не латает их за вас:

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

– требования, которые можно понять двумя способами;

– критерии приёмки, которые нельзя однозначно проверить;

– пропущенные сценарии – ошибки, пустые состояния, граничные случаи;

– противоречия между пунктами.

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

Вот ТЗ:

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

Контекст: экран «Список заявок» в админке оператора. Сейчас все заявки выглядят одинаково.

Что нужно сделать:

1. Срочные заявки подсвечивать красным фоном.

2. Подсветка должна появляться быстро после поступления заявки.

3. Оператор может вручную пометить заявку как срочную.

4. Срочные заявки всегда показывать вверху списка.

Критерии приёмки:

– Когда заявка срочная, её строка выделена красным.

– Интерфейс работает удобно и быстро.

Не входит в задачу: настройка палитры цветов администратором.

Оба промпта можно запустить прямо в браузере на двух моделях (GPT-5.4 nano и DeepSeek V4 Flash) в интерактивной версии статьи на сайте – удобно сравнить, как разные модели справляются с одной заявкой.

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

Что стоит зафиксировать

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

Слабое место не в выборе задач, а в калибровке доверия. Те же люди, которые точно просят помочь с ТЗ, готовы поверить выдуманному списку документов или доверить модели расчёт, который она не вытянет. Разрыв проходит не между умными и наивными запросами, а внутри головы одного человека – между задачей из первой корзины и задачей из третьей, которые внешне выглядят одинаково уверенно.

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

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

Три самые частые группы из этой статьи – постановка задач, отчётность и ресёрч – мы разбираем на курсе по шагам, на реальных ситуациях, а не на абстрактных примерах. В открытом модуле для руководителей школы mysummit.school – 9 практических задач, где сразу видно, где ИИ надёжен, а где врёт: диагностика по трём корзинам, промпт для ТЗ с защитой от додумывания, проверка AI-ответов на фактах и расчётах. Первые уроки – бесплатно и без регистрации.

А если ваша рутина – именно проектная, те же запросы закрыты в специализации по управлению проектами: цикл «черновик в трекер перед публикацией», pre-mortem и аудит WBS на пропущенные задачи, PM-агент с batch-ресёрчем и разбором границ доступа.

Читайте также в нашем блоге: