Как составить техническое задание на разработку сайта и принять результат

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

Что описывает ТЗ и чем оно отличается от брифа и прототипа

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

Бриф и прототип его не заменяют.

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

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

Если требований к платформе у вас нет, так и напишите. Исполнитель предложит вариант и обоснует его.

Как сделать требования проверяемыми и принять по ним сайт

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

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

По оценке автора той же статьи, для лендинга можно обойтись без детально зафиксированных требований. Для проекта с интеграциями это красный флаг: без записанных требований приемка держится на памяти и доброй воле.

В разделе о сдаче работы зафиксируйте:

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

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

Отдельный довод в споре: отраслевое издание называет ТЗ самостоятельным доказательством при обращении в суд. Отношения сторон опираются на главу 37 ГК РФ о договоре подряда. Суды, которые квалифицируют договор как оказание услуг, применяют нормы о подряде субсидиарно согласно статье 783 ГК РФ.

Кто пишет ТЗ и из-за чего сдвигаются сроки

Составить ТЗ может любая из сторон, но чаще это делает подрядчик на основе расчетов и проектного моделирования будущего сайта (law.ru).

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

График чаще всего ломают 3 вещи:

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

В сроки закладывайте тестирование и исправление ошибок. Без этого есть риск не уложиться.

ТЗ держится на проверяемых формулировках и согласованной приемке

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

Если задание пора превращать в рабочий документ, команда QIO поможет разобрать вашу задачу и подготовить основу для разработки сайта.