Техническое задание на разработку сайта: шаблон, который защищает от лишних доработок

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

Из-за чего сайт приходится дорабатывать после сдачи

Платные правки после сдачи чаще всего появляются не потому, что исполнитель плохой. Они появляются в местах, которые никто не записал: две стороны читают одну фразу по-разному или в документе нет фразы вовсе. Три таких места встречаются снова и снова.

Страница есть, а блока, который вы ждали, на ней нет

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

Заявка отправлена, а менеджер о ней не узнал

Форма работает, письмо уходит на почту, которую никто не открывает. Или заявка попадает в CRM без страницы и источника, и менеджер не понимает, о чём человек спрашивал. Никто не записал, куда приходит обращение и что в нём должно быть.

Спор о том, что считать правкой

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

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

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

Шаблон ТЗ на сайт: девять разделов

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

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

Слова, которых вы не понимаете (CMS, контент, подвал), попросите расшифровать списком в конце самого ТЗ. Документ, который вы не можете прочитать, вы не можете и принять.

Цель, аудитория и границы: что входит в сайт, а что нет

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

Цель сайта одной проверяемой фразой

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

Список страниц и список того, чего не будет

Для примера состав такой: главная, каталог услуг, страница каждой услуги, портфолио, контакты, страница с политикой. Структуру можно нарисовать блок-схемой: главная ведёт в услуги, услуги — на страницу услуги, оттуда — в контакты.

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

Как описать страницы и блоки, чтобы их можно было принять

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

Сценарий превращается в экран

Из сценария следует страница услуги. В ТЗ записываете блоки по порядку и действие, которого ждёте на каждом:

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

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

Экран превращается в проверку

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

Расплывчатые слова и их проверяемые замены

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

Пороги Core Web Vitals не переписывайте по памяти: текущие значения и способы замера публикует web.dev, сверяйте с ним на дату приёмки.

Факт. Core Web Vitals — набор метрик загрузки и отзывчивости страницы; определения и актуальные значения публикует документация web.dev.

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

Заявки, формы и CRM: что записать, чтобы обращения не терялись

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

Поля формы и откуда пришла заявка

Перечислите поля, отметьте обязательные и объясните, зачем каждое. Лишнее поле уменьшает число отправок, а нехватка данных заставляет менеджера перезванивать. Отдельно запишите, что вместе с заявкой передаются страница, с которой отправили форму, и UTM-метки. Назовите, кто настраивает учёт и как вы проверите его. Считать обращения можно, только когда учёт настроен.

Куда заявка попадает и что будет при сбое

Назовите получателя: CRM, почта или мессенджер. Затем сбой: если CRM недоступна, заявка не исчезает, а приходит копией на почту или отправляется повторно. Ещё одно требование: сотрудник получает уведомление, а не узнаёт о заявке при случайном заходе в систему. Как настраивается передача, смотрите в документации вашей CRM.

Чат и мессенджеры как второй канал заявок

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

Персональные данные и согласие: что вписать в ТЗ и что проверить у юриста

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

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

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

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

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

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

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

Отдельно запишите технологии: CMS, хостинг и домен. Важно, на кого они оформлены и у кого останутся доступы после сдачи. Проверьте права на фото, шрифты и тексты, взятые из чужих источников. Решите, кто пишет тексты и кто их вычитывает.

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

Запрос на изменение: как менять согласованное и не терять деньги и сроки

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

Что записать в запросе

Пять полей, по одной строке каждое:

• что меняется, со ссылкой на пункт ТЗ;
• зачем это нужно;
• как это влияет на срок;
• как это влияет на стоимость: часы и ставка из договора;
• кто подтвердил и когда.

Мелкие правки, которые входят в оплаченные часы, запишите в договоре списком. Цифры согласуйте с исполнителем заранее, не заимствуйте чужие.

Кто согласует и как быстро

С каждой стороны один человек. У заказчика это тот, кто вправе тратить деньги и утверждать решения. У исполнителя — руководитель проекта. Порядок простой:

1. Заказчик пишет запрос.
2. Исполнитель оценивает срок и часы.
3. Заказчик подтверждает письменно.
4. Работа начинается только после подтверждения.
5. ТЗ получает новую версию с номером и датой.

Сообщение в мессенджере «давайте добавим» запросом не считается. Если правки идут именно так, никто не помнит, какая версия утверждена, и цену обсуждают после выполнения.

Ошибка исполнителя или новая доработка: как их разделить

Ошибку от доработки отличает одно правило: откройте ТЗ и найдите пункт. Если в ТЗ записано одно, а на сайте другое, это дефект, и исправляет его исполнитель за свой счёт. Если в ТЗ этого нет или заказчик поменял решение, это доработка через запрос на изменение.

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

Дефект: сделано не так, как записано

В ТЗ сказано: форма на странице услуги отправляет страницу в CRM. На сайте поле страницы пустое. Это дефект.

Доработка: этого нет в ТЗ или решение изменилось

В ТЗ нет калькулятора, но на приёмке заказчик просит его добавить. Это доработка.

Условный разговор на приёмке сайта ремонта квартир, без запроса:

— Где калькулятор стоимости? — В ТЗ его не было. — Но мы же говорили по телефону. — Это новая работа, отдельная смета.

Тот же разговор с запросом на изменение:

— Нужен калькулятор. Давайте оформим запрос. — Запрос № 3: калькулятор, оценка в часах и срок. Подтверждаете? — Да. Версия ТЗ обновлена.

Спорный случай: запись можно прочитать двумя способами

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

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

Приёмка по ТЗ: договор, акт, чек-лист и первый шаг

Приёмка проходит спокойно, когда ТЗ приложено к договору подряда, а в акт приёмки идут пункты из чек-листа ТЗ. Тогда критерии приёмки проверяются при подписании акта, а не придумываются в этот момент. В договоре укажите номер версии ТЗ и приложите макеты и список страниц.

Срок на замечания и гарантийный период берите из договора и согласуйте числа заранее. Общие правила о подряде, приёмке и качестве работ изложены в главе Гражданского кодекса о подряде; точные нормы смотрите в тексте кодекса и у юриста.

Перед подписанием проверьте ТЗ по чек-листу:

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

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

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

Кто должен составлять ТЗ на сайт: заказчик или исполнитель?

Чаще черновик пишет исполнитель по вашему брифу, а вы проверяете, что цели, список страниц и пункты про заявки записаны так, как вы их понимаете. Подписывают оба: так ни одна сторона не скажет «я думал иначе».

Чем техническое задание отличается от брифа и прототипа?

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

Нужно ли писать ТЗ на сайт по ГОСТ?

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

Можно ли составить ТЗ на сайт с помощью нейросети?

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