Рассмотрим несколько типичных ошибок, допускаемых при выборе базового программного обеспечения для построения интернет-магазина.
Ошибка 1. Выбор платформы в отрыве от конкретных условий, опираясь только на слухи или советы знакомых, на рекламные описания движков, или высказывания на форумах, найденные в интернете.
Любой знакомый, давая «бесплатный» совет, как правило, не вникает глубоко в особенности того торгового процесса, который необходимо автоматизировать, уже хотя бы потому, что не несет ответственности за последствия принятия такого совета. Обычно такой совет дается, исходя из личного опыта самого советчика, который бывает весьма ограничен и обусловлен решением его собственных задач, которые зачастую мало схожи с задачей того, кто обратился за советом.
Составители описаний движков - это либо их разработчики, либо web - студии или отдельные разработчики, предлагающие услуги по разработке именно на этих платформах. В любом случае они заинтересованы подчеркивать сильные стороны предлагаемого ПО, умалчивая о недостатках, а, значит, полностью доверяться такой информации нельзя, так как она заведомо тенденциозна.
Человек, высказывающийся на форуме в пользу того или иного базового ПО, либо ограничен своими знаниями, либо правилами форума, которые часто бывают связаны с конкретной платформой (в этом случае о движке, составляющем главный предмет обсуждения форума, можно говорить как о покойнике - либо только хорошее, либо ничего), но в любом случае говорящий не несет ответственности за последствия решений, принятых на основе его суждений.
Ошибка 2. Передача выбора платформы заранее выбранному разработчику. В этом случае, последний естественно стремится навязать ту платформу, которая выгодна ему (которую он лучше знает или от продажи которой он получит большую выгоду со стороны разработчика платформы), а не ту, которая соответствует потребностям заказчика. В этом случае реальные особенности автоматизируемого процесса учитываются не полностью, а только те, которые подтверждают правильность предложения выбора исполнителем платформы. В такой ситуации перед подрядчиком стоит одна из двух задач:
убедить заказчика приобрести лицензии на коммерческую платформу и на разные расширения и дополнения к ней (потому что получит доход от ее продажи, даже если не сделает на ее основе сайт, то есть в этом случае он действует не как разработчик сайтов а как простой продавец ПО);
втянуть заказчика в процесс разработки магазина на любой платформе, лишь бы получить возможность брать деньги за сам процесс строительства магазина, особенно если заказчик готов делать предоплату (ситуация как в известном анекдоте: «Поручик, вы любите детей?- Нет, но сам процесс их получения...»).
Ошибка 3. Неправильная расстановка приоритетов критериев оценки программных платформ. Очень часто первоочередное внимание уделяют таким вопросам, как быстродействие ПО, простота в освоении (доступность понимания), возможность реализовать определенные оформительские решения (установить баннер или слайдер на главной странице и т.п.). При этом ключевым характеристикам, таким как функциональные возможности ПО, внимание не уделяется вовсе, хотя элементарная логика подсказывает, что:
легкость освоения ПО и высокое быстродействие практически всегда достигаются за счет минимизации функциональных возможностей, а чем меньше функциональные возможности «движка», тем он бесполезнее в реальном деле (аналогия - игрушечный автомобиль, который доступен для освоения даже младенцам, но бесполезен при перевозке людей и грузов);
оформительские возможности практически всех движков практически одинаковы, и даже более высокие базовые возможности имеют те движки, которые не связаны с торговлей (платформы общего назначения, используемые в основном для сайтов - визиток), а, значит, по данному критерию предпочтительным является платформа, которая имеет наименьшие функциональные возможности для автоматизации конкретного процесса (то есть, опять приходим самому неэффективному выбору).
Источник ошибок 1 и 2 - неправильная схема организации действий по подбору ПО, их участников и отношений между ними, при которых интересы хозяина будущего бизнеса и остальных не совпадают (у подрядчика нет заинтересованности в том конечном результате, который нужен заказчику, у советчиков не ответственности за качество совета).
Источник ошибок третьего вида — неверное понимание конечной цели деятельности по созданию интернет-магазина. Фактически получается, что такие владельцы и менеджеры сначала строят интернет-сайт, похожий на магазин, а потом уже вокруг того, что получилось, пытаются выстроить бизнес. Выходит, что целью деятельности становится создание сайта, а не бизнеса.
Главная причина перечисленных выше ошибок — дефицит знаний у начинающего интернет-предпринимателя в этом вопросе. Вот некоторые рекомендации, которые могут помочь избежать ошибок:
уделять как можно больше внимания работам на этапе проектирования магазина, потому что по статистике каждый рубль, вложенный в предотвращение ошибок на этой стадии процесса, экономит до 200-300 рублей на устранение сделанных ошибок на стадии реализации (« … если стоимость усилий, необходимых для обнаружения и устранения ошибки на стадии написания кода принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований (проектирования; прим. автора) будет в 4-5 раз меньше. А стоимость обнаружения и устранения ошибки на стадии сопровождения (эксплуатации; прим. автора) — в 20 раз больше.» Дин Леффигуэл, Дон Уидриг, Принципы работы с требованиями к программному обеспечению, Москва, 2002, ISBN 5-8459-0275-4) . В этот вам могут помочь материалы раздела «Организация выбора CMS»;
привлечь к проработке функциональных требований к платформе специалиста, при этом поставив задачу всесторонней оценки платформ для использования в конкретном торговом процессе. Для большей мотивации не обнадеживать его тем, что именно он будет реализовывать этот проект (это позволит выполнить данный этап работ наиболее объективно и качественно, поскольку заставит исполнителя сосредоточить усилия именно на учете всех функциональных требований торгового процесса и описании функционала разных платформ без учета его собственных предпочтений).
Выделение проектных работ в отдельный этап с привлечением эксперта может показаться целесообразным только для крупных магазинов, но на самом деле если данный этап работ будет выполнен плохо, то это уменьшает шансы любого малого магазина вырасти в приличный бизнес. Главная идея рекомендаций — хозяин (менеджер) должен построить такую систему отношений между всеми участниками процесса подбора базового ПО, при которой их интересы совпадают с его собственными.
Последствия неверного выбора платформы бывают весьма плачевными. Во-первых, по мере развития бизнеса растут потребности в расширении функционала. Если выбор платформы был сделан правильно, то потребности в развитии легко удовлетворяются с минимальными затратами. Если нет — владелец начинает втягиваться в длинный и затратный процесс постоянных переделок и доработок, с высокими издержками. Во-вторых, по мере роста количества переделок и числа их исполнителей качество и надежность ПО сайта падает, ресурсоемкость растет, производительность снижается. Поскольку работы, как правило, выполняются исходя из необходимости минимизации затрат, к работам привлекаются низкоквалифицированные программисты, не имеющие навыков профессионального кодирования. Как следствие - организация кода сайта, его качество резко ухудшается, документирование кода и внесенных изменений отсутствует, решения выбираются первые попавшиеся и зачастую не самые оптимальные. В результате наступает момент, когда после очередной переделки сайт, а вместе с ним и бизнес рассыпается как карточный домик.
Комментарии (2)
Владимир:
Правдивый сайт.
Антон:
Согласен. Вот только практических рекомендаций не хватает, особенно по вопросам организации некоторых процессов, таких как интернет-реклама, интернет-маркетинг, управленческий учет и т.п. Рекомендаций по техническим вопросам в сети довольно много, хотя конечно обобщающий и объективных материалов маловато. Обычно все по большей части примитивная реклама движков или услуг.