Можно ли сделать классный сайт без внятного технического задания, или попросту ТЗ? В теории да, но на практике вряд ли. Ни один вменяемый разработчик не возьмется за дело без грамотного техзадания. Исполнитель должен четко понимать, чего хочет заказчик, а не играть в волшебника и угадывать чужие желания.
Сегодня расскажем о том, как написать хорошее техническое задание на разработку сайта. На первый взгляд, в сети полно примеров ТЗ — нужно только найти подходящий образец, скачать его и приступить к делу. Если бы все было так просто, вы бы не читали эту статью. Разберемся, что следует писать в техзадании, а чего нужно избегать.
ТЗ на разработку сайта, что ты такое?
Техническим заданием называется документ, где подробно рассказывается, каким заказчик видит будущий сайт с технической стороны, в плане юзабилити, с точки зрения отображения контента. Чем информативнее и конкретнее ТЗ, тем лучше для всех: разработчик действует по плану, а клиент получает нужный результат. Посмотрим, какие плюсы получает каждая из сторон.
Преимущества создания ТЗ для заказчика
Техническое задание позволяет клиенту:
- Спланировать бюджет. Благодаря ТЗ заказчик может узнать, во сколько обойдется создание веб-ресурса.
- Оценить профессионализм разработчика.Техзадание, в котором все разложено по полочкам, показывает, что исполнителю можно доверять.
- Ускорить процесс согласования. С грамотным ТЗ проще вести конструктивный диалог.
- Защитить свои интересы. Заказчик может проверить, насколько готовый сайт соответствует техзаданию. При выявлении неточностей исполнитель должен будет их исправить.
- Быстро сменить разработчика. Иногда пути заказчика и исполнителя расходятся — бывает, жизнь продолжается. Если работа над сайтом зашла в тупик, можно просто найти другую команду, передать ей техзадание и не тратить время на многочасовые объяснения.
Преимущества создания ТЗ для исполнителя
Техническое задание необходимо и разработчику. Оно помогает:
- Понять, чего хочет клиент. Важно, чтобы исполнитель точно знал, какой результат нужен заказчику. Когда все нюансы четко прописаны в ТЗ и одобрены клиентом, можно приступать к работе.
- Продемонстрировать свою компетентность. Хорошее ТЗ показывает клиенту: «Мы знаем, что делаем, нам можно доверять».
- Быстро адаптироваться к переменам. Техзадание — отличная страховка от разных внезапностей. Например, при смене менеджера проекта можно быстро ввести нового человека в курс дела. Или другая ситуация: у заказчика временные финансовые трудности, поэтому работа приостанавливается. Когда все стабилизируется, исполнитель сможет быстро сконцентрироваться на проекте.
- Защитить свои интересы. Работа в разгаре, а заказчик решил все изменить? Так не пойдет. При согласованном и подписанном ТЗ можно не волноваться: даже суд примет сторону исполнителя.
- Получить дополнительный доход. Многие разработчики предлагают оплатить составление ТЗ как отдельную услугу.
В общем, одни плюсы для обеих сторон. Важно понимать, что техническое задание — это не «какая-то инструкция для программистов и дизайнеров». Все серьезно. ТЗ — это документ, который имеет юридическую силу. При этом техзадание не заменяет договор между заказчиком и исполнителем.
Кто составляет ТЗ на разработку сайта
Лучше всего, когда клиент и исполнитель вместе трудятся над созданием ТЗ, ведут живой диалог и приходят к оптимальному решению. В реальности составление техзадания чаще всего ложится на плечи разработчика. Это логично: заказчики не знают многих нюансов, в которых разбирается исполнитель. Именно поэтому разработчику стоит составить ТЗ, предложить клиенту ознакомиться с документом и ответить на возникшие вопросы. Чтобы сэкономить время и помочь исполнителю, заказчик может заполнить бриф. Так называется документ с базовыми вопросами о том, каким клиент представляет сайт своей мечты.
*Клиент представляет сайт своей мечты
Какие моменты нужно учесть при составлении ТЗ
Правильное ТЗ — это объективность и конкретика. Формулировки в техзадании должны быть максимально четкими. Если в документе прописываются какие-либо критерии, важно, чтобы они подлежали объективной оценке. Для примера возьмем характеристику дизайна. «Нежный», «дерзкий», «комфортный» — все это очень субъективно. Другое дело — «фон страниц оттенка пыльной розы PANTONE 17-1718 TCX Dusty Rose».
Еще один момент: когда заказчик обозначает свои пожелания, он не обязан знать, как разработчик их осуществит. Следовательно, в случаях, которые не упомянуты в ТЗ, исполнитель может действовать по своему усмотрению. Этот момент также стоит прописать в заключительной части техзадания.
Важно: поскольку ТЗ является документом, необходимо убедиться, что оно грамотно составлено с точки зрения орфографии, пунктуации и стилистики. Ошибки, опечатки, «кривые» формулировки — этого лучше избегать.
Теперь перейдем к главному — тому, из чего состоит техзадание на разработку сайта.
Рецепт хорошего ТЗ: разбираем ингредиенты
Техническое задание включает несколько разделов. Они могут по-разному называться, но смысл не меняется. Посмотрим на «начинку» ТЗ.
Раздел с организационными моментами
Здесь нужно прописать срок сдачи проекта. Сразу обозначим, что речь идет о средних показателях. Например, небольшой веб-ресурс на шаблоне можно запустить уже через 1–1,5 месяца после старта работ. А вот создание многостраничного портала, да еще и с самописным кодом, может занять и более полугода.
Кроме того, в этом разделе следует подробно описать объем работ. Все зависит от сложности поставленной перед исполнителем задачи.
Раздел с требованиями к сайту
Здесь будет несколько подразделов, о которых мы сейчас и поговорим.
Сценарий использования сайта
В этом подразделе нужно прописать, для чего вообще создается ресурс — будет ли это интернет-магазин, информационный портал или визитка. Кроме того, важно указать целевую аудиторию. Исполнитель должен понимать, для какого пользователя предназначен сайт. В подразделе также нужно прописать, какие целевые действия будут совершать посетители веб-ресурса. Важно четко разложить, что должно происходить при нажатии на ту или иную кнопку. В дальнейшем исполнитель детализирует движение пользователя по сайту. Речь идет о User Flow — визуализации каждого шага, который совершает посетитель ресурса.
CMS сайта
CMS (Content Management System), или движок, — это «скелет» веб-ресурса. В техзадании необходимо указать, какой вариант выбрал клиент:
- самописный движок;
- конструктор, например, Tilda;
- популярную CMS — «1С-Битрикс» или WordPress.
Часто заказчик не может определиться, какая CMS ему нужна. В таком случае помогут наводящие вопросы, кто будет выполнять функцию администратора, выкладывать контент, заниматься обслуживанием сайта.
По личному опыту можем сказать, что среди всех CMS выделяется «1С-Битрикс». Это решение от российских разработчиков часто используется при создании веб-ресурсов. Система интуитивно понятна и проста в управлении, а при необходимости сайт на «1С-Битрикс» легко «допилить».
Требования к структуре
Содержание этого подраздела зависит от типа сайта. Для примера возьмем интернет-магазин. В ТЗ на разработку такого ресурса нужно указать, какие элементы должна включать структура:
- хедер («шапка») с названием и логотипом магазина;
- блок с меню (здесь должны быть категории «Каталог», «Главная», «Информация для покупателей» и т. д. Для каталога нужна четкая структура — ее также необходимо раскрыть в ТЗ);
- блок с новостями;
- блок с отображением новых товаров;
- блок с отображением расширенного поиска;
- футер («подвал») со ссылками на соцсети бренда или другой информацией.
Это примерный список, а на практике все зависит от сферы деятельности компании, концепции площадки, потребностей аудитории и т. д.
Технические требования
В этом подразделе следует указать, каким техническим критериям должен соответствовать сайт. Вот примерный список требований:
- наличие версий для корректного отображения на телефоне, планшете, ноутбуке и т. д., чтобы сайт адаптировался под любые пользовательские устройства;
- кроссбраузерность (корректное отображение в любом браузере);
- наличие карты сайта и robots.txt;
- использование человекопонятных УРЛов (ЧПУ);
- базовая оптимизация веб-страниц;
- настройка систем аналитики;
- интеграция со сторонними сервисами.
При создании сайта с нуля особенно важным этапом становится выбор доменной зоны, доменного имени и хостинга. Обо всем по порядку.
Начнем с доменной зоны. При запуске коммерческого проекта, рассчитанного на международный рынок, стоит выбрать зону .com или .net. Если владелец будущего сайта планирует работать на территории РФ и стран СНГ, оптимальный вариант — зоны .ru, .su и .рф.
Что касается доменного имени, то оно должно легко запоминаться и содержать название компании, ключевые слова или тематику сайта. Вот примеры:
- rubix.su;
- детскиеигрушки.рф и т. п.
Теперь о хостинге, т. е. месте, где «живет» сайт. Оно определяет доступность веб-ресурса и стабильность его работы. В техзадании нужно указать:
- тип хостинга — в облаке, на физическом или виртуальном сервере;
- наличие защиты от DDoS-атак;
- объем пространства для сайта;
- ориентировочное количество пользователей на ресурсе за сутки;
- опцию бесплатного переноса сайта на другой хостинг.
*Заказчик, который на 100% определился с именем домена
Описание и содержание страниц
При составлении ТЗ нужно обязательно обсудить наличие контента, иначе заказчик может получить пустой сайт. В случае с содержимым веб-страниц есть два варианта:
- Контент создает заказчик.
- За наполнение страниц отвечает разработчик.
Во втором случае техзадание должно содержать информацию о качестве контента: список ключевых слов и фраз, количество вхождений, требования к уникальности и др. Если при создании текстового контента необходимо участие экспертов, этот момент также стоит прописать в ТЗ. Кроме того, нужно указать требования к медиафайлам: изображениям, видео, инфографике и др. Разработкой контента может заняться исполнитель. Отметим, что в таком случае стоимость реализации проекта повышается. Еще один момент: не все подрядчики оказывают комплексные услуги. Некоторые компании занимаются только технической разработкой, поэтому при сотрудничестве с такими исполнителями вопрос с контентом нужно решать отдельно.
Еще один важный аспект — особенности создания служебных страниц:
- страницы 404;
- страницы с соглашением на обработку пользовательских данных;
- страницы фильтров;
- страницы с информацией о способах оплаты и доставке.
Особого внимания требует оптимизация страниц-фильтров. Это задача для SEO-специалистов. Оптимизация страниц-фильтров не имеет прямого отношения к разработке, но в дальнейшем сыграет положительную роль. Если заказчик готов оплатить эту дополнительную услугу, тогда в техзадании необходимо указать:
- Использование только статических ссылок для фильтров первого уровня и пересечения более двух параметров. Кроме того, для таких страниц обязательна возможность самостоятельной настройки Title, Description и заголовков H1–H6.
- Порядок формирования УРЛов страниц-фильтров.
- Настройки индексации страниц-фильтров, а также их внутренней перелинковки.
Кроме того, в ТЗ стоит добавить прототипы страниц, т. е. наброски. Можно прикрепить сами черновики либо подробное описание вида страниц. Еще один вариант — проработать страницы на этапе создания дизайна.
Описание дизайна
В начале статьи мы уже говорили о том, что здесь нужно избегать расплывчатых формулировок. Никакого «стильного», «яркого», «брутального» или «продающего» дизайна быть не должно.
И заказчику, и исполнителю будет проще, если у клиента есть брендбук. Так называется документ, в котором содержится руководство по использованию визуального стиля компании. Если брендбука нет, не беда. В таком случае в ТЗ нужно четко прописать следующие требования к оформлению страниц:
- набор шрифтов;
- палитра оттенков (главные и дополнительные цвета);
- разрешенные цветовые сочетания;
- тематика изображений (обычно материалы предоставляет заказчик — этот момент нужно отметить в договоре).
А вот так не надо: распространенные ошибки при составлении ТЗ
Посмотрим, какие недочеты заказчики и исполнители допускают чаще всего.
Не указан тип сайта
Если клиенту нужен имиджевый сайт, а разработчик создает интернет-магазин, недопонимания не избежать.
В ТЗ не прописаны целевые действия пользователей
Эта информация необходимо для базовой настройки аналитики. Если заказчик хочет, чтобы пользователи совершали покупки или оставляли контакты, важно прописать такое требование в ТЗ.
Отсутствуют референсы
Чтобы получить нужный результат, клиенту стоит указать исполнителю верное направление. Примеры сайтов, которые нравятся заказчику, не будут лишними.
Обтекаемые формулировки
Конкретика, конкретика и еще раз конкретика! Мы не зря акцентируем внимание на том, что формулировки должны быть максимально четкими. Отсутствие конкретики может стать лазейкой и для заказчика, и для исполнителя. «Мы вообще не то имели в виду! Сказали же, хотим стильный дизайн! — Мы и сделали стильный, что вам не нравится?» — примерно такие диалоги происходят, если в техническом задании используются расплывчатые формулировки.
*Когда прочитал ТЗ с непонятными формулировками
Заключение
Тщательно проработанное ТЗ — это документ, который защищает интересы и заказчика, и исполнителя. Можно скачать из сети хороший шаблон и адаптировать его под конкретный проект либо написать техзадание с нуля. Главное, чтобы обе стороны говорили на одном языке. Тогда исполнитель сможет сделать классный сайт, а заказчик будет доволен.
