Как составить техническое задание на сайт

Зачем вообще нужно техническое задание

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

Хорошее техническое задание решает сразу несколько задач:

• Фиксирует ожидания. Заказчик и исполнитель одинаково понимают, что именно будет сделано и как это будет работать.
• Позволяет точно оценить проект. Без ТЗ любая смета — это прикидка «на глаз» с большим запасом на риски, а значит, вы переплачиваете за неопределённость.
• Даёт критерии приёмки. Когда работа сдана, вы сверяете результат с документом, а не спорите о том, «что имелось в виду».
• Защищает обе стороны. Если в процессе появляются новые пожелания, их легко отделить от исходного объёма и оценить отдельно.
• Упрощает смену подрядчика. Если по какой-то причине придётся передать проект другой команде, ТЗ станет отправной точкой и сэкономит недели.

В нашей практике проекты с проработанным заданием почти всегда укладываются в согласованный бюджет, а вот проекты «на доверии» регулярно превращаются в бесконечную череду доработок.

Кто должен писать ТЗ

Частый вопрос: кто отвечает за техническое задание — заказчик или разработчик? Правильный ответ — обе стороны, но с разными ролями.

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

Поэтому оптимальная схема выглядит так:

1. Заказчик готовит бриф — описание задачи на понятном ему языке.
2. Исполнитель проводит интервью, задаёт уточняющие вопросы, изучает конкурентов и аудиторию.
3. Аналитик или менеджер проекта на стороне исполнителя пишет ТЗ.
4. Заказчик читает документ, вносит правки, задаёт вопросы.
5. Стороны подписывают финальную версию, и она становится приложением к договору.

Если вы небольшая компания и делаете простой сайт-визитку, можно обойтись брифом и коротким перечнем страниц. Но для интернет-магазина, корпоративного портала или сервиса с личным кабинетом полноценное ТЗ обязательно. Многие агентства, включая КомРА, выделяют написание задания в отдельный этап — аналитику, — и это окупается на всех последующих стадиях.

Структура технического задания

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

Общие сведения о проекте

Короткое описание компании, её продуктов и целей сайта. Здесь важно ответить на вопрос «зачем»: продавать товары, собирать заявки, повышать узнаваемость бренда, снижать нагрузку на колл-центр. От цели зависит всё остальное — от структуры до выбора CMS.

Целевая аудитория

Кто будет пользоваться сайтом: возраст, род занятий, с каких устройств заходят, что ищут, что их останавливает от покупки. Если у компании несколько сегментов клиентов (например, розница и опт), опишите каждый.

Структура сайта

Перечень всех страниц и разделов, лучше в виде дерева. Для каждого типа страниц — какие блоки на ней будут. Например, карточка товара: название, галерея фото, цена, наличие, кнопка «В корзину», характеристики, описание, отзывы, похожие товары.

Функциональные требования

Что сайт должен уметь делать: поиск, фильтры каталога, корзина, оформление заказа, личный кабинет, онлайн-оплата, калькулятор стоимости, формы обратной связи, рассылки. Для каждой функции — описание того, как она работает с точки зрения пользователя.

Требования к дизайну

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

Требования к системе управления

На какой CMS делается сайт или почему нужна разработка с нуля. Что должен уметь редактировать администратор самостоятельно: тексты, баннеры, товары, цены, мета-теги.

Интеграции

Связь с 1С, CRM, складской системой, платёжными сервисами, службами доставки, сервисами рассылок, IP-телефонией. Для каждой интеграции — направление обмена данными и частота синхронизации.

Технические требования

Хостинг, поддерживаемые браузеры, требования к скорости загрузки, безопасности, резервному копированию, нагрузке.

Требования к SEO

Человекопонятные адреса страниц, управление мета-тегами, автоматическая генерация карты сайта, настройка robots.txt, микроразметка, корректные редиректы, отсутствие дублей.

Контент

Кто готовит тексты, фотографии, описания товаров. Нужен ли перенос контента со старого сайта и в каком объёме.

Порядок сдачи и приёмки

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

Как формулировать требования

Самая сложная часть ТЗ — не структура, а формулировки. Одна и та же мысль может быть записана так, что её невозможно проверить, или так, что результат однозначен.

Сравните:

• Плохо: «Сайт должен быстро загружаться». Хорошо: «Главная страница и карточка товара загружаются на мобильном интернете за время, при котором оценка в Google PageSpeed Insights для мобильных не ниже 80 баллов».
• Плохо: «Удобный поиск». Хорошо: «Поиск работает по названию и артикулу товара, исправляет опечатки, показывает подсказки после ввода трёх символов, выводит результаты с фото и ценой».
• Плохо: «Современный дизайн». Хорошо: «Минималистичный дизайн в фирменных цветах, крупная типографика, много воздуха; ориентиры — сайты из приложения с комментариями».
• Плохо: «Интеграция с 1С». Хорошо: «Из 1С на сайт раз в час выгружаются товары, цены и остатки; с сайта в 1С сразу после оформления передаются заказы со статусом "Новый"».

Главное правило: каждое требование должно быть проверяемым. Если вы не можете придумать способ проверить, выполнено ли требование, — его надо переписать.

Совет: избегайте слов «удобный», «красивый», «современный», «быстрый», «интуитивный» без расшифровки. Это оценочные суждения, и у заказчика с исполнителем они почти всегда разные.

Ещё одна полезная практика — описывать сценарии. Вместо перечня функций расскажите, как пользователь проходит путь: «Посетитель заходит в каталог, выбирает категорию, фильтрует по цене и бренду, открывает карточку, добавляет товар в корзину, оформляет заказ без регистрации, выбирает доставку курьером, оплачивает картой, получает письмо с подтверждением». Такой сценарий сразу выявляет недостающие элементы: а что, если товара нет в наличии? А можно ли изменить количество в корзине? А какое письмо придёт, если оплата не прошла?

Прототип как часть задания

Текстовое описание страниц хорошо, но визуальная схема лучше. Прототип — это чёрно-белый макет страницы, на котором показано расположение блоков без проработки дизайна. Он помогает заказчику увидеть будущий сайт ещё до начала дизайна и вовремя заметить, что, например, на главной странице нет блока с преимуществами, а в карточке товара не хватает информации о доставке.

Прототипы обычно делают для ключевых типов страниц:

• главная;
• страница категории или каталога;
• карточка товара или услуги;
• корзина и оформление заказа;
• страница контактов;
• типовая текстовая страница;
• личный кабинет, если он есть.

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

Типичные ошибки при составлении ТЗ

За время работы мы видели десятки заданий от клиентов, и многие из них страдают одними и теми же проблемами.

Копирование чужого сайта. «Сделайте как у конкурента» — не задание. У конкурента другая аудитория, другие процессы, другой ассортимент. Брать идеи можно и нужно, но каждый элемент должен быть обоснован вашими задачами.

Избыточный функционал. Желание сразу заложить всё: личный кабинет, программу лояльности, блог, форум, чат, мобильное приложение. В итоге бюджет и сроки растут, а половиной функций никто не пользуется. Лучше запустить базовую версию и развивать её по результатам аналитики.

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

Игнорирование контента. ТЗ подробно описывает функционал, но ни слова о том, кто и когда наполнит сайт. В итоге готовый сайт месяцами стоит с текстами-заглушками.

Забытая мобильная версия. Значительная часть трафика коммерческих сайтов приходит со смартфонов, но в задании мобильные экраны часто вообще не упоминаются.

Нет требований к админке. Заказчик получает сайт, в котором для смены телефона в шапке нужно звать программиста. Опишите, что именно сотрудники должны менять самостоятельно.

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

Отсутствие SEO-требований. Если о продвижении подумать после запуска, многое придётся переделывать: адреса страниц, структуру, шаблоны мета-тегов.

Пошаговый алгоритм подготовки ТЗ

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

1. Сформулируйте цели. Запишите две-три главные бизнес-задачи сайта и метрики, по которым будете оценивать успех: количество заявок, конверсия, средний чек.
2. Опишите аудиторию. Составьте портреты ключевых клиентов и их основные вопросы.
3. Изучите конкурентов. Посмотрите пять-семь сайтов в вашей нише, выпишите удачные решения и раздражающие моменты.
4. Соберите семантическое ядро. Даже грубый список поисковых запросов подскажет, какие страницы и разделы нужны.
5. Нарисуйте структуру. Дерево страниц с иерархией и связями.
6. Опишите функции через сценарии. Пройдите путь пользователя от входа до целевого действия.
7. Перечислите интеграции. С какими внешними системами должен общаться сайт.
8. Определите требования к администрированию. Что и кто будет редактировать.
9. Сделайте прототипы. Хотя бы для ключевых страниц.
10. Расставьте приоритеты. Обязательное, желательное, на потом.
11. Согласуйте и подпишите. Документ становится частью договора.

Что делать, если требования меняются

Даже самое продуманное ТЗ не может предусмотреть всё. В процессе работы появляются новые идеи, меняется рынок, руководство пересматривает приоритеты. Это нормально — важно правильно управлять изменениями.

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

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

Итог

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

Ключевые принципы:

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

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