Техническое задание на сайт нейросеть собирает за один разговор, если заказчик отвечает на десяток уточняющих вопросов о цели сайта, структуре и бюджете. Без этих вводных документ выходит общим и почти всегда дорабатывается уже в процессе разработки.
Из чего состоит ТЗ
По нашему опыту внедрений полное техническое задание на сайт среднего размера — 10–15 страниц с формами и каталогом — занимает 3–5 страниц текста и собирается нейросетью за один прогон при условии, что заказчик заранее ответил на ключевые уточняющие вопросы.
- Цель сайта и целевое действие посетителя: заявка, покупка, звонок, подписка.
- Структура разделов и примерное число страниц каждого типа.
- Функциональные требования: форма заявки, каталог, личный кабинет, интеграция с CRM или платёжной системой.
- Референсы — примеры сайтов, которые заказчику нравятся или отталкивают, и почему именно.
- Сроки и вилка бюджета, в которую должна уложиться разработка.
Модель хорошо раскладывает эти пункты по разделам документа и формулирует их языком, понятным разработчику, — но сами ответы на вопросы о цели, бюджете и сроках заказчик даёт сам: без них документ превращается в общий шаблон, который годится для любого сайта вообще.
Для сайта услуг вместо интернет-магазина набор разделов немного смещается: вместо каталога и корзины на первый план выходят страницы услуг с ценами, форма записи или заявки и раздел с портфолио примеров работ. Модель учитывает эту разницу автоматически, если в самом начале указать тип бизнеса и основной сценарий заявки клиента.
Отдельно полезно сразу закладывать раздел про требования к хостингу и домену: где будет жить сайт после запуска, нужен ли отдельный сервер под нагрузку или хватит обычного тарифного хостинга. Этот раздел часто выпадает из первой версии ТЗ и всплывает уже на этапе передачи готового сайта заказчику.
Что уточнить заранее
- Кто целевая аудитория сайта и с какого устройства она чаще заходит — мобильного или компьютера.
- Нужна ли интеграция с уже действующими системами компании: CRM, складской учёт, платёжный шлюз.
- Кто будет наполнять сайт контентом после запуска — сама компания через админку или подрядчик разово.
- Есть ли готовый фирменный стиль и логотип или дизайн разрабатывается с нуля вместе с сайтом.
- Какой максимальный срок приемлем для первой версии сайта и что можно перенести во вторую очередь.
Пятый пункт — про приоритеты — часто пропускают, а зря: он превращает общее ТЗ в документ с чёткой границей между обязательным минимумом для запуска и функциями, которые можно добавить уже после старта продаж.
Для интернет-магазина стоит отдельно уточнить и вопрос о будущем росте каталога: сто товаров сегодня и тысяча через полгода — разные требования к структуре базы данных и скорости поиска по фильтрам. Закладывать запас на рост дешевле на этапе ТЗ, чем переписывать структуру каталога уже после запуска сайта.
Пример диалога
Собери ТЗ на сайт интернет-магазина мебели на 200 товаров: нужны каталог с фильтрами, корзина, форма заказа без онлайн-оплаты, интеграция с amoCRM. Дизайн — по референсам двух конкурентов, которые я приложу отдельно. пример вводных заказчика
Собрать такое ТЗ под свой проект?
По таким вводным модель уже способна предложить структуру разделов каталога, список фильтров по типу товара и черновик формы заказа — а заказчику остаётся уточнить детали вроде способов доставки или необходимости регистрации личного кабинета покупателя.
Риски пробелов в ТЗ
| Пробел в задании | Чем это грозит на этапе разработки | Как закрыть заранее |
|---|---|---|
| Объём каталога и структура фильтров остаются неуказанными | Разработчик закладывает упрощённую структуру, которую придётся переделывать при росте каталога | Указать примерное число товаров и категорий уже в ТЗ |
| Нет референсов дизайна | Несколько раундов правок макета из-за расхождения ожиданий | Приложить два-три примера сайтов с пометкой, что именно нравится |
| Интеграция с CRM остаётся неоговорённой заранее | Интеграция закладывается на финальном этапе и требует переделки логики форм | Указать конкретную CRM и нужные поля синхронизации в самом начале |
| Ответственность за наполнение контентом остаётся неназначенной | Сайт готов технически, но пустует без текстов и фото на момент запуска | Заранее назначить, кто и когда готовит тексты и фотографии товаров |
Каждый пробел в этой таблице дороже всего обходится уже через несколько недель разработки, когда готовый макет или код приходится переделывать под условие, которое можно было учесть с самого начала.
Полезная привычка перед стартом разработки — пройтись по готовому ТЗ вместе с разработчиком и попросить его отметить два-три пункта, которые кажутся ему наименее конкретными. Такой взгляд со стороны исполнителя часто ловит именно те формулировки, которые автору документа казались достаточно ясными, а на практике допускают два разных толкования.
Частые ошибки
- Писать ТЗ общими фразами вроде «современный дизайн» без конкретных референсов — разработчик и заказчик представляют это по-разному.
- Пропускать вопрос про бюджет — без вилки цифр модель предлагает функциональность без границ, которую разработчик потом урезает уже в процессе.
- Утверждать ТЗ без финальной вычитки заказчиком целиком — легче поймать неточность на бумаге, чем в готовом коде сайта.
- Смешивать в одном документе техническое задание и договор с исполнителем — это разные документы с разной юридической силой.
Вопрос, что вообще выгоднее — заказать сайт в студии или собрать его силами команды на нейросети, — разобран в статье про сравнение агентства и сборки сайта на нейросети; здесь же разобрана подготовка самого технического задания вне зависимости от того, кто в итоге разрабатывает сайт.
Что важно прописать в договоре с подрядчиком отдельно про использование нейросетей в самой разработке, разбирает статья про договор с подрядчиком и использование ИИ. Общий обзор работы с документами через нейросеть — на странице нейросетей для документов.
Готовое ТЗ полезно хранить вместе с последующей перепиской по проекту в одном месте — тогда при споре о границах работ легко поднять исходный документ и сверить, что именно было согласовано на старте, а что появилось уже позже в виде дополнительных пожеланий заказчика.
Типичный пробел в ТЗ для сайта услуг — пропустить отдельный пункт про адаптацию под мобильные экраны, посчитав это само собой разумеющимся. Разработчик в таком случае обычно закладывает в оценку только версию для компьютера, и доработку под телефоны приходится делать уже после сдачи проекта — почти в объёме отдельной вёрстки. Пункт про обязательную адаптацию и конкретные экраны для проверки стоит вносить в ТЗ отдельной строкой по умолчанию.