Два подрядчика оценивают один и тот же «корпоративный сайт с каталогом» и называют суммы, которые отличаются в разы. Ни один не ошибся: каждый просто представил себе свой сайт. Техническое задание на разработку сайта убирает эту неопределённость. Оно описывает, что именно будет сделано, как это должно работать и по каким признакам работу примут.
Разберём, зачем нужно ТЗ на сайт, чем оно отличается от брифа и прототипа, какие разделы в нём должны быть, кто его пишет и что делать, когда требования меняются по ходу проекта.
Зачем нужно техническое задание
У ТЗ три практические задачи, и все три касаются денег и нервов.
- Оценка цены и сроков. Без перечня страниц, функций и интеграций подрядчик закладывает риски в цену или считает по минимуму, а потом выставляет доплаты. С ТЗ оценки разных агентств можно сравнивать между собой.
- Приёмка. Когда сайт готов, нужно понять, сделано ли то, о чём договаривались. ТЗ отвечает на этот вопрос по пунктам, а не по ощущениям.
- Споры. Если стороны по-разному поняли задачу, ТЗ — документ, к которому обе возвращаются. Обычно его делают приложением к договору, и тогда оно имеет юридический вес.
Есть и четвёртая, менее очевидная польза. Пока пишется ТЗ, заказчик сам впервые проговаривает, что ему нужно, и часто отказывается от части функций или находит то, о чём не подумал.
Бриф, ТЗ и прототип: в чём разница
Эти три документа часто путают или пытаются заменить один другим. На деле они отвечают на разные вопросы и появляются в проекте по очереди.
| Бриф | Техническое задание | Прототип | |
|---|---|---|---|
| Отвечает на вопрос | Какая задача у бизнеса | Что и как должен делать сайт | Как это выглядит на экранах |
| Кто заполняет | Заказчик | Чаще подрядчик вместе с заказчиком | Подрядчик |
| Объём | Несколько страниц анкеты | От нескольких до десятков страниц | Схемы ключевых экранов |
| Для чего нужен | Первичная оценка и разговор | Точная оценка, договор, приёмка | Проверка логики до дизайна |
Бриф на разработку сайта — стартовая точка: чем занимается компания, кто клиенты, зачем нужен сайт, какие есть примеры и ограничения. По брифу можно дать вилку, но не точную цену. ТЗ превращает задачу в требования. Прототип показывает требования визуально и часто входит в ТЗ или идёт рядом с ним: одну и ту же форму заявки проще согласовать на схеме, чем в трёх абзацах текста.
Структура ТЗ: что должно быть в документе
Единого ГОСТа для коммерческих сайтов нет, и это нормально. Структура ТЗ зависит от проекта, но набор разделов у большинства сайтов похож. Используйте его как чек-лист, когда составляете документ сами или проверяете то, что прислал подрядчик.
- Цели и аудитория. Зачем сайт бизнесу, какие действия должен совершить посетитель, кто он и с какого устройства чаще заходит.
- Структура и страницы. Карта сайта, типы страниц и что на каждой из них: главная, каталог, карточка, услуга, контакты, блог.
- Функции. Формы, фильтры, поиск, корзина, оплата, личный кабинет — каждая с описанием сценария.
- Роли и админка. Кто управляет сайтом, какие у кого права, что можно менять без программиста.
- Интеграции. CRM, 1С, склад, платёжные системы, службы доставки, рассылки: что передаётся, в какую сторону и как часто.
- Контент. Кто готовит тексты, фото и видео, кто переносит данные со старого сайта, в каком виде всё это передаётся.
- Требования к дизайну. Фирменный стиль, брендбук, примеры, что нравится и что точно не подходит, сколько вариантов концепции.
- Адаптив. Какие устройства и браузеры поддерживаются, что меняется в мобильной версии.
- SEO и аналитика. Адреса страниц, мета-теги, перенос старых URL и редиректы, цели в Яндекс Метрике.
- Производительность и безопасность. Ожидаемая скорость загрузки, нагрузка, защита форм и админки, резервные копии.
- Хостинг и домен. Где будет жить сайт, на кого оформлены домен и сервер, кто за них платит.
- Критерии приёмки. Как проверяется каждая функция и что считается готовым результатом.
Последний пункт самый важный и чаще всего пропускается. Функция без критерия приёмки — повод для спора, а не требование. «Удобный поиск» проверить нельзя. «Поиск находит товар по названию и артикулу, исправляет опечатки и показывает подсказки после третьего символа» — можно.
ТЗ для интернет-магазина
У магазина к общему списку добавляется своё. Описывают структуру каталога и фильтры, источник товаров и остатков, логику цен и скидок, способы оплаты и доставки, статусы заказа и уведомления покупателю. Отдельно — что происходит с заказом после оформления: куда он уходит, кто его обрабатывает, как синхронизируется с учётной системой. Эти сценарии определяют большую часть работы, и без них оценка магазина почти всегда неточна.
Уровень детализации: короткое или подробное ТЗ
Писать сорок страниц для лендинга бессмысленно, а описывать личный кабинет одним абзацем опасно. Детализация зависит от сложности и цены ошибки.
Короткого ТЗ хватает, когда сайт в основном информационный: лендинг, сайт-визитка, небольшой корпоративный сайт без интеграций. Достаточно целей, списка страниц с блоками, форм с описанием, куда уходят заявки, требований к дизайну и адаптиву, плана по контенту и аналитике.
Подробное ТЗ нужно, когда есть логика, которую легко понять по-разному: интернет-магазин, личный кабинет, интеграции с 1С и CRM, разные роли пользователей, расчёты и калькуляторы. Здесь каждая функция описывается сценарием: кто, что делает, что видит, что происходит при ошибке.
Подробно описывать стоит то, где ошибка дорогая: интеграции, оплату, личный кабинет и роли.
Удобное правило: чем больше на сайте данных, которые куда-то передаются, тем подробнее ТЗ. Тексты на странице «О компании» можно поправить за час, а неправильно понятый обмен заказами с учётной системой — переделывать неделями.
Кто пишет ТЗ: заказчик или подрядчик
Вопрос «кто пишет ТЗ» на практике решается так: заказчик знает бизнес, подрядчик знает, как превратить его в требования к сайту. Поэтому хорошее техническое задание почти всегда пишется вместе.
Заказчик может составить ТЗ сам, если у него есть опыт или технический специалист в штате. Такой документ полезен для сравнения подрядчиков, но обычно его всё равно дорабатывают: в нём хорошо описано «что хочется» и слабее — «как это будет работать».
Чаще ТЗ появляется у подрядчика на отдельном этапе аналитики. В Sphere первый этап любого проекта — аналитика, структура и смыслы: разбираемся в рынке, аудитории и конкурентах, продумываем каждый экран. Результат этого этапа и становится основой требований к сайту. Как мы работаем по этапам, можно посмотреть на странице о компании.
Как составить ТЗ на сайт, если вы делаете это впервые
- Сформулируйте цель. Одной фразой: что сайт должен давать бизнесу — заявки, продажи, снижение нагрузки на менеджеров.
- Опишите посетителей и их сценарии. Кто приходит, что ищет, какое действие вы от него ждёте.
- Соберите список страниц и функций. Начните с обязательного, отдельно отметьте то, что можно сделать позже.
- Перечислите системы, с которыми сайт должен работать. CRM, 1С, склад, оплата, доставка.
- Решите, кто готовит контент. Тексты, фото, перенос каталога.
- Обсудите документ с подрядчиком. Его вопросы покажут, где требования понятны не до конца.
Частые ошибки в техническом задании
Большинство проблем с ТЗ повторяются от проекта к проекту. Их проще заметить заранее, чем исправлять на приёмке.
Ещё две ошибки встречаются реже, но обходятся дорого. Первая — не указать, кто отвечает за контент: сайт готов, а наполнять его нечем. Вторая — забыть про старый сайт: без плана переноса страниц и редиректов новый сайт теряет накопленный поисковый трафик.
Как ТЗ меняется по ходу проекта
Техническое задание, которое ни разу не поменялось, — редкость. В процессе дизайна выясняется, что сценарий удобнее устроить иначе. После первых тестов заказчик понимает, что фильтр нужен по другому признаку. Это нормально: менять требования можно, важно делать это по правилам.
Порядок изменений стоит описать заранее, в ТЗ или договоре:
- Как оформляется изменение. Письменный запрос с описанием, что меняется и зачем.
- Как оно оценивается. Подрядчик называет, сколько времени и денег займёт правка и как она сдвинет сроки.
- Кто согласует. Одно ответственное лицо со стороны заказчика, чтобы правки не приходили из трёх отделов с противоречиями.
- Где фиксируется. Новая версия ТЗ или дополнение к нему, чтобы на приёмке проверяли актуальные требования.
Крупные идеи, которые появляются по ходу работы, удобно не вливать в текущий объём, а отложить во вторую очередь. Так первый релиз выходит в срок, а новое делается после запуска, уже с данными о том, как посетители пользуются сайтом. Как такие решения выглядят в готовых проектах, можно посмотреть в разделе проектов.
Частые вопросы
Обязательно ли ТЗ для небольшого сайта?
Объёмный документ не нужен, но короткое ТЗ стоит составить даже для лендинга: цель, список блоков, формы и куда уходят заявки, требования к адаптиву и аналитике. Это защищает обе стороны на приёмке.
Можно ли сделать ТЗ по примеру технического задания из интернета?
Пример технического задания полезен как список разделов, чтобы ничего не забыть. Но содержание всё равно придётся писать под свой бизнес: чужие требования описывают чужие процессы.
Кто пишет ТЗ на сайт?
Чаще всего подрядчик на этапе аналитики вместе с заказчиком. Заказчик даёт знание бизнеса, клиентов и процессов, подрядчик превращает их в требования, сценарии и критерии приёмки.
Можно ли менять ТЗ после начала разработки?
Да, если изменения оформляются по правилам: письменный запрос, оценка влияния на цену и сроки, согласование и новая версия документа. Крупные идеи лучше переносить во вторую очередь после запуска.
Чем бриф отличается от ТЗ?
Бриф описывает задачу бизнеса и нужен для первого разговора и примерной оценки. ТЗ описывает требования к сайту и нужно для точной оценки, договора и приёмки.
