ТЗ на сайт легко принять за бумагу для подрядчика. Подписываете её вы, и принимать по ней работу тоже вам. Если пункты размытые, спор о результате начнётся после оплаты. Дальше - блоки ТЗ и как проверить каждый без технического бэкграунда.
Зачем заказчику ТЗ, если подрядчик «и так понял»
ТЗ нужно прежде всего вам: оно фиксирует объём работ, по которому принимают результат. Пока требований нет на бумаге, «поняли одинаково» живёт до первой приёмки. А исправлять на этом этапе дорого.
Масштаб показывает исследование PMI 2014 года. В опросе 2 066 руководителей проектов и бизнес-аналитиков (май 2014 года) 47% неуспешных проектов не достигали целей из-за слабого управления требованиями. Речь о доле неуспешных проектов, а не о всех проектах. Это про проекты в целом, но логика та же: расплывчатые требования дают расплывчатый результат.
Где заканчивается бриф и начинается ТЗ
Бриф - вход, ТЗ - выход, договор - рамки сделки. В брифе вы рассказываете, что у вас есть и чего вы хотите. В ТЗ подрядчик превращает ваши ответы в конкретные требования, а вы их согласуете. Если эти документы путают, ТЗ выходит копией брифа или списком пожеланий.
Договор отвечает на другие вопросы: сколько стоит, когда сдача, кто за что отвечает. ТЗ обычно идёт к нему приложением. Сроки и этапы разобраны в статье как фиксируются сроки и этапы разработки.
Из каких блоков состоит ТЗ на сайт
Единого обязательного перечня нет: ни ГОСТ, ни ISO его не задают, а набор блоков - практика студий.
Цели, метрики и аудитория
Зачем сайт и что считаем результатом: заявку, звонок, заказ? Кто ваш посетитель и что он должен сделать? Без этого не понять, какие страницы нужны и как оценивать результат.
Структура и функции
Страницы и сценарии: что человек делает шаг за шагом до заявки или оплаты. Если формат ещё не выбран, поможет статья лендинг или многостраничный сайт: что выбрать вашему бизнесу.
Контент, дизайн и интеграции
Кто готовит тексты и фотографии, сколько макетов входит в работу и сколько раундов правок. И куда попадают заявки: в CRM, на почту или в мессенджер.
Технические требования и приёмка
Домен и хостинг, мобильная версия, скорость, аналитика. И главное: что считается сданной работой и в каком виде вы её получите.
Что в ГОСТ 34.602-2020 есть, а чего в нём нет
ГОСТ 34.602-2020 - действующий стандарт на техническое задание, с 1 января 2022 года он заменил ГОСТ 34.602-89. Но написан он про автоматизированные системы, а не про сайты. Для сайта его применяют добровольно и частично, по аналогии. Стандарт есть в реестре Росстандарта.
Из десяти разделов пригодятся два: состав работ (этапы и сроки) и порядок приёмки. Требований к контенту, дизайну, SEO, домену и хостингу в нём нет.
Пункт 3.4 перечисляет шесть характеристик хорошего требования, о них ниже. Пункт 5.3 требует указывать значения с допусками или с минимумом и максимумом. Если точного значения пока нет, в ТЗ пишут, что оно уточняется и согласовывается. Формулировка законная, но именно она часто становится поводом для спора при приёмке.
Что будет, если в ТЗ общие слова
Спор на приёмке. Если пункт нельзя проверить, сравнивать результат не с чем.
Размытость видно по формулировкам: «современный дизайн», «удобный интерфейс», «интуитивно понятно», «как у конкурента», «и т. д.», «при необходимости доработаем». Проверить их нечем, и по п. 3.4 такой пункт не проходит по проверяемости: скорее пожелание, чем требование.
Оборачивается это доплатами и переделками, а из чего складывается цена, разобрано в статье сколько стоит сайт и из чего складывается цена.
Как отличить проверяемое требование от пожелания
Смотрите не на объём документа, а на проверяемость каждого пункта. Шесть характеристик из п. 3.4 ГОСТ 34.602-2020 в переводе на обычный язык:
- единичность: один пункт описывает одно требование, а не три сразу;
- непротиворечивость: пункты не спорят друг с другом;
- актуальность: требование нужно вашей задаче, а не взято из чужого проекта;
- выполнимость: это реально сделать в заявленные сроки и бюджет;
- проверяемость: понятно, как убедиться, что требование выполнено;
- однозначность: пункт нельзя прочитать двумя способами.
Вместо «удобная форма связи» напишите: «форма с полями «имя» и «телефон»; после отправки заявка попадает в CRM, посетитель видит подтверждение». Такой пункт проверить легко: отправили форму, нашли заявку.
Пять вопросов подрядчику перед подписанием
Проверить это проще всего в разговоре. Задайте вопросы до подписания и зафиксируйте ответы документом или протоколом, а не в переписке.
- Кто пользователь сайта и что он должен сделать?
- Что считается результатом каждой функции?
- Что входит в объём работ, а что нет?
- Как будет выглядеть приёмка?
- Что происходит, если объём изменится?
Если подрядчика ещё нет, начните с как выбрать подрядчика на разработку сайта.
📩 Планируете обновить или переделать сайт? Посчитаем сроки и стоимость: оставить заявку.
