Клиентский бриф обычно смешивает цели, пожелания, примеры чужих решений и уже принятые ограничения. Если сразу попросить ИИ написать техническое задание, он может превратить расплывчатые идеи в конкретные обязательства. Более надёжный первый результат — реестр требований, в котором видно, что сказал клиент и что ещё предстоит согласовать.
Гайд подготовлен для Tarasov Code — проекта Ильи Тарасова и TarasovWeb. Метод подходит для сайта, внутреннего инструмента или контентного проекта. Он помогает подготовить обсуждение, но не заменяет подтверждение требований заказчиком.
Разберите исходный текст на отдельные утверждения
Сохраните бриф, заметки встречи и приложения с устойчивыми идентификаторами. Попросите ИИ выделить каждое самостоятельное пожелание, не объединяя несколько функций в одну строку. Фраза «нужен удобный каталог с фильтрами и заявкой» содержит как минимум ожидание удобства, фильтрацию и отправку заявки. У них разные способы проверки.
Для каждой записи укажите источник, тип и статус. Типами могут быть бизнес-цель, функция, ограничение, данные, интеграция и требование к качеству. Статус показывает, подтверждено ли требование или это интерпретация. Ссылки на понравившиеся сайты рассматривайте как материал для уточнения: клиент мог иметь в виду визуальный стиль, а не весь функционал.
Превратите пожелания в проверяемые условия
Для функции определите пользователя, действие и ожидаемый результат. Для требования к качеству запросите условия измерения. «Быстро загружается» без устройства, сети, страницы и метрики остаётся пожеланием. Модель может предложить варианты уточнения, но не должна самостоятельно назначать технический норматив.
Отдельно найдите зависимости и противоречия. Например, открытый просмотр каталога и обязательная авторизация перед просмотром могут относиться к разным разделам, а могут конфликтовать. Требование экспорта зависит от состава данных и прав доступа. Покажите эти связи клиенту до оценки трудозатрат.
Учебный пример каталога оборудования
Предположим, бриф содержит 12 пунктов. После разделения составных фраз получилось 19 записей: 10 функций, 3 ограничения, 2 бизнес-цели и 4 вопроса без достаточной конкретики. Это не означает автоматического увеличения объёма проекта; реестр просто делает исходные ожидания видимыми.
Для фразы «удобно отбирать оборудование» можно предложить уточнение: покупатель выбирает категорию и диапазон мощности, после чего видит соответствующие позиции. Критерий приёмки проверяется на согласованном тестовом наборе. Но список фильтров, единицы мощности, обработка пустой выдачи и сочетание условий ещё требуют ответа. Их нельзя молча додумать.
Извлеки требования из брифа, не расширяя объём проекта.
Для каждой записи дай ID, исходную цитату, тип,
понятную формулировку, статус и вопрос на уточнение.
Разделяй составные требования на отдельные проверяемые действия.
Предложи критерии приёмки как черновики для согласования.
Отметь противоречия, зависимости и отсутствующие данные.
Не назначай приоритеты, сроки и бюджет вместо заказчика.
Бриф: [текст]. Приложения: [источники с ID].Согласуйте реестр до детализации решения
Сгруппируйте вопросы по влиянию на решение. Сначала обсуждайте то, что меняет архитектуру, объём или доступы. Затем переходите к деталям отображения. Если отправить клиенту десятки равнозначных вопросов без порядка, важные неопределённости могут остаться без ответа.
После обсуждения обновите статусы и сохраните дату подтверждения. Приоритеты полезно разделять на обязательное для запуска, желательное и отложенное. Само название категории должно быть согласовано командой. Слова «важно» и «срочно» без сравнения с другими требованиями мало помогают планировать.
Ведите связь между требованием, проектным решением и проверкой. Если на позднем этапе клиент меняет сценарий, можно увидеть затронутые экраны и тесты. Это особенно полезно для небольших проектов, где требования часто живут в переписке: реестр превращает разговор в управляемый список договорённостей.
Для требований к данным отдельно уточните происхождение, владельца и право изменения. Наличие поля на экране не отвечает на вопрос, кто его заполняет и что происходит при ошибке. Если каталог импортируется из внешней системы, выясните частоту обновления и поведение при недоступности источника. Эти вопросы нередко сильнее влияют на объём проекта, чем визуальная структура страницы, хотя в первоначальном брифе занимают одну строку.
Проверка перед оценкой работ
- Каждое требование связано с исходным источником.
- Предложения команды отделены от пожеланий клиента.
- Критичные противоречия разобраны.
- Для функций понятны пользователь, действие и результат.
- Открытые вопросы не скрыты внутри окончательных формулировок.
Частые вопросы
Нужен ли отдельный реестр для маленького сайта?
Он может быть короткой таблицей. Важна прослеживаемость и согласование, а не сложность инструмента или количество документов.
Можно ли поручить модели оценить сроки?
Можно получить список факторов для оценки. Реальный срок зависит от команды, технологий, исходных материалов и неопределённостей, которых модель может не знать.
Для ясности описания действий полезен редакционный справочник Google. Он помогает формулировкам, а предметные требования и критерии остаются результатом согласования участников проекта.