Когда проект сайта идёт плохо, причина почти всегда одна: стороны по-разному понимали, что именно должно получиться. Заказчик думал, что «личный кабинет» подразумевает историю заказов и повтор покупки, а разработчик сделал только вход и смену пароля. Формально никто не ошибся, но результат не устраивает обоих. Техническое задание существует, чтобы такие расхождения исчезли до начала работ.
ТЗ — это договорённость, записанная языком, понятным и бизнесу, и разработчикам. Оно отвечает на вопросы: что мы делаем, из каких частей это состоит, как должно работать, по каким признакам мы поймём, что работа выполнена. Хорошее ТЗ защищает заказчика от недоделок, а студию — от бесконечных пожеланий, возникающих в процессе.
Ниже разберём назначение документа, его структуру по разделам, способы формулировать требования так, чтобы их можно было проверить, и ошибки, которые встречаются снова и снова. Статья пригодится и тем, кто пишет ТЗ самостоятельно, и тем, кто получает его от студии и хочет понимать, что в нём должно быть.
Зачем нужно техническое задание
У документа три основные роли.
Согласование ожиданий. Пока задача существует только в головах, каждый участник представляет свою версию. Письменное ТЗ вынуждает прояснить детали и обнаружить противоречия на старте, когда исправление ничего не стоит.
Основа для оценки. Стоимость и срок рассчитываются по ТЗ. Без него смета остаётся приблизительной и меняется по ходу проекта. О том, как складывается цена, читайте в статье «Из чего складывается стоимость разработки сайта».
Критерий приёмки. При сдаче работ сравнивают результат с ТЗ: всё ли реализовано, соответствует ли описанию. Это превращает спор «мне не нравится» в проверяемый вопрос «сделано ли то, о чём договорились». О том, как проходит приёмка, — в материале «Как принимать работу по этапам».
ТЗ и бриф: в чём разница
Бриф описывает бизнес-задачу, аудиторию и пожелания к стилю. Он отвечает на вопрос «зачем и для кого». ТЗ переводит это в инженерные требования: «что именно делаем и как оно работает». Бриф — вход, ТЗ — выход этапа аналитики. Если вы ещё не составили бриф, начните с него: «Как подготовить бриф на дизайн сайта».
Кто пишет ТЗ
Идеальный вариант — совместная работа. Заказчик знает бизнес и клиентов, студия знает технологии и типичные подводные камни. На практике ТЗ чаще готовит аналитик или менеджер студии по результатам интервью, а заказчик проверяет и утверждает документ. Это разумно: человек, не знакомый с веб-разработкой, не может предусмотреть все технические нюансы.
Если вы пишете задание самостоятельно, не стремитесь к идеальной форме. Лучше неформальный, но подробный документ, чем аккуратный шаблон с пустыми разделами. Студия поможет довести его до нужной структуры.
Структура технического задания
Единого стандарта для сайтов нет, но удачные документы строятся по схожей схеме. Рассмотрим разделы по порядку.
1. Общие сведения
Название проекта, описание компании, краткое изложение задачи, термины и определения. Раздел терминов недооценивают, а зря: слова «каталог», «лид», «личный кабинет» разные люди понимают по-разному, и закрепление значений снимает половину недоразумений.
2. Цели и задачи сайта
Что должен давать сайт бизнесу, каковы метрики успеха. Например: увеличить число заявок через форму, снизить нагрузку на отдел продаж за счёт подробного описания услуг, повысить доверие за счёт кейсов и отзывов. Формулируйте измеримо, как показано в статье о брифе.
3. Целевая аудитория и сценарии
Кто пользуется сайтом, с какими задачами и с каких устройств. Для каждого основного сегмента полезно описать сценарий: откуда человек пришёл, что ищет, какое действие должен совершить. Подробнее о построении сценариев — в статье «Пользовательские сценарии: как их проектировать».
4. Структура сайта
Карта разделов и страниц с иерархией. Для каждой страницы или типа страницы указывается назначение и состав блоков. Здесь же описывается навигация: главное меню, подвал, хлебные крошки. Принципы построения навигации разобраны в материале «Навигация по сайту: ошибки, из-за которых уходят клиенты». Разделы корпоративного сайта подробно перечислены в статье «Корпоративный сайт: обязательные разделы и страницы».
5. Функциональные требования
Самый объёмный раздел. Для каждой функции описывается, что делает система, какие данные принимает и выдаёт, как ведёт себя в разных ситуациях. Формулировать лучше в виде конкретных правил.
Типичный перечень функций:
- формы заявок: поля, обязательность, проверка данных, куда уходит заявка, что видит пользователь после отправки (о формах — в статье «Формы обратной связи: как сделать их удобными»);
- каталог: структура категорий, фильтры, сортировка, поиск, карточка элемента;
- корзина и оформление заказа, способы оплаты и доставки;
- личный кабинет: регистрация, авторизация, профиль, история;
- блог или новости, управление публикациями;
- многоязычность и региональность;
- интеграции с CRM, учётными и платёжными системами, рассылками, мессенджерами.
6. Требования к дизайну
Стилистика, референсы, наличие фирменного стиля, количество уникальных макетов, адаптивность, анимации. Указывается, на какие разрешения экранов и устройства нужна адаптация. Если есть брендбук — он прикладывается. Важно описать формат согласования: сколько раундов правок входит, кто принимает решение.
7. Требования к администрированию
Как будет редактироваться контент. Какие роли и права доступа нужны: администратор, редактор, менеджер. Какие разделы сотрудники должны менять без помощи разработчиков. Здесь же указывается выбранная система управления; о выборе читайте в статье «Как выбрать CMS для корпоративного сайта».
8. Нефункциональные требования
Эта часть описывает «как хорошо должно работать», а не «что должно быть». Сюда входят:
- Производительность: допустимое время загрузки, оценки по метрикам скорости. См. статью про скорость загрузки.
- Совместимость: поддерживаемые браузеры и устройства.
- Безопасность: защита данных, шифрование соединения, резервное копирование. Основы разобраны в материале «SSL-сертификат и базовая безопасность сайта».
- Доступность: соответствие рекомендациям по доступности, см. статью о доступности.
- Нагрузка: ожидаемая посещаемость и запас прочности.
- Масштабируемость: как сайт будет расти.
9. SEO-требования
Структура адресов, шаблоны заголовков и описаний, микроразметка, карта сайта, настройки индексации, перенаправления со старого сайта. Эти вещи легче заложить в начале, чем исправлять потом. Подробнее — в статье «SEO на этапе разработки».
10. Контент и наполнение
Кто готовит тексты, изображения, видео, документы, в какие сроки и в каком виде их передаёт. Нужна ли миграция данных со старого сайта. Это раздел-«страховка» от срыва сроков из-за неготового контента.
11. Этапы, сроки и порядок приёмки
Календарный план с контрольными точками, критерии готовности каждого этапа, порядок передачи материалов и согласований. О стандартной схеме работы можно прочитать на странице этапов.
12. Поддержка и гарантии
Что происходит после запуска: гарантийный период, обучение сотрудников, условия поддержки. Подробнее о наших условиях — на странице гарантий и в услуге поддержки сайтов.
Как формулировать требования проверяемо
Главное качество хорошего ТЗ — проверяемость. Каждое требование должно допускать ответ «выполнено» или «не выполнено». Сравните формулировки.
| Размытое требование | Проверяемое требование |
|---|---|
| Сайт должен быстро загружаться | Главная страница на мобильном устройстве становится интерактивной не дольше трёх секунд при обычном мобильном соединении |
| Удобная форма заявки | Форма содержит не более четырёх полей, обязательны имя и контакт, после отправки показывается подтверждение, заявка приходит на почту отдела продаж и в CRM |
| Современный дизайн | Дизайн выполнен в стилистике референсов из приложения, использует фирменные цвета и шрифт, согласован в два раунда правок |
| Адаптивность | Сайт корректно отображается на экранах от трёхсот двадцати пикселей по ширине; проверка на указанном перечне устройств и браузеров |
| Простое управление | Сотрудник без навыков программирования может добавить новость с изображением и опубликовать её не более чем за пять минут |
Приём прост: если после прочтения требования нельзя придумать способ проверить его, оно слишком расплывчато. Добавьте число, условие или наблюдаемый результат.
Приоритеты требований
Разделяйте обязательное, желательное и возможное в будущем. Один из удобных методов — три уровня: «должно быть», «хорошо бы», «потом». Это помогает уложиться в бюджет и при необходимости урезать объём, не теряя главного. Ещё один плюс: на старте не нужно реализовывать всё сразу — можно запустить основу и развивать сайт поэтапно.
Пример фрагмента ТЗ
Чтобы стало нагляднее, приведём упрощённый пример описания одной функции — формы расчёта стоимости.
- Назначение: получение заявок от посетителей, заинтересованных в расчёте.
- Расположение: главная страница, страницы услуг, отдельная страница «Рассчитать стоимость».
- Поля: имя (обязательное), телефон или почта (одно из двух обязательно), тип услуги (выпадающий список), комментарий (необязательное).
- Проверка: формат контактных данных, защита от автоматических отправок.
- После отправки: пользователь видит сообщение о принятой заявке; письмо уходит на адрес отдела продаж; данные попадают в CRM с пометкой источника страницы.
- Ошибки: при сбое отправки пользователь видит понятное сообщение, введённые данные сохраняются.
- Критерий приёмки: заявка из каждого места размещения доходит до отдела продаж и фиксируется в CRM; на мобильных экранах форма использует подходящие типы клавиатуры.
Обратите внимание на структуру: назначение, место, состав, поведение, ошибки, критерий. Такое описание можно использовать как шаблон для любой функции сайта.
Типичные ошибки при составлении ТЗ
Слишком общий документ
ТЗ на две страницы вида «сделать красивый сайт с каталогом и формой» не защищает никого. При первом же споре выяснится, что каждый понимал задачу по-своему. Объём документа должен соответствовать сложности проекта: для лендинга достаточно нескольких страниц, для интернет-магазина с интеграциями — десятков.
Слишком подробный дизайн в ТЗ
Обратная крайность — описывать каждый пиксель словами. Визуальные решения лучше фиксировать в макетах, а в ТЗ оставить принципы и ограничения. Иначе документ устареет при первой же итерации дизайна.
Смешение целей и решений
Заказчик пишет: «Нужен слайдер на главной», хотя на самом деле хочет «показать три главных предложения». Описывайте цель, а решение оставьте специалистам: они предложат вариант лучше. Часто то, что просят, оказывается не лучшим способом достичь задуманного, как, например, с каруселями, которые мало кто листает.
Забытые роли и права
Кто может менять цены? Кто видит заявки? Кто публикует статьи? Без описания ролей администрирование превращается в хаос, а после запуска начинаются просьбы «поменять права».
Нет описания интеграций
Фраза «интеграция с CRM» не говорит ничего. Какая система? Какие данные передаются в какую сторону? Как часто? Что делать при сбое? Есть ли у стороннего сервиса документация? Интеграции — самый частый источник удорожания, поэтому их нужно описывать подробно.
Игнорирование контента
Сайт проектируется под несуществующие тексты и изображения, потом оказывается, что заголовки не помещаются, а фотографий нет. Согласуйте объём и сроки подготовки материалов заранее.
Отсутствие критериев приёмки
Без них спор о качестве бесконечен. Для каждого этапа и функции должно быть понятно, что считается выполненной работой.
Копирование чужого ТЗ
Шаблон из интернета полезен как чек-лист, но не как готовый документ. Он не знает вашу аудиторию, бизнес-процессы и особенности. Скопированные разделы часто содержат требования, которые вам не нужны, и не содержат тех, что действительно важны.
Неактуальный документ
В ходе работы требования меняются. Если изменения обсуждаются в переписке и не попадают в ТЗ, через месяц никто не вспомнит, что и когда решили. Любая правка должна фиксироваться с оценкой влияния на сроки и стоимость.
Как работать с ТЗ в процессе проекта
Документ не лежит мёртвым грузом. Он живёт вместе с проектом.
- Версионность. Каждая редакция имеет номер и перечень изменений.
- Единый источник истины. Если есть противоречие между перепиской и ТЗ, действует последняя утверждённая версия.
- Управление изменениями. Новые требования оформляются как дополнения с указанием влияния на сроки и бюджет.
- Регулярная сверка. На каждом этапе стороны проверяют, что реализованное соответствует документу.
Такая дисциплина кажется бюрократией, пока не возникнет первый спор. После него она кажется удачей. Хорошая студия сама предлагает такой порядок, и мы в Mevero работаем именно так: фиксируем договорённости, согласуем изменения и показываем промежуточные результаты на каждой контрольной точке.
Нужно ли ТЗ для небольшого проекта
Да, но формат можно упростить. Для лендинга или сайта-визитки достаточно короткого документа: цель, структура экрана за экраном, перечень блоков, форма и её поведение, требования к скорости и адаптивности, перечень материалов от заказчика, порядок приёмки. Он займёт несколько страниц и сэкономит недели. Для одностраничных проектов можно ориентироваться на материал о разработке лендингов, а для крупных порталов и интернет-магазинов — на описание услуг корпоративных сайтов и интернет-магазинов.
Итоги
Техническое задание — не бюрократическая формальность, а инструмент, который делает проект управляемым. Он фиксирует цели, структуру, функции и критерии приёмки, помогает точно оценить стоимость и сроки и защищает обе стороны от недопонимания.
Запомните основные принципы: описывайте цель, а не только решение; формулируйте проверяемо; прописывайте исключения и роли; детально разбирайте интеграции; фиксируйте изменения; согласуйте контент. Если нужна помощь в подготовке задания или вы хотите проверить уже имеющийся документ, напишите нам через страницу контактов — мы разберём вашу задачу и предложим понятную структуру работ.
