Я ненавижу писать требования. Честно. Я люблю проектировать, придумывать решения, смотреть метрики, но сидеть и расписывать "Пользователь нажимает кнопку А, открывается модалка Б" для меня это духота.
Но реальность такова: я работаю в условиях ограниченных ресурсов. У меня нет штата бизнес-аналитиков. Если я не разберусь, как составить ТЗ для разраба грамотно — разработчик сделает как понял и мы не попадем в сроки потому что будем переделывать.
Обычно на описание одной средней фичи у меня уходило 1.5 часа. Сейчас — 20-30 минут. И качество выросло.
В этой статье покажу на реальном примере, как написать промпт для нейросети (я использую Claude, но подойдет и ChatGPT), чтобы она сделала всю грязную работу за вас. Разберем главные ошибки и почему просто скопировать user story пример из интернета не сработает.
Главная ошибка: "Напиши мне требования"
Большинство пробует LLM один раз и бросает. Почему? Потому что они вводят запрос в стиле:
"Напиши требования для функции выбора бизнес-центра в приложении"
В ответ получают полотно воды: цели бизнеса, "как пользователь я хочу..." и прочую чушь. Это абстрактная тема, она красивая и ее много. Часто дубли а иногда и полный булщит. Разработчик это читать не будет. Я бы сам не стал.
Как это исправить?
Мой процесс: От галлюцинаций к структуре
Разберем на живом кейсе.
Задача: В CRM системе (PRYSM) нужно добавить возможность привязывать новости и баннеры к конкретным бизнес-центрам. Раньше был один БЦ, теперь их много.
Шаг 1. Загрузка контекста проекта, дизайна и промпта для требований
Я не пишу контекст руками. Это долго. Я использую заготовленный заранее файл с описанием контекста проекта. Дальше я как-будто другу рассказываю суть задачи и что о ней знаю, как я вижу образ результата. Тут на поомщь приходит голосовой ввод. 2-3 минуты голосового переводится в текст и с хорошим качество.
Кроме этого в чат я скидываю png изображения макетов из Figma (2-3 экрана которые LLM должна понимать).
Промпт для сбора контекста о продукте тут
Вот как выглядит этот промпт для нейросети в чате:
Зачем это нужно? Если вы попросите написать требование сразу, LLM придумает логику за вас. И скорее всего, ошибется.
Шаг 2. Допрос с пристрастием
Claude не кидается писать требования. Он начинает задавать вопросы. И это самые правильные вопросы, которые мог бы задать дотошный QA.
Я трачу 10-15 минут на ответы. В этот момент я сам до конца не понимаю, как правильно составить ТЗ. Мы вместе с нейронкой пытаемся это понять.
Шаг 3. Генерация мяса
Когда контекст синхронизирован, я даю команду писать. Но не просто "пиши", а по моему шаблону (ToDo лист для разработки + требования + критерии приемки).
Результат получается таким, что дизайнер мне пишет
Что получаем на выходе:
- Четкий список "Что сделать" (поля, теги, логика).
- Требования к форме (мультиселект, валидация).
- Корнер-кейсы (что делать с деактивированными БЦ).
Это уже не просто пример user story, это готовые требования с критериями приемки.
Почему это работает
Потому что ты следуешь правилам и не надеешься на магию.
Мои правила:
- Держу актуальный файл с "Контекстом проекта". В конце каждой задачи я прошу LLM проапдейтить файл с контекстом проекта исходя из того что изменилось по ходу решения задачи.
- Скармливаю файл с контенкстом LLM в начале сессии.
- Есть четкие критерии для написания требований + примеры уже завершенных требований которые прошли мою верификацию.
- Запрещаю генерировать решение сразу.
Где можно облажаться:
- Слепое доверие. LLM может придумать несуществующий функционал. Вычитывать обязательно.
- Сложная архитектура. Если задача затрагивает биллинг или сложные интеграции — нейросети для работы тут помогут только с описанием интерфейса, "мясо" проектируйте сами.
- Читать придется все равно. LLM лишь помогает подготовить материал и решить корнер кейсы.
Итог
LLM — это не замена продакта или аналитика. Это лишь помощник с которым растет качество решаемых задач (при должных навыках)
У себя в тг канале я оставил подробные инструкции и промпты, забирайте 🥩
Попробуйте начать с малого: возьмите простую задачу, надиктуйте её и используйте мой подход. И тогда вопрос "как писать техническое задание" перестанет вызывать головную боль.