ИИ для постановки задач: как превратить идею в готовое техническое задание

ИИ для постановки задач: как превратить идею в готовое техническое задание

Большинство людей, которые впервые работают с ИИ для постановки задач разработчикам, совершают одну и ту же ошибку. Они пишут в чат что-то вроде "Помоги мне написать ТЗ для мобильного приложения" и ждут, что модель выдаст нечто полезное. Результат предсказуем: текст, который звучит правдоподобно, но не содержит ничего конкретного. Причина проста — ИИ не знает вашего бизнеса, ваших ограничений, вашей аудитории. Чтобы получить работающий результат, нужна система. Эта статья описывает, как её построить.

Почему ИИ эффективен в постановке задач

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

ИИ справляется с этой работой хорошо по трём причинам.

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

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

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

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

Где ИИ подведёт без контроля

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

Галлюцинации про ваш домен

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

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

Решение: используйте ИИ для структурирования информации, которую вы знаете, а не для заполнения пробелов в вашем знании.

Недостаточная детализация критериев приёмки

ИИ напишет критерий вроде "система должна быстро обрабатывать запросы". Разработчик прочитает это и не поймёт, быстро — это 100 миллисекунд или 10 секунд? ИИ часто избегает конкретных цифр, потому что их может быть много вариантов, и модель не уверена, какой выбрать.

Результат: разработчик реализует что-то, что технически соответствует ТЗ, но не соответствует вашим реальным ожиданиям.

Игнорирование контекста о приоритизации

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

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

Рабочий процесс: от размытого запроса до тест-плана

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

Как устроена система

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

Затем вы просите ИИ разбить задачу на подзадачи (декомпозировать) и дать грубую оценку. После этого — создать тест-кейсы. И только на финальном этапе — сгенерировать user stories или другой формат, который используют в вашей команде.

Каждый этап опирается на результаты предыдущего. Вы не просите ИИ "дать мне user stories" — вы просите "на основе вот этого ТЗ, которое мы уже проверили, сделай user stories". Контекст накапливается, качество растёт.

Контекст один раз — чтобы модель не выдумывала ваш домен

Первый критический момент — это момент, когда вы даёте ИИ фоновую информацию о вашем продукте и бизнесе.

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

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

Что должно быть в контексте:

• Кратко: что делает ваш продукт, кто его использует.
• Основные ограничения: технические, бизнес-ограничения, регуляторные требования.
• Текущая архитектура в двух предложениях: frontend на React, backend на Node.js, база данных PostgreSQL.
• Список существующих фич или модулей, о которых ИИ должен знать.
• Стиль общения с разработчиком: должен ли ТЗ быть формальным или более casual.

Вот примерный шаблон:

Мы разрабатываем CRM для малых агентств недвижимости. Пользователи — агенты и менеджеры. Приложение работает в браузере, backend на Python, frontend на Vue.js. В системе уже есть модули управления объектами, клиентами, сделками и документами. Главное ограничение — скорость загрузки данных, потому что агенты часто работают на медленном интернете. Все ТЗ должны содержать пункт про оптимизацию.

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

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

Промпт 1: размытый запрос в ТЗ с критериями приёмки

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

Пример размытого запроса:

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

Вот промпт, который вы напишете после этого:

Вот контекст про наш продукт: [вставьте контекст, который описали выше]

У нас есть следующая идея: [вставьте размытый запрос]

Помоги структурировать это в техническое задание. В ТЗ должны быть: — Описание проблемы, которую решает фича — Что конкретно пользователь сможет делать после реализации — Критерии приёмки (я их буду проверять, чтобы понять, правильно ли сделана задача) — Возможные граничные случаи и ограничения Пусть критерии приёмки будут конкретными, с цифрами где нужно. Если что-то не понятно или противоречит контексту продукта, указывай на это.

ИИ выдаст примерно следующее:

• Структурированное описание проблемы
• Список конкретных действий пользователя
• Критерии приёмки с конкретными сроками (например, "если последний контакт более 60 дней назад")
• Замечания, которые он выявил (например, что неясно, должна ли фича работать в реальном времени или достаточно раз в день пересчитываться)

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

Вы вернётесь к ИИ и скажете что-то вроде: "По второму критерию приёмки — раз в день пересчитывается достаточно, ночью в 2 часа. И да, фильтр нам нужен, не сортировка. И напоминания не отправляем пока вообще, это потом."

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

Почему это работает лучше, чем писать ТЗ самому

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

ИИ вынуждает вас сделать эти предположения явными. Это основной источник ценности на этом этапе.

Промпт 2: ревью готового ТЗ глазами скептичного техлида

После того как вы получили первую версию ТЗ и уточнили детали, нужно проверить, насколько оно устойчиво к критике. Лучший способ сделать это — попросить ИИ сыграть роль человека, который ищет проблемы.

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

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

Как построить промпт для критического ревью

Вот что вы пишете ИИ после того, как получили первую версию ТЗ:

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

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

Пример того, что может вернуть модель:

• В критерии приёмки написано, что фильтр должен работать мгновенно, но не указано, на каком объёме данных. Если клиентов 100 тысяч, мгновенно не получится без индекса в базе.
• Не указано, что происходит, если агент одновременно открыл список клиентов на телефоне и на компьютере, а потом применил фильтр только на одном устройстве. Синхронизируется ли состояние?
• В описании написано, что фильтр применяется к дате последнего контакта, но не уточнено, какой именно контакт считается — только сообщения или также звонки, встречи, email.
• Пересчёт раз в день в 2 ночи означает, что агент, который работает поздно вечером, может видеть устаревшую информацию. Это приемлемо?

Обратите внимание: это не придирки ради придирок. Это реальные вопросы, которые возникнут у разработчика во время реализации. Если вы не ответите на них в ТЗ, разработчик примет решение сам — и это решение может быть не таким, какое вы хотели.

Что делать с результатами ревью

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

Например, на первое замечание вы можете ответить: "Да, нужен индекс. Добавь в ТЗ пункт про создание индекса по полю last_contact_date". На второе замечание: "Синхронизация состояния фильтра не нужна, это локальная настройка. Укажи это явно в ТЗ". На третье: "Считаются только сообщения в CRM, email и звонки не учитываем. Уточни формулировку".

После этого вы просите ИИ обновить ТЗ с учётом всех ответов. Модель внесёт правки, и вы получите вторую версию документа — уже намного более детальную и проработанную.

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

Промпт 3: user stories по описанию схемы аналитика

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

ИИ умеет превращать готовое ТЗ в набор user stories. Это полезно, потому что разработчики часто лучше понимают задачу, когда она сформулирована через действия пользователя, а не через технические требования.

Промпт выглядит так:

На основе этого ТЗ создай набор user stories в формате: Как [роль], я хочу [действие], чтобы [цель]. Для каждой story добавь критерии приёмки в виде списка конкретных сценариев. Раздели на обязательные stories для первой версии и дополнительные, которые можно отложить.

ИИ выдаст примерно следующее:

Обязательные stories:

• Как агент, я хочу видеть список клиентов, с которыми не было контакта больше 60 дней, чтобы понять, кому нужно напомнить о себе. Критерии приёмки: список загружается за 2 секунды при базе до 10 тысяч клиентов; учитываются только сообщения в CRM; фильтр сохраняется при переключении между вкладками.
• Как агент, я хочу применить фильтр по давности последнего контакта через выпадающий список, чтобы быстро переключаться между разными периодами. Критерии приёмки: доступны варианты 30, 60, 90 дней; выбранный период сохраняется до следующего изменения; список обновляется без перезагрузки страницы.

Дополнительные stories:

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

Это удобно, потому что вы сразу видите, что можно сделать в первую очередь, а что отложить. Разработчики тоже видят приоритеты и могут спланировать работу.

Когда user stories избыточны

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

Если ваша команда не работает с user stories, пропустите этот промпт и переходите сразу к декомпозиции.

Промпт 4: декомпозиция и черновая оценка

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

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

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

Разбей эту задачу на подзадачи для разработчика. Для каждой подзадачи укажи: что нужно сделать, какие зависимости от других подзадач, примерная сложность в часах (оптимистичная, реалистичная, пессимистичная оценка). Учитывай, что у нас frontend на Vue.js, backend на Python, база PostgreSQL. Обрати внимание на то, что нужно сделать сначала, чтобы не блокировать другие задачи.

ИИ вернёт что-то вроде:

1. Добавить индекс в базу данных по полю last_contact_date. Зависимостей нет. Оценка: 0.5 / 1 / 2 часа.
2. Создать API endpoint для получения списка клиентов с фильтром по давности контакта. Зависит от пункта 1. Оценка: 2 / 4 / 6 часов.
3. Добавить UI для выпадающего списка фильтра во frontend. Зависимостей нет, можно делать параллельно с пунктом 2. Оценка: 1 / 2 / 3 часа.
4. Интегрировать frontend с новым endpoint. Зависит от пунктов 2 и 3. Оценка: 1 / 2 / 4 часа.
5. Добавить автоматический пересчёт списка раз в день через cron. Зависит от пункта 2. Оценка: 1 / 2 / 3 часа.
6. Написать тесты для endpoint и UI. Зависит от всех предыдущих пунктов. Оценка: 2 / 3 / 5 часов.

Итоговая оценка: от 7.5 до 23 часов в зависимости от того, как пойдёт реализация.

Почему три оценки, а не одна

Одна цифра создаёт иллюзию точности. Разработчик видит "4 часа" и думает, что задача займёт ровно 4 часа. Но на практике всегда есть неопределённость. Может оказаться, что база данных медленно строит индекс из-за большого объёма данных. Может оказаться, что интеграция с frontend требует рефакторинга существующего кода.

Три оценки показывают диапазон возможных исходов. Оптимистичная — если всё идёт гладко. Реалистичная — если возникают обычные проблемы, которые можно решить быстро. Пессимистичная — если всплывают неожиданные сложности.

Это даёт менеджеру возможность планировать с учётом рисков, а разработчику — не чувствовать себя виноватым, если задача заняла больше времени, чем одна цифра в оценке.

Что делать, если оценка ИИ не похожа на правду

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

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

Промпт 5: тест-план из критериев приёмки

Последний промпт в цепочке — генерация тест-плана. Это список конкретных сценариев, которые нужно проверить перед тем, как считать задачу выполненной.

Тест-план отличается от критериев приёмки тем, что он более детальный и описывает не только что проверять, но и как именно это делать.

Промпт выглядит так:

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

ИИ вернёт примерно следующее:

Тест 1: Применение фильтра на 60 дней

• Что проверяем: список клиентов фильтруется корректно.
• Шаги: открыть страницу клиентов, выбрать в выпадающем списке "60 дней", дождаться обновления списка.
• Ожидаемый результат: отображаются только клиенты, с которыми последний контакт был более 60 дней назад. Список загружается за 2 секунды или быстрее.
• Если провален: проверить SQL-запрос, убедиться, что индекс создан, проверить логику фильтрации на backend.

Тест 2: Граничный случай — ровно 60 дней

• Что проверяем: клиент с контактом ровно 60 дней назад попадает в список.
• Шаги: создать тестового клиента с датой последнего контакта ровно 60 дней назад, применить фильтр.
• Ожидаемый результат: клиент отображается в списке.
• Если провален: проверить условие фильтрации (должно быть >= 60, а не >).

Тест 3: Негативный сценарий — база данных недоступна

• Что проверяем: система корректно обрабатывает ошибку подключения к базе.
• Шаги: отключить базу данных, попытаться применить фильтр.
• Ожидаемый результат: пользователь видит сообщение об ошибке, приложение не падает.
• Если провален: добавить обработку исключений в код backend.

Тест-план помогает не пропустить очевидные проблемы. Он также полезен для QA-инженеров, если они есть в команде. Если QA нет, разработчик может использовать этот план как чек-лист перед тем, как отправить задачу на проверку.

Как это выглядит вживую: от запроса до проверенного ТЗ

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

Исходный запрос

Менеджер пишет в чат с ИИ: "Нам нужно сделать так, чтобы пользователи могли экспортировать отчёт по продажам за выбранный период. Сейчас они могут только смотреть на экране, а нужно, чтобы скачивали файл. Может быть Excel или PDF, не знаю что лучше. Важно, чтобы это работало быстро, потому что данных много."

Контекст, который даётся перед запросом

Мы разрабатываем SaaS-платформу для управления продажами в малом бизнесе. Пользователи — менеджеры по продажам и владельцы бизнеса. Frontend на React, backend на Django, база данных PostgreSQL. В системе уже есть модули для работы с клиентами, сделками, продуктами и отчётами. Главное ограничение — скорость генерации отчётов, потому что у некоторых клиентов десятки тысяч записей о продажах. Все новые функции должны работать без блокировки интерфейса.

Первый промпт — структурирование в ТЗ

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

Менеджер отвечает: "Формат Excel. Только таблица, без графиков. Ограничение — максимум 100 тысяч строк за один экспорт. Если больше, пусть выдаёт ошибку с предложением уменьшить период."

ИИ обновляет ТЗ с учётом ответов.

Второй промпт — критическое ревью

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

Менеджер уточняет: "Экспорт может делать любой пользователь. Даты в формате ДД.ММ.ГГГГ. Если экспорт занимает больше 5 секунд, показываем индикатор загрузки и делаем запрос асинхронным — пользователь получает файл по email. Если повторный запрос, отменяем предыдущий."

ИИ снова обновляет ТЗ.

Третий промпт — декомпозиция

ИИ разбивает задачу на подзадачи: создать endpoint для генерации Excel-файла, добавить UI-кнопку для экспорта, реализовать асинхронную обработку через Celery, настроить отправку файла на email, добавить проверку на ограничение по количеству строк, написать тесты.

Оценка: от 12 до 30 часов в зависимости от сложности интеграции с Celery.

Четвёртый промпт — тест-план

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

Всё готово. ТЗ можно передавать разработчику.

Промпт 2: ревью готового ТЗ глазами скептичного техлида

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

Промпт выглядит так:

Ты опытный техлид, который видел сотни проваленных задач из-за неточной постановки. Твоя задача — найти в этом ТЗ всё, что может привести к проблемам. Читай между строк. Ищи противоречия, неочевидные граничные случаи, зависимости от других модулей, проблемы производительности. Не будь вежливым — укажи на всё, что вызывает вопросы.

Дальше вставляете текст ТЗ, которое получили на первом этапе.

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

Примеры того, что находит ИИ на этом этапе

• Вы написали, что фильтр показывает клиентов, с которыми не было контакта более 60 дней. ИИ спросит: что считается контактом? Только сообщения в чате или телефонные звонки тоже? А если агент отправил письмо, но клиент не ответил — это контакт?
• Вы указали, что данные пересчитываются ночью в 2 часа. ИИ заметит: а если в вашей системе есть пользователи из других часовых поясов? Будет ли ночь у них в другое время?
• Вы сказали, что фильтр не должен замораживать приложение. ИИ укажет: вы не написали конкретное время ответа. 500 миллисекунд — это нормально? Или нужно быстрее?

Не все замечания будут актуальны. Часть из них можно отклонить, объяснив ИИ, почему это не проблема в вашем случае. Но сам факт того, что ИИ ставит эти вопросы, заставляет вас думать на шаг глубже.

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

Промпт 3: user stories по описанию схемы аналитика

User stories — это формат описания задачи с точки зрения пользователя. Классическая структура: как [тип пользователя], я хочу [действие], чтобы [результат]. Этот формат помогает разработчику понять, зачем вообще нужна фича, а не только что нужно сделать технически.

Если у вас уже есть готовое ТЗ с критериями приёмки, ИИ может превратить его в набор user stories. Промпт прямолинейный:

На основе этого ТЗ создай user stories в формате: Как [роль пользователя], я хочу [действие], чтобы [польза]. Разбей фичу на отдельные истории так, чтобы каждая была независимой и понятной разработчику. Добавь к каждой истории краткие критерии приёмки.

Дальше вставляете ТЗ.

ИИ выдаст примерно следующее:

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

К каждой истории ИИ добавит критерии приёмки, которые проверяют, что история реализована правильно. Это удобно для команды, которая работает по Scrum или другой методологии с user stories.

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

Промпт 4: декомпозиция и черновая оценка

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

Промпт для декомпозиции:

Разбей эту задачу на подзадачи для разработчика. Укажи, что нужно сделать на backend, что на frontend, какие данные нужно изменить в базе, какие API endpoints создать. Для каждой подзадачи дай грубую оценку времени в человеко-часах: от и до. Учти, что разработчик знаком с кодовой базой, но может потратить время на исследование деталей.

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

• Backend: создать поле last_contact_date в таблице clients — 1–2 часа.
• Backend: написать функцию расчёта давности контакта — 2–3 часа.
• Backend: добавить параметр фильтрации в API endpoint GET /clients — 3–4 часа.
• Frontend: добавить элемент фильтра в интерфейс списка клиентов — 4–6 часов.
• Frontend: подключить фильтр к запросу на backend — 2–3 часа.
• Тестирование: написать unit-тесты для функции расчёта — 2–3 часа.
• Тестирование: проверить работу фильтра на тестовых данных — 1–2 часа.

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

Зачем это нужно

Декомпозиция помогает увидеть объём работы. Часто задача кажется простой, пока вы не разложили её на части. ИИ может выявить скрытые зависимости. Например, окажется, что для реализации фильтра нужно сначала добавить индекс в базу данных, иначе запрос будет слишком медленным. Без декомпозиции вы бы узнали об этом уже в процессе разработки.

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

Промпт 5: тест-план из критериев приёмки

Последний этап — создание тест-плана. Тест-план нужен, чтобы проверить, что реализованная фича действительно работает так, как задумано. Тестировщик или разработчик будет использовать этот документ, чтобы воспроизвести сценарии и убедиться, что всё корректно.

Промпт для тест-плана:

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

Вставляете критерии приёмки из ТЗ.

ИИ выдаст список тест-кейсов. Примерно так:

• Тест 1: Проверка отображения клиентов без контакта более 60 дней.
  • Шаг 1: Открыть список клиентов.
  • Шаг 2: Выбрать фильтр "Без контакта более 60 дней".
  • Ожидаемый результат: отображаются только клиенты, у которых last_contact_date старше 60 дней от текущей даты.
• Тест 2: Проверка пустого результата фильтра.
  • Шаг 1: Открыть список клиентов.
  • Шаг 2: Выбрать фильтр "Без контакта более 60 дней".
  • Ожидаемый результат: если таких клиентов нет, отображается сообщение "Клиенты не найдены".
• Тест 3: Граничный случай — клиент с контактом ровно 60 дней назад.
  • Шаг 1: Открыть список клиентов.
  • Шаг 2: Выбрать фильтр "Без контакта более 60 дней".
  • Ожидаемый результат: клиент не отображается, потому что условие "более 60 дней", а не "60 дней или больше".

ИИ также добавит негативные сценарии. Например: что происходит, если у клиента вообще нет записи о последнем контакте? Должна ли система показывать его в фильтре или игнорировать?

Тест-план даёт конкретный чек-лист для проверки. Без него тестирование превращается в хаотичное нажимание на кнопки в надежде найти баг. С тест-планом процесс становится систематическим.

Как это выглядит вживую: от запроса до проверенного ТЗ

Теперь соберём весь процесс воедино на реальном примере. Представим, что вы руководите проектом интернет-магазина электроники. Вам поступил запрос от отдела продаж: нужно добавить возможность отложенной покупки — клиент может зарезервировать товар на несколько дней, пока он думает.

Шаг 1: Исходный запрос

Вы записываете то, что сказал отдел продаж:

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

Шаг 2: Контекст для ИИ

Вы даёте ИИ контекст о вашем магазине:

Мы интернет-магазин электроники. Основная аудитория — B2C, но есть небольшая доля корпоративных клиентов. Сайт на React, backend на Django, база PostgreSQL. У нас уже есть модули управления товарами, заказами, корзиной, оплатой. Главная проблема — точность остатков на складе. Если система показывает, что товар есть, а его уже продали, клиент недоволен. Скорость работы сайта критична, потому что трафик высокий.

Шаг 3: Первый промпт — структурирование

Вы пишете ИИ:

Помоги структурировать это в ТЗ с критериями приёмки. Учти, что точность остатков критична.

ИИ возвращает:

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

Что пользователь сможет делать:

• Клиент видит кнопку "Зарезервировать" на странице товара.
• После нажатия товар резервируется на 72 часа.
• Клиент получает уведомление с датой окончания резерва.
• Менеджер видит список зарезервированных товаров в админке.

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

• Зарезервированный товар не доступен для покупки другим клиентам в течение 72 часов.
• После истечения срока резерв автоматически снимается.
• Если клиент покупает зарезервированный товар, резерв снимается немедленно.
• Система корректно обрабатывает ситуацию, когда товара осталась одна единица, и два клиента пытаются зарезервировать одновременно.

Замечания ИИ:

• Неясно, может ли один клиент зарезервировать несколько единиц одного товара.
• Неясно, нужно ли уведомлять клиента перед окончанием резерва.
• Неясно, может ли клиент продлить резерв.

Шаг 4: Уточнение

Вы отвечаете:

Один клиент может зарезервировать только одну единицу товара. Уведомление за день до окончания резерва — да, нужно. Продление резерва — нет, пока не делаем.

ИИ обновляет ТЗ с учётом этих уточнений.

Шаг 5: Ревью техлида

Вы запускаете второй промпт — ревью от имени скептичного техлида. ИИ находит:

• Что происходит, если клиент зарезервировал товар, но его учётная запись была удалена до окончания срока резерва?
• Как система обрабатывает ситуацию, когда товар зарезервирован, но складской учёт показывает, что товара физически нет?
• Нужно ли логировать действия по резервированию для аудита?

Вы возвращаетесь к ТЗ и добавляете ответы на эти вопросы.

Шаг 6: Декомпозиция

Вы запускаете третий промпт — декомпозиция. ИИ выдаёт список подзадач:

• Backend: добавить таблицу reservations с полями product_id, user_id, reserved_until.
• Backend: изменить логику проверки доступности товара — учитывать резервы.
• Backend: создать фоновую задачу, которая каждый час снимает истёкшие резервы.
• Backend: добавить endpoint POST /reservations для создания резерва.
• Frontend: добавить кнопку "Зарезервировать" на страницу товара.
• Frontend: показывать уведомление об успешном резервировании.
• Админка: создать страницу со списком активных резервов.
• Уведомления: настроить отправку email за 24 часа до окончания резерва.

Оценка: 40–55 человеко-часов.

Шаг 7: Тест-план

Вы запускаете четвёртый промпт — тест-план. ИИ создаёт список из 15 тест-кейсов, покрывающих основные и граничные сценарии.

Итог

Весь процесс занял около часа вашего времени. Вы получили:

• Проверенное ТЗ с конкретными критериями приёмки.
• Список подзадач для разработчика.
• Тест-план для тестировщика.
• Ответы на вопросы, которые возникли бы только в процессе разработки.

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

Чек-лист готовности постановки

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

• Описание проблемы понятно без дополнительных объяснений.
• Критерии приёмки содержат конкретные цифры и условия, а не общие фразы.
• Указаны граничные случаи и обработка ошибок.
• Есть декомпозиция на подзадачи с примерными оценками.
• Тест-план покрывает основные и негативные сценарии.
• ТЗ прошло ревью от скептичного техлида (через ИИ или реального человека).
• Все зависимости от других модулей выявлены и описаны.
• Приоритеты понятны: что обязательно, что желательно, что можно отложить.

Этот чек-лист можно сохранить как шаблон и использовать для каждой новой задачи. Со временем вы запомните пункты и будете проверять автоматически.

Что отличает случайную удачу от стабильного результата

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

Единый формат контекста

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

Последовательность промптов

Не пытайтесь получить идеальное ТЗ за один запрос. Разбейте процесс на этапы: структурирование, ревью, декомпозиция, тест-план. Каждый этап опирается на предыдущий. Это снижает вероятность ошибок и повышает качество.

Критическое мышление

ИИ — это инструмент, а не оракул. Проверяйте каждое утверждение, которое он делает. Если ИИ говорит, что задача займёт 10 часов, спросите себя: это реалистично? Если ИИ предлагает решение, которое звучит слишком сложно, уточните: а можно проще?

Обратная связь

Когда задача реализована, сравните результат с ТЗ, которое вы создали через ИИ. Если что-то пошло не так, вернитесь к промптам и посмотрите, где была ошибка. Может быть, вы дали недостаточно контекста. Может быть, пропустили важный граничный случай. Каждый провал — это урок, который делает следующий промпт лучше.

Как ИИ помогает с другими управленческими задачами

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

Автоматизация отчётов и статусов

Каждую неделю нужно собрать статус по проекту: что сделано, что в работе, какие риски. Обычно это занимает час — вы листаете таск-трекер, спрашиваете команду, собираете информацию в документ.

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

ИИ вернёт структурированный текст. Вам останется только проверить факты и добавить комментарии, где нужно. Вместо часа — 15 минут.

Анализ конкурентов

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

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

Обработка входящих запросов клиентов

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

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

Часто задаваемые вопросы

Нужно ли каждый раз давать контекст заново?

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

Можно ли использовать ИИ для оценки сроков?

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

Что делать, если ИИ выдаёт противоречивые требования?

Укажите на противоречие напрямую. Например: "В третьем критерии ты написал X, а в пятом — Y. Это противоречит друг другу. Как правильно?" ИИ пересмотрит логику и предложит исправление. Если противоречие осталось, это сигнал, что в исходном запросе была неточность. Уточните требования и запустите промпт заново.

Нужно ли показывать ТЗ от ИИ разработчику до начала работы?

Обязательно. ТЗ от ИИ — это черновик, который нужно обсудить с человеком, который будет его реализовывать. Разработчик может указать на технические проблемы, которые ИИ не увидел. После обсуждения доработайте ТЗ и зафиксируйте финальную версию.

Можно ли использовать ИИ для постановки задач не только разработчикам?

Да. Та же система работает для дизайнеров, маркетологов, аналитиков. Меняется только формат задачи. Для дизайнера вместо критериев приёмки будут требования к макету. Для маркетолога — метрики успеха кампании. Логика остаётся той же: контекст, структурирование, ревью, декомпозиция.

Что делать, если ИИ не понимает специфику моей отрасли?

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

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