Почему разработка интернет-магазина превращается в муку?

      Комментарии к записи Почему разработка интернет-магазина превращается в муку? отключены

Почему разработка интернет-магазина превращается в муку?

Сергей Соловьев Менеджер интернет-проекта, Москва

Знакомая обстановка: денег на сайт израсходовано больше, чем планировалось, а итог хуже, чем ожидалось. Кто виноват? Два взора на подрядчика: и проблему заказчика IT-проектов.

Участники этого двойного интервью ни при каких обстоятельствах не трудились совместно, и до подготовки данной публикации по большому счету не были привычны. Так что ничего личного, just a business. Executive.ru внес предложение им обсудить проблемы и риски, с которыми возможно столкнуться в электронной торговле на стадии запуска и разработки проектов, и дать советы участникам Сообщества.

Клиент – Лидия Серегина, председатель совета директоров портала натуральных продуктов питания seryogina.ru. Путь по редизайну сайта был тернистым, с задержкой практически в год и ответом множества различных неприятностей. На этом проекте Лидия купила обширный опыт общения с разработчиками, и у нее накопилось к ним много вопросов.

Разработчик – Константин Попов, директор по продажам и маркетингу digital-агентства «Антигравитация». Запускал и перезапускал более десятка онлайн-проектов. Различные отрасли – обувь и одежда, автозапчасти, кейтеринг, интерьер и декор, автобусные перевозки, мебель.

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

Executive.ru: Лидия, для начала сообщите в целом – оно того стоило? Не жалеете, что занялись онлайн-торговлей?

Лидия Серегина: Отечественный вебмагазин получил в 2009 году. В то время массово торговали электроникой и книгами, так что с продуктами питания мы были в первых последовательностях. Удачно трудились и продолжаем. Непременно, не жалею.

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

Executive.ru: Константин, у вас более 80 постоянных клиентов и значительно больше разовых проектов. Обо всем получается договариваться, либо бывают безвыходные обстановки?

Константин Попов: Отечественные деньги находятся у клиента, исходя из этого агентство изначально более эластичный партнер в переговорах. Тупиковым есть лишь одна обстановка – в то время, когда клиент перестает нас слышать, не принимает отечественные доводы. В случае если такое случается, проект приходится завершать, несмотря на утраты и потерянную пользу.

Executive.ru: Вы оба рассказываете об потерянной пользе. Как ее оценивают в e-commerce подрядчики и заказчики? Это числовой показатель, его возможно учесть в контракте, либо легко такое выражение, которое «к делу не подошьешь»?

Л.С.: Мы не думали, что задержка будет таковой огромной. Разработчики в соглашении прописали, что не несут ответственности.

К.П.: Для агентства потерянная польза – это та прибыль, которую мы имели возможность бы взять в рамках подписанного контракта, если бы стороны не решили о его досрочном прекращении. Не обращая внимания на наличие зафиксированных обязательств, отечественное агентство ни при каких обстоятельствах не брало потерянную пользу с клиента, и я не слышал, дабы такая практика кем-либо использовалась в e-commerce.

Executive.ru: Какой основной вопрос по работе в e-commerce остался для вас открытым? Задайте его друг другу, пожалуйста! И ответьте также, само собой разумеется.

Л.С.: Как оценить адекватность и профессионализм IT-разработчика, еще не начав с ним трудиться?

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

Демонстрирует ли разработчик познание вашей потребностей и ситуации вашего бизнеса, либо он просто продает себя и собственные услуги?

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

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

Встречный вопрос: из-за чего довольно часто заказывают ответ в сфере e-commerce у программистов? Из-за чего не поручают экспертам в e-commerce – другими словами тем, кто кроме опыта программирования и web-разработки имеет кроме этого управления и опыт построения коммерческими онлайн-проектами?

Л.С.: «Я Вам не сообщу за всю Одессу…». Лишь за собственную компанию. Нам сайт (объединение блога с рецептами и вебмагазина) делают разработчики, цитирую: «с опытом поддержки и создания вебмагазинов с 2006 года».

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

Другими словами, заявлены компетенции как раз в сфере e-commerce, о которых вы рассказываете. Обширный опыт. Ниша в точности отечественная. Проекты «живые», я контролировала. Все выглядит красиво и подходяще.

Начинаем трудиться – неприятность за проблемой.

Executive.ru: Лидия, назовите главные неприятности, с которыми вы столкнулись в ходе запуска новой онлайн-площадки, пожалуйста.

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

К примеру, разработчик сделал фильтрацию по одному принципу, в то время как мы растолковывали прямо противоположное. Логика на отечественной стороне: к примеру, подобно фильтрует Яндекс.Маркет. Но, потому, что в ТЗ на данный счет ничего прописано не было, разработчик игнорирует отечественные аргументы и отказывается что-либо поменять.

Как быть?

Еще один пример похожей неприятности. Дизайн утвердили в статике, в динамике сходу стало ясно, что он неудобен. Вопрос: разработчик обязан переделать за те же деньги, либо он может отказать клиенту, аргументируя тем, что дизайн уже утвержден? Мы не эксперты в web-дизайне, надеялись на вывод разработчиков.

Как и за чей счет решаются такие вопросы?

На протяжении сотрудничества стало ясно, что трудиться с разработчиком проблематично: поменяли менеджера, затягивают решение проблем, не отвечают. Мы желаем поменять подрядчика. Сайт готов, обращение о его помощи и развитии. Код написан на фреймворке Simphony на базе языка PHP, модули на Python.

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

Executive.ru: Итак, три вопроса: как решать разногласия по ТЗ, за чей счет выполняются доработки и как обязана происходить смена подрядчика? Что об этом думают разработчики?

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

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

И в-третьих, отрасли специфики и понимание бизнеса я уже отмечал как ответственную составляющую профессионализма. Ищите разработчиков с пониманием вашей специфики! Портфолио – серьёзный критерий, но далеко не единственный. Быть может, те сотрудники, каковые делали ветхие проекты, в далеком прошлом покинули компанию.

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

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

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

Executive.ru: Как вы вычисляете, сколько раз возможно что-то поменять без повышения бюджета? Что возможно поменять, чего запрещено?

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

И мы готовы доплатить, в случае если количество возрастает.

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

К примеру, мы столкнулись с тем, что при установке скидки на товар не предусмотрен срок ее действия. По большому счету нет для того чтобы поля. Это мелочь? Да. Но необходимая.

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

К.П.: Снова мы видим ту же проблему – непонимание разработчиком сути бизнеса клиента, его задач и целей, специфики отрасли. В противном случае разработчик сам задал вопрос бы о необходимости таковой функции и зафиксировал это в ТЗ.

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

Быть может, а также вероятнее, оно будет означать кроме этого и корректировку бюджета.

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

Необходимо доверять друг другу, и все будет значительно несложнее.

Executive.ru: Доверие, само собой разумеется, нужно, но как и за что подрядчик готов отвечать перед клиентом?

Л.С.: Присоединяюсь к этому вопросу. Какую ответственность разработчик несет за конечный продукт? За задержку сроков, к примеру, за неграмотный интерфейс?

И как это прописать в контракте?

К.П.: Ответственность возможно прописать в соглашении, это обычная бизнес-практика. Но, само собой разумеется, все не пропишешь. Исходя из этого лучший вариант, в то время, когда разработчик отвечает не за «код», «движок» либо другие элементы (не забывайте классику: «К пуговицам претензии имеется?»), а сходу за тот самый конечный продукт. Другими словами за итог в виде заказов, продаж.

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

Executive.ru: Как глубоко разработчики e-commerce готовы «нырять» в бизнес клиента, в случае если «разрешит войти»?

К.П.: До самого дна! У нас имеется и собственные финансисты большого уровня, которых возможно подключить к проекту. Мы можем оценить рентабельность проекта, и в отечественных проектах продвижения, к примеру, неизменно имеется бонусная часть, которая считается с учетом настоящей прибыли, приобретаемой отечественным клиентом.

Executive.ru: Константин, давайте уточним. Вы готовы приобретать дополнительную прибыль, в случае если проект «взлетит»? А поделить с клиентом его убытки, в случае если «что-то отправится не так» также готовы?

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

До тех пор пока таких предложений не было.

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

Главные риски проектов в e-commerce:

  • Оценка продукта/рынка. За неточности платит клиент, по причине того, что это его компетенция.
  • Сроки реализации. Не обращая внимания на то, что в 99% случаев задержка происходит по вине клиента, мы не выставляем ему счет за это. Терпим убытки, совместно трудимся на неспециализированный итог.

Executive.ru: С каких цифр начинаются адекватные бюджеты вебмагазинов?

Л.С.: Отечественный бюджет: разработка ТЗ – 100 тыс. руб. Проект в сумме 1,3 миллионов рублей. Еще 100 тыс. руб. мы доплатили по окончании запуска за недостающие функции – это было сделать несложнее и стремительнее.

Итого целый бюджет составил 1,5 миллионов рублей. Это реализовывающий портал под отечественную целевую аудиторию, по примеру сайта Jamie Oliver – возможно брать прямо из рецептов. Оказалось кривовато, не обращая внимания на нашу готовность и готовый пример консультировать по логике работы, и наработки, прошедшие диагностику временем на прошлой версии сайта.

По-моему, мы изрядно переплатили. Особенно с учетом задержки практически на год, и важных недоработок на сайте, что был запущен достаточно «сырым»: без расчетов доставки, корректной оплаты и т.д.

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

Разработка всего лишь его часть, не всегда самая громадная.

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