Как составить идеальное техзадание на разработку сайта

Знаете, как работает закон подлости (он же закон Мерфи и закон бутерброда)? Если вас можно понять неправильно — вас обязательно поймут неправильно. Это работает и при разработке сайтов. Заказчик просил второй Инстаграм*, а получил Одноклассники. Исполнитель не угадал с хотелками клиента — потратил время зря, оба недовольны.

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

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

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

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

Пользы от составления ТЗ много. И для заказчика, и для исполнителя.

Что ТЗ даёт заказчику

1. Понимание, за что платим. И каким будет результат. Заказчик увидит структуру, посмотрит — нравится или нет, оценит будущий функционал и добавит пожеланий. Если будут вопросы — без проблем, всегда можно внести коррективы и поправить ТЗ, пока разработчик не сел собирать сайт.

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

3. Страховку. Когда сайт готов, его проверяют на соответствие условиям ТЗ. Что-то не так? Исполнитель обязан все поправить. Или дорабатывай, или возвращай предоплату. Не забывайте вносить такие условия в договор с разработчиком и он точно не отвертится.

4. Возможность поменять исполнителя. Бывает, что заказчик и исполнитель не сработались и разбежались. Проект застынет, сроки реализации сорвутся. Если есть грамотное ТЗ, новой команде будет сильно проще вникать в суть дела — проект запустят в разы быстрее.

5. Оценить стоимость и сроки. Сходу нельзя сказать, во сколько обойдется сложный сайт и как долго его будут собирать. Стороны разбираются, как он будет работать и что для этого нужно. Затем определяют объем работ, и только потом оценивают сроки и стоимость. Без ТЗ все будет очень примерно.

Техническое задание гарантирует, что заказчик получит то, что хотел. Если исполнитель не готов следовать ТЗ, с ним всегда можно попрощаться и забрать предоплату

Что ТЗ даёт исполнителю

1. Понимание, чего хотят. В ТЗ пакуют все пожелания клиента. Ему задают 100 вопросов (или больше), показывают 30 разных вариантов, советуют возможные решения. Потом записывают и согласовывают. Если заказчику нравится — отлично, исполнитель понял, чего от него хотят. Можно браться за работу.

2. Страховку. Заказчики с внезапными хотелками — боль исполнителя. «А у конкурентов не так — давайте делать как у них» или еще хуже «Фу, что за дизайн такой страшный. Давайте переделывать. И бабочек добавьте...». Согласованное ТЗ помогает избегать таких вещей. «Хотите переделать? Давайте вносить правки в ТЗ — за отдельную плату». Если что, справедливость и правда всегда на вашей стороне.

3. Демонстрирует экспертизу. Грамотное ТЗ покажет, какой вы крутой исполнитель. Техзадание — это демонстрация экспертности. Если у заказчика были сомнения, ТЗ поможет их развеять и получить нового и лояльного клиента.

4. Дополнительный доход. Подготовка ТЗ — сложный и длительный этап работы над сайтом. Никто не хочет тратить время и силы бесплатно. А вдруг клиент сбежит с ТЗ? Поэтому обычно разработчики берут за его составление деньги — или включают в общий прайс, или считают как отдельную услугу.

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

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

Кто составляет ТЗ для сайта

Мы встречаем две позиции и, обычно, обе они зависят от точки смотрения:

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

Вторая — исполнитель. Мол, разработчик куда лучше разбирается в создании сайтов, чем предприниматель или управляющий партнер адвокатского бюро. Поэтому пусть он и описывает проект. А мы потом посмотрим, посоветуемся с сыном маминой подруги (он учился на курсах верстки сайтов) и все согласуем.

Третья — правильная. В разработке ТЗ на сайт должны участвовать обе стороны. Понятно, что менеджер или разработчик лучше разбираются в создании сайтов. Идеально, если сайт будут проектировать при участии маркетологов (SEO-специалиста + интернет-маркетолога). Поэтому формально составлять ТЗ будет сторона исполнителя. Справедливо, что за это она попросит вознаграждение, соразмерное проведенным работам и потраченному времени. Но без активного участия заказчика — все в пустую.

Заказчик не может самоустраниться. У него одна из главных ролей в процессе создания сайта. Клиенту точно придется:

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

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

Заказчику, который никогда не сталкивался с разработкой, сложно представить структуру ТЗ. Обычно она состоит из 10–12 разделов и еще стольких же подразделов с уточнения. Это большой и емкий документ на 15–30 страниц в зависимости от сложности сайта. Настоящий реферат. В нем точно должны быть:

1. Информация о проекте
2. Технические особенности проекта
3. Структура сайта в виде блок-схемы или иной визуализации
4. Детальное описание сущностей
5. Функциональные особенности
6. Дизайн
7. Описание контента и определение ответственного за него
8. Сценарии использования сайта

Пожалуйста, заполняйте ТЗ однозначно и точно

В грамотном ТЗ не может неоднозначных прилагательных, вроде «красивый», «надежный», «модный», «полезный». Их нельзя корректно понять и воспроизвести. У каждого свои представления о пользе и красоте.

Исключайте невнятные формулировки:

• Сайт должен быть удобным. Для кого и чего?
• Должен выдерживать нагрузки. Это какие?
• Нужен убедительный контент. Это какой? И кого он должен убедить?

Используйте только цифры и однозначные метрики:

• Сайт должен выдерживать наплыв пользователей → Ожидаемая посещаемость — 25 тысяч одновременно
• Быстрая загрузка → скорость ответа сервера в Яндекс.Вебмастер по каждой странице — не более 20 миллисекунд
• Убедительный контент → информационные статьи с алгоритмами, инструкциями и схемами

Объясняйте сложные формулировки:

• CMS — это система управления сайтом. Через нее можно управлять контентом
• Контент — это тексты, иллюстрации, видео, анимации и любое другое наполнение сайта
• Подвал — это блок внизу каждой страницы. В нем отображаются основные разделы и важные ссылки

Информация о проекте

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

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

Обычно эти особенности узнают в процессе интервью. Проект-менеджер приглашает заказчика в офис, проводит опрос и все фиксирует. Не стоит отдавать этот раздел заказчику: - «Это заполняете вы, а остальную часть ТЗ мы берем на себя». Есть риск упустить важные детали и тонкости.

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

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

Адаптивность. Понятно, что любой современный сайт должен корректно отображаться на мобильных устройствах. Вопрос в том, как он должен отображаться. Это нужно уточнять. Например:

Адаптивность (доступные размеры:

настольный монитор — 1600 х 992 px;

ноутбук — 1280 х 802 px;

планшет — 768 х 1024 px;

смартфон — 1920 х 1080 px)

Кроссбраузерность. Уточняйте, в каких минимальных версиях браузера должен отображаться сайт. Это важно, потому что браузерные требования (особенно для старых браузеров вроде Internet Explorer 7) сильно урезают возможности разработки. Не забывайте уточнять. Например:

Кроссбраузерность: Internet Explorer 9+, Opera 10+, Safari 4+, Chrome 1+

Управление сайтом. Представьте, что вы 3 месяца собирали сайт, все согласовали — клиент доволен. Показываете заказчику админку а он: «Вордпресс? Я думал вы сделаете сайт на Joomla!». Чтобы такого не произошло, все инструменты, библиотеки и движки уточняют в техзадании на разработку сайта. Заодно уточняйте и хостинг. Вдруг, вы пишите сайт на PHP, а заказчик купил хостинг на .NET?

Сюда же относят скорость загрузки, устойчивость к DDoS-атакам, устойчивость к наплыву посетителей и т.д. Если у проекта есть технические особенности — все сюда.

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

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

Структуру можно нарисовать списком, а можно блок-схемой. Для наглядности мы рекомендуем второй вариант.

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

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

1. Шапка. Верхний прикрученный блок. Обычно на нем располагаются контакты, лого, навигация по сайту, строка поиска, кнопки регистрации и авторизации, иные элементы в зависимости от направленности сайта
2. Подвал. Нижний блок, закрывающий каждую страницу. Обычно в нем повторяется часть шапки, размещаются важные кнопки, разделы и и ссылки
3. Сайдбары. Это боковые вертикальные панели, на которых собраны наборы функциональных блоков и виджетов. Например, боковая панель Вконтакте, где собраны кнопки «Новости», «Друзья», «Сообщества», «Музыка», «Игры» и другие прикрученные элементы
4. Формы и окна. Интерактивные элементы, которые появляются при взаимодействии или произвольно. Например, всплывающее окно чата с оператором

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

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

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

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

   БЛОГ (основной раздел)

• заголовок первого уровня
• список постов блога в виде ФОТО + заголовок + анонс на один абзац
• кнопки для постраничной навигации. 1 страница вмещает не более 10 постов
БЛОГ (боковая колонка)
• список категорий блога (маркетинг, интернет-маркетинг, аналитика, разработка, инструменты, кейсы)
• форма подписки на рассылку
• кнопки для перехода в наши соцсети: Вконтакте, Инстаграм* и Фэйсбук*
2. Прототип. Продвинутая штука, которую используют профессионалы. Однозначно и наглядно демонстрирует, как будет выглядеть будущая страница. Это эскизы интерфейса страниц, которые разработчик рисует и прикладывает к заданию. Клиент посмотрит, как будет выглядеть его сайт и скажет, что ему нравится, а что нужно переделать
   Прототип сайта для официального дилера грузовиков в Краснодаре. Заказчик может заранее увидеть интерфейс своего будущего сайта, оценить его визуальное восприятие, предложить исправления и дать свои рекомендации

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

• Типовая текстовая страница. Обычно это шаблон для страниц, которые не подпадают под описание уникальных. В таких страницах предусматривают весь необходимый функционал для размещения текста: заголовки первого-шестого порядка (Н1-Н6), списки, таблицы, иллюстрации, инструменты выравнивания, шрифты и т.д.
• Страница результатов поиска. Люди часто ищут что-то на сайтах через поиск. От того, насколько будет удобной страница поисковой выдачи, зависит конверсия. Поэтому обычно такие страницы не рекомендуют перегружать
• Вход и регистрация. Если предполагается, что люди будут логинится на вашем сайте, позаботьтесь о простоте заполнения форм — опишите, а лучше покажите в ТЗ, как должна выглядеть хорошая и простая форма. Если она будет сложной, люди не захотят регистрироваться
• Страницы 404. Это те страницы, на которые сайт приводит пользователей, если что-то пошло не так. Кажется, что это простая техническая страницы. Но нет — пользователям часто придется сталкиваться с ошибками и видеть эти самые 404. Чем креативнее и заботливее они будут оформлены, тем больше лояльности заработает сайт

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

Детальное описание сущностей

Что это. Чтобы стороны четко понимали структуру сайта, при разработке принято детально описывать сущности — некие виды элементов, которые обладают собственными характеристиками, критериями и параметрами. Сущность — это типовой элемент, если хотите, «атом» интерфейса, который может размещаться на страницах разных категорий. Он может выглядеть по разном, но всегда будет решать одинаковую задачу.

Чтобы было понятно: все рыбы имеют плавники. У каждой рыбы плавники имеют разную форму, но все они выполняют одну функцию — помогают рыбе передвигаться. Плавник — это сущность. С элементами-сущностями на сайте примерно так же.

Пример.

Допустим, мы создаем сайт для каршеринга. Мы точно знаем, что в структуре нашего сайта должны быть две независимые сущности:

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

Эти сущности будут постоянно повторяться на сайте и иметь разное описание, но в пределах определенного набора параметров. Набор параметров сущности нужно прописать в ТЗ.

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

Функциональные особенности

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

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

Дизайн

Его тоже обычно фиксируют в ТЗ. По крайней мере, стараются зафиксировать. Проблема в том, что дизайн (визуал, НЕ интерфейс) — это про вкус и эстетику. А значит все субъективно, прописать объективные критерии оценки почти невозможно. Если о чем то все-таки удалось договориться — фиксируйте это в ТЗ. Хорошо, если у заказчика есть брендбук — будет проще согласовать:

• цветовую гамму будущего сайта
• фирменные цвета
• цвета элементов и кнопок
• шрифты
• декоративные элементы
• стиль и настроение — строгий, индустриальный, динамичный, добрый и т.д.

Писать про оригинальный и яркий дизайн не нужно. Это не имеет силы, не дает четкого понимания задачи и просто бессмысленно. Если представления о визуальном оформлении дизайна у заказчика нет, лучше отдать этот вопрос на усмотрение дизайнера (обязательно с правом попросить внести правки). Функциональные особенности.

Сценарии использования

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

Составить сценарии использования не проблема. Используйте простую схему:

Действие пользователя → Ответ системы … → Результат

Простой пример:

СЦЕНАРИЙ ОФОРМЛЕНИЯ ЗАКАЗА НА САЙТЕ:

1. Клиент нажимает на кнопку «Заказать»
2. Сайт открывает форму заявки
3. Пользователь вводит номер телефона, имя и нажимает «ок»
4. Сайт принимает заявку и выводит пользователю сообщение «Заказ принят»
5. На электронную почту менеджера приходит сообщение о новом заказе с деталями

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

Определение ответственного за контент

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

1. Студия-разработчик — под ключ. Обычно, когда заказывают сайт под ключ, предполагается его наполнение всем необходимым контентом — текстами, иллюстрациями, видео. Это уже входит в стоимость, сайт на приемку отдают в готовом виде
2. Студия-разработчик — за отдельную плату. Справедливо, если разработчик отказывается наполнять сайт в рамках услуги по созданию сайта. Это отдельный вид работ, которым занимается отдельная команда (редактор, корректор, копирайтер, графдизайнер, иллюстратор и т.д.). Качественное наполнение — это долго и дорого, поэтому создание контента вписывают в договор как отдельную услугу
3. Заказчик или нанятые им подрядчики. Разработчик может подготовить «рыбу» — «скелет» контента, на основе которого заказчик или нанятые им подрядчики будут создавать контент. Часто это выгоднее, чем заказывать у студии-разработчики. Кроме гонорара копирайтеров и дизайнеров, в прайс включается еще и накрутка студии

Если за частично или полностью отвечает исполнитель, это должно быть прописано в ТЗ.

Пример

КОНТЕНТ

Исполнитель должен создать и разместить уникальные (ранее не используемые в интернете) текстово-графические материалы, включая заголовки Title и мета-теги Description для:

• Главной страницы
• Раздела «О компании»
• Всех страниц раздела «Услуги»
• Страницы «Политика конфиденциальности»

Проверка уникальности текстового контента осуществляется с помощью сервисов Текст.РФ и Адвего. Уникальным считается контент, уникальность которого выше 90%. Остальные страницы заказчик наполняет контентом собственными силами.

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

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

1. Скачайте шаблон. В нем подробно опишите основную информацию о проекте: вид деятельности, особенности бизнеса, ЦА и ее потребности, цели и задачи, потребности, которые должен закрывать сайт
   
2. Опишите технические особенности проекта: адаптивность, кроссбраузерность, особенности управления сайтом, потенциальную нагрузку, скорость загрузки страниц и т.д.
3. Опишите структуру сайта: необходимые сквозные элементы, уникальные и иные технические страницы. Попробуйте визуализировать структуру в виде блок-схемы, а элементы страниц в виде прототипов
4. Составьте список и описание сущностей с набором параметров, которым они должны соответствовать. Для функциональных особенностей, которым не нашлось места ни в одной из категорий, посвятите отдельный раздел
5. Опишите критерии дизайна: цветовые стили, шрифты, палитру кнопок, иные особенности визуального оформления, которые удалось согласовать
6. Составьте сценарии использования сайта, если на нем планируется размещать интерактивные элементы. Определите ответственного за контент и составьте контент-план
7. Согласуйте ТЗ с заказчиком

*Суд Москвы признал компанию Meta экстремистской организацией. Организация Meta и ее продукты Facebook и Instagram признаны экстремистскими и запрещены на территории РФ