Как составить ТЗ на разработку сайта: почему проекты срывают дедлайны

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

Как выбрать исполнителя или веб-студию

Смотрите не на красоту сайта студии, а на то, задают ли вам правильные вопросы до старта. Хороший исполнитель сам помогает сформулировать задачу, называет сроки и стоимость до работ и фиксирует объём правок. Если вам сразу называют цену без вопросов - это тревожный знак.

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

Зачем нужно ТЗ

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

Сроки срываются в основном по трём причинам: задача была понята по-разному, объём рос по ходу работы, обратная связь приходила неделями. Все три лечатся на этапе технического задания.

Что обязательно должно быть

1. Цель сайта. Заявки, продажи, запись, информирование. Одна главная, остальные вторичны.
2. Целевая аудитория. Кто эти люди и какие у них возражения.
3. Структура. Перечень страниц и блоков на каждой.
4. Функциональность. Формы, калькуляторы, личный кабинет, оплата, интеграции.
5. Контент. Кто пишет тексты и готовит фото, в какие сроки.
6. Технические требования. Скорость, адаптивность, браузеры, доступность.
7. Сроки и этапы. С контрольными точками и порядком приёмки.
8. Что не входит. Самый недооценённый раздел.

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

Как описывать функции

Через поведение, а не через названия. Не «сделать умную форму», а «после отправки формы данные уходят в CRM, клиент видит благодарность, менеджеру приходит уведомление в Telegram в течение минуты».

Так проверяется результат: либо работает по описанию, либо нет.

Правило простое: функция описана достаточно, если по тексту понятно, как проверить её работу при приёмке.

Референсы

Прикладывайте 3 до 5 примеров с пояснением, что именно нравится: структура, типографика, анимация. Ссылка без комментария бесполезна, потому что каждый видит в ней своё.

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

Раздел про правки

Зафиксируйте количество итераций на каждом этапе и порядок подачи замечаний: одним списком, а не потоком сообщений. Это самая частая причина срыва сроков.

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

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

• Указана измеримая цель.
• Есть структура всех страниц.
• Функции описаны через поведение.
• Понятно, кто отвечает за контент.
• Есть раздел «не входит в проект».
• Прописан порядок приёмки и правок.

Как принимать работу по этапам

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

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

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

Что передаётся при сдаче проекта

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

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

Частые вопросы

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

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

Что делать, если требования изменились по ходу? Оформлять как отдельную задачу с пересмотром сроков и стоимости, а не втискивать в текущий этап.

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

Кто владеет исходниками после сдачи? Пропишите это отдельно. По умолчанию вопрос часто остаётся открытым, и это создаёт проблемы при смене подрядчика.

Я начинаю любой проект с короткого брифа и превращаю его в понятное ТЗ, чтобы вы заранее знали, что и когда получите. Посмотрите создание лендинга под ключ и сайт под задачу. Хотите разложить вашу задачу по полкам - напишите.