Техническое задание на разработку сайта: что должно быть в ТЗ и как его составить

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

На самом деле хорошее техническое задание не должно начинаться с технологий.

Его основная задача — зафиксировать, что именно нужно создать, как это должно работать и какого результата ожидает бизнес. А уже разработчик может предложить технический способ реализации.

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

Главное не объём документа, а то, насколько одинаково заказчик и команда разработки понимают будущий проект.

Для чего нужно техническое задание на разработку сайта

Представим простую ситуацию.

Клиент говорит:

Нужен современный корпоративный сайт примерно на 10 страниц.

Для бизнеса такого описания может хватить, чтобы объяснить общую идею. Для оценки разработки — нет.

Непонятно, нужен ли индивидуальный дизайн, сколько будет уникальных шаблонов страниц, кто готовит тексты, нужна ли многоязычность, какие формы должны работать, будут ли CRM, блог, поиск, фильтры, аналитика или дальнейшее SEO-продвижение.

Именно эти детали постепенно превращают общее пожелание в конкретный проект.

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

Клиент, в свою очередь, получает понятное представление о том, что именно будет создано.

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

Должен ли клиент самостоятельно писать ТЗ

Нет.

И это одна из важнейших вещей, которые стоит понимать перед обращением к разработчику.

Клиент хорошо знает свой бизнес, продукты, услуги, клиентов и внутренние процессы. Но он не обязан знать, как правильно выстроить структуру WordPress, какой тип интеграции использовать или каким способом реализовать каталог.

Более того, слишком подробное техническое решение от заказчика иногда даже мешает.

Например, клиент может написать:

Нужен сайт на WordPress с 12 плагинами, таким-то фильтром и конкретным модулем CRM.

А после анализа может оказаться, что часть этих инструментов вообще не нужна или ту же задачу можно решить проще.

Поэтому нормальный процесс выглядит иначе.

Бизнес объясняет, что ему нужно получить, а команда разработки помогает превратить это в структуру, функциональные требования и техническое решение.

В theDC.studio мы именно поэтому перед оценкой более сложных проектов сначала уточняем задачу, структуру и функционал, а не ожидаем от клиента готового технического документа.

С чего начинается хорошее ТЗ

Первая часть технического задания вообще может не содержать ничего технического.

Сначала нужно описать сам бизнес и роль будущего сайта.

Например:

Компания занимается производством оборудования. Сайт должен представлять продукцию, давать возможность найти нужную модель по характеристикам и отправить запрос менеджеру.

Или:

Частная клиника планирует создать сайт с отдельными страницами направлений, врачей, услуг и возможностью записи на консультацию.

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

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

Для одного проекта главным действием будет заявка.

Для другого — звонок.

Для интернет-магазина — оформление заказа.

Для образовательного сайта — выбор программы и регистрация.

И уже от этого должна строиться структура.

Структура сайта — одна из главных частей ТЗ

Следующий этап — определить, из каких страниц будет состоять сайт.

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

Но просто написать «10 страниц» недостаточно.

Важно понимать, какие из них будут уникальными, а какие будут использовать один шаблон.

Например, у медицинской клиники может быть 30 страниц врачей. Это не означает, что дизайнер должен создавать 30 разных макетов. Обычно создаётся один шаблон страницы врача, а контент в нём меняется.

То же самое касается:

• товаров;
• услуг;
• кейсов;
• преподавателей;
• городов;
• категорий;
• объектов каталога.

Эта разница очень важна при оценке проекта.

Именно поэтому в хорошем ТЗ описывают не только количество страниц, но и логику их построения.

Что нужно описать для каждой важной страницы

Необязательно писать подробную инструкцию для каждого блока.

Но для ключевых страниц желательно зафиксировать их функцию.

Например, для главной страницы можно определить, что она должна кратко объяснять направление деятельности компании, показывать основные услуги, преимущества, кейсы, отзывы и вести пользователя к форме заявки.

Для страницы услуги — описывать конкретное направление, отвечать на основные вопросы клиента и давать возможность обратиться в компанию.

Для карточки товара — содержать фото, цену, характеристики, вариации, статус наличия и кнопку покупки.

Так команда понимает не только, как называется страница, но и зачем она нужна.

Функционал нужно описывать через сценарии

Это особенно важно для более сложных сайтов.

Фраза:

Нужен личный кабинет.

почти ничего не говорит разработчику.

Гораздо полезнее написать:

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

Или вместо:

Нужна интеграция с CRM.

лучше:

После отправки формы на сайте контакт пользователя и выбранная услуга должны автоматически передаваться в CRM и создавать новый лид.

Это называется пользовательским сценарием.

Именно такие сценарии помогают понять реальный объём программирования.

Особенно подробно их стоит описывать, если на сайте есть каталог, личный кабинет, бронирование, онлайн-оплата, сложные фильтры, интеграция с ERP или CRM, автоматический обмен данными или нестандартная логика работы.

Дизайн: что нужно зафиксировать в ТЗ

Техническое задание не должно определять, что «кнопка должна быть синей, шириной 240 px», если дизайн ещё даже не создан.

Но общее направление желательно зафиксировать.

Если у компании уже есть фирменный стиль, нужно передать логотип, цвета, шрифты и брендбук.

Если стиля нет, полезно показать несколько сайтов, которые нравятся, и объяснить почему.

Например:

Нравится крупная типографика и минималистичная подача.

или:

Нравится структура страницы, но не цвета.

Это гораздо полезнее, чем просто прислать пять ссылок со словами «хотим примерно так».

Референс не означает, что сайт нужно копировать. Он помогает быстрее понять ожидания клиента.

Кто готовит контент

Этот пункт часто забывают зафиксировать в начале.

В результате дизайн уже готов, разработка завершена, а сайт невозможно запустить, потому что нет текстов, фотографий или описаний товаров.

Поэтому ещё в ТЗ желательно определить, кто отвечает за контент.

Это может быть клиент, веб-студия или обе стороны.

Например, клиент передаёт техническую информацию о продукте, а студия адаптирует её для сайта.

Или бизнес полностью готовит тексты и фотографии самостоятельно, а команда разработки только размещает материалы.

Особенно важно определить это для крупных каталогов и интернет-магазинов, где наполнение может занимать не меньше времени, чем сама разработка.

SEO в техническом задании

Необязательно проводить полное SEO-исследование ещё до начала каждого проекта.

Но если бизнес планирует получать трафик из Google, это нужно учесть в ТЗ.

Например, ещё на этапе структуры стоит понять, нужны ли отдельные страницы для разных услуг, городов, категорий или направлений.

Также желательно предусмотреть корректную структуру URL, возможность редактировать метаданные, заголовки, тексты, ALT изображений и создавать внутреннюю перелинковку.

Почему эти вещи желательно закладывать ещё при разработке, мы подробно разберём в отдельном материале об SEO-подготовке сайта.

Интеграции нужно определить до оценки

CRM, службы доставки, платёжные системы, телефония, email-маркетинг, ERP или внешние API могут существенно влиять на объём разработки.

Поэтому желательно назвать их ещё до составления окончательной сметы.

Даже одна фраза «нужно передавать заказы во внутреннюю систему компании» может означать как простую готовую интеграцию, так и отдельную разработку обмена данными.

Если конкретная система уже используется, нужно сразу сообщить её название.

Если бизнес лишь знает, что хочет автоматизировать определённый процесс, технический способ реализации можно выбрать вместе с разработчиком.

Не забудьте об аналитике

Ещё до запуска желательно определить, какие действия пользователей нужно отслеживать.

Для большинства бизнес-сайтов это могут быть отправки форм, нажатия на номер телефона, переходы в мессенджеры или оформление заказа.

Обычно на сайт подключают Google Analytics 4, Google Search Console и, при необходимости, рекламные системы или другие аналитические сервисы.

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

Как определить, что сайт готов

Ещё один важный пункт технического задания — критерии завершения работы.

Формулировка «сайт должен работать нормально» слишком размыта.

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

Для интернет-магазина дополнительно проверяется процесс от добавления товара в корзину до создания заказа и оплаты.

Для более сложного сервиса тестируются пользовательские сценарии, описанные в ТЗ.

Так у клиента и разработчика появляется понятная точка, когда проект переходит из разработки в запуск.

Что делать, если во время разработки появились новые идеи

Это абсолютно нормальная ситуация.

Во время работы над дизайном или уже готовыми страницами часто становится понятно, что нужно добавить ещё один блок, интеграцию или функцию.

Проблема возникает только тогда, когда первоначальное ТЗ начинает постоянно расширяться, а бюджет и сроки при этом ожидаются прежними.

Поэтому важно различать уточнение первоначального задания и новый функционал.

Если в ТЗ была форма заявки, но нужно изменить название одного поля — это обычное уточнение.

Если вместо формы в процессе работы решили добавить личный кабинет пользователя — это уже новый объём.

Хороший процесс предполагает, что такие изменения фиксируются и оцениваются до начала дополнительной работы.

Техническое задание, бриф и прототип — не одно и то же

Эти понятия часто путают.

Бриф помогает собрать первоначальную информацию о бизнесе, целях, аудитории и пожеланиях.

Техническое задание фиксирует, что именно нужно реализовать на сайте.

Прототип показывает будущую структуру страниц визуально: где будут заголовок, форма, каталог, преимущества, кейсы или другие блоки.

В небольшом проекте эти этапы могут частично объединяться.

Для сложного сайта их лучше разделять.

Как может выглядеть короткое ТЗ на сайт

Для небольшого бизнес-сайта необязательно создавать документ на 50 страниц.

Базовый вариант может содержать следующие разделы:

• информация о компании и задача сайта;
• целевая аудитория;
• структура страниц;
• функциональные требования;
• требования к дизайну;
• контент и ответственные стороны;
• интеграции;
• базовые SEO-требования;
• аналитика;
• порядок согласования и тестирования;
• условия запуска.

Этого уже достаточно, чтобы перейти к подробной проработке проекта.

Для интернет-магазина, каталога или веб-сервиса каждый из этих пунктов будет раскрываться намного подробнее.

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

Самая распространённая ошибка — пытаться описать технологии вместо задач.

Клиенту гораздо полезнее написать:

Менеджер должен получать заявку с сайта в CRM.

чем самостоятельно определять API, формат передачи данных и необходимый плагин.

Вторая проблема — нечёткие формулировки вроде «современный дизайн», «удобная админка» или «сайт должен быть быстрым». Всё это правильно, но каждая сторона может понимать их по-разному.

Третья — отсутствие распределения ответственности. Если не определить, кто готовит тексты, фотографии, переводы и информацию о товарах, это почти гарантированно повлияет на сроки запуска.

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

Можно ли заказать разработку сайта без готового ТЗ

Да.

Для большинства бизнес-проектов это абсолютно нормальная ситуация.

Достаточно объяснить, чем занимается компания, показать текущий сайт, если он есть, рассказать о необходимом функционале и желаемом результате.

На основе этой информации уже можно сформировать структуру будущего сайта, определить технические требования и подготовить оценку.

Именно так мы работаем в theDC.studio: не ожидаем от клиента готовой технической документации, если её нет на старте. Сначала разбираем задачу, а затем переводим её на язык структуры, дизайна и разработки.

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

Если нужен проект именно на WordPress, мы отдельно описали это направление на странице разработки сайтов на WordPress.

Что в итоге даёт хорошее техническое задание

ТЗ нужно не для того, чтобы сделать разработку сложнее.

Напротив, оно должно упростить её для обеих сторон.

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

И хорошее техническое задание необязательно должно быть большим.

Для простого сайта достаточно короткого структурированного документа. Для сложной системы понадобится подробная спецификация.

Главное, чтобы после прочтения ТЗ у заказчика и разработчика не было двух разных представлений об одном и том же сайте.

Частые вопросы о техническом задании на разработку сайта

Планируете разработку сайта?

Если у вас уже есть готовое техническое задание — можем проанализировать его и оценить разработку.

Если ТЗ нет, это тоже не проблема.

Опишите бизнес, примерную структуру сайта и необходимые функции. Мы поможем сформировать требования, предложим оптимальный способ реализации и подготовим оценку проекта.