Программное обеспечение интернет-магазина

Сейчас проходит регистрация на V конференцию "Электронная торговля – 2009" – крупнейшее событие года в интернет-коммерции.

Чтобы вы могли составить представление о содержании конференции, мы публикуем избранные доклады II "Электронной торговли", прошедшей в 2006 году. Конечно, за три года в онлайн-торговле появились новые идеи и наработки, но некоторые доклады из коллекции Oborot.ru сохранили свою ценность и уникальность.

Самая актуальная информация и свежий опыт успешных интернет-магазинов будут озвучены в октябре 2009 года, на V конференции "Электронная торговля". Не пора ли зарегистрироваться?

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

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

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

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

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

Поддержка и развитие. Никогда интернет-магазин, который будет работать, не может быть сделан один раз и не иметь никакой поддержки. Это и поддержка существующего функционала, и доработка нового.

Такие вещи, как интеграция с внешними системами (ERP, CRM) – это само собой разумеющееся.

И – важный момент – снижение стоимости владения именно технической части, уже в процессе эксплуатации.

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

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

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

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

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

В чем достоинство универсальной системы? В том, что интернет-магазин (я имею в виду каталог и заказ) – это далеко не все. Также на сайте у вас будет присутствовать и контент, и реклама, и, возможно, форум, опросы, и множество дополнительных сервисов. Когда это все объединено в одном продукте и в одном интерфейсе – безусловно, это намного удобнее. Опять же, для ваших собственных разработчиков (если вы делаете все сами) либо для внешней компании работа с одним продуктом гораздо стабильнее и предоставляет больше возможностей. Например, захотели сделать рассылку – практически в любом продукте это – стандартная возможность, вам не надо разбираться с какой-то отдельной программой, которая делает рассылку. А хорошая рассылка по клиентской базе, может иметь очень высокую отдачу.

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

Какой бы подход к выбору платформы вы ни выбрали: делаете вы что-то уникальное или используете 99% готового функционала готового продукта – проблемы, как правило, одни и те же.

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

• Срыв срока (наверное, все с этим сталкивались);
• Выход из бюджета – это особенно актуально, если делается проект внутри. Когда с внешними разработчиками есть какие-то договоры и обязательства этот риск также присутствует, хотя и в меньшей степени.
• Результат не соответствует нашим ожиданиям – менее очевидный, но гораздо более опасный риск. Вы, вроде бы, делали проект, все как по техническому заданию, а когда закончили разработку, выяснилось, что бизнес-задача вообще была другая, и то, что сделано – это хорошо, но не очень-то и нужно.
• И технически проблемы, связанные с безопасностью или с масштабируемостью. С масштабируемостью как по производительности (чтобы сайт выдерживал больше посетителей простым увеличением вычислительных ресурсов), так и по функционалу (чтобы не пришлось при добавлении новой функции переписывать заново половину существующего кода).

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

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

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

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

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

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

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

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

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

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

Какие здесь возникают проблемы? Во-первых, менеджер может не все правильно понять и может передать искаженно, так как передавать надо много что и много куда. Менеджер может быть просто перегружен и всего не успевать. Поэтому важно "спрямлять" взаимодействие заказчиков и исполнителей. Каким образом мы поступаем. На каждом этапе со стороны заказчика и со стороны разработчика подключаются соответствующие специалисты, носители знаний –скажем так. Главная тонкость здесь – чтобы менеджеры не потеряли контроль. Такой подход не подразумевает, что менеджеры должны посадить вместе маркетолога со стороны заказчика и аналитика со стороны разработчика, и пусть они там договариваются о чем хотят. Нет, конечно, все должно быть подконтрольно, все должно регламентироваться. Но это уже технические детали. Есть хорошие технические средства, как это все можно организовать, документировать и обеспечить прозрачный процесс.

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

Со времени проведения II конференции "Электронная торговля", на которой был представлен этот доклад, многое изменилось. Хотите владеть актуальной информацией? Не только узнать больше, но и обменяться опытом с коллегами, завести полезные знакомства и получить достоверные данные для развития бизнеса?

Регистрируйтесь на Пятую, юбилейную конференцию по интернет-продажам "Электронная торговля – 2009"!
Общая информация о конференции
Программа
Регистрация