Как написать тз на разработку сайта

Зачем вообще нужно ТЗ и кому оно нужно

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

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

Что такое хорошее ТЗ — основные свойства

Не существует идеального шаблона, который подходит ко всем проектам. Но есть набор характеристик, по которым можно судить о качестве ТЗ. Хорошее ТЗ:

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

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

Структура ТЗ: что должно быть обязательно

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

• Введение и краткое описание проекта;
• Цели и задачи;
• Целевая аудитория и сценарии использования;
• Структура сайта и карта страниц;
• Контент: кто готовит и в каком формате;
• Функциональные требования;
• Технические требования и интеграции;
• Дизайн и UX-требования;
• Хостинг, домен и безопасность;
• План работ, сроки и вехи;
• Бюджет и порядок оплаты;
• Критерии приёмки и тестирование;
• Поддержка и SLA после запуска.

Введение и описание проекта

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

Пример: интернет-магазин аксессуаров для велосипедистов, ориентированный на городских покупателей 18–45 лет, желающих быстрого решения и доставку в пределах города.

Введение не должно быть длинной историей. Пара чётких предложений — и дальше в технические детали.

Цели и задачи

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

Например: поднять конверсию в покупку на 20% в течение полугода, снизить отказ от корзины на 15%. Когда цель конкретна, легче проектировать функционал и оценивать результат.

Целевая аудитория и сценарии использования

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

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

Карта сайта и структура страниц

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

Пример таблицы с описанием страниц:

Контент: кто делает, в каких форматах и когда

Контент часто становится тормозом проекта. Чётко укажите, кто отвечает за тексты, фотографии, видео и когда они будут готовы. Укажите формат и требования к файлам: размеры картинок, формат видео, языки.

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

Функциональные требования — подробно и приоритетно

Функционал — это сердце ТЗ. Перечисляйте функции ясными предложениями и проставляйте приоритеты: must-have, should-have, nice-to-have. Для сложного функционала давайте сценарии использования и примеры данных.

Таблица с примерами функциональных требований:

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

Технические требования и интеграции

Здесь вы перечисляете платформы, с которыми нужно интегрироваться: CRM, платёжные шлюзы, службы доставки, ERP. Если у подрядчика есть ограничения по используемым технологиям, укажите их.

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

Если вы хотите использовать конкретную CMS или стек технологий, пропишите это. Если нет — укажите желаемые свойства: безопасность, масштабируемость, удобство администрирования.

Дизайн и UX требования

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

Укажите требования к адаптивности: какие устройства и экраны важны, а также требования к доступности (WCAG), если они критичны. Если есть готовые прототипы — приложите их и опишите взаимодействие элементов.

SEO и маркетинговые требования

Если сайт должен привлекать трафик с поисковых систем, включите блок с SEO-требованиями. Укажите структуру URL, требование к человеко-понятным заголовкам, мета-теги, микроразметку, карту сайта и robots.txt. Также опишите ожидания по аналитике: подключение Google Analytics, Яндекс.Метрики, событий и целей.

Маркетинговые инструменты, такие как формы подписки, pop-up, интеграция с e-mail сервисом, тоже важно зафиксировать в ТЗ.

Хостинг, домен и безопасность

Укажите, кто отвечает за домен и хостинг: заказчик или подрядчик. Если у вас уже есть хостинг — дайте доступ, если нет — опишите требования к нему (размер диска, резервное копирование, SSL-сертификат).

Безопасность — отдельный пункт. Попросите реализовать HTTPS, защиту от SQL-инъекций и XSS, бэкапы, базовые правила брандмауэра. Для интернет-магазина важна защита персональных данных и соответствие законодательству о защите данных.

План работ, сроки и вехи

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

Таблица плана с примером вех:

Бюджет и порядок оплаты

Чётко пропишите бюджетные ожидания и модель оплаты: фиксированная сумма, почасовая оплата или оплата по этапам. Если вы платите по вехам, укажите условия приёмки и какие работы считаются завершёнными.

Укажите необходимость резерва на непредвиденные изменения. Проекты почти всегда требуют доработок, лучше заложить в бюджет 10–20% на изменения или дополнительные задачи.

Критерии приёмки и тестирование

Опишите, как будет проходить приёмка работы: какие тесты выполнить, на каких устройствах смотреть, какие баги считаются критичными. Пропишите SLA по исправлению критических ошибок после приёмки.

Примеры критериев приёмки:

• Главная страница загружается за 3 секунды при среднем соединении;
• Форма заказа корректно принимает данные и создаёт заказ в CRM;
• Адаптивность отображается корректно на мобильных и планшетах;
• Прохождение базового набора тестов безопасности.

Поддержка и обслуживание после запуска

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

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

Коммуникация и менеджмент проекта

Опишите, кто из заказачика и исполнителя участвует в проекте, кто принимает решения, кто отвечает за контент, кто за финансы. Укажите каналы связи: почта, мессенджер, трекер задач, регулярные созвоны.

Рекомендуется прописать частоту отчётности и формат: еженедельные отчёты, доступ к доске задач, демонстрации результатов по вехам. Чёткая коммуникация снижает риск недопонимания.

Примеры типичных ошибок в ТЗ и как их избежать

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

1. Нечёткие цели. Решение: формулируйте цели в цифрах.
2. Отсутствие ответственных за контент. Решение: назначьте владельца контента и сроки.
3. Слишком общий функционал. Решение: расписывайте сценарии и ожидаемое поведение.
4. Неучёт мобильной аудитории. Решение: прописывайте требования к адаптивности.
5. Неописанные процессы приёмки. Решение: согласуйте чек-листы для каждого этапа.

Шаблон ТЗ: краткая практика

Ниже краткий шаблон, который можно скопировать и заполнить. Он покрывает ключевые блоки и помогает не забыть важного.

• Название проекта и короткое описание;
• Цели и метрики успеха;
• Целевая аудитория и основные сценарии;
• Карта сайта и список страниц;
• Контент: что есть и что нужно подготовить;
• Функциональные требования с приоритетами;
• Технические требования и интеграции;
• Дизайн-ориентиры и примеры;
• План работ и вехи;
• Бюджет и условия оплаты;
• Критерии приёмки и поддержка.

Практические советы для эффективного ТЗ

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

• Пишите понятными предложениями, избегайте двусмысленности.
• Иллюстрируйте сложные вещи примерами или скриншотами.
• Разделяйте желательное и обязательное. Это экономит время и бюджет.
• Добавляйте контактные данные и назначайте ответственных.
• Делайте ТЗ живым документом: корректируйте по ходу проекта, фиксируя изменения.

Как работать с подрядчиком, если ТЗ готово

Когда документ готов, не бросайте его в пустоту. Организуйте встречу с подрядчиком, пройдитесь по важным моментам и убедитесь, что все понимают задачи одинаково. Попросите подрядчика дать оценку и расписать сроки по этапам.

Отделите процесс оценки и переговоров от самого ТЗ: в документе — требования, в приложениях — переговоры, протоколы и дополнительные договорённости.

Чек-лист готового ТЗ

Перед отправкой ТЗ подрядчику пройдитесь по чек-листу. Это простая вещь, но она экономит кучу времени.

• Есть краткое описание проекта;
• Цели измеримы;
• Есть карта сайта;
• Функционал расписан с приоритетами;
• Указаны сроки и вехи;
• Назначены ответственные за контент;
• Прописаны критерии приёмки;
• Указан бюджет или порядок его согласования;
• Добавлены контакты и план коммуникации.

Пример простого ТЗ для лендинга

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

Заключение: делайте ТЗ живым и понятным

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

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

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