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