Как получить от разработчиков именно то, что нужно вашему бизнесу

Сегодня статья о том, с чего начать проект, на что стоит обратить внимание, как общаться с разработчиками и о том, как избежать проблем при разработке проекта.

Краткое содержание:

1. Предпроектная аналитика и сбор требований.

2. Как понять, какой функционал будет полезен в текущий момент и быстро окупить вложения (MVP).

3. Как НЕ нужно делать.

Предпроектная аналитика и сбор требований

Анализ конкурентов на рынке

Когда компания выходит в онлайн, в 99% случаев рынок уже разделен между конкурентами. Если вам кажется, что вы оказались единственными, то у вас или настолько классный продукт, что у него нет конкурентов и тогда автоматически, или он никому не нужен.

Вернемся к нашему рынку. Наверняка, задумываясь о выходе в онлайн вы смотрите на сайты конкурентов и определяете для себя «‎топов» в отрасли.

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

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

По итогу этого этапа получаем информацию о том какой крутой функционал используют наши конкуренты и как применить его на нашем проекте.

Исследование стейкхолдеров (заинтересованных лиц)

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

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

• Сервисники. Покупают запчасти к проданному им ранее оборудованию.
• Сетевые магазины. Покупают для продажи конечному покупателю.
• Менеджеры по закупкам. Покупают товар для нужд предприятия.

Это далеко не полный список возможных ролей.

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

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

Не забываем и про внутренних стейкхолдеров, тех кто взаимодействует с сайтом по работе: менеджеры по продажам, маркетологи, руководители отделов.

Например, для маркетологов важна статистика по отдельным направлениям (розница и опт), настройка скидок, предложений, размещение маркетинговых материалов.

Руководителям важно понимать сколько было заказов, сумма, сколько отмененных заказов и почему. А ещё маржа, продажа маркерных товаров, «‎висяки‎».

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

Так важно знать, какой это клиент (новый, старый), посмотреть историю взаимодействия с этим клиентом.

Построение дорожной карты развития проекта.

После того как мы провели аналитику и определились с тем, кому нужен товар и каким способом им удобнее покупать, образуется список из задач (Бэклог). Из этих задач будут формироваться четкие спринты с понятными сроками и результатами.

Кидаться в случайном порядке от задачи к задаче – не наш подход, мы за осмысленную продуктивность!

Работаем

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

Понятность и прогнозируемость позволит:

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

Как понять, какой функционал будет полезен в текущий момент и быстро окупить вложения (MVP)

MVP+штатный функционал для опта 

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

Этот подход подходит для тех компаний, у которых еще нет сайта и они только собираются выходить в онлайн.

Что это такое MVP и зачем он нужен?

MVP - минимально жизнеспособный продукт. Это продукт с набором функционала, который позволяет пользователю найти и оплатить нужный товар.

Перечень функционала, который потребуется MVP:

1. Каталог товаров (очевидно, не так ли?).

2. Удобный и понятный способ коммуникации с вами (лучше несколько):

• чат;
• форма обратной связи;
• полноценный заказ;
• покупка в 1 клик;
• звонок;
• отправка письма на почту.

Вообще все равно как, лишь бы вы узнали о том, что вашим продуктом интересуется покупатель.

3. Страницы, с помощью которых, клиент знакомится с компанией. Мало кто уделяет внимание таким страницам как «‎О компании‎» и «‎Оптовикам‎», либо «‎Партнерам‎».

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

Не всем очевидна проблема отсутствия страницы для оптовых покупателей. Если на сайте нет ни страницы, ни баннера, ничего что говорит о том что компания работает не только в розницу, то?

Для MVP достаточно текстового описания условий оптовой покупки и формы обращения в компанию.

Но мы любим и умеем развивать проекты, поэтому подходим к этой странице как к странице «‎О компании‎», стараясь заставить наших заказчиков рассказать о преимуществах работы по оптовой схеме.

Вот примеры того, как выглядят эти страницы: polusplus.ru, neskyuga.ru

4. Сделать файл/прайс, который клиент загружает и использует для передачи данных ЛПР (ком.директор, финансист, владелец, принимающий решение о закупках), формирования заказ offline или совместно с удаленной командой, корректировки цены и передачи своим покупателям и еще 1000 кейсов применения прайсов. Создание этого функционала на сайте занимает немного времени, но результат несет ни с чем не сравнимую пользу.

5. Настройка оплаты на сайте, любой удобный способ для ваших клиентов:

• по корректно сформированному счету (важно для юрлиц);
• банковской картой;
• в рассрочку или кредит.

6. Настройка доставок.

Можно подключать готовые модули автоматического расчета доставки популярными транспортными компаниями, или настроить свои типы:

• самовывоз со склада;
• доставка на склады и в магазины сети;
• собственная логистика;

• либо «‎Рассчитывается менеджером‎» (этот способ требует доработки стадий заказа).

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

7. Цены и группы пользователей.

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

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

Как НЕ нужно делать

Пускаем все на самотек (дали денег и забили) 

Функциональный и продающий сайт - результат сотрудничества исполнителя и заказчика. Никто лучше заказчика не знает особенности бизнеса и клиентов. Для сайта нужны готовый контент, структурированный и полный каталог, все типы цен. Поэтому важна постоянная и осмысленная связь с командой разработки. И еще много чего. Заказчики! Не пропадайте и участвуйте в процессе. Мы сталкивались с тем, что клиент заказывал разработку сайта, платил и пропадал. Когда клиент «‎теряется‎» на несколько месяцев, а потом приходит и говорит что нужно все переделывать, потому что его не «‎так поняли‎» – это плохая практика. Так работать не эффективно, в первую очередь, для самих заказчиков – тратится и время и деньги. Мы хотим приносить пользу тем, кто в этом заинтересован.

Делаем без плана

Про этот пункт говорилось ранее. Давайте сегодня одно «‎пилить», потом другое, а четвертое вообще нам не нужно потому что что-то сложное и время еще свое тратить нужно, давай когда-нибудь сделаем.

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

И опять – дешевле сначала все придумать, а потом делать.

Чайка-менеджмент

Редко встречаются заказчики полностью понимающие процесс разработки и внедрения IT продуктов, для некоторых из них это первый и единственный опыт. Недостаток осведомленности и компетенций в новой области приводит к чайка-менеджменту со стороны заказчика. Это накладывает отпечаток на процесс общения с командой и может привести к срыву сроков. Заказчик старается быть максимально вовлеченным во все процессы и начинают каждые 30 минут спрашивать: – «‎ну как дела‎», «‎а что с этой задачей, которую мы будем в августе делать?‎».

По сути мы имеем эффект: сейчас приехали? А сейчас? А сейчас?

Это приводит к тому что менеджер проекта тратит минимум 15 минут на каждое присланное сообщение или звонок, вместо того чтоб уделить время развитию проекта. 32 вопроса в день займут всё рабочее время менеджера проекта. 32 неинформативных вопроса и 0 выполненных задач по проекту. В нашей компании координационные планерки, сверка план-факта и другие инструменты контроля выполнения задач проводятся регулярно и позволяют закрыть большую часть вопросов о ходе работ от заказчика.

Дизайн ради дизайна, процессы ради процессов, продажи ради продаж

Бывают ситуации когда мы сталкиваемся с «‎хотелками‎» заказчика. Заказчики, далекие от дизайна предлагают сделать «‎красиво‎» в своем представлении, например красный текст на фиолетовом фоне. Я утрирую, но вот примеры:

Красивые сайты - бестолковки

Можно сделать красиво, но непонятно - мы видим главную страницу одного из интернет-магазинов.

Что продает этот магазин? Видимо, модные геометрические фигуры? Или это магазин тканей с принтом? Подушек? Худи? Машин?

Сайт - facepalm

Пример сайта, сдающего в аренду автомобили. Здесь мозг взрывается окончательно. Для того чтобы увидеть какие машины доступны для аренды и их стоимость придется хорошенько напрячь зрение.

Сайты - перегрузки

Вот еще пара примеров, где внимание покупателя рассеивается.

Наша задача провести клиента от страницы сайта, на которую он попал с рекламных объявлений или поиска, до страницы «‎Спасибо за успешно оплаченный заказ».

Представьте, что наш клиент это человек, который попал в незнакомый дом и ищет кота.

Так вот, дизайн сайта должен помочь человеку приобрести товар, а не усложнять ему жизнь своей «‎красивостью» или удивительностью.

Процесс ради процесса

Тоже касается и процессов. Делать что-то ради того чтобы делать - не работает.

Если бегать по комнате и набегать 10 км, ты не уйдешь от комнаты на 10 км.

С продажами та же ситуация. Можно продавать ради продажи, хотите много заказов?

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

Знайте и держите у себя в голове 

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

В компанию WEB-AiM обратился заказчик с проектом разработки и запуска сайта. Мы сделали проект в срок и передали заказчику. Заказчик был доволен дизайном, функционалом, сервисами. Через 3 месяца заказчик попросил остановить прием заказов, потому что команда не успевали обрабатывать заказы.

Да, бывает и так, в это сложно поверить пока сам не столкнешься.

Причина провала не в количества заказов, а в настройке бизнес-процесса внутри компании. Люди внутри компании не знали как быстро и правильно работать с заказами. С заказами можно справится вне зависимости от объема. На своем примере это показывают сервисы Яндекс.Маркет, OZON, Wildberries: 

305 млн заказов в год это 835 617 тысяч заказов в день и 35 000 заказов в час.

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

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

Как WEB-AiM работает с проектами

• анализ перед разработкой;
• планирование этапов;
• полная прозрачность уже с этапа планирования;
• проекты ведутся по SCRUM;
• задачи ставятся по SMART;
• планы по развитию проекта, даже если все изначальные цели достигнуты (всегда что-то за горизонтом);
• поддержка и развитие проекта – наш приоритет.