Как составить ТЗ на разработку сайта правильно

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

Кстати, в AmSales мы делаем внедрение и настройку Битрикс24 и разработку сайтов и приложений под ключ. Если нужна помощь - напишите нам.

Почему плохое ТЗ удваивает стоимость разработки

Когда заказчик говорит "сделайте нам современный интернет-магазин", разработчик слышит это как "сделайте что-нибудь, а потом мы будем доплачивать за каждую кнопку". Без четких границ проект превращается в бесконечный процесс. Каждое уточнение в середине разработки - это изменение рамок проекта (scope creep), которое неизбежно ведет к пересмотру сметы.

На практике это выглядит так. Вы заказали сайт с каталогом, а через месяц выясняется, что вам нужна фильтрация по 50 параметрам, личный кабинет с историей заказов и синхронизация остатков с 1С. Если в изначальном документе этого не было, подрядчик выставит счет за дополнительные часы. В итоге бюджет раздувается на 50-100% от первоначального, а сроки сдвигаются на месяцы.

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

Основные разделы идеального технического задания

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

• Цели и задачи проекта. Не пишите "увеличить продажи". Пишите: "сократить время оформления заказа до 3 кликов" или "автоматизировать сбор заявок с 5 разных лендингов в одну базу".
• Целевая аудитория и сценарии. Опишите, кто ваш клиент. Это снабженец крупного завода, которому важны PDF-спецификации, или частный покупатель, который ищет товар по фото?
• Структура сайта. Карта страниц, иерархия разделов и логика переходов.
• Технические требования. Выбор CMS (Bitrix, WordPress, Tilda или самопис), требования к скорости загрузки по Google PageSpeed, адаптивность под мобильные устройства.
• Дизайн и контент. Ссылки на референсы, требования к типографике, наличие брендбука и правила работы с изображениями.

Важно понимать, что ТЗ - это не просто список хотелок. Это юридический документ. Если в нем написано "сайт должен быть быстрым", это невозможно проверить. Если написано "время отрисовки первого экрана не более 1.5 секунд при скорости соединения 4G" - это конкретный критерий приемки.

Как описать функционал и интеграцию с CRM

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

Недостаточно написать "интегрировать с AmoCRM или Bitrix24". Нужно детализировать процесс. Например: при заполнении формы "Заказать звонок" создается сделка, в которой поле "Телефон" подтягивается из формы, а источник сделки автоматически получает метку "Сайт". Если у вас сложная воронка, укажите, какие именно поля из личного кабинета должны передаваться в карточку клиента.

Разберитесь с синхронизацией товаров и остатков. Если вы используете 1С УТ, пропишите правила: как часто обновляются цены, передаются ли остатки в штуках или в килограммах, как обрабатываются изменения артикулов. Если в 1С товар называется "Болт М8", а на сайте вы хотите "Болт высокопрочный М8", нужно заранее прописать логику сопоставления данных, иначе интеграция превратит вашу базу в хаос.

Типичные ошибки заказчика при постановке задач

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

Еще одна проблема - игнорирование этапа проектирования. Многие пытаются сразу нанять дизайнера, не имея готовой структуры и прототипов. Это путь в никуда. Сначала строится логическая схема (UX-прототип), где расставлены все кнопки и формы, и только потом накладывается визуальный слой. Попытка "поправить дизайн" на этапе верстки, когда выяснится, что кнопка не влезает в логику корзины, стоит очень дорого.

Забытые мелочи также бьют по карману. Например, вы не указали, кто будет наполнять каталог. В итоге разработчик делает админку, в которой невозможно добавить товар без знания кода, или вы понимаете, что для загрузки 10 000 позиций вам нужен инструмент массового импорта через Excel, о котором никто не подумал.

Как проверить ТЗ перед отправкой подрядчику

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

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