Автор: Дмитрий Родин
Рассказав об особенностях российского рынка СMS, его основных проблемах и перспективах развития, а также пообщавшись с участниками этого самого как бы несуществующего рынка, TelNews попытается рассмотреть практический вопрос, который касается даже скорее не самих игроков, а их клиентов. В данной статье с помощью любезно согласившихся дать свои комментарии экспертов попробуем понять, как с умом подойти к выбору системы управления контентом.
За последнее время уже появилось несколько публикаций на эту тему — как авторских, так и написанных самими участниками рынка. Мы же попытаемся рассмотреть этот вопрос глазами сразу нескольких игроков, что поможет выявить основные, наиболее важные моменты или же, напротив, отсечь то, что в действительности при выборе CMS не так уж и важно. На несколько общих вопросов TelNews по указанной теме согласились ответить представители пяти участников российского CMS-рынка, профессиональные успехи которых довольно сильно разнятся между собой, что, возможно, позволит проследить изменение позиций игроков в зависимости от успешности их бизнеса.
Своим мнением на этот счет с нами поделились: руководитель интернет-направления компании «Ленвендо» Станислав Базылевич, генеральный директор компании QSOFT Михаил Токовинин, генеральный директор компании «АИСТ» Дмитрий Васильев, генеральный директор ООО «Юмисофт» Сергей Котырев и директор по развитию компании TRINET Алексей Довжиков.
1. На какие параметры стоит ориентироваться при выборе CMS прежде всего?
На этот вопрос наиболее развернутый ответ дал Станислав Базылевич. Он назвал несколько «решающих» показателей, расположив их в произвольном порядке и подчеркнув, что этот список еще можно дополнять:
- простота работы пользователей с системой (удобный интерфейс и т.д.);
- стоимость разработки на системе, стоимость владения конечным решением (сайтом), стоимость самой системы;
- функционал системы. Модули, входящие в поставку от вендора, их функционал. Также важно обратить внимание и на то, является ли разработка CMS специализацией компании либо одним из направлений деятельности;
- техническая поддержка системы (и со стороны вендора, и со стороны конечного разработчика), уровень обслуживания в рамках технической поддержки, время реакции на обращения и т.п.;
- документация по системе. Нужно обратить внимание на то, что описывается в документации, на то, насколько она понятна и подробна, учитывает ли документация все группы пользователей (разработчики и конченые потребители), как часто обновляется документация, сколько языковых версий она имеет;
- обновления системы. Как происходят обновления системы, как часто они происходят, требуется ли привлечение разработчика для установки обновлений или это может выполнить пользователь, как осуществляется подписка на обновления от вендора;
- надежность и безопасность системы. Здесь важно понять, уделяет ли вендор внимание вопросам безопасности системы. Насколько серьезно прорабатывается этот вопрос. Есть ли сторонний аудит безопасности, есть ли сертификаты по безопасности и т.д.;
- независимость от разработчика. Это в большей степени касается «самописных» CMS. Нужно разобраться, является ли CMS, к которой вы приглядываетесь, основой для интернет-решений только одной компании либо платформу использует целая партнерская сеть. Правильно выбранная система позволит вам обратиться к другим разработчикам, если Вас не устроила та, с которой вы начали работу;
- насколько система масштабируема. Возможен ли переход на более функциональные версии системы с сохранением текущей функциональности и данных, возможна ли разработка дополнительных модулей к системе;
- устойчивость к нагрузкам (и по контенту, и по посещаемости). Выдержит ли система большую нагрузку по количеству посетителей или по объему данных, или по тому и другому вместе (что бывает чаще всего). Проводится ли нагрузочное тестирование системы компанией-разработчиком. Есть ли проекты с высокой нагрузкой на этой системе и т.д.;
- технические требования системы и ее платформа.
Ответы остальных комментаторов, в основном, повторяют те аспекты выбора CMS, которые уже перечислил Станислав Базылевич. Поэтому остановимся на отдельных замечаниях экспертов. Дмитрий Васильев напоминает о таком важном параметре системы управления контентом (да и любого другого товара) как ее цена: «Причем не столько цена самой «коробки», сколько стоимость внедрения, то есть создания сайта на этой CMS. Часто бывает так, что изначально «красивая» и мощная система оказывается тяжелой в «тюнинге» и отнимает на этапе разработки сайта много времени, а значит и денег. Следующий показатель — стоимость владения, в которую входит стоимость хостинга, поддержки сайта, возможных доработок».
Михаил Токовинин в очередной раз подчеркивает, что CMS должна соответствовать задачам проекта: «Если вам нужен маленький сайт с контактами и описанием компании, и в ближайшие пару лет вряд ли что-то изменится, глупо покупать для этого большую платную систему».
Сергей Котырев считает, что перед покупкой CMS стоит обязательно проверить систему в действии: «Мы предлагаем открыть демо-версию и самостоятельно попробовать выполнить некоторые действия: например, добавить новость, скопировать страницу в структурном дереве и перенести ее в дерево другого сайта и т.п. — те самые действия, которые придется выполнять каждый день. Тогда уже клиент задумывается, насколько этот инструмент удобен для того, чтобы работать с ним изо дня в день, работник какой квалификации сможет оперировать этим инструментом».
Алексей Довжиков подводит черту под высказываниями остальных аналитиков: «На сегодняшний день практически все коробочные продукты, занимающие топовые позиции на рынке, удовлетворяют требованиям, перечисленным выше. С моей точки зрения, самым важным критерием при выборе CMS является возможность решения всех задач, поставленных заказчиком в рамках проекта».
2. Есть ли у CMS какие-либо неочевидные недостатки, которые зачастую остаются незамеченными клиентами при выборе системы управления контентом?
Да, есть. Поскольку клиенты не являются техническими специалистами, они могут не видеть «подводных камней» при выборе системы, — считает Станислав Базылевич. — Часто максимум, на что они могут рассчитывать — это либо демо-версия системы либо просто словесная презентация. Однако технические проблемы (качество кода системы, устойчивость к взлому) и коммерческие проблемы (стоимость владения сайтом на основе выбранной системы) возникают только после выхода проекта в рабочую эксплуатацию».
Эту мысль развивает Михаил Токовинин: «Большинство таких недостатков заказчик видит, но не воспринимает, предпочитая не обращать на них внимания. Часто при выборе руководствуются не здравым смыслом, а стереотипами, выбирают какой-нибудь «прогрессивный» язык программирования, и потом очень долго мучаются. Если оперировать целями, задачами и деньгами, то многих ошибок можно избежать».
Дмитрий Васильев имеет собственное мнение на этот счет и развеивает один из мифов о работе CMS. «Да, подводных камней для неискушенных пользователей может быть много. Это и высокие требования к хостингу, и неудобность административной части системы, и плохая документация, и неинтуитивность средств разработки. Хочется сказать об одном «псевдонедостатке», о котором мне часто приходится слышать: универсальные CMS не гибкие и подходят только под типовые задачи, а под сложные задачи лучше разрабатывать свою систему управления. Это совершенно не так. Нынешние ведущие CMS являются, в том числе, фреймворками, средствами разработки, значительно упрощая реализацию нетиповых задач. В большинстве случаев использование мощной системы управления для крупных проектов полностью оправдано», — объясняет он.
«Зачастую пользователь, уже получив готовый сайт, видит, как ему сложно разобраться во множестве настроек CMS, и что есть необходимость потратить массу времени на обучение сотрудников работе с системой. Поэтому CMS должна гармонично сочетать функциональные возможности с потребностями клиентов», — отмечает Сергей Котырев.
Алексей Довжиков, в свою очередь, приводит пример из собственной практики: «К нам иногда обращаются клиенты с проектом, разработанным на CMS, которую они приобрели по рекомендации или руководствуясь тем, что это «известный бренд». Итог: в процессе или после реализации проекта оказывается, что данная CMS не решает поставленных задач».
3. Как правильно подобрать CMS в зависимости от хостинга и «серьезности» сайта? В каком случае и на чем можно сэкономить, и когда этого делать нельзя?
Алексей Довжиков полагает, что для 95% интернет-проектов, независимо от CMS, на которой они строятся, достаточно использования виртуального хостинга. «Если рассматривать именно коммерческие проекты, — продолжает директор по развитию TRINET, — то вопрос экономии на виртуальном хостинге лишен смысла. Стоимость данной услуги колеблется от $2 до $50 в месяц. Соответственно, максимальная экономия за год составит не более $500. Для любой компании, которая перед своим проектом основной задачей ставит получение прибыли, данная сумма по сравнению с извлекаемым доходом незначительна. Я считаю, что нет смысла экономить на хостинге, так как качество ресурса напрямую зависит от качества предоставляемых услуг. Возможная экономия несравнима с упущенной прибылью вследствие некорректной работы хостера».
«Ставить выбор CMS в зависимость от хостинга — весьма неразумный подход, — предупреждает Сергей Котырев. — Хостинг — это недорогая и распространенная услуга, поэтому целесообразно подбирать хостера под CMS, а не наоборот. Кроме того, современные технологии позволяют содержать высоконагрузочные интернет-проекты и на ограниченных серверных ресурсах».
Со своими коллегами согласен и Станислав Базылевич: «С нашей точки зрения, нецелесообразно подбирать систему под хостинг. Логичнее подбирать хостинг под выбранную систему. Естественно, хостинг серьезно влияет на стоимость владения решением. Однако очевидно, что чем серьезнее сайт, тем больше требований будет выдвигаться к хостинг-площадке. Но на сегодняшний день уже достаточно широко распространены услуги специализированного хостинга для большого количества современных CMS, что существенно упрощает выбор площадки. Что же касается «серьезности» сайта, то для сайта в 5-10 страниц, где не будет частых обновлений контента, конечно, нет смысла брать серьезную коммерческую CMS. Подойдут и оpen source-разработки. Для всех остальных следует выбирать коммерческие CMS по критериям, перечисленным выше».
Дмитрий Васильев с энтузиазмом рассказывает о возможности сэкономить на выборе CMS: «Выскажу крамольную мысль: в зависимости от задачи сэкономить можно на всем. Если бюджет позволяет, нужно выбирать проверенную именитую веб-студию и мощную систему управления с хорошей технической поддержкой, иначе поговорка «скупой платит дважды» оправдается. Но когда проект небольшой, а бюджет его ограничен, на него вполне реально выбрать недорогую (или вообще бесплатную) легкую CMS, пятидолларовый хостинг и недорогого частного разработчика».
«Экономить можно и нужно, если нет денег, а сайт не является основой бизнеса, — подытоживает Михаил Токовинин. — Во всех остальных случаях экономить не стоит. Прежде всего, не стоит экономить на самой CMS. Стоимость системы в большинстве случаев ничтожна по сравнению с совокупными затратами на проект».
4. Насколько сложно бывает клиенту разорвать отношения с компанией-разработчиком выбранной им CMS? По каким причинам чаще всего происходит такой разрыв, и какие обстоятельства могут удерживать клиента?
«Прежде, чем ответить на этот вопрос, я бы хотел разделить два понятия: компания-разработчик проекта (компания-партнер, студия) и компания-разработчик CMS, — начинает Алексей Довжиков. — Если мы говорим о взаимоотношениях клиента и компании-партнера, использующей коробочную CMS, то в большинстве случаев причинами разрыва являются некомпетентность и непрофессионализм данной компании. В подобной ситуации прекращение сотрудничества может быть безболезненным для заказчика, так как у него есть возможность перейти к другому партнеру. Очень часто встречаются проекты, собранные на собственной CMS студии-разработчика. Разрыв отношений с такой компанией и обращение к другому разработчику в большинстве случаев влечет за собой разработку проекта с нуля на новой платформе, хотя, конечно же, есть и исключения».
Сергей Котырев продолжает эту мысль: «Такая ситуация может иметь место, главным образом, в случае с так называемыми «внутренними» CMS. Студии с «внутренним» продуктом не имеют больших ресурсов для развития и обновления своей системы, поскольку почти все силы уходят на создание сайтов — ведь это основной для них источник дохода. Но сайт не может развиваться без развития CMS, а студии–разработчику внутренней системы далеко не всегда бывает выгодно дописывать новый функционал, поскольку это трудозатратно и дорого для клиента. И тогда заказчик оказывается в тупике: уход от студии означает потерю сайта, его придется делать с нуля. Даже если какое-то время нет задачи создавать новый сайт, клиенту негде будет получать техподдержку. Кстати, эти же риски связаны и с потенциальной возможностью ухода ключевого веб-девелопера из компании-разработчика».
В целом с коллегами согласен и Станислав Базылевич: «Если проект был создан на основе системы, за разработку которой отвечает одна компания, а производство сайта ведется партнерской сетью вендора, проблем с переходом от одного разработчика к другому в рамках партнерской сети нет. При этом если разработка велась на «самописной» системе, то, наоборот, проблем может возникнуть много (например, по причине некачественного менеджмента со стороны компании-разработчика), вплоть до полной переработки сайта и переноса на новую систему (в лучшем случае, с сохранением дизайна и контента). Это, как правило, и удерживает клиента от разрыва отношений с теми студиями, которые ведут разработку на собственных системах».
Более пессимистично настроен Михаил Токовинин: «Вероятность того, что вам потребуется смена подрядчика, намного выше, чем кажется. И причина этого — даже не в низком качестве услуг на нашем рынке, а в проблемах с «коммуникациями». Любой, даже самый благополучный проект содержит в себе конфликты и разногласия. Шансы на то, что заказчик и исполнитель просто перестанут или не захотят понимать друг друга, очень велики. Желательно, чтобы CMS была в стороне от этого и спокойно переживала переход разработки от одного подрядчика к другому. К сожалению, пока на рынке очень небольшой выбор систем, которые это позволяют».
«Разорвать отношения нетрудно — нужно всего лишь переделать сайт на другой платформе, -рассуждает Дмитрий Васильев. — Вообще, краеугольный камень идеологии «коробочной» системы управления сайтами — отчуждаемость от разработчика. Если CMS хорошая, пользователь будет очень редко общаться с производителем. Максимум это общение будет ограничиваться получением обновлений и консультациями с техподдержкой по нестандартным вопросам. Если же после начала использования система она оказалась неудобной или «тормозной», винить пользователь в этом может только себя - плохо выбирал. Но если страдает качество техподдержки или в системе обнаружились явные ошибки, клиент вправе требовать удовлетворения своих претензий, угрожая если не судом, то, по крайней мере, обнародованием своих проблем. Любой вменяемый производитель заботится о собственном имидже и, скорее всего, внемлет законным требованиям пользователя. Практика показывает, что самые недовольные пользователи легко могут превратиться в лояльных, если производитель не будет общаться с ними по принципу «продал и забыл».
Закончить же наш обзор, который, будем надеяться, поможет кому-то избежать ошибок при выборе CMS для своих интернет-проектов, стоит словами Михаила Токовинина, которые как нельзя лучше отражают суть и смысл правильного выбора системы управления контентом: «CMS должна прежде всего защищать ваши инвестиции в проект. Нередко сталкиваешься со случаями, когда CMS становится причиной переделки сайта. Это в корне неправильно. CMS должна не мешать развивать проект, не ограничивать вас в выборе хостинга или поставщика услуг».