И заказчику это нужно не меньше, чем разработчику. В первую очередь, для экономии его же денег.
Почему?
Потому что, во-первых, проработанное до мелочей техническое задание на создание сайта практически исключает вероятность того, что сайт не будет соответствовать требованиям заказчика. А если и будет — то это уже станет проблемой разработчика, обязанного четко придерживаться ТЗ. При отсутствии же этого документа велика вероятность того, что в итоге работа будет сдана и принята со множеством не явных моментов, требующих дальнейшей доработки. И затраты на эту доработку целиком лягут на клиента, поскольку без ТЗ доказать, что «об этой кнопке мы договаривались», будет невозможно.
Что еще дает ТЗ заказчику? Помогает защититься от недобросовестных исполнителей, поскольку является главным аргументом в случае неполного соответствия результата ожиданиям.
Но главное!
Предположим, клиент обращается по поводу разработки сайта к проверенному подрядчику с годами наработанной репутацией, отличным портфолио и отзывами. То есть, недобросовестное отношение к работе исключено.
Но обычно клиент обращается в веб-студию, не имея четкого понимания, что ему нужно. Чтобы точно сформулировать изначально разрозненные мысли, пожелания, формулировки — нужно составить ТЗ на сайт, разложив в нем все по полочкам. Ведь начинается все обычно с формулировок, реализовать которые не представляется возможным.
Например: «Сайт должен быть удобным» - удобным для кого и для чего? «Сайт должен работать с большим количеством товаров» - большим это сколько? 100 или 100 000?
Что дает ТЗ подрядчику?
Прежде всего, четко поставленные задачи. Детальное описание всех нюансов будущего интернет-ресурса позволяет ускорить процесс его создания, и в то же время защищает веб-студию от необоснованных требований по созданию функционала, изначально не обговоренного и не входящего в стоимость.
Кто должен составлять ТЗ?
Техническое задание должен составлять заказчик. Только он — в особенности на начальном этапе работы — владеет информацией о своем проекте, знает специфику своего бизнеса и ориентируется в том, какие возможности необходимы для эффективной работы. Задача подрядчика — грамотно реализовать его идеи в интернет-пространстве.
Даже такой набросок от руки уже дает разработчику информацию о пожеланиях заказчика
На практике нередко заказчик не может четко сформулировать ТЗ. Ведь владелец или управляющий магазина, медицинского центра или адвокатской конторы вряд ли должен понимать что-либо в веб-разработке и составлении технической документации. И тогда студия пойдет ему навстречу, выделив разработку технического задания, а при необходимости и сопутствующую аналитику, в отдельный подготовительный этап работы.
Что должно быть в ТЗ
Независимо от того, кто будет заниматься разработкой технического задания, знать о его структуре будет, как минимум, не лишним.
Информация о компании
Понимание особенностей бизнеса клиента — крайне важная составляющая успешной разработки сайта. Поэтому в разделе информации о компании стоит максимально подробно описать направления деятельности, целевую аудиторию сайта, а также те задачи, которые должен решать сайт. Если новый ресурс создается, как замена уже существующему сайту, нужно подробно описать проблемы нынешнего сайта и причины, по которым было принято решение о его замене. Чем больше информации — тем глубже разработчикам удастся вникнуть в суть задачи — и тем лучше будет результат!
Глоссарий терминов
Далеко не каждый клиент знает, что такое сайдбар, хедер или футер. Поэтому, особенно если ТЗ составляет разработчик, важно предоставить заказчику своеобразный словарь терминов, используемых в технической документации. Это поможет избежать недоразумений и облегчит дальнейшее общение.
Фрагмент глоссария — элемента ТЗ на разработку сайта
Технические особенности
В этом разделе нужно максимально отобразить все требования к технической части будущего сайта. Даже те, которые на сегодняшний день очевидны. На практике, этот пункт нередко игнорируется, а зря.
С точки зрения логики — нет смысла сегодня писать в ТЗ, что сайт должен быть адаптивным, то есть корректно отображаться на мобильных устройствах со всем разнообразием их размеров экрана. Кроссбраузероность — тоже вроде бы «по умолчанию». Но на деле такие моменты тоже лучше прописать в ТЗ.
Иногда в этом разделе технического задания указывается система управления (CMS), которую хочет видеть заказчик в качестве платформы для сайта. Но как раз этот момент лучше обсудить со специалистами веб-студии: они однозначно лучше владеют информацией, на какой CMS получится максимально реализовать необходимый клиенту функционал.
Требования к стилистическому и графическому оформлению сайта
Здесь, конечно же, оптимальным будет предоставление графического макета. Но зачастую его у заказчика нет, и тогда нужно максимально подробно изложить требования к оформлению сайта в техническом задании, чтобы дизайнеру было от чего оттолкнуться. Хорошо, если к изложенным словами в ТЗ требованиям будет приложен, например, бренд-бук компании или примеры дизайна ее полиграфической продукции (буклетов, рекламы и т.д.)
Фрагмент раздела требований к стилистическому и графическому оформлению сайта.
Структура сайта
Это своего рода план-схема сайта. Для наглядности лучше использовать древовидные или иерархические модели. Но, чтобы работа с этим разделом ТЗ не вызвала сложностей, рассмотрим некоторые особенности «анатомии» сайта. Вот его основные элементы:
- сквозные элементы;
- уникальные страницы;
- прочие (служебные) страницы
А теперь подробнее. Сквозными называются те элементы, которые присутствуют на любой странице сайта. Это header (шапка) сайта, footer (подвал), сайдбары (боковые панели), а также формы обратной связи, всплывающие окна, если они есть на всех страницах. Уникальные страницы — в данном случае, термин не совсем прямолинейный. Скорее можно сформулировать так: уникальные шаблоны страниц. Например, для каталога интернет-магазина уникальными страницами будут макеты страницы раздела, страницы подраздела и страницы товара. Также скорее всего понадобятся макеты страниц новостей, статей, акций, о компании, контакты и ряда других.
Какие же тогда страницы относятся к прочим или служебным? Это страницы фильтров, сортировок, результатов поиска, входа и регистрации, а также страница ошибки 404.
Понимая приведенную выше информацию, уже гораздо проще будет составить древовидную структуру будущего сайта и описать детальные требования к каждому типу страницы.
Пример структуры сайта
В идеале, у каждой будущей страницы должен быть прототип или эскиз. В крайнем случае — текстовое перечисление блоков и элементов каждой уникальной страницы.
Функциональные требования к сайту
К функциональным требованиям, которые стоит отразить в ТЗ на создание сайта, относятся языковые версии будущего сайта, язык и функционал административной панели, классы пользователей и требования к правам их доступа.
Фрагмент раздела ТЗ с функциональными требованиями
Здесь также можно (и нужно!) расписать сценарий работы сайта. Необходимо, чтобы всем — и заказчику, и разработчику — было предельно понятно, как будут пользоваться сайтом и его элементами. Например:
- пользователь нажимает кнопку «заказать сайт»;
- сайт открывает форму заказа;
- пользователь вводит данные: телефон, адрес электронной почты, нажимает кнопку «отправить»;
- сайт выдает сообщение «Спасибо, Ваш заказ принят»;
- на электронную почту менеджера отправляется заполненная заявка посетителям
Пример требований к функционалу интернет-магазина
Требования к поисковой оптимизации
И, наконец, то, о чем многие забывают — поисковая оптимизация будущего сайта. По умолчанию большинство современных CMS уже более-менее оптимизированы, но это не значит, что работы по SEO можно проигнорировать. В ТЗ стоит подробно прописать требования к текстам (если контент сайта создает разработчик), метатегам страниц и изображений, самим изображениям, скорости загрузки страниц, соответствию тестов поисковых систем на совместимость с мобильными устройствами.
Пример требований к поисковой оптимизации сайта
Итог
Единого образца ТЗ на все случаи жизни не существует. Технические задания для разработки одностраничного сайта, небольшого интернет-магазина или социальной сети заметно отличаются как по структуре, так и по содержанию. Но если и общие черты: в любом ТЗ нужно максимально подробно изложить требования к дизайну, функционалу, структуре сайта и не забыть о поисковом продвижении. А при возникновении любых сложностей с созданием ТЗ стоит обращаться к разработчику — он в такой же степени, как и заказчик, заинтересован в грамотной и подробной документации, поэтому всегда пойдет навстречу!