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