Техническое задание (ТЗ) — важная часть любого договора на создание сайта. Обычно это приложение к договору, главная цель которого — четко обозначить объём работы, чтобы избежать ситуаций типа «Ой, мы тут подумали, вместо лендинга хотим магазин» или «Дизайн конечно красивый, но нужно еще 4 блока добавить».#nbsp;
Моё ТЗ довольно короткое и занимает всего 2 страницы, но при этом закрывает все важные для меня вопросы. В принципе, с ним ни разу не было ситуации, когда объём работ по сайту пришлось бы увеличивать без доплаты.
Техническое задание у меня состоит из 6 разделов:#nbsp;
1. Общая информация о проекте
В этой части я размещаю ссылку на прототип и дизайн-концепцию (в фигме) и уточняю, что эти файлы приоритетнее, чем всё, что написано в ТЗ.
Это важно, так как в процессе работы вы можете сильно изменить объём сайта, а без этого уточнения придётся каждый раз править и заново подписывать ТЗ.
2. Понимание задачи
Максимально простыми словами описываю, что нужно будет сделать (типа «Разработать дизайн многостраничного сайта, на основе текстом, предоставленных заказчиком»).
В этом же блоке я прописываю примерный объём сайта, чтобы зафиксировать, сколько страниц входит в стоимость работы. Если у нас еще нет четкого понимания, пишу в формате «до…» (до 10 блоков, до 5 страниц).
3. Структура по страницам
Опциональный раздел, который я добавляю только для многостраничных сайтов.
Перечисляю все страницы сайта + в скобках примерные блоки, которые они будут включать. Выглядит это примерно так:
Страница «О компании» (блоки: шапка, обложка, миссия, команда, новости, футер).
4. Этапы и сроки
В этом блоке самое важное - зафиксировать «точки невозврата». Тако событие Х, после которого переделывать сайт больше нельзя))
У меня их 2: день согласования прототипа (после этого правки в текст вносят только за доплату) и день начала вёрстки (после этого правки в дизайн не вносятся)
Здесь же перечисляю все этапы и срок, который на них уйдет (в рабочих днях, без дат). Обязательно пишу, что сроки ориентировочные и не учитывают время согласования.
5. Технические требования
Тут остаются банальные формальности: в каком формате я передам заказчику макет, под какие минимальное разрешение будет адаптирован сайт (здесь же сразу уточняю, что при адаптации дизайн может быть упрощен, тк не всем заказчикам это очевидно).
В этом же блоке указываю число языков + уточняю, что текст для перевода предоставляет заказчик (у меня несколько раз было, что заказчик думал, что перевод я сделаю сама).
В целом я считаю, что самое главное для любого ТЗ — использовать простые и понятные формулировки, чтобы заказчику (и нам) всё было «очевидно» и ни у какого пункта не могло быть двойного толкования. Мы же делаем ТЗ для людей, а не роботов — пусть оно будет написано по-человечески.
И еще важный совет — не пытайтесь сделать максимально точное ТЗ. Конкретное — да, а вот точное — необязательно. Я отношусь к ТЗ как к отправной точке в разработке, по которому мы лишь ориентируемся, к чему должны прийти в итоге.
Поэтому если какие-то вещи мне неизвестны до начала работы, я пишу все в примерном формате — не «10 блоков», а «до 10 блоков»; не «Дизайн-концепция будет 29 октября» а «На дизайн-концепцию уйдет 3 дня». Это позволяет мне не закопаться в формальностях — на подготовку ТЗ у меня уходит 20-30 минут максимум.
———
Подписывайтесь на мой телеграм-канал и страницу ВКонтакте, чтобы узнать больше полезного о веб-дизайне.
