Основные ошибки разработчиков интернет-магазинов. подборка чистосердечных признаний веб-студий

Posted on by riasevastopol

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

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

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

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

Мурад Эфендиев, менеджер проектов студии веб-дизайна ITSOFT: «Один из отечественных клиентов желал как следует обновить собственный вебмагазин и наряду с этим в обязательном порядке сохранить устаревшую админку со всеми археологическими слоями кода в ней.

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

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

А времени и ресурсов уже было израсходовано неоправданно большое количество.

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

Основные ошибки разработчиков интернет-магазинов. подборка чистосердечных признаний веб-студийАлексей Шкарупа, начальник отдела веб-проектов интернет-агентства ИНТЕРВОЛГА: «Будет неправдой заявить, что у нас неизменно все гладко, прибыльно и благодушно. Приключений хватает.

Самые неприятные неточности, требующие самой громадной работы, такие:

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

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

Это больно и а также исходя из этого мы не любим браться за такие проекты в режиме водопада.

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

2. Тонем числом итераций при внешней интеграции. При любой методологии в проекте делать эту работу очень сильно продолжительно — неверно.

К примеру, выгрузка одного справочника “по требованиям” обязана проходить в 3-5 итераций максимум (с выдачей замечаний).

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

Как один умный человек сообщил: “любой косяк — это ресурс”. Тебе посоветовали где ты не сильный и как тебе стать лучше.

Так и действуем».

Степан Корнев, начальник коммерческого департамента компании Intaro: «Значительной проблемой при оценке нового проекта может являться наличие в архитектуре нераспространенной ERP. К примеру, нам доводилось решать интеграционные вопросы с Tiger ERP, которая популярна в средней Азии, промахнулись с оценкой трудозатрат, не обращая внимания на наличие API. Тут обстановка как с 1С: не легко без опыта работы с конкретной ERP с первого раза попасть в яблочко не закладывая риски.

Но еще громадные неприятности были у нас с одной отечественной ERP, которая кроме того, что не имеет API, так еще применяет СУБД Firebird, которая требует обслуживания с остановкой базы, что само по себе противоречит с главным постулатом интернет торговли — доступность 24/7. В итоге употребляется схема с очередью запросов к БД при недоступности, наряду с этим на сайте сохраняется все данные и употребляется локальное хранилище данных для скидок и просчёта цен, а по окончании того как база данных делается дешёвой из стека запросов осуществляется соединение с БД и проведение транзакций. Учитывая распределенность совокупности, где у каждого ТЦ развернута собственная версия ERP, то и для каждого ТЦ существует собственный шлюз, что есть точкой для отправки запросов по SOAP API».

Иннокентий Нестеренко, начальник Nimax: «Неприятность №1. «Забыли про Ядро». Обращение про разобщенные действия продакшена (проектировщиков, дизайнеров, разработчиков) и SEO-экспертов. Формально все знают, что при разработке структуры е-коммерсных проектов необходимо учитывать (а лучше закладывать в базу) семантическое ядро и другие SEO-требования. На деле все не хорошо:

• Или ни клиент, ни разработчики сайта по большому счету не вспоминают про SEO-требования, думая «заняться SEO» по окончании сдачи сайта. Это глупо, по причине того, что современное SEO — это свойство сайта, которое закладывается как раз на протяжении разработки. Не делать SEO сходу — обрекать себя на двойную работу, на затраты и двойные сроки.

• Или клиент приходит к хорошим дизайнерам, каковые не сильны в SEO, со своим «семантическим ядром». На деле это легко нечистая выгрузка из КейКоллектора, без аналитической очистки, разбивки на блоки и т.п. Дизайнеры решают, что у клиента и без того все прекрасно с SEO, и просто закладывают в дизайн место под главные слова.

Клиент как-то сам позже обязан в том направлении применить собственный «ядро». Это не работа со структурой, а вредная имитация. Хорошее семантическое ядро требует а также пары недель ручного труда SEO-аналитика.

• Или клиент приходит в компанию, где имеется и SEO-эксперты, и разработчики, и берёт комплексную работу над проектом. Да, необходимые отделы в компании имеется, но они друг друга или просто не слышат, или деятельно не обожают (SEOшники уверены в том, что разработчики косячат, а разработчики ненавидят SEOшников за муторные требования). Итог снова же так себе: SEO-требования собраны, формально презентованы клиенту, но не учтены по ходу разработки.

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

Тем самым сайт недополучал до 80% SEO-трафика легко по недомыслию.

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

Неприятность №2. «Разработка Громадным Куском». Мы (как и все, возможно) раньше пробовали делать громадные магазины в один заход. Процесс смотрелся приблизительно так:

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

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

Это разрешит сходу приобретать обратную сообщение от клиентов и корректировать догадки/приоритеты по ходу разработки.

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

  • Не забудьте сразу же настроить аналитику (в совершенстве Гугл Tag Manager + Гугл Analytcis + Метрику c отчетами электронной торговли, либо хотя бы что-то из этого). Вы удивитесь, на каком количестве е-коммерсных проектов эти до сих пор не планируют либо планируют не хорошо.
  • Разработчики в погоне за дизайном делают ту неточность, которую мы уже упоминали в примере про магазин шин. Результаты фильтрации выводятся динамикой, исходя из этого на сайте нет адресов не только для SEO, но и для кампаний в контекстной рекламе. Кроме того переслать ссылку приятелю — да и то запрещено. Не увлекайтесь динамическими фильтрами!
  • Еще довольно часто забывают о том, что структуру каталога необходимо проектировать с учетом выгрузок — будь то выгрузки на Я.Маркет, Авито и другие прайс-площадки, выгрузки для совокупностей автоматизации контекстной рекламы, для партнерских совокупностей и т.п. Фильтры необходимо продумывать максимально детально, дабы каталог возможно было в любую секунду перестроить под ассортиментную политику нужной вам площадки. И в этом случае допиливать структуру будет значительно дороже, чем сходу сделать прекрасно».

Инга Таирова, помощник директора по формированию интернет-агентства Bquadro: «Отечественный клиент, узнаваемая компания, реализовывающая канцелярию, сотрудничая с прошлым подрядчиком, уделила мало внимания техническому заданию и не зафиксировала сроки сдачи работ. В следствии разработка сайта затянулась на полтора года в силу не хорошо обрисованной синхронизации сайта с 1С и отсутствия требований к платформе.

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

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

на данный момент сайт запущен и принимает заказы. Но работа над базой ещё ведётся. Так, отсутствие своевременной опытной консультации более чем на 2 года отодвинуло запуск нового магазина».

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

Меньше так. Самая громадная экономическая неточность для нас — это проекты, по которым мы соглашались брать за базу ТЗ от клиента и трудиться с ним. Особенно в случае если это толстое и подробное ТЗ в 100500 страниц.

СТО (РОВНО СТО!) процентов толстых ТЗ от клиентов, даже если они написаны второй супер-студией-и-лично-Артемием-Лебедевым — это Неприятность. У нас не было ни одного проекта, где за базу было забрано ТЗ клиента, а на выходе оказалось Прекрасно и с ПРИБЫЛЬЮ. Все — анальная боль с кровавыми кишками.

Студии, если вы взяли Громадное Толстое ТЗ на руки — у вас ДВА верных дороги:

  1. Оценить его строки за строчкой, уточняя непонятные подробности и прокрашивая каждое слово. Это имеет суть Лишь в случае если возможность сделки высока и вам некуда девать свободное время.
  2. Вы имеете возможность дать клиенту Весьма Громадную ВИЛКУ. В обязательном порядке поведать, что его ТЗ употребляться НЕ БУДЕТ (каким бы толстым оно ни было). И что цикл будет полный:

Агрегация требований (аналитика) — прототип — отечественные процессы (у нас — scrum; значит, будут бэклог и итерации).

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

Это адекватно, поскольку в ТЗ — трешак. Кроме того в случае если на первый взгляд оно суперзвездатое. Я на спор на коньяк отыщу места и дыры с различными вероятными трактовками в любом ТЗ.

Я реально видел техническое задание на 120 страниц с весьма подробной и занудной детализацией, но на 88-й странице было через точку с запятой мелко написано требование «соцсеть». И все. Ни единого упоминания больше.

Возможность пропустить такую «радость» — довольно высокая.

Коллеги, берите деньги за аналитику. Раздербанивайте ТЗ на аминокислоты, лишь позже генерируйте собственный белок.

В случае если данный вариант клиента НЕ УСТРАИВАЕТ, а на первый необходимо неадекватно большое количество времени — вы НИЧЕМ не имеете возможность ему оказать помощь. Разве что подарить плакат с В.И. Лениным.

Захотите удачи. Хлебнет бед — придет к вам. Варианта волшебным образом назвать правильную цифру по смете из 100500 страниц бреда и позже нести за нее материальную ответственность у вас нет.

Действуйте адекватно.

В случае если кто-то желает поиграть в гадания по толстому ТЗ — подходите на диагностику сметы с закладной на квартиру. :)».

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

Ясное дело, что тут необходимы качественные фотографии, варианты размеров, модификации, привязка к коллекциям, дизайнерам. Все ужесточилось уже заказанной рекламой в печатном издании с адресом сайта, что еще в разработке. Мы-то и спарсить с архипродукст готовы были. Но цена написания парсера для 40+К товаров из 200+ категорий для клиента показалась громадной, а нам для этого ночами по выходным трудиться.

Вот так зафакапили.
Сейчас при разработке e-commerce-проектов мы раздельно весьма четко прописываем какое количество товаров мы наполняем на этапе разработки, дабы проверить функциональность магазина. Все другое можем импортировать из уже подготовленной базы товаров (таблица, файлы, 1С), либо спарсить, либо Но стоимость и объём этого раздельно проговариваем».

Николай Дингес, председатель совета директоров компании «Метроном»: «Я думаю, перечень таких неточностей всем известен. Эпичность фейла зависит по большей части от терпения клиента, а в различных проектах в той либо другой степени повторялось приблизительно одно да и то же:

  1. Некорректная оценка сроков (правильнее, невозможность их оценки и недостаточный резерв времени), усложненные громадным числом промежуточных контрольных точек. Срыв сроков, конфликт с клиентом.
  2. Скрытые работы — отсутствие ситуации и изменений надлежащего контроля задачи, как следствие — полная либо частичная переделка проекта безвозмездно. Срыв сроков, конфликт с клиентом.
  3. Недостаточный технический контроль за исполнителями, в следствии при вынужденной смене команды — полная либо частичная бесплатная переделка проекта.
  4. Смена команды на стороне клиента на практически готовом проекте, попытка всецело поменять задачу. После этого как везде: полная либо частичная переделка, срыв сроков и т.д.

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

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

  1. Обращать внимание клиента на то, что адекватно оценить сроки нереально в принципе и минимизировать ограничения изначально. Обучаться договариваться и коммуницировать. Не бросать клиента одного, всегда поддерживать сообщение, информировать об трансформациях, давать предупреждение о сложностях. И ни за что не лгать и не брать на себя через чур много. Лучше время от времени сходу отказаться от заведомо невыполнимых обязательств, чем давать надежду, а позже поставить перед фактом, что ничего не вышло.
  2. Трудиться с минимальным авансом (дабы меньше возвращать при фейла), разбивать проект на большое количество мелких этапов с оплатой по факту.
  3. Осуществлять контроль и документировать трансформации. Ввести соответствующий пункт в соглашение, дабы возможно было обойтись электронным документооборотом (уменьшает сроки согласований в разы)».

Дмитрий Ничипорчук, начальник студии «Тайм Дизайн»: «Мы переносили сайт со ветхой CMS на другую, современную. Обсудили контрольные точки, что принципиально важно перенести, составили ТЗ на данной базе. По окончании нескончаемых уточнений, в то время, когда преисподняя должен был уже прикатиться, поскольку сделали все, приходит последнее уточнение. Одна из ответственных логик работы с товарами трудится не так, как нужно.

И мы это должны были видеть в ветхой CMS сами. Дабы решить эту задачу, требовалось переписать логику CMS и переделать 50% проекта. Словом, вернули деньги».

Дмитрий Батраков, председатель совета директоров интернет-агентства Dextra: «Думаю, неприятность недооценки проекта поднималась перед большинством агентств, трудящихся в среднем ценовом сегменте. Как раз в нем, поскольку борьба в большинстве случаев довольно большая, а клиент за собственные деньги уже желает нешаблонное ответ, трудоемкость которого может очень сильно изменяться.

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

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

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

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

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

  1. Разработчики – простые, живые люди и также смогут ошибаться. Снизить риск неточностей с их стороны возможно методом выбора самые опытных команд. В случае если бюджета на обращение в студии верхнего ценового сегмента не достаточно, необходимо держать ухо в остро и не стесняться задавать вопросы подрядчику по всем волнующим моментам.
  2. Одна из самых распространенных неточностей разработчиков содержится в неверной оценке бюджета. В соответствии с неспециализированной статистике, итоговая сумма на запуск сайта сходится с начальной только в 42% случаев. Большей частью такое несоответствие связано с тем, что клиент не озвучил все собственные пожелания в начале. Так или иначе, при заказе сайта лучше иметь денежный запас в 25-30% от общей оценки проекта.
  3. Множество неточностей разработчики связывают с проблемами в коммуникациях с клиентом. К примеру, в то время, когда вопреки своим собственным убеждениям, они идут на предлогу жажд клиента, и, в итоге выясняется, что интуиция и опыт не подвела – ответ было неверным. В данной связи остается захотеть клиентам чутко прислушиваться к аргументам и мнению разработчиков, заблаговременно совместно взвешивать все «за» и «против».
  4. Одной из основных обстоятельств неточностей со стороны студий веб-дизайна довольно часто есть организационная разобщенность собственной команды либо коммуникации с подрядчиками. Данной хворью страдает множество студий, но, не все готовы рассказать о этом кроме того себе. Подстраховаться тут несложно – основное заблаговременно прояснить метод сотрудничества с разработчиком, узнать, в какие конкретно моменты к рабочему процессу кроме программистов и проектировщиков будут подключены эксперты по юзабилити, seo и т.д.
  5. Еще одной распространенной обстоятельством последующих неприятностей есть нежелание клиента расставаться с самописной либо устаревшей CMS. Из этого – невозможность реализации многих функций, привязка к конкретному разработчику и отсутствие возможности его поменять, удорожание разработки (иногда программистам приходится вручную прописывать то, что уже имеется в современных коробочных CMS по умолчанию).
  6. Довольно часто проблем возможно избежать, в случае если сходу разбить проект на пара главных и понятных всем составляющих, спланировать главные итерации.
  7. Особняком стоят неприятности, которые связаны с «мелочами»: своевременной настройкой аналитики, злоупотребление динамическими фильтрами, учет выгрузок при построении структуры каталога и т.д. Клиенты тут в большинстве случаев не смогут ничего сделать, помимо этого, дабы изначально выбрать умелую команду.
  8. Многие студии готовы брать на себя ответственность за неточности (среди них и клиента) и дорабатывать проекты за собственный счет. Казалось бы, хорошая новость. Но, на такие шаги готовы не все. К тому же, довольно часто переделки и доделки переносят срок запуска, а как правило – это прямые либо косвенные денежные утраты для бизнеса клиентов.

На сегодня все 🙂

Случайные статьи:

003. Разработка веб проектов в компании без проект менеджеров — Артур Богданов


Подборка похожих статей:

riasevastopol

More Posts