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