Основные ошибки разработчиков интернет-магазинов. Подборка чистосердечных признаний веб-студий
Так уж устроены люди – всем нам свойственно делиться своими достижениями и победами, скромно умалчивая об ошибках и неверных решениях.
Сегодня мы решили найти самых смелых разработчиков сайтов, которые готовы открыто рассказать о своих промахах для того, чтобы уберечь от них своих коллег и заказчиков интернет-магазинов.
Итак, на этот раз мы задали нашим экспертам следующие вопросы: «Какие ошибки при работе над интернет-магазинами допускали именно вы или ваши коллеги, а не заказчики?», «В чем заключались причины данных ошибок?», «Как в итоге решилась проблема?», «Какие выводы вы сделали и какие советы можете дать коллегам и заказчикам сайтов?».
На удивление, ответы получились довольно разнообразными. Уверены, ознакомление с ними поможет вам избежать многих ошибок в работе над своим проектом.
Мурад Эфендиев, менеджер проектов веб-студии 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. «Разработка Большим Куском». Мы (как и все, наверное) раньше пытались делать большие магазины в один заход. Процесс выглядел примерно так:
- Во время сбора требований клиент не мог решить, что важнее, заказывая внедрение всего и сразу. Мы недостаточно хорошо управляли требованиями, не настаивали на приоритизации.
- Разработка магазина затягивалась на год и более — на отрисовку, согласование и внедрение бесконечного списка фишек уходило бесконечное же количество времени.
- Проект умирал, не успев родиться — у клиента кончались деньги, менялись приоритеты, увольнялось руководство и так далее.
- В итоге печальны были все: мы не могли сделать хорошую работу и недополучали прибыль, а компания-заказчик впустую теряла деньги и время.
- Даже если проект успешно запускался, разработку наверняка можно было сократить на несколько месяцев — а это ощутимая упущенная прибыль.
Лечение проблемы — итерационная разработка по гибким методологиям и хороший консалтинг. Нужно разбить бэклог (полный список функций) на несколько итераций, а каждую итерацию — на несколько спринтов. Результаты нужно выкатывать как можно быстрее, сразу настраивая аналитику. Это позволит сразу получать обратную связь от покупателей и корректировать гипотезы/приоритеты по ходу разработки.
Кроме того, есть ряд досадных мелочей, о которых тоже часто забывают. На полноценную проблему они не тянут, поэтому даем их просто списком:
- Не забудьте сразу же настроить аналитику (в идеале Google (сайт нарушает закон РФ) Tag Manager + Google (сайт нарушает закон РФ) Analytcis + Метрику c отчетами электронной торговли, или хотя бы что-то из этого). Вы удивитесь, на каком количестве е-коммерсных проектов данные до сих пор не собираются или собираются плохо.
- Разработчики в погоне за дизайном делают ту ошибку, которую мы уже упоминали в примере про магазин шин. Результаты фильтрации выводятся динамикой, поэтому на сайте нет адресов не только для SEO, но и для кампаний в контекстной рекламе. Даже переслать ссылку другу — и то нельзя. Не увлекайтесь динамическими фильтрами!
- Еще часто забывают о том, что структуру каталога нужно проектировать с учетом выгрузок — будь то выгрузки на Я.Маркет, Авито и прочие прайс-площадки, выгрузки для систем автоматизации контекстной рекламы, для партнерских систем и т.п. Фильтры нужно продумывать максимально подробно, чтобы каталог можно было в любой момент перестроить под ассортиментную политику нужной вам площадки. И в этом случае допиливать структуру будет гораздо дороже, чем сразу сделать хорошо».
Инга Таирова, заместитель директора по развитию интернет-агентства Bquadro: «Наш клиент, известная компания, продающая канцелярию, сотрудничая с предыдущим подрядчиком, уделила мало внимания техническому заданию и не зафиксировала сроки сдачи работ. В результате разработка сайта затянулась на полтора года в силу плохо описанной синхронизации сайта с 1С и отсутствия требований к платформе.
Уже на этапе разработки клиент обнаружил проблемы с синхронизацией товаров, низкую скорость работы и недостаточную функциональность личного кабинета, а также то, что сайт сделан на самописной системе. Указанные недочёты подрядчик не смог устранить в разумные сроки, ссылаясь на ТЗ.
Когда клиент обратился к нам за помощью, мы провели технический аудит и приняли решение о переносе сайта на другую платформу. Ошибки с загрузкой данных из 1С были связаны с неправильной организацией данных на стороне клиента. Нам потребовалась 1 встреча, чтобы дать консультации по исправлению БД, а клиенту — полгода, чтобы привести свою базу в рабочий формат.
Сейчас сайт запущен и принимает заказы. Но работа над базой ещё ведётся. Таким образом, отсутствие своевременной профессиональной консультации более чем на 2 года отодвинуло запуск нового магазина».
Владимир Завертайлов, руководитель Сибирикс: scrum-студия: «Обожаю вопросы про «наши ошибки». Сидишь и думаешь, чтобы такого вспомнить, чтобы и про ошибку рассказать, и потом героем себя выставить.
Короче так. Самая большая экономическая ошибка для нас — это проекты, по которым мы соглашались брать за основу ТЗ от клиента и работать с ним. Особенно если это толстое и подробное ТЗ в 100500 листов.
СТО (РОВНО СТО!) процентов толстых ТЗ от клиентов, даже если они написаны другой супер-студией-и-лично-Артемием-Лебедевым — это ПРОБЛЕМА. У нас не было ни одного проекта, где за основу было взято ТЗ клиента, а на выходе получилось ХОРОШО и с ПРИБЫЛЬЮ. Все — анальная боль с кровавыми кишками.
Студии, если вы получили Большое Толстое ТЗ на руки — у вас ДВА правильных пути:
- Оценить его строчка за строчкой, уточняя непонятные детали и прокрашивая каждое слово. Это имеет смысл ТОЛЬКО если вероятность сделки высока и вам некуда девать свободное время.
- Вы можете дать клиенту ОЧЕНЬ БОЛЬШУЮ ВИЛКУ. Обязательно рассказать, что его ТЗ использоваться НЕ БУДЕТ (каким бы толстым оно ни было). И что цикл будет полный:
Агрегация требований (аналитика) -> прототип -> наши процессы (у нас — scrum; значит, будут бэклог и итерации).
Формируйте ожидания, что ТЗ мы выкинем. А все сакральные нюансы и тонкости, которые там были прописаны, потеряем, если специально не внедрим их в бэклог.
Это адекватно, так как в ТЗ — трешак. Даже если на первый взгляд оно суперзвездатое. Я на спор на коньяк найду дыры и места с разными возможными трактовками в любом ТЗ.
Я реально видел техническое задание на 120 страниц с очень подробной и занудной детализацией, но на 88-й странице было через точку с запятой мелко написано требование «социальная сеть». И все. Ни единого упоминания больше. Вероятность пропустить такую «радость» — очень высокая.
Коллеги, берите деньги за аналитику. Раздербанивайте ТЗ на аминокислоты, только потом генерируйте свой белок.
Если этот вариант клиента НЕ УСТРАИВАЕТ, а на первый нужно неадекватно много времени — вы НИЧЕМ не можете ему помочь. Разве что подарить плакат с В.И. Лениным. Пожелайте удачи. Хлебнет бед — придет к вам. Варианта магическим образом назвать точную цифру по смете из 100500 листов бреда и потом нести за нее материальную ответственность у вас нет.
Действуйте адекватно.
Если кто-то хочет поиграть в гадания по толстому ТЗ — подходите на проверку сметы с закладной на квартиру. :)».
Антон Золотарев совладелец и директор по развитию бизнеса веб-студии IT4U: «Наш эпичный файл заключался в отсутствии контента у заказчика. Точнее в конце разработки выяснилось, что у заказчика было ожидание, что мы волшебной кнопкой спарсим фото, характеристики, описание товаров "из интернета". Сегмент - элитная европейская мебель.
Ясное дело, что тут нужны качественные фотографии, варианты размеров, модификации, привязка к коллекциям, дизайнерам. Все ужесточилось уже заказанной рекламой в печатном издании с адресом сайта, который еще в разработке. Мы-то и спарсить с архипродукст готовы были. Но цена написания парсера для 40+К товаров из 200+ категорий для клиента показалась большой, а нам для этого ночами по выходным работать. Вот так зафакапили.
Теперь при разработке e-commerce-проектов мы отдельно очень четко прописываем сколько товаров мы наполняем на этапе разработки, чтобы проверить функциональность магазина. Все остальное можем импортировать из уже подготовленной базы товаров (таблица, файлы, 1С…), или спарсить, или… Но объем и стоимость этого отдельно проговариваем».
Николай Дингес, генеральный директор компании «Метроном»: «Я думаю, список таких ошибок всем известен. Эпичность фейла зависит в основном от терпения заказчика, а в разных проектах в той или иной степени повторялось примерно одно и то же:
- Некорректная оценка сроков (точнее, невозможность их оценки и недостаточный резерв времени), усложненные большим количеством промежуточных контрольных точек. Срыв сроков, конфликт с заказчиком.
- "Скрытые работы" - отсутствие надлежащего контроля изменений задачи и ситуации, как следствие - полная или частичная переделка проекта бесплатно. Срыв сроков, конфликт с заказчиком.
- Недостаточный технический контроль за исполнителями, в результате при вынужденной смене команды - полная или частичная бесплатная переделка проекта.
- Смена команды на стороне заказчика на почти готовом проекте, попытка полностью изменить задачу. Затем как везде: полная или частичная переделка, срыв сроков и т.д.
Дальше - как повезет. Иногда решается мирно, иногда заказчик таскает по судам и славит на весь свой круг общения.
Выводы, в принципе, содержатся в самих пунктах, но можно резюмировать. Разработчикам необходимо:
- Обращать внимание заказчика на то, что адекватно оценить сроки невозможно в принципе и минимизировать ограничения изначально. Учиться договариваться и коммуницировать. Не бросать заказчика одного, постоянно поддерживать связь, информировать об изменениях, предупреждать о сложностях. И ни в коем случае не врать и не брать на себя слишком много. Лучше иногда сразу отказаться от заведомо невыполнимых обязательств, чем давать надежду, а потом поставить перед фактом, что ничего не вышло.
- Работать с минимальным авансом (чтобы меньше возвращать в случае фейла), разбивать проект на много маленьких этапов с оплатой по факту.
- Контролировать и документировать изменения. Ввести соответствующий пункт в договор, чтобы можно было обойтись электронным документооборотом (сокращает сроки согласований в разы)».
Дмитрий Ничипорчук, руководитель студии «Тайм Дизайн»: «Мы переносили сайт со старой CMS на другую, современную. Обсудили контрольные точки, что важно перенести, составили ТЗ на этой основе. После бесконечных уточнений, когда ад должен был уже прикатиться, так как сделали все, приходит последнее уточнение. Одна из важных логик работы с товарами работает не так, как надо. И мы это должны были видеть в старой CMS сами. Чтобы решить эту задачу, требовалось переписать логику CMS и переделать 50% проекта. Словом, вернули деньги».
Дмитрий Батраков, генеральный директор интернет-агентства Dextra: «Думаю, проблема недооценки проекта вставала перед большинством агентств, работающих в среднем ценовом сегменте. Именно в нем, так как конкуренция обычно очень высока, а клиент за свои деньги уже хочет нешаблонное решение, трудоемкость которого может сильно изменяться.
Конечно, менять стоимость при работе по уже подписанному договору мы привычки не имеем и были проекты, где мы уходили в минус на сотни часов работы разработчиков.
Уверен, что избежать этого целиком без применения почасовой системы оплаты работ нереально, но снижать риски можно. Практически стандартом стало у нас прописание подробного технического задания перед каждым проектом. Явно это не новость, но не все так делают. И да, техническое задание делается по отдельному договору, что позволяет закрыть его в понятные сроки, а заодно посмотреть, как заказчик взаимодействует по проекту, понять риски, оценить перспективы совместной работы.
Другой пример – типизация решений и сведение работы к более простой и понятной логике за счет экспертного мнения. Часто тот функционал, на который может быть убито много времени (и, как на зло, он может не противоречить техзаданию) не принесет практической пользы клиенту!».
Ознакомиться с остальными ошибками разработчиков или поделиться своими можно в закрытой группе CMS Magazine & Рейтинг Рунета, а мы по традиции переходим к выводам.
- Разработчики – обычные, живые люди и тоже могут ошибаться. Снизить риск ошибок с их стороны можно путем выбора наиболее опытных команд. Если бюджета на обращение в студии верхнего ценового сегмента не хватает, нужно держать ухо в остро и не стесняться задавать вопросы подрядчику по всем волнующим моментам.
- Одна из самых распространенных ошибок разработчиков заключается в неверной оценке бюджета. Согласно общей статистике, итоговая сумма на запуск сайта сходится с первоначальной лишь в 42% случаев. Большей частью такое несоответствие связано с тем, что заказчик не озвучил все свои пожелания в самом начале. Так или иначе, при заказе сайта лучше иметь финансовый запас в 25-30% от общей оценки проекта.
- Множество ошибок разработчики связывают с проблемами в коммуникациях с заказчиком. Например, когда вопреки своим собственным убеждениям, они идут на поводу желаний клиента, и, в итоге оказывается, что опыт и интуиция не подвела – решение было неверным. В этой связи остается пожелать заказчикам чутко прислушиваться к мнению и аргументам разработчиков, заранее совместно взвешивать все «за» и «против».
- Одной из главных причин ошибок со стороны веб-студий часто является организационная разобщенность собственной команды или коммуникации с субподрядчиками. Данной хворью страдает множество студий, однако, не все готовы признаться в этом даже себе. Подстраховаться здесь несложно – главное заранее прояснить алгоритм взаимодействия с разработчиком, выяснить, в какие моменты к рабочему процессу помимо проектировщиков и программистов будут подключены специалисты по юзабилити, seo и т.д.
- Еще одной распространенной причиной последующих проблем является нежелание клиента расставаться с самописной или устаревшей CMS. Отсюда – невозможность реализации многих функций, привязка к конкретному разработчику и отсутствие возможности его сменить, удорожание разработки (порой программистам приходится вручную прописывать то, что уже есть в современных коробочных CMS по умолчанию).
- Часто неприятностей можно избежать, если сразу разбить проект на несколько основных и понятных всем составляющих, спланировать ключевые итерации.
- Особняком стоят проблемы, связанные с «мелочами»: своевременной настройкой аналитики, злоупотребление динамическими фильтрами, учет выгрузок при построении структуры каталога и т.д. Заказчики здесь как правило не могут ничего поделать, кроме того, чтобы изначально выбрать опытную команду.
- Многие студии готовы брать на себя ответственность за ошибки (в том числе и заказчика) и дорабатывать проекты за свой счет. Казалось бы, отличная новость. Однако, на такие шаги готовы далеко не все. К тому же, часто переделки и доделки переносят срок запуска, а в большинстве случаев – это прямые или косвенные финансовые потери для бизнеса клиентов.
На сегодня все :)