ТЗ на разработку сайта: этапы и примеры

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

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

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

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

^{Если художник хотя бы говорит, что он так видит, то разработчик часто не видит никак, потому что для него важен код и только код…}

Из чего состоит ТЗ на разработку сайта

Общие требования

Это те моменты, которые вам важны для работы с сайтом и его правильного отображения. Вы прикрепляете ссылку на дизайн (дополните его комментариями по необходимости, например, если где-то нужна анимация), и также на гайдлайн. Можно прислать и само ТЗ, отданное дизайнеру, чтобы разработчик вникнул в процесс изнутри.

^{Наш образец ТЗ на разработку сайта: начало}

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

Далее указываются требования к конкретной CMS, на которой делается сайт. Мы, работая чаще с WordPress, пишем про то, какие инструменты использовать для меню, блоков, кнопок, а также напоминаем, где информация должна подтягиваться автоматически, а не заполняться вручную на каждой странице. А вот для MODX и “Битрикс” важно указывать, допустим, про смену метатегов через админку, редактирование robots.txt и генерацию sitemap.

Работа со страницами

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

^{Пример ТЗ для разработчика на конкретную страницу и отдельные ее блоки}

Описывая шаблоны страниц, нужно указать, какие блоки на них будут выводиться и в каком порядке. Как описывать сами блоки? На этом этапе разработчик уже познакомился с дизайном, так что вам осталось объяснить свои технические требования:

• Какой формат для фото нужно использовать;
• Как загружается видео (через админку или ссылками с площадок);
• Какие HTML-теги нужны для работы с текстовым контентом;
• Где нужна возможность менять текст на кнопке, а где не нужна и сама кнопка.

^{Так выглядит наш шаблон ТЗ для разработки отдельных блоков}

Что еще должно быть в ТЗ разработчику

• Четкий дедлайн;
• Объяснение СЕО-терминов и терминов из бизнес-ниши клиента);
• Скриншоты и референсы.

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

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

На этом у нас всё. Помните: будьте к своим коллегам добрее и терпимее, и они ответят вам тем же. Мир, дружба, разработка.

Подписывайся на наши соцсети — там мы рассказываем о своей работе и анонсируем новые статьи: LZ.Media в ВК и телеграм.