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

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

Без этой границы спор упирается в память и характер. С ней — в документ.

Что делает ТЗ бесполезным

Три формулировки, которые встречаются чаще всего и не значат ничего:

• «Современный дизайн» — у сторон разные представления, и обе правы.
• «Сайт должен быть удобным и быстрым» — без порогов это не требование, а пожелание.
• «Функционал стандартный для интернет-магазина» — стандартного набора не существует.

Заменяются они одинаково — конкретикой, которую можно проверить:

• «Дизайн по референсам: [три ссылки]. Основной цвет — фирменный, шрифт — заголовки Х, текст Y».
• «На мобильном основной контент главной появляется за 2,5 секунды при проверке в PageSpeed Insights».
• «Каталог: фильтр по трём параметрам, сортировка по цене, корзина, оформление без регистрации, оплата — эквайринг Х».

Что должно быть внутри

1. Задача и результат. Зачем сайт нужен бизнесу и что считается успехом. Один абзац, но он определяет решения по всем спорным местам.

2. Структура. Полный список страниц и разделов. Не «раздел услуг», а перечень услуг. Именно здесь чаще всего вылезает объём, о котором не договаривались.

3. Сценарии. Как человек проходит путь до целевого действия. Три-четыре основных сценария словами: «Посетитель приходит из поиска на страницу услуги → видит цену → нажимает "Рассчитать" → заполняет форму из трёх полей → получает подтверждение на экране и письмо».

4. Состояния, а не только страницы. Самый пропускаемый пункт и самый дорогой. У каждой формы есть состояния: пустая, заполняется, ошибка валидации, отправляется, успех, отказ сервера. У каталога — пустой результат фильтра. У списка — нулевое состояние. Их не описывают, а потом обнаруживают на тестировании.

5. Контент: кто и к какой дате. Тексты, фотографии, логотип в векторе, данные каталога. Указать ответственного поимённо и дату. Отсутствие этого пункта — причина примерно половины сдвигов графика.

6. Интеграции. Конкретные системы, направление обмена, что происходит при недоступности. «Интеграция с CRM» — не требование. «При отправке формы создаётся лид в Битрикс24 с полями A, B, C; при недоступности API заявка сохраняется и отправляется письмом» — требование.

7. Технические рамки. CMS, хостинг, браузеры и устройства, на которых проверяем, требования к доступности, если они есть.

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

9. Количество итераций. «Две итерации правок на макет» — не жёсткость, а защита обеих сторон. Без ограничения согласование не заканчивается никогда.

10. Права и доступы. Кому принадлежат домен, хостинг, репозиторий, макеты и админка после оплаты. Пункт скучный ровно до того момента, когда вы решите сменить подрядчика.

Как менять ТЗ по ходу

Изменения будут — это нормально, а не признак плохого планирования. Плохо, когда они не оформляются.

Рабочая практика: любое изменение объёма оформляется отдельно — что добавляется, сколько это стоит, на сколько сдвигает срок. Подписывается до начала работ по нему. Три строки в переписке достаточно, если обе стороны их подтвердили.

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

Что делать, если ТЗ писать некому

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

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

Второй — начать с обсуждения структуры и сценариев вместе с подрядчиком, а ТЗ получить как результат первого этапа. У нас подготовка структуры входит в проект и занимает 2–3 дня; всё, что решено на этом этапе, дешевле, чем то же решение, принятое в вёрстке.

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

Состав работ и сроки по типам проектов — в прайсе. Смежный материал — «Сколько времени занимает разработка сайта».

Оригинал опубликован на verstalabs.ru.