Так что же такое «Техническое Задание»? Образцы технических заданий. Как правильно составить техническое задание Пример перечня документации

Глоссарий

Термин	Описание
	Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных HTML-страниц
World wide web (WWW, web, веб)	Единое информационное пространство на базе сети Internet, состоящее из совокупности сайтов. Приставка "веб-" может использоваться для обозначения объектов, ориентированных на использование в WWW или использующих типичные для WWW технологии (например, веб-интерфейс - интерфейс на базе веб-страниц)
HTML-страница (веб-страница, страница)	Основной носитель информации в World ide Web. Особым образом сформатированный файл (набор файлов), просматриваемый с помощью www-браузера как единое целое (без перехода по гиперссылкам)
HTML-теги (теги)	Управляющие коды, посредством которых осуществляется форматирование HTML-страницы
	Активный элемент HTML-страницы, задаваемый специальным тегом. Выделенный фрагмент текста или изображения, позволяющий загрузить другую страницу или выполнить определенное действие
WWW-браузер (браузер)	Клиентская программа, поставляемая третьими сторонами и позволяющая просматривать содержимое HTML-страниц
HTML-форма (форма)	Часть HTML-страницы, предназначенная для взаимодействия с посетителем сайта. Представляет собой набор элементов (текстовых полей, селекторов, выпадающих списков), посредством которых пользователь может ввести какую-либо информацию и отправить ее для обработки на сервере
Поле (поле БД, поле формы)	Структурный элемент, содержащий однотипную информацию, например, текст, дату, числовые значения и т.п.
	Особое поле данных, могущее содержать только одно из двух допустимых значений. Позволяет указать на наличие или отсутствие какого-либо события или свойства объекта
Справочник	Вспомогательная структура данных, содержащая список допустимых значений для какого-либо поля основных форм или БД. Справочники подразделяются на фиксированные (неизменяемые и поставляемые Исполнителем вместе с готовым сайтом) и редактируемые (состав которых может изменяться администратором)
Администратор (менеджер, редактор) сайта	Лицо, осуществляющее от имени Заказчика информационную поддержку сайта
Дизайн-шаблон страниц
Дизайн веб-сайта	Уникальные для конкретного веб-сайта структура, графическое оформление и способы представления информации
Информационные материалы	Информация о деятельности Заказчика. Может включать графические, текстовые, аудио или видео материалы. Предоставляется Заказчиком
Наполнение (контент)	Совокупность информационного наполнения веб-сайта. Включает тексты, изображения, файлы и т.п. предназначенные для пользователей системы
Элемент наполнения (контента)	Отдельная запись в базе данных, внешнее представление которой зависит от управляющего ей программного модуля (например, в модуле «новостная лента» элементом наполнения является отдельная новость)
Система динамического управления наполнением (контентом) сайта
	Совокупность объектов базы данных, представленная в виде файлов, позволяющая восстановить точную копию структуры исходной базы данных в аналогичной системе управления базами данных
Веб-интерфейс	Совокупность экранов и элементов управления системы, позволяющих пользователю, осуществляющему доступ к системе через веб-браузер, осуществлять поддержку и управление системой.
Шаблона раздела	Ссобым образом размеченный ASCII-файл, определяющий как графическое оформление страниц раздела, так и их макет (раскладку) - взаимное расположение блоков с наполнением раздела
WYSIWYG редактор	Редактор языка HTML, имеющий возможности по работе в текстовом режиме и в режиме WYSIWYG (What You See Is What You Get). В режиме WYSIWYG элементы HTML страницы при редактировании представляются в том же виде, что и при просмотре
	Класс пользователей системы, обладающих определенным набором прав доступа

Прочая техническая терминология понимается в соответствии с действующими стандартами и рекомендациями международных органов, ответственных за вопросы стандартизации в сети Интернет.

Общие положения

Предмет разработки

Предметом разработки является Интернет-сайт компании ООО «…», с системой динамического управления наполнением на базе веб-интерфейса.
Назначение сайта:
- предоставление информации о компании ООО «…»;
- предоставление информации о деятельности компании ООО «…»;
- т.д.;
- пр.

Цель создания сайта: ... .

Назначение документа

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

Требования к графическому дизайну сайта

Требования к дизайну сайта

При разработке сайта должны быть использованы преимущественно светлые стили.
Основные разделы сайта должны быть доступны с первой страницы.
На первой странице не должно быть большого объема текстовой информации.

В дизайне сайта не должны присутствовать:
- мелькающие баннеры;
- много сливающегося текста;
- т.д.;
- пр.

Порядок утверждения дизайн-концепции

Под дизайн-концепцией понимается вариант оформления главной страницы и графическая оболочка внутренних страниц, демонстрирующие общее визуальное (композиционное, цветовое, шрифтовое, навигационное) решение основных страниц сайта. Дизайн-концепция представляется в виде файла (нескольких файлов) в растровом формате или в распечатке по согласованию сторон.
Если представленная Исполнителем дизайн-концепция удовлетворяет Заказчика, он должен утвердить ее в течение пяти рабочих дней с момента представления. При этом он может направить Исполнителю список частных доработок, не затрагивающих общую структуру страниц и их стилевое решение. Указанные доработки производятся параллельно с разработкой программных модулей сайта. Внесение изменений в дизайн-концепцию после ее приемки допускается только по дополнительному соглашению сторон.
Если представленная концепция не удовлетворяет требованиям Заказчика, последний предоставляет мотивированный отказ от принятия концепции с указанием деталей, которые послужили препятствием для принятия концепции и более четкой формулировкой требований.
В этом случае Исполнитель разрабатывает второй вариант дизайн-концепции. Обязательства по разработке второго варианта дизайн-концепции Исполнитель принимает только после согласования и подписания дополнительного соглашения о продлении этапа разработки дизайн-концепции на срок не менее пяти рабочих дней.
Дополнительные (третий и последующие) варианты разрабатываются Исполнителем за отдельную плату на основании дополнительных соглашений.

Функциональные требования

Требования к представлению сайта

Требования к представлению главной страницы сайта Главная страница сайта должна содержать графическую часть, навигационное меню сайта, а также контентную область для того, чтобы посетитель сайта с первой страницы мог получить вводную информацию о компании, а также ознакомиться с последними новостями компании.
Контентная область первой страницы должна делиться на следующие разделы:
- вступительная статья о компании со ссылкой «подробнее», ведущей на раздел «О компании»;
- новости - содержит 3 последние новости (анонсы) в формате: дата, заголовок, краткое содержание;
- краткая контактная информация - телефон и e-mail компании;
- вверху страницы отображаются облегченная навигационная панель, которая обеспечивает переход к основным пунктам меню сайта (О компании, Новости и т.д.);


- счетчики и ссылка на страницу обмена ссылками.

Рис. 1. Пример размещения элементов главной страницы.

Графическая оболочка внутренних страниц (общая для всех подразделов)
Графическая оболочка внутренних страниц должна делиться на следующие разделы:
- графическая шапка
- навигационное меню сайта (навигационная панель 2 обеспечивает переход к основным пунктам меню сайта);
- поле поиска - предназначено для выполнения полнотекстового поиска по сайту;
- поле выбора языка - русский\английский;
- ссылка «На главную»;
- навигационная панель по подразделам выбранного раздела сайта;
- поле для отображения контента выбранной страницы сайта;
- внизу страницы - краткая контактная информация - телефон и e-mail компании;
- кнопка «Для печати» - обеспечивает вывод контентной области в виде, отверстанном для печати на листах формата А4;
- кнопка «Задать вопрос» - обеспечивает переход к форме «Задать вопрос».

Рис. 2. Пример размещения элементов внутренних страниц сайта.

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

a. История компании
b. Дипломы и сертификаты
c. Наши партнеры
d. Наши клиенты
e. Наши координаты
f. ...

2. Новости
3. т.д.
4. пр.

Требования к системе управления сайтом

Общие требования к административной части
Для получения доступа к административной части сайта необходимо указать определенный адрес в строке броузера и пройти авторизацию.
Главная страница административной части должна содержать следующие пункты меню:
- Станицы сайта (в соответствии с первым уровнем структуры сайта):

О компании
- Новости
- т.д.;

Рис. 3. Макет формы главной страницы административной части сайта.

Требования к управлению разделами сайта
Для управления разделами сайта должны быть предусмотрены следующие функции:
- создание подраздела 1 уровня;
- создание подраздела 2 (и далее) уровня;
- редактирование контента страницы;
- удаление раздела;
- перемещение раздела вверх в списке;
- перемещение раздела вниз в списке;
- признак показа (show) или не показа (hide) страницы в клиентской части сайта;
- отображение списка подразделов выбранного уровня.

Управление наполнением сайта
Для управления наполнением сайта должны быть предусмотрены следующие блоки:
1. поле элемента контента, может быть одного из следующих типов:
- строка;
- дата;
- ссылка на файл;
- многострочный текст;
2. элемент контента - состоит из набора полей элемента контента;
3. список элементов контента - состоит из набора элементов контента.

Рис. 4. Поля элемента контента.

Поле элемента контента типа «Текст» должно редактироваться на отдельной странице в редакторе многострочного текста (данный редактор допускает включение в текст изображений).

Рис. 5. Редактор многострочного текста в административной части.

Для каждого элемента контента должен определяться требуемый набор полей. Например, для элемента «Новость» определяется следующий набор полей контента:

Рис. 6. Пример представления элемента контента «Новость» в административной части.

Список элементов контента должен позволять:
. перейти к редактированию полей элемента списка;
. удалить элемент списка;
. определить порядок элементов списка вывода в клиентской части;
. указать признак hide\show.

Рис. 7. Пример представления списка элементов контента в административной части и их отображения в клиентской части.

В списке элементов должны выводиться все поля элемента, кроме полей вида «Многострочный текст».

Управление настройками сайта
В состав настроек сайта должны входить:
- e-mail для …;
- т.д.;
- пр.

Дополнительные функции административной части
В состав дополнительных функций административной части должны входить:
- …;

Требования к разделению доступа

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

Требования к видам обеспечения

Требования к информационному обеспечению

Требования к хранению данных
Все данные сайта должны храниться в структурированном виде под управлением реляционной СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания (изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД размещаются ссылки на них.
Наполнение различных сайтов, функционирование которых поддерживается одной и той же инсталляцией системы, должно храниться под управлением единой СУБД.
Требования к языкам программирования
Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS. Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).
Для реализации интерактивных элементов клиентской части должны использоваться языки JavaScript и DHTML.
Для реализации динамических страниц должен использоваться язык PHP.
Требования к организации гиперссылок
Все ссылки на сайте должны быть относительными (за исключением внешних).

Требования к иллюстрациям
Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.
Требования к объему одной страницы
Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.
Объем flash-заставки не должен превышать 300 Kb.

Требования к программному обеспечению

Требования к программному обеспечению серверной части
Для функционирования сайта необходимо следующее программное обеспечение:
- Операционная система - Windows XP и Windows Server 2003;
- Веб-сервер - Apache версии не ниже 1.3.26;
- СУБД - MySQL версии не ниже 3.23;
Требования к клиентскому программному обеспечению
Сайт должен быть доступен для полнофункционального просмотра с помощью следующих браузеров:
. MS IE 5.0 и выше;
. Opera 6.0 и выше;
. Mozilla Firefox 1.0;
. Mozilla 1.7.
Сайт должен быть работоспособен (информация, расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и JavaScript.

Требования к техническому обеспечению

Для функционирования сайта необходимо следующее техническое обеспечение со следующими минимальными характеристиками:
- процессор - Intel Pentium III 1 Ghz;
- оперативная память - 512 Mb RAM;
- жесткий диск - 20 Gb HDD.
- т.д.;
- пр.

Требования к лингвистическому обеспечению

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

Требования к эргономике и технической эстетике

Сайт должен быть оптимизирован для просмотра при разрешении 1024*768, 1280*1024 без горизонтальной полосы прокрутки и без пустых (белых) полей для основных типов разрешения.
Элементы управления должны быть сгруппированы однотипно - горизонтально либо вертикально - на всех страницах.
На каждой странице должны отображаться логотип компании и контактная информация.
Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.

Требования к приемке-сдаче проекта

Требования к наполнению информацией

Общие требования к информационному наполнению
В рамках работ по данному проекту Исполнитель обеспечивает наполнение разделов сайта предоставленными Заказчиком материалами в порядке, указанном в п. 6.1.2.
Исполнитель обеспечивает обработку иллюстраций для приведения их в соответствие с техническими требованиями и HTML-верстку подготовленных материалов. Сканирование, набор и правка-вычитка текстов, ретушь, монтаж, перевод и другие работы могут быть выполнены Исполнителем на основании дополнительного соглашения (после просмотра имеющихся у заказчика материалов).
После сдачи системы в эксплуатацию информационное наполнение разделов, осуществляется на основании договора на поддержку сайта.
Объем текста и количество иллюстраций в других типах разделов определяется предусмотренной настоящим ТЗ структурой данных и уточняется на этапе согласования дизайн-концепции.
Порядок предоставления информационного наполнения
Заказчик предоставляет материалы в электронной форме в zip-архиве, содержащем дерево директорий, соответствующих структуре сайта.
В каждой директории размещается набор документов в формате MS Word - по одному документу на каждый информационный модуль, информационные блоки которого опубликованы в соответствующем разделе. Не допускается размещение текста в виде графических изображений или иных нетекстовых элементов.
Изображения могут быть размещены как в тексте внутри файла, так и в виде отдельного изображения. Однако, в последнем случае текст должен содержать ссылку на изображение в виде указания пути и названия файла изображения.
Для каждого информационного модуля структура документа должна соответствовать шаблонам, предоставляемым Исполнителем до начала этапа предоставления материалов.
Материалы для первоначального наполнения разделов должны быть полностью представлены Исполнителю в сроки, установленные планом-графиком работ. Допускается передача материалов частями, в нескольких zip-файлах, соответствующих приведенным требованиям.
Передача материалов в объеме и формате, соответствующем настоящему ТЗ закрепляется подписанием Акта о передаче информационного наполнения.
Любые изменения информационного наполнения силами Исполнителя после подписания данного Акта допускаются только на основании отдельного соглашения за дополнительную плату.
Информационные материалы, не предоставленные Заказчиком в сроки, установленные планом-графиком работ, размещаются Исполнителем по гарантийному письму Исполнителя в течение 2-х недель после сдачи-приемки проекта. На эту часть информационных материалов также накладываются требования к формату предоставления, изложенные выше.

Требования к персоналу

Для эксплуатации веб-интерфейса системы динамического управления наполнением от администратора не должно требоваться специальных технических навыков, знания технологий или программных продуктов, за исключением общих навыков работы с персональным компьютером и стандартным веб-браузером (например, MS IE 6.0 или выше).

Порядок предоставления дистрибутива

По окончании разработки Исполнитель должен предоставить Заказчику дистрибутив системы в составе:
-архив с исходными кодами всех программных модулей и разделов сайта;
- дамп проектной базы данных с актуальной информацией.
Дистрибутив предоставляется на CD-диске в виде файлового архива.

Порядок переноса сайта на технические средства заказчика

После завершения сдачи-приемки сайта, в рамках гарантийной поддержки Исполнителем производится однократный перенос разработанного программного обеспечения на аппаратные средства Заказчика. Соответствие программно-аппаратной платформы требованиям настоящего документа обеспечивает Заказчик.
Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и доступ к базе данных сайта.

Павел Молянов

Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.

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

Статья будет полезна:

• Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
• Менеджерам проектов.
• Руководителям диджитал-студий.
• Предпринимателям, которые планируют заказать разработку сайта.

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

Что такое техзадание и зачем оно нужно

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

Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.

Пользы от технического задания много. Для каждой стороны она своя.

Польза для клиента:

• Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
• Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
• Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
• Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
• Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.

Польза для исполнителя:

• Понять, что хочет заказчик. Клиенту задают десятки вопросов, показывают примеры, предлагают решения. Затем записывают все в единый документ и согласовывают. Если все окей - ура, вы поняли правильно.
• Застраховаться от внезапных хотелок клиента. Иногда попадаются заказчики, которые хотят поменять задачу на полпути. Если вы согласовали и подписали ТЗ, вам не страшно подобное. В случае чего, даже суд будет на вашей стороне.
• Показать свою компетентность. Классно подготовленное техзадание покажет клиенту экспертность разработчиков. Если компания сомневалась, доверять ли вам разработку сайта, сомнения с большой вероятностью развеются.
• Заработать деньги. Некоторые студии и разработчики предлагают составление ТЗ как отдельную услугу.

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

Теперь давайте разберемся, как составить хорошее техзадание, которое выполняет все эти функции.

Техзадание составляет исполнитель

Вообще техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» - это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.

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

Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:

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

Пишите однозначно и точно

Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое - с невнятными формулировками, которые ничего сами по себе не значат:

• Сайт должен понравиться заказчику. А если у него будет плохое настроение?
• Сайт должен быть удобным. Что это значит? Удобным для чего?
• Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
• Качественный экспертный контент. Ну, вы поняли.

Проверяйте, нет ли в тексте неоднозначностей. Если есть - перепишите. Ваши формулировки должны быть четкими и точными:

• Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
• Большие нагрузки → 50 тысяч посетителей одновременно.
• На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
• Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

С формулировками разобрались, давайте пробежимся по структуре.

Укажите общую информацию

Все члены команды должны правильно понимать, чем занимается компания и кто ее целевая аудитория. Чтобы никто не запутался, это лучше прописать в самом начале техзадания.

А еще стоит указать цель сайта и описать его функционал в двух словах - чтобы не получить интернет-магазин вместо блога.

Поясните сложные термины

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

Опишите инструменты и требования к хостингу

Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.

Перечислите требования к работе сайта

Сайт должен работать во всех браузерах актуальных версий и на всех типах устройств. Да, это очевидно для любого разработчика и любого заказчика. Но лучше написать, чтобы защитить клиента от недобросовестно выполненной работы.

Сюда же напишите требования к скорости загрузки сайта , устойчивости к нагрузкам, защите от хакерских атак и подобным вещам.

Укажите структуру сайта

До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.

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

Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.

Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.

Объясните, что будет на каждой странице

Клиент должен понять, зачем нужна каждая страница и какие элементы на ней будут. Есть два способа это показать.

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

Перечисление элементов - ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице, и что они делают.

Распишите сценарии использования сайта

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

• Действие пользователя.
• Ответное действие сайта.
• Результат.

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

Подробнее о сценариях использования читайте в «Википедии ».

Определите, кто отвечает за контент

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

Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.

Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.

Опишите дизайн (если сможете)

Как и в с случае с текстом, объективные критерии оценки дизайна сайта придумать сложно. Если вы с клиентом договорились о цветовой гамме - напишите ее. Если у него есть брендбук, в котором прописаны шрифты, - укажите и их.

Писать про красивый и современный дизайн не надо. Это ничего не значит, не имеет силы и вообще фу.

Вместо вывода: структура техзадания

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

• Информация о компании и целевой аудитории, цели и задачи сайта.
• Глоссарий терминов, которые могут быть непонятны клиенту.
• Технические требования к верстке и работе сайта.
• Описание используемых технологий и список требований к хостингу.
• Подробная структура сайта.
• Прототипы страниц или описания элементов, которые должны на них быть.
• Сценарии использования нестандартного интерфейса (опционально).
• Список контента, который делает разработчик.
• Требования к дизайну (опционально).

• Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
• Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.

Это конец той части, которую писал я. Но есть и другая - комментарии специалистов, которые помогали делать гайд. Почитайте, это тоже интересно.

Комментарии разработчиков

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

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

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

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.

Мы указываем:

• Информацию о компании и цель сайта.
• Требования к дизайну, цветовую гамму.
• Используемые технологии и CMS.
• Кто занимается контентом - мы или клиент.
• Структуру сайта вплоть до каждой страницы.
• Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.

Последние 2 раздела - самые важные. Именно они обеспечивают понимание, какие будет сайт и как он будет работать.

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

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

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

В этой статье вы узнаете, как правильно составить техническое задание на создание сайта, чтобы все остались довольны проделанной работой.

Что такое техническое задание

Техническое задание (ТЗ) – документ, содержащий требования заказчика к сайту. Заказчик и исполнитель должны правильно понимать друг друга, поэтому лучше подробно расписать все требования. Четко составленное ТЗ увеличивает шансы того, что заказчик будет доволен получившимся результатом, а исполнитель не будет переделывать ресурс 2-3 раза.

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

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

• Рассказать подробнее о компании, предлагаемых товарах или услугах, целевой аудитории;
• Уточнить о проблемах, с которыми целевая аудитория (ЦА) будет приходить к клиенту и их решения;
• Узнать, что именно клиент хочет получить от сайта;
• Попросить привести примеры удачных сайтов конкурентов.

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

Чёткость формулировок в ТЗ

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

Главный критерий качества ТЗ - чёткие формулировки, отсутствие двусмысленных трактовок.

Конкретика в техническом задании - главное условие качества, например:

• Каждая страница должна провериться на GTmetrix или GoogleSpeed с показателем скорости не менее 80/100 по Google Page Speed.
• Ресурс должен выдерживать до 20 тыс. посетителей одновременно.
• На главной должны выводиться новости и ниже отображаться форма с кнопкой «Подписаться» с возможностью отправить e-mail адрес.
• Список партнеров в виде карусели логотипов, отзывы клиентов в слайдере с горизонтальной прокруткой по 1-му отзыву на слайд.

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

Структура сайта – фундамент. Решите, какие страницы необходимо создать и продумайте навигацию на них. По нашему опыту клиент проще воспринимает блок-схему, нарисованную в XMind. Но если вы считаете, что работа в XMind займет слишком много времени, то просто перечислите секции в word файле. Кстати, не лишним будет предварительно собрать , которое поможет в определении структуры и разделов на основании реальных запросов потенциальных клиентов в вашем сегменте.

Пример структуры ТЗ по договору

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

Страница «Главная»

• Секция «Меню» с разделами и выпадающим списком подразделов:
  • Логотип и слоган;
  • «Главная»;
  • «Проекты»;
  • «Каталог продукции» с выпадающим списком разделов «Трубы SML», «Фитинги SML», «Соединительные хомуты»;
  • «Производство»;
  • «О компании»;
  • «Проектировщикам»
  • «База знаний / FAQ»;
  • «Контакты»;
  • Ссылка на скачивание катала продукции в.pdf;
  • Контактный телефон компании;
  • Кнопка «Заказать звонок».
• Секция «Слайдер» с фотографией по ширине экрана и кнопкой обратной связи с запросом на просчёт проекта / запроса на полный прайс-лист продукции.
• Секция «Преимущества» с указанием ключевых выгод для клиентов;
• Секция «Производство» с кратким описанием и информацией про систему контроля качества, со ссылкой на раздел «Производство» и кнопкой с записью на поездку на завод;
• Секция «Продукция» с текстовым описанием преимуществ, ссылками на сертификаты, ссылкой на «Каталог продукции»;
• Секция «Наши проекты» (с переходом в раздел «Все проекты»);
• Секция «Компания в цифрах» с цифрами достижений и ссылкой на раздел «О компании»;
• Секция «Видео-инструкции» с текстовым описанием и ссылкой в раздел «Все видео»;
• Секция «Подвал»:
• Контакты, телефон, адрес, электронная почта;
• Кнопка обратной связи;
• Ссылка на YouTube канал и на социальные сети компании.

Если вы также заказываете уникальный дизайн, то структуру страниц можно строить по предварительному прототипу. Ниже пример прототипа сайта, который можно прикрепить к техническому заданию на разработку. Определите вид главной страницы. Решите, где будет заголовок, пропишите основные элементы, на чём сделать акцент и так далее.

Функционал сайта

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

• CMS система Вордпресс, Битрикс и тп.
• Формы заявок с возможностью оставить заявку
• Модальные окна
• Слайдеры
• Модули галереи
• Модули SEO оптимизации и страниц
• Модули кеширования и сжатия
• Онлайн-карта с гео-метками
• с расчетом цены

К технической части относятся требования хостингу и его настройкам. Советуем выбирать проверенный и быстрого хостинг-провайдера с приемлемыми тарифами на обслуживание. Мы используем в проектах вот этот хостинг. Стоимость всего 2500 в год, домен в зоне.ru можно купить за 179 руб. Вот пример функционального описания для технического задания.

Подключение и настройка CMS системы 1С Битрикс	Исполнитель настраивает CMS систему управления сайтом 1С Битрикс. Лицензия «1С-Битрикс: Управление сайтом» оплачивается Заказчиком самостоятельно.
Наполнение контентом	Наполнение текстом и фотографиями указанных выше страниц. Текст и фотографии предоставляет Заказчик. Исполнитель в праве использовать также контент с сайта заказчика. Расположение блоков на страницах выводится в рамках структуры страниц шаблона.
Настройка ролей доступа	Добавление роли «Администратор» с возможностью администрирования CMS, роли редактора (для отдела закупок) с возможностью добавления информации.
Адаптация для мобильных устройств и планшетов	Широкоэкранная верстка и адаптация под более мелкие разрешения экрана, сайт должен корректно отображаться на экранах шириной от 1920 до 320 пикселей, появление горизонтальной прокрутки недопустимо.
Подключение дополнительных модулей CMS	Исполнитель также вправе добавлять модули CMS и функциональные элементы на своё усмотрение, если они улучшают работоспособность сайта по согласованию с Заказчиком, платные модули оплачиваются Заказчиком.
Подключение домена и хостинга Заказчика	Исполнитель подключает домен и хостинг Заказчика для веб-сайта. Производится парковка домена с указанием адресов ns1, ns2. Включается версия PHP не ниже 7.0.
Настройка базы данных MySQL	Исполнитель создает базу данных MySQL на хостинге заказчика для размещения данных веб-сайта. Доступы к базе данных передаются Исполнителем Заказчику по электронной почте.
Видеофон на главной странице	Вывод подложки с видеорядом Заказчика в первом блоке главной страницы сайта. Должна присутствовать затемняющая подложка для повышения читабельности текста.
Вывод модальных окон и отправка данных	Каждая из кнопок должна вызывать соответствующее модальное окно с формой обратной связи. Данные с формы в корректном виде должны отправляться на почту Заказчика.
Вывод форм обратной связи	Форма обратной связи должна выводиться на каждой странице. В форме обратной связи должны присутствовать: форма поля ввода номера телефона и кнопка «отправить заявку». Данные с формы должны передаваться на электронный адрес администратора, а также дублироваться на адрес [email protected].
Подключение Яндекс карты c ГЕО-метками	На страницах выводится Яндекс.Карта с ГЕО меткой расположения / адреса Заказчика. Заказчик устанавливает метку на собственном аккаунте Яндекс.
Подключение статистики Яндекс.Метрика	Сервис сбора данных о посещаемости и поведении пользователей. Заказчик предоставляет Яндекс почту, на которую Исполнитель подключает сервис.
Настройка целей в Яндекс.Метрика	Исполнитель настраивает цели в Яндекс.Метрика. Цели сообщают в статистике о том, с какой конкретно формы была отправлена заявка.
Вывод H1 и МЕТА-описаний страниц согласно ключевому запросу веб-страницы	Каждая страница веб-сайта должна иметь заголовок и МЕТА-описание в соответствии с содержимым страницы.
Кроссбраузерная оптимизация сайта	Сайт должен корректно открываться в последних актуальных версиях существующих браузеров.
Настройка файлов sitemap.xml	Исполнитель выводит карту сайта в отдельный раздел sitemap.xml с указанием существующих страниц для индексации.
Добавление «хлебных крошек»	Исполнитель выводит в каждый раздел навигационную цепочку («хлебные крошки», англ. Breadcrumbs) с адресом страницы формата: Главная → Раздел → Подраздел → Текущая страница.
Настройка файла robots.txt	Исполнитель настраивает текстовый файл, который содержит параметры индексирования сайта для роботов поисковых систем.
Настройка файла.htaccess	Исполнитель настраивает специальный файл, позволяющий редактировать конфигурации и настройки веб-сервера.
Настройка ЧПУ адресов страниц в формате domen.ru/arenda-sklada	Адрес каждой страницы должен содержать корректное описание для поисковых систем и посетителей на латинице.
Настройка 404 и 303 страниц	Настройка корректной выдачи ошибки 404, настройка 303 переадресации на страницы, которые изменили свой адрес.
Оптимизация программного кода HTML/CSS/PHP и скриптов	Исполнитель выполняет оптимизацию программного кода страниц сайта для повышения скорости загрузки страниц и веб-сайта в целом. При необходимости Исполнитель переносит загрузку.js скриптов в «подвал» сайта, настраивает кеширование страниц и сжатие CSS / HTML.
Оптимизация размера изображений и графического контента	Исполнитель сжимает изображения и видео, размещаемые на страницах веб-сайта для повышения скорости загрузки страниц ресурса.
Тестирование и поддержка в течение 1-го месяца после запуска	После приемки и запуска веб-сайта Исполнитель оказывает услуги по технической поддержке, устраняет технические ошибки и корректирует работу сайта при необходимости.

Отдельно.

Помните, что сайт - это техническое и программное обрамление контента. Если контент (фото и видео) не очень, то и сайт будет таким же.

Отдельно стоит уделить внимание качеству фото и видео. Мы всегда рекомендуем заказать фото и видео съёмку клиентам, если нет презентабельного фото и видео контента для сайта.

Что относится к оформлению: оформление кнопок и элементов взаимодействия - ссылки, кликабельные стрелки слайдера, формы заявок и так далее. Продумайте цветовую гамму и пропишите гарнитуры шрифтов. У вас есть брендбук? Отлично, вы можете взять из него основные цвета и стили шрифтов для заголовков и основного текста и прописать всё это в техническом задании. Помните, что хорошее оформление зависит от качества исходного контента. Если у вас будут неказистые фото, то красивые кнопочки не помогут.

Кстати, многие клиенты путают понятие оформления и дизайна. Дизайн - это структура страниц от слова design (проектировать). Дизайн страниц должен содержать ключевые блоки и элементы, которые они содержат. Дизайн - это логика построения страниц.

Структура технического задания

Итак, что должно содержать в себе хорошее техническое задание, которое обезопасит вас от недопонимания с исполнителем. Вот перечень:

• Общая концепция.
• Структура сайта и страниц.
• Требования к хостингу.
• Прототипы страниц.
• Требования к вёрстке и работоспособности.
• Функциональная часть.
• Требования к дизайну и контенту.

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

Если вам нужен новый сайт, то вы можете создание сайта или технического задания в нашей веб-студии.

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы - могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

Как говорится - «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.

Проблема

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

Техническое задание - исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Техническое задание является юридическим документом - как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет. Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков. Техническое задание, как термин в области информационных технологий – это юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям на разработку, внедрение или интеграцию программного продукта, информационной системы, сайта, портала либо прочего ИТ сервиса.

Переводим на понятный язык

1) ТехЗадание - оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура - это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами - любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом - это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.

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

3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт - вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия - быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.

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

4) ТехЗадание должно обязательно согласоваться с общим бизнес-планом заказчика, с его стратегией развития бизнеса и анализом сегмента рынка. Именно все это позволит установить правильные цели, вывести точные метрики, по которым затем адекватно провести приемку готового инфопродукта. Отсутствие у заказчика бизнес-плана автоматически гарантирует непрофессиональное выполнение Технического Задания.

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

5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.

Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.

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

Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? - написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

Контрольные вопросы

А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? - Да, даже несколько.

2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? - В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей - но не вместо четкой постановки задачи, а уже после нее.

3) Так может оно мне такое и не нужно? - Возможно, сегодня тысячи сайтов делаются вообще без ТЗ, также, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения. Но если вы хотите видеть - куда вы вообще движетесь, осознанно принимать решения и самостоятельно оценивать полученные результаты - то без ТЗ тут не обойтись.

4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? - Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? - Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) - то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL - уже нет.

6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? - Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» - установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь - обязательно.