Основная ошибка клиента — скромное техническое задание, которое «обрастает» новым функционалом уже после подписания договора и начала разработки интернет-магазина.

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

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

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

• адаптивность сайта;

• размещение товара: вручную, выгрузка из csv, интеграция DIAFAN.CMS с 1С и т.п.;

• способы оплаты товара и критерии формирования окончательной стоимости совершаемых покупок.

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

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

Какая самая типичная ситуация в Рунете при заказе интернет-магазина? Обратиться в веб-студию с некой классной задумкой о том, как сделать революционный необычный интернет-магазин. А потом год мучиться с дизайном, менять раскраски, согласовывать стили. Уже после запуска сайта понять, что есть еще логистика, склад, трафик... да и с пониманием аудитории тоже накосячили, а ассортиментная матрица ни к черту... и... закрыть проект.

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

Всем правит оффер. Если ваше предложение рынку — «туфта», то юзабилити не спасет. Отточите оффер, заработайте денег, а потом наймите адекватных специалистов и дайте им делать свою работу (но при этом наймите в штат кого-то, кто хорошо понимает, как взаимодействовать с веб-студией).

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

Я могу выделить одну критичную ошибку, которая не всегда на первый взгляд очевидна: неверно выбранная точка приложения усилий в момент эмоционально-напряженного экстремума в проекте. Звучит немного сложно, но имеет простой смысл: в сложные моменты проекта (запуск, пуско-наладка, внедрение сложных модулей) обе стороны команды «нагреваются изнутри» и вместо сосредоточения усилий на решении задач, направляют силы на «борьбу» друг с другом.

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

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

Но случается, что заказчик абсолютно уверен в своей правоте и считает, что для того, чтобы выбрать текстуру для жалюзи совершенно точно необходимо сделать однострочный слайдер по пять предложений, несмотря на то, что общее количество элементов в слайдере состоит из нескольких сотен вариантов текстур и расцветок. Некоторые клиенты (таких мало, но они есть) считают, что самый простой вариант для них — «сайт под ключ». Идеальная ситуация — если не придется общаться с разработчиками или просто составить ТЗ и ждать результата. Большая ошибка — отказываться от участия в разработке сайта на каждом этапе. А если проект долгосрочный? Требования могут меняться, но что, если они изменятся, когда все уже сделано?

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

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

Большинство наших клиентов уже «набило шишки». Они точнее формулируют требования, но всё равно забывают о некоторых важных вещах. Зафиксирую здесь несколько:

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

• часто у клиента, имеющего большую базу товаров, всё ещё не организовано хранение этой информации в 1С, что тормозит начало разработки и запуска магазина;

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

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

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

На самом деле, наиболее частая ошибка — это отсутствие у клиента веры в то, что в онлайне можно успешно продавать. Мы сейчас успешно идем к тому, что в онлайне есть всё. Пример: новую модель автомобиля Tesla можно купить на официальном сайте, оплатив ее банковской картой.

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

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

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

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

Следующий этап — это обсудить проект с разработчиком и совместно сформировать задание. Большинства ошибок можно будет избежать, если между клиентом и разработчиком наладится хороший контакт и взаимопонимание. Разработчик, конечно, должен выполнять пожелания клиента. Но и клиент должен прислушиваться к советам разработчика

Три основные ошибки клиентов, с которыми сталкивались мы:

• придумывание технических решений для реализации собственных задач. Пример: вывод товара в категории магазина по новизне. Клиент требует сортировку по артикулу, не зная, что есть сортировка по дате добавления. Решение: понимаем какую именно первичную задачу клиент хочет решить и предлагаем свой вариант;

• нечеткое формулирование задач, аргументация субъективными понятиями. Пример: «Хочу удобную форму поиска/понятный каталог/лучшую карточку товара». Решение: если клиент не может сформулировать (что естественно, зачастую так) задачу конкретно, можно предложить ему ориентироваться на примеры уже работающих магазинов;

• неправильно расставленные приоритеты. Пример: углубляемся в обсуждение интеграций платежных систем (довольно типовой возможности), вместо обсуждения синхронизации базы товаров с перепиленной 1С. Решение: акцентируем внимание на фундаментальных бизнес-процессах.

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

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

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

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

Часть из них мы умеем снимать на своей стороне, но будет больно. Поясню примером.

В схемотехнике (да-да, я изучал транзисторы в ВУЗе) сигналы кодируются ноликами и единичками.

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

_|¯|_|¯|_|¯|_

Но в реальных системах есть наводки, глюки, взаимное влияние физики. Из-за чего сигналы начинают скругляться.

.◠._.◠._.◠.

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

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

Если задачи ставятся без конкретики, по типу «Обсудить дизайн», «Поговорить про архитектуру», а сроки «Возможно через недельку» и «Нам некогда, т.к. идут разборки наших категорийщиков с 1С-никами» — это признак, что сигнал скруглился.

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

Ошибки бывают самые разнообразные. Например, забыли внести в ТЗ важный функционал, сэкономили на адаптивной версии, с задержкой давали обратную связь, заранее не задумались о seo...
Однако есть положительные и тенденции. Мы заметили, что постепенно квалификация клиентов повышается. Все чаще мы получаем или «ТЗ на 80 страниц» или (это веселее, но труднее) профессионала, который «знает, как надо».

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

Это приводит к «водопадным» проектам «за миллион», которые по факту делаются 2 года и в итоге никого не радуют.

Мысль о поэтапном старте и постоянном развитии все еще нова для клиента и фраза «без финального бюджета мы не начнем» — симптом беды.

Я писал об этом развернуто в статье: http://www.intervolga.ru/blog/thoughts/bolshoy-proekt-tolko-chastyami-priderzhite-vash-million/.

По-моему, самая фатальная ошибка клиента — «давайте сделаем идеально работающий магазин, в процессе работы дополняя его новыми требованиями». Это приводит к увеличению сроков разработки в разы, здорово раздражая всех участников процесса. Разработчик недоволен, что сайт не запускается, потому что «они снова что-то придумали/вспомнили», клиент недоволен, что «они запускают сайт уже полгода». Но ведь мы для того и нужны, чтобы помочь клиентам избежать частых общих ошибок!

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