Согласно новым трендам в сайтостроении, особенно на западе, типичные технические задания уже уходят в прошлое. А в совершенном настоящем уже рулит прототипирование узлов, модуле и страниц будущих сайтов.
Не согласимся с таким подходом, ведь для того, что описать механику работы того или иного узла сайта, надо тщательно прописать шаги по пунктам 1,2,3… К сожалению ни один прототип этого не покажет. Но у прототипов есть свои преимущества – это возможность показать черновой визуал будущей страницы.
Зачем нужны доработки сайта в SEO-продвижении
80% сайтов, которые к нам попадают, требуются переработок. Иногда это чисто визуальная ретушь устаревших форм или блоков цен, но чаще всего это работа со следующими вещами:
- Переработка навигационных цепочек и сценариев, начиная от меню и, заканчивая иерархиями и вложенностями
- Переработка с нуля компонентов и инфоблоков, отвечающих за вывод прайсов
- Создание новых форм: обратная связь, заявки на кредиты и рассрочки, перелинковочные формы и многие другое.
- Переработка адаптивной версии ресурса
- Создание калькуляторов
- Разработка квизов и калькуляторов, конфигураторов и тест-форм
- Ускорение сайта
Улучшение восприятия ресурса в глазах простого интернет-пользователя заключается в мелочах и деталях. Но для поискового продвижения это дает сильнейший толчок в ранжировании. Достигается это благодаря изменению поведения пользователями.
С чего начать разработку
Как правило, на стороне заказчика нет ни желания ни ресурсов для внедрения изменений на сайте. Мы стараемся на первом этапе поискового продвижения отдавать 2 пакета правок:
- Первый пакет: обязательные работы по внедрению SEO-настроек (robots, sitemap, настройка канонических урлов, настройка 301-х команд, устранение битых ссылок и прочее)
- Второй пакет: глобальные доработки коммерческих элементов (сюда входят блоки форм, калькуляторы, перелинковочные формы, фильтры, сортировки и многое другое)
Коммерческие факторы – это сильнейшие точки роста коммерческого трафика. Мы делаем для своих клиентов «улучшайзеры», которые поднимают посещаемость минимум на 60% в рамках нескольких периодов.
Начинать разработку нужно начать с:
- Консультирования рабочей группы, которая состоит из SEO — оптимизатора, программиста, аккаунт-менеджера, дизайнера, верстальщика
- Приведения требований к разработке к единому понимаю результата
- Общему консенсусу и согласованию начального этапа разработок с Заказчиком
Прототипирование и техническое задание
После согласования обязательных и дополнительных доработок, дизайнер начинает в рамках стиля сайта клиента рисовать прототипы. Мы в своей работе используем лучший инструмент. Конечные прототипы согласовываются с Заказчиком.
Прототипы – это визуальная часть работы, которая на 100% снижает риск возникновения непонимания и конфликта сторон. На этапе дизайна и внедрения значительно экономится и время и деньги всех сторон.
Внедрение и тестирование работ
Мы опускаем вопрос дизайна и переходим к внедрению. И тут самое важное – тестирование. Недорогое программирование на фрилансе или «удаленке» плохо тем, тем что тестированием модулей будете заниматься Вы.
Происходит все следующим образом:
- Внедряется модуль
- Поверхностно проверяется программистов
- Отдается на тестирование приемщику
- На 75% что-то работает не так, потому что не было уделено время тестированию
- Приемщик проверяет и находит ошибки, тратя много времени
- Приемщик готовит пакет правок и отдает программисту или верстальщику (в данном случае не очень важно)
- Программист берет задачу в работу и цикл закрывается.
Такая ситуация может повторяться очень и очень долго. Потому что недорогой программинг – это как правило только внедрение без проверки работы. Недорогой программинг – это в 45% «костыли» при разработке тех или иных модулей и узлов. Под костылем мы пониманием написание новых компонентов при возможности использовании базовых, а также некорректный код.
Рекомендуем использовать только проверенных технических специалистов и не вестись на предельно низкие цены на разработку.
Как сделать эффективное ТЗ программисту
Техническое задание должно быть детализированным
Нужно максимально подробно описать работу каждого элемента, который требуется доработать. Писать его должен опытный маркетолог и оптимизатор, ведь именно этим люди знают подводные камни процессов и того, что не на поверхности. Именно от этих людей будет зависеть успех поискового продвижения или общей конверсии сайта. Поэтому пишите просто и детально.
Оно должно едино трактоваться всеми сторонами
Единая система координат должна быть у всех участников процесса. У заказчика должно быть четкое понимание, что он получит на выходе; у маркетолога как это все будет конвертироваться и сколько лидов будет сделано по заданным KPI; у программиста – как внедрять, писать новый компонент или поставить плагин и тд; у SEO-оптимизатора какая структура страниц будет выведена или типа того.
ТЗ должно быть написано человеческим языком
Меньше сложной терминологии. Берем обычный вордовский документ и делаем в нем табличку. Фиксируем название доработки, во втором столбике указываем расширенное описание того, что хотим создать или преобразовать. В третьем столбце – оценка часов и комментарий технарей. Для таких целей отлично подойдет инструмент совместного использования – Гугл Таблицы
ТЗ требует обсуждения голосом
Проверено годами на собственной шкуре – невозможно до конца понять, понимает ли тебя другой человек, пока с ним не проговорить это голосом. Мы не знаем почему так, но только личная или скайп-конференция позволяет вовлечь всех участников в обсуждение ТЗ и таких планерках вскрывает то, что может сэкономить десятки и сотни тысяч рублей заказчика.
Написанное ТЗ нельзя отдавать сразу, переспите с этим
Маркетолог, который пишет техническое задание не должен сразу отдавать документ на обсуждение. Как показывает практика, лучше отложить документ и переспать с этой идеей. На следующей день то, что казалось сложным, можно реализовать по-другому, а что-то вообще лучше не трогать. Идеальный срок на создание ТЗ – около 3-х дней. Такого срока достаточно что создать обдуманный и сбалансированный документ на доработку.
Всегда придерживайтесь утвержденного документа
Это касается уже процесса, потому что программисты бывают разными и 10-30% отклонение от изначальных прототипов, дизайна или верстки для многих спецов – норма, но не для нас, маркетологов. Так быть не должно. Нужно требовать 100% исполнения верстки и механики.
