Техническое задание на разработку сайта: что включить и как не упустить важное

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

Почти каждый конфликт между заказчиком и подрядчиком, который нам доводилось разбирать, начинался с одной фразы: «Мы же это имели в виду». Заказчик уверен, что форма обратной связи, конечно, должна отправлять заявки в CRM. Разработчик уверен, что «форма обратной связи» — это форма, которая отправляет письмо на почту. Оба правы, потому что нигде не написано иначе.

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

Зачем нужно ТЗ, если есть бриф

Бриф и техническое задание часто путают. Бриф — это анкета, которую заполняет заказчик: чем занимается компания, кто её клиенты, какие сайты нравятся, какой бюджет. Он отвечает на вопрос «что мы хотим». ТЗ отвечает на вопрос «что именно будет сделано и как мы поймём, что это готово».

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

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

Цели и аудитория: раздел, который пропускают чаще всего

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

Что мы фиксируем в этом разделе:

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

Когда в середине проекта дизайнер спрашивает, куда поставить кнопку, а менеджер заказчика хочет добавить на главную ещё один баннер, именно этот раздел помогает решить спор. Если главная цель — заявки от оптовиков, баннер про розничную акцию на главной не нужен, и это видно без долгих обсуждений.

Структура сайта и описание страниц

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

Хорошее описание страницы выглядит не как «страница услуги с описанием», а примерно так:

1. Заголовок и короткий подзаголовок с выгодой для клиента.
2. Блок с ценой или вилкой цен и кнопкой заявки.
3. Описание услуги: что входит, этапы, сроки.
4. Примеры работ — три-шесть кейсов с фото.
5. Ответы на частые вопросы.
6. Форма заявки с полями «имя», «телефон или почта», «комментарий».
7. Ссылки на смежные услуги.

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

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

Функциональные требования: где прячутся главные риски

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

Для каждой функции мы стараемся ответить на пять вопросов. Кто ею пользуется? Что происходит при нормальном сценарии? Что происходит при ошибке? Куда уходят данные? Кто и как может это настраивать?

Возьмём ту же форму заявки. В хорошем ТЗ будет написано, какие поля обязательны, как проверяется номер телефона, что видит пользователь после отправки, куда уходит заявка — на почту, в CRM, в мессенджер, — кто получает уведомление, как защищается форма от спама и что происходит, если CRM временно недоступна. Каждый из этих пунктов — это часы работы, и если его не описать, он либо не будет сделан, либо будет сделан «как получится».

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

Интеграции и административная часть

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

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

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

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

Контент, дизайн и нефункциональные требования

Контент — это тексты, фото, видео, документы, переводы. В ТЗ фиксируется, кто их готовит: студия или заказчик, в какие сроки и в каком виде передаёт. Проекты чаще всего буксуют не из-за разработки, а из-за того, что тексты для двадцати страниц услуг не готовы к моменту вёрстки. Мы прописываем график передачи материалов и отдельно оговариваем, что делаем, если материалов нет: ставим временные тексты, пишем сами за отдельную плату или сдвигаем сроки.

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

Нефункциональные требования — это всё, что касается качества работы сайта:

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

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

Критерии приёмки и порядок изменений

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

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

Несколько практических советов по работе с ТЗ:

• Читайте документ целиком и задавайте вопросы по каждому непонятному пункту.
• Покажите ТЗ тем, кто будет пользоваться сайтом: менеджерам, контент-редактору, бухгалтерии.
• Не требуйте «как у конкурента» без уточнения, что именно нравится.
• Оставляйте в ТЗ список того, что в проект не входит, — это так же важно, как то, что входит.

Главное о техническом задании

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

Чем больше вопросов снято до начала дизайна и разработки, тем спокойнее проходит проект. Мы в MediaFrukt готовим ТЗ как отдельный этап работ, и на тарифах «Стандарт» и «Эксклюзив» он входит в проект по умолчанию. Если у вас уже есть собственное ТЗ, пришлите его на [email protected] — мы посмотрим, чего в нём не хватает, и подскажем, какие места стоит уточнить до старта.