Как составить техническое задание для разработчика с помощью ИИ

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

Опишите проблему и пользователя

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

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

Задайте ИИ вопросы, а не готовые решения

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

В SYNTX можно обратиться к языковой модели за структурой документа или перечнем уточнений. Не предполагайте, что агрегатор подключён к вашему репозиторию или создаёт задачу в трекере: используйте подготовленный текст как черновик. Бесплатный старт включает пять токенов и пять запросов к языковым моделям; план FREE не ограничен по времени. Открыть SYNTX AI.

Опишите сценарии и критерии приёмки

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

Критерии приёмки должны быть проверяемыми. Например: «после сохранения заявка появляется в списке со статусом “Черновик”» лучше, чем «интерфейс удобный». Если интерфейс зависит от ролей, перечислите роль и доступные действия.

Пример: фильтр заявок

Проблема: сотруднику сложно находить заявки, где нужен ответ. Черновое требование: «Список показывает только заявки с открытым статусом после включения фильтра». Уточнения: какие статусы считаются открытыми; фильтр сохраняется после перезагрузки; как отображается пустой результат; кто имеет право менять список.

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

Пример приёмки: «Если выбран фильтр открытых заявок, в списке остаются только записи из согласованного набора статусов; при отсутствии совпадений показывается пустое состояние с предложением сбросить фильтр». Этот критерий требует уточнить точные статусы и текст пустого состояния до разработки.

Проведите ревью черновика

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

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

Проведите короткую проверку требований

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

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

Частые вопросы