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

Подводные грабли при создании интернет-магазина

13 Сентября 2018
Владимир Ховенец
Middle backend developer
Владимир Ховенец
следующая статья

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

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

Ошибка 0: Нет понимания этапов разработки проекта.

Каждый проект проходит через разные стадии существования. Некоторые из них явно переходят одна в другую (например: релиз или закрытие проекта), некоторые — перетекают постепенно. Аналогично и разработка сайта имеет свои стадии.

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

Разработка более-менее стандартного магазина на CMS “1С-Битрикс” состоит из следующих стадий:

  1. Написание технического задания проекта с созданием, при потребности, прототипов — на этом этапе продумывается основной функционал;

  2. Разработка макетов дизайна. Если прототипов не было — функционал сайта закладывает дизайнер;

  3. Когда макеты дизайна приняты —они отдаются на верстку;

  4. После того, как верстка готова, бэкенд-программист «садит» её на динамику.

  5. Финальное тестирование, релиз.

Каждый этап «сдаётся» разработчиками и «принимается» заказчиком. Зачастую один накладывается на другой:  можно начинать верстку, имея макет пары страниц; начинать программирование, не имея всей верстки и т.д. Главное, чтобы разработчики поддерживали связь друг с другом.

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

Что произошло дальше разработчикам не известно... Да это и не их проблема.

Ошибка 1: Нет технического задания, непонимание технологии заказчиком.

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

Был случай, когда техзадания нет, но есть дизайн. Когда проект был готов, выяснилось, что заказчик хочет, чтобы на сайте нельзя было оформить заказ без предварительной его проплаты. Соответственно, в CMS “1С-Битрикс” сущность оплаты должна быть привязана к заказу и нельзя добавлять оплату без заказа. Программист всеми силами пытается донести это до проектного менеджера, который это понимает, но никак не может убедить заказчика. Клиент топает ногами и кричит, что не знает такого слова как «нельзя». И вообще, у всех его друзей есть «интернет-магазины в Америке» и у всех  у них заказ не оформляется, пока не будет оплачен прямо там же на сайте...

И действительно: вот он показывает интернет-магазин на CMS Shopify, в котором третьим этапом оформления заказа является оплата. И никакой аргумент об особенностях архитектуры уже не существуют. Заказчик ликует, менеджер молчит, программист понимает, что придется делать. Невзначай вспоминает, что для приема платежей на сайте нужен сертификат PCI DSS и удаляется изобретать тот самый велосипед.

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

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

Ошибка 2: У заказчика и исполнителя разные техзадания.

Однажды, поступила задача реализовать бэкенд часть интернет-магазина на подряде у другой студии. Было техзадание, был частично готов фронтенд, был даже старый магазин. Работа закипела. Иногда в уже готовый функционал вносились изменения, но, как показывает практика, это нормально. Складывалось впечатление, что заказчик следит за проектом: в целом его все устраивает и, время от времени, появляются небольшие “хотелочки” с родни: «А сделайте, чтобы в попапе картинка была слева, а не сверху».

Пока не пришло время презентовать готовый проект.

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

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

Ошибка 3: Почему никто не любит срочные заказы?

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

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

Разработчик был предупрежден о необходимости овертайма и в субботний обед начался 48 часовой марафон «успей до дедлайна».

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

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

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

Ошибка 4: Самое обидное.

Самое обидное для разработчика — когда проект сделан качественно и в сроки, в процессе разработки были реализованы какие-то новые для разработчика технологии, проект был срочным и работы велись с овертаймами (в том числе в выходные и праздничные дни), а спустя год, зайдя вечером на сайт, видно такую картину:

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

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

Подводим общие итоги

Ежедневно в мире открываются новые интернет-магазины, которые призваны приносить выгоду их владельцам и снабжать население планеты разными товарами. Но за каждым подобным проектом стоит колоссальная работа разработчиков, сожженные нервные клетки, разочарования и конфликты интересов. Это неизбежно в принципе, но вполне может быть минимизировано, если, хотя бы, не повторять вышеупомянутых ошибок. И если Вы хотите организовать свой бизнес в сфере єлектронной коммерции и представляете в голове свое будущее детище — Вам не помешает  вникнуть, как должны работать его отдельные компоненты и примите решение об их воплощении до того, как окончательно одобрите задание. Ну а если Вы разработчик — лучше потратьте больше времени на вопросы, объяснения и контроль соответствия в начале проекта. Иначе это обязательно “вылезет боком” где-то на этапах его реализации, причем “боком” для Вас:)

Need help?

Ask a question.

Chat Now
Записаться На Консультацию
Записаться На Консультацию
Мы свяжемся
с вами
в течении
10 минут
laptop
Мы свяжемся с вами в течении 10 минут