Техническое задание на сайт нужно не подрядчику, а заказчику: это единственный документ, по которому потом можно сказать, сделано или нет. Без него спор о результате превращается в спор о вкусах, где выигрывает тот, кто громче. Ниже — что должно быть в ТЗ, чего в нём быть не может и почему шаблон из интернета обычно бесполезен.
- ТЗ защищает заказчика: без него «сделано» определяется на словах.
- Формулировки «современный дизайн» и «удобная навигация» непроверяемы и в ТЗ не работают.
- Список страниц с назначением каждой важнее описания технологий.
- В ТЗ входит, что заказчик получает на выходе: домен, код, доступы.
- Шаблон из интернета описывает чужой проект — переносить его целиком бессмысленно.
Зачем ТЗ на самом деле
Его пишут, думая, что это инструкция для исполнителя. На деле главная функция другая — зафиксировать критерий приёмки. Пока не написано, что считается готовым результатом, любая доработка обсуждается заново, и обе стороны считают себя правыми.
Спор без ТЗ
Заказчик говорит, что хотел иначе. Подрядчик отвечает, что сделал как договаривались. Проверить нечем: договорённость была устной, а память у сторон разная.
Спор с ТЗ
Открывается пункт и сверяется. Если в ТЗ написано «страница услуги содержит цену, состав работ и форму», то либо это есть, либо нет. Обсуждать нечего.
Что должно быть в ТЗ
Список страниц с назначением
Не «сайт из десяти страниц», а перечень: какая страница, на какой вопрос отвечает, что на ней обязательно есть. Это самая полезная часть документа и самая часто пропускаемая.
Структура типовой страницы
Что содержит страница услуги, страница объекта, страница цен. Тогда добавление одиннадцатой страницы не превращается в новый проект.
Что делает сайт, а не как он выглядит
Формы, расчёты, фильтры, интеграции — с указанием, куда уходят заявки и кто их получает. Это то, что ломается чаще всего, и то, о чём вспоминают в последний день.
Технические требования, которые можно проверить
Скорость загрузки в цифрах, работа на телефоне, требования к разметке и аналитике. «Сайт должен быть быстрым» — не требование, «главная открывается за две секунды на 4G» — требование.
Что заказчик получает на выходе
Домен, исходный код, доступы к хостингу и аналитике, права на дизайн и тексты. Пункт, который дороже всего пропустить: без него сайт может оказаться в аренде. Подробнее — в стандарте о правах.
Порядок приёмки
Сколько этапов, что проверяется на каждом, сколько дней на замечания и сколько на исправления. Без этого приёмка растягивается на месяцы.
Чего в ТЗ быть не должно
Оценочных формулировок
«Современный», «стильный», «удобный», «продающий». Проверить их невозможно, и в споре они играют против того, кто их написал.
Описания реализации вместо результата
«Сделать на таком-то фреймворке» — требование к инструменту, а не к результату. Оно имеет смысл, только если у заказчика есть причина: своя команда, интеграции, требования службы безопасности.
Обещаний трафика и позиций
Их место в договоре на продвижение, а не в ТЗ на разработку. Сайт может быть сделан идеально и не иметь трафика, потому что трафик — другая работа.
Кто пишет ТЗ
Идеально — подрядчик после разговора с заказчиком, а заказчик проверяет и подписывает. Заказчик не обязан разбираться в вёрстке, но обязан понимать, что написано: если пункт непонятен, его нужно переформулировать, а не согласовывать на доверии.
Готовый шаблон из интернета описывает чужой проект с чужими задачами. Полезно взять из него оглавление, но содержание придётся написать своё — иначе в ТЗ окажутся разделы, которых у вас нет, и не окажется того, что важно именно вам.
Разделы ТЗ по порядку
Структура, которой достаточно для сайта услуг или отраслевой компании. Каждый раздел — ответ на вопрос, который иначе всплывёт в конце проекта.
1. Что за бизнес и кто клиент
Пара абзацев: чем занимаетесь, кто покупает, как принимает решение. Без этого подрядчик будет делать сайт «вообще», а не под вашего заказчика.
2. Задача сайта
Одно предложение: что должно произойти. «Получать заявки на строительство домов в своём районе» — задача. «Представить компанию в интернете» — не задача, под неё невозможно принять работу.
3. Карта страниц
Таблица: адрес, назначение, обязательные блоки. Самая полезная часть документа. Из неё же потом растёт структура продвижения.
4. Содержание типовых страниц
Что обязательно есть на странице услуги, на карточке объекта, на странице цен. Это избавляет от переделок, когда страниц станет двадцать.
5. Функциональность
Формы, расчёты, фильтры, интеграции. Для каждой формы — куда уходит заявка, кто получает уведомление, что видит пользователь после отправки.
6. Материалы и кто их даёт
Тексты, фотографии, документы, логотип. Самая частая причина срыва сроков — не работа подрядчика, а материалы, которых заказчик не прислал. Поэтому в ТЗ пишут, кто что готовит и к какому сроку.
7. Технические требования
Скорость в цифрах, работа на телефоне, разметка, аналитика и цели, защита форм, доступность из нужных регионов.
8. Что передаётся заказчику
Домен, код, доступы, права на дизайн и тексты, инструкция по обновлению.
9. Приёмка и сроки
Этапы, что проверяется на каждом, сколько дней на замечания и на исправления, что считается завершением.
Как проверить чужое ТЗ за десять минут
Три вопроса к готовому документу, которые сразу показывают его качество.
Можно ли по нему сказать «нет»
Возьмите любой пункт и спросите: как я проверю, что это сделано? Если ответа нет, пункт бесполезен и его нужно переписать в проверяемую форму.
Есть ли карта страниц
Если её нет, объём работ не зафиксирован, и любая дополнительная страница станет поводом для спора о доплате — в обе стороны.
Написано ли, что вы получаете
Отсутствие раздела о передаче домена, кода и доступов — самый дорогой пропуск. Обнаруживается он обычно при попытке сменить подрядчика.
Частая ошибка: ТЗ вместо разговора
Заказчик присылает документ на двадцать страниц, найденный в интернете, и ждёт оценки. В нём описан интернет-магазин с личным кабинетом, хотя нужен сайт услуг на восемь страниц. Подрядчик оценивает написанное — и цена оказывается втрое выше нужной.
Рабочий порядок обратный: сначала разговор о задаче, потом документ, который эту задачу описывает. Тогда ТЗ занимает пять страниц и все они про ваш проект.
ТЗ и договор: что где
Их часто путают или дублируют, и оба документа от этого проигрывают.
В договоре
Стороны, сроки, деньги, порядок оплаты, ответственность, права на результат, порядок расторжения. Это про отношения сторон.
В ТЗ
Что именно делается: страницы, содержание, функциональность, технические требования. Это про предмет работы.
Как их связать
ТЗ прикладывается к договору и упоминается в нём как приложение. Тогда невыполнение пункта ТЗ становится невыполнением договора, а не поводом для дискуссии о том, договаривались ли вообще.
Что делать, если ТЗ уже нарушено
Порядок простой и работает в обе стороны. Сначала письменно фиксируется расхождение: пункт ТЗ, что ожидалось, что получилось. Дальше даётся срок на исправление — разумный, а не «до завтра». Если исправления нет, вступают условия договора о приёмке и ответственности.
Ключевое здесь — письменная форма. Претензия в мессенджере голосом не является документом, а переписка по существу с датами является.
Посмотрим, что в нём непроверяемо, чего не хватает и где формулировки играют против вас. Сумма зачитывается в стоимость работ.
Заказать разборЧастые вопросы
Особенно если знакомый. Устная договорённость плохо переживает разногласие, а испорченные отношения дороже документа на пять страниц.
Как оглавление — да, как содержание — нет. Шаблон описывает чужой проект: в нём будут разделы, которых у вас нет, и не будет того, что важно вам.
Обычно подрядчик после интервью с заказчиком, а заказчик проверяет и подписывает. Главное правило: непонятный пункт переформулируется, а не согласовывается на доверии.
Оформлять изменением к ТЗ с указанием, как оно влияет на срок и стоимость. Устные правки по ходу — главная причина, по которой проекты выходят за сроки.
Нет, это отдельная работа и отдельный договор. В ТЗ на разработку входит то, что делает сайт готовым к продвижению: структура, скорость, разметка, аналитика.
Список страниц с назначением каждой и пункт о том, что заказчик получает на выходе: домен, код, доступы. Эти два раздела снимают большинство будущих споров.