От портрета ЦА до договора: как подготовиться к разработке сайта? Часть 2

Поделиться

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

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

Рекомендации по подготовке к разработке сайта дает Дмитрий Хоружко, руководитель web-студии Nineseven.

rasrabotka_03_new.png

Шаг 1. Портрет ЦА, customer journey map 

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

Если ты, например, продаешь путешествия, основная твоя аудитория – люди, которые будут искать путешествие, люди, которые не любят «заморачиваться» по букингам. Нам необходимо представить портрет такого человека. Также важно выстроить customer journey map – то есть путь потребления, понять, как пользователь попадет на твой сайт, какая у него мотивация, что он ищет, чего он боится. Например, клиент может бояться, что заплатит 700 долларов, как написано в карточке тура, а потом попадет на «помойную» гостиницу, и за все остальное будет еще платить дополнительные деньги. Поэтому ему нужно четко написать, что будет входить в стоимость путевки. Как только будет расписан такой сценарий потребления, тогда будет понятно, какая структура должна быть у сайта.

Например, пользователь приходит на сайт туристической компании и вместо того, чтобы увидеть горячие туры или список стран, ему приходиться смотреть флэш-ролик о том, какая крутая эта туристическая компания. При этом сайт весит 10 ГБ, а пользователь ждет, пока он грузится. Скорее всего пользователь уйдет с такого сайта.

Шаг 2. Контент

Далее нужно определиться с контентом. Он будет влиять на программирование и управлением сайтом. Бывает такое, что ты квадратный брусок пробуешь засунуть в круглую дырку. Это означает, что контент не был продуман изначально. Получается, ты сделал шикарную дырку, и приходит к тебе клиент с бруском и говорит: «ну давайте что-нибудь придумайте». И мы берем нож, и давай брусок исправлять до круга. В итоге получаются щели, засоры. Представляете результат такой работы?

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

Лучше всего клиенту будет создать файл с подготовленным заранее контентом — согласно структуре. Это и план контента — и сам контент. Потом дизайнеру показывается этот контент, и он начинает с ним работать. Только так можно избежать множество ошибок.

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

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

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

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

Шаг 3. Каналы продвижения

Затем нужно выписать все каналы, которые будут использоваться клиентом для продвижения.

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

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

Если планируете e-mail маркетинг, нужно продумать форму захвата e-mail’ов. Кстати, важно продумать не только форму подписки, но и мотивацию.

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

Шаг 4. Интеграции

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

У одного клиента — была интеграция с API в техзадании.. В запросе была прописана определенная логика, как это необходимо реализовать. Мы реализовали это, а потом выяснилось, что API биллинга клиента не предоставляет таких функций вообще. С интеграциями нужно продумывать всю логику: образец файла выгрузки, параметры обмена, частота, структура данных и так далее, здесь надо быть очень дотошным. Иначе клиент выбросит деньги на ветер.

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

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

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

Шаг 5. Технические требования

Еще важный момент – технические требования к проекту, к системе. У нас был проект с огромной базой товаров, который клиент хотел реализовать на Битриксе. У нас были большие сомнения, на счет того, что Битрикс сможет выдержать такую нагрузку. Соответственно, нужно было провести нагрузочный тест, который показал, что Битрикс даже 100 000 товаров не выдерживает, не говоря о 400 000.

На самом деле, техническое задание должно содержать листов так 30. Бриф нужен студии скорее для того, чтобы узнать ожидания клиента, узнать, какой тип сайта нужен клиенту – интернет-магазин, визитка, каталог и так далее. Бриф нужен для определения поверхностных границ проекта. А также для первого знакомства студии и клиента.

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

Нам однажды клиент прислал просто список интеграции. И хотел получить адекватную оценку проекта. Это оказалось просто невозможным. С такой формой технического задания неопытные студии выставляют 3 000 долларов, а потом клиент получается что-то, что просто не работает.

Лучше заплатите 1000 или 2000, пусть студия потратит 40 или 60 часов – и разберется во всех интеграциях, которые вам нужны. Специалисты пообщаются с программистами, напишут нормальное техническое задание и сделают реальную оценку.

С какой информацией должен прийти клиент в студию в итоге?

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

Один из наших клиентов поступил мудро — он провел сначала тендер на техническое задание на интернет-магазин, и только после этого — подал техническое задание и организовал с ним второй тендер.

Если клиент боится и не может работать по Agile, по гибкой методологии, и хочет фикс прайс, тогда нужно нормальное техническое задание. И заказывать его за деньги – это тоже нормально.

Шаг 6. Договор

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

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

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

rasrabotka_04.png

Есть несколько критериев, по которым нужно выбирать студию.

Рекомендации. Если студия качественно выполняет свою работу – ее обязательно порекомендуют. Спросить у знакомых, был ли у них опыт работы по сайтам и какие у них были впечатления.

Рейтинги. Их нужно обязательно смотреть. Сейчас очень много есть рейтингов по специализациям – web-студии, интеграторы и так далее. Затем сужать выборки и смотреть компании, которые тебе подходят.

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

Сначала собрать лонглист, исходя из задач, формируя параллельно критерии для отбора. Хочешь, чтобы подрядчик был в шаговой доступности, выбери свой регион. Затем собери рекомендации, рейтинги.

После этого сделай short-лист, выбери студии, которые объективно нравятся, у которых хороший сайт, у которых есть приятные работы твоей тематики или схожей. Кейсы тоже у всех студий разные – обратите на это внимание. Кто-то пишет: «мы нарисовали крутую главную страницу», а кто-то пишет: «мы добились повышения конверсии». Бывает клиенты прямо так и обращаются в студию, видят у нас в портфолио сайт и говорят, что хотят такой же. Так можно сформировать длинный список.

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

Вы готовы!

Об авторе статьи:

Дмитрий Хоружко. Опыт работы над онлайн-проектами — более 11 лет, 5 из которых Дмитрий руководит собственным агентством веб-разработки Nineseven. Участвовал в проектировании электронного правительства Казахстана, работал над проектами для Газпрома, МТС, Билайна, ХоумКредит Банка и др.



Поделиться
Материалы по теме:
Обсуждение:
Читайте также: