Техническое задание на сайт: как составить, чтобы не переплатить

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

Зачем вообще нужно ТЗ, если можно всё обсудить на словах?

Устные договорённости забываются и трактуются по-разному. Заказчик говорит «сделайте удобный каталог», а разработчик под этим может понимать что угодно — от простого списка товаров до сложной системы фильтров. ТЗ фиксирует общее понимание проекта на бумаге (или в файле), и если позже возникает спор, обе стороны обращаются к документу, а не к памяти.

Кроме того, без ТЗ невозможно посчитать нормальную стоимость проекта. Разработчик либо завышает цену «с запасом на неизвестность», либо называет заниженную сумму, а потом добавляет платные доработки по ходу дела. Подробное ТЗ убирает эту неопределённость с обеих сторон.

Кто должен составлять техническое задание — заказчик или исполнитель?

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

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

Что обязательно должно быть в техническом задании?

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

• цели сайта и целевая аудитория;
• структура сайта — карта разделов и страниц;
• функциональные требования — что должен уметь сайт (каталог, форма заявки, личный кабинет, интеграция с CRM и так далее);
• требования к дизайну — стиль, наличие брендбука, референсы;
• техническая часть — на какой платформе или CMS будет сайт, какие нужны интеграции;
• сроки по этапам и критерии приёмки каждого этапа;
• требования к хостингу, домену и безопасности сайта после запуска.

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

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

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

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

Что будет, если сайт делать вообще без ТЗ, «по ходу»?

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

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

Как ТЗ влияет на итоговую стоимость сайта?

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

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

Можно ли менять ТЗ в процессе разработки?

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

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

Есть ли интересный факт из истории технических заданий?

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

С чего начать, если раньше никогда не составлял ТЗ?

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

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