Nezname

Наткнулся на обороте на великолепную статью по разработке интернет-магазинов. Статья – доклад Дениса Митрофанова, руководителя отдела разработок компании Qsoft, которая разработала ИМ ТМ «Эльдорадо». Суть статьи – как правильно разрабатывать интернет-магазин (да и любой сайт).

Предисловие

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

В статье приведен малозатратный, в материальном и временном отношении, метод разработки проектов. И есть прямой намек на то, как стоит запускать средний по оборотам интернет-магазин. Читайте, очень полезно.

Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что я всегда советую любому будущему руководителю ИМ, когда он спрашивает: «какую CMS выбрать?». Мой ответ один: «ту, с которой работают многие веб-мастера или сторонние разработчики»

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

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

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

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

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

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

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

Рис. 1. Разработка «водопадом»

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

Рис.2. Стоимость исправления ошибки при разработке «водопадом»

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

Рис.3. Итерационный подход к разработке

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

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

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

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

Выводы

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

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