Як правильно вибрати CMS

Автор: Дмитро Родін

Своєю думкою з цього приводу поділилися: керівник інтернет-напряму компанії «Ленвендо» Станіслав Базилевич, генеральний директор компанії QSOFT Михайло Токовінін, генеральний директор компанії «АІСТ» Дмитро Васильєв, генеральний директор ТОВ «Юмісофт» Сергій Котирьов та директор з розвитку компанії TRINET Олексій Довжиков.

1. На які параметри варто орієнтуватися при виборі CMS насамперед?

На це питання найбільш розгорнуту відповідь дав Станіслав Базилевич. Він назвав кілька «вирішальних» показників, розташувавши їх у довільному порядку і наголосивши, що цей список ще можна доповнювати:

Михайло Токовинін вкотре наголошує, що CMS має відповідати завданням проекту: «Якщо вам потрібен маленький сайт із контактами та описом компанії, і в найближчі кілька років навряд чи щось зміниться, безглуздо купувати для цього велику платну систему».

Сергій Котирьов вважає, що перед покупкою CMS варто обов'язково перевірити систему у дії: «Ми пропонуємо відкрити демо-версію та самостійно спробувати виконати деякі дії: наприклад, додати новину, скопіювати сторінку у структурному дереві та перенести її в дерево іншого сайту тощо. . - Ті самі дії, які доведеться виконувати щодня. Тоді вже клієнт замислюється, наскільки цей інструмент зручний для того, щоб працювати з ним день у день, працівник якоїсь кваліфікації зможе оперувати цим інструментом».

Олексій Довжиков підводить межу під висловлюваннями інших аналітиків: «На сьогоднішній день практично всі коробкові продукти, що займають топові позиції на ринку, задовольняють вимоги, перераховані вище. На мій погляд, найважливішим критерієм при виборі CMS є можливість вирішення всіхзавдань, поставлених замовником у межах проекту».

2. Чи є у CMS якісь неочевидні недоліки, які часто залишаються непоміченими клієнтами при виборі системи керування контентом?

Так є. Оскільки клієнти не є технічними фахівцями, вони можуть не бачити підводного каміння при виборі системи, вважає Станіслав Базилевич. — Часто максимум, на що вони можуть розраховувати — це демо-версія системи або просто словесна презентація. Проте технічні проблеми (якість коду системи, стійкість до злому) та комерційні проблеми (вартість володіння сайтом на основі обраної системи) виникають лише після виходу проекту на робочу експлуатацію».

Цю думку розвиває Михайло Токовинін: «Більшість таких недоліків замовник бачить, але не сприймає, воліючи не звертати на них уваги. Часто при виборі керуються не здоровим глуздом, а стереотипами, вибирають якусь «прогресивну» мову програмування, і потім дуже довго страждають. Якщо оперувати цілями, завданнями та грошима, то багатьох помилок можна уникнути».

Дмитро Васильєв має власну думку з цього приводу і розвіює один із міфів про роботу CMS. «Так, підводного каміння для недосвідчених користувачів може бути багато. Це і високі вимоги до хостингу, незручність адміністративної частини системи, і погана документація, і неінтуїтивність засобів розробки. Хочеться сказати про один «псевдонедолік», про який мені часто доводиться чути: універсальні CMS не гнучкі та підходять лише під типові завдання, а під складні завдання краще розробляти свою систему управління. Це зовсім не так. Нинішні провідні CMS є, зокрема, фреймворками, засобами розробки, значно спрощуючи реалізацію нетипових завдань. У більшостівипадків використання потужної системи управління для великих проектів є цілком виправданим», — пояснює він.

«Часто користувач, вже отримавши готовий сайт, бачить, як йому складно розібратися в багатьох налаштуваннях CMS, і що є необхідність витратити багато часу на навчання співробітників роботі з системою. Тому CMS має гармонійно поєднувати функціональні можливості з потребами клієнтів», - зазначає Сергій Котирьов.

Олексій Довжиков, у свою чергу, наводить приклад із власної практики: «До нас іноді звертаються клієнти з проектом, розробленим на CMS, яку вони придбали за рекомендацією або керуючись тим, що це «відомий бренд». Підсумок: у процесі або після реалізації проекту виявляється, що CMS не вирішує поставлених завдань».

3. Як правильно підібрати CMS залежно від хостингу та «серйозності» сайту? У якому разі і на чому можна заощадити і коли цього робити не можна?

Олексій Довжиков вважає, що для 95% інтернет-проектів, незалежно від CMS, де вони будуються, достатньо використання віртуального хостингу. «Якщо розглядати саме комерційні проекти, — продовжує директор з розвитку TRINET, — то питання економії на віртуальному хостингу не має сенсу. Вартість цієї послуги коливається від $2 до $50 на місяць. Відповідно, максимальна економія за рік становитиме не більше $500. Для будь-якої компанії, яка перед своїм проектом основним завданням ставить отримання прибутку, дана сума порівняно з доходом, що видобувається, незначна. Я вважаю, що немає сенсу економити на хостингу, оскільки якість ресурсу залежить від якості послуг, що надаються. Можлива економія незрівнянна з втраченим прибутком внаслідок некоректної роботи хостера».

«Ставити вибір CMS у залежність відхостингу — нерозумний підхід, — попереджає Сергій Котирьов. — Хостинг — це недорога та поширена послуга, тож доцільно підбирати хостери під CMS, а не навпаки. Крім того, сучасні технології дозволяють утримувати високонавантажувальні інтернет-проекти та на обмежених серверних ресурсах».

Дмитро Васильєв з ентузіазмом розповідає про можливість заощадити на виборі CMS: «Висловлю крамольну думку: залежно від завдання можна заощадити на всьому. Якщо бюджет дозволяє, потрібно вибирати перевірену імениту веб-студію та потужну систему управління з гарною технічною підтримкою, інакше приказка «скупий платить двічі» виправдається. Але коли проект невеликий, а бюджет його обмежений, на нього цілком реально вибрати недорогу (або взагалі безкоштовну) легку CMS, п'ятидоларовий хостинг та недорогого приватного розробника».

«Економити можна і потрібно, якщо немає грошей, а сайт не є основою бізнесу, — підсумовує Михайло Токовинін. — У решті випадків економити не варто. Насамперед, не варто економити на самій CMS. Вартість системи здебільшого нікчемна проти сукупними витратами проект».

4. Наскільки складно буває клієнту розірвати стосунки з компанією-розробником обраної ним CMS? З яких причин найчастіше відбувається такий розрив і які обставини можуть утримувати клієнта?

«Перш ніж відповісти на це питання, я хотів би розділити два поняття: компанія-розробник проекту (компанія-партнер, студія) і компанія-розробник CMS, — починає Олексій Довжиков. — Якщо ми говоримо про взаємини клієнта та компанії-партнера, яка використовує коробкову CMS, то здебільшого причинами розриву є некомпетентність та непрофесіоналізм цієї компанії. У подібній ситуаціїприпинення співробітництва може бути безболісним для замовника, оскільки він має можливість перейти до іншого партнера. Найчастіше зустрічаються проекти, зібрані на власній CMS студії-розробника. Розрив відносин із такою компанією та звернення до іншого розробника в більшості випадків тягне за собою розробку проекту з нуля на новій платформі, хоча, звичайно, є й винятки».

Сергій Котирьов продовжує цю думку: «Така ситуація може мати місце, головним чином, у разі так званих «внутрішніх» CMS. Студії з «внутрішнім» продуктом не мають великих ресурсів для розвитку та оновлення своєї системи, оскільки майже всі сили йдуть на створення сайтів, адже це основне для них джерело доходу. Але сайт не може розвиватися без розвитку CMS, а студії-розробнику внутрішньої системи далеко не завжди буває вигідно дописувати новий функціонал, оскільки це важко і дорого для клієнта. І тоді замовник опиняється в глухому куті: відхід від студії означає втрату сайту, його доведеться робити з нуля. Навіть якщо якийсь час немає завдання створювати новий сайт, клієнту не буде де отримувати техпідтримку. До речі, ці ж ризики пов'язані і з потенційною можливістю звільнення ключового веб-девелопера з компанії-розробника».

Загалом із колегами згоден і Станіслав Базилевич: «Якщо проект був створений на основі системи, за розробку якої відповідає одна компанія, а виробництво сайту ведеться партнерською мережею вендора, проблем із переходом від одного розробника до іншого в рамках партнерської мережі немає. При цьому якщо розробка велася на «самописній» системі, то, навпаки, проблем може виникнути багато (наприклад, через неякісний менеджмент з боку компанії-розробника), аж до повної переробки сайту та перенесення на новусистему (у кращому випадку, із збереженням дизайну та контенту). Це, як правило, і утримує клієнта від розриву відносин із студіями, які ведуть розробку на власних системах».

Песимістичніше налаштований Михайло Токовинін: «Ймовірність того, що вам знадобиться зміна підрядника, набагато вища, ніж здається. І причина цього — навіть не низька якість послуг на нашому ринку, а проблеми з «комунікаціями». Будь-який, навіть найблагополучніший проект містить у собі конфлікти та розбіжності. Шанси на те, що замовник і виконавець просто перестануть чи не захочуть розуміти одне одного, дуже великі. Бажано, щоб CMS була осторонь цього і спокійно переживала перехід розробки від одного підрядника до іншого. На жаль, поки що на ринку дуже невеликий вибір систем, які це дозволяють».

«Розірвати відносини неважко - потрібно лише переробити сайт на іншій платформі, - розмірковує Дмитро Васильєв. — Загалом наріжний камінь ідеології «коробкової» системи управління сайтами — відчужуваність від розробника. Якщо CMS хороша, користувач буде рідко спілкуватися з виробником. Максимум це спілкування обмежуватиметься отриманням оновлень та консультаціями з техпідтримкою з нестандартних питань. Якщо ж після початку використання система вона виявилася незручною або «гальмівною», звинувачувати користувач у цьому може лише себе – погано вибирав. Але якщо страждає на якість техпідтримки або в системі виявилися явні помилки, клієнт має право вимагати задоволення своїх претензій, погрожуючи якщо не судом, то принаймні оприлюдненням своїх проблем. Будь-який осудний виробник піклується про власний імідж і, швидше за все, дослухається до законних вимог користувача. Практика показує, що незадоволені користувачі легко можутьперетворитися на лояльних, якщо виробник не спілкуватиметься з ними за принципом «продав і забув».

Закінчити ж наш огляд, який, сподіватимемося, допоможе комусь уникнути помилок при виборі CMS для своїх інтернет-проектів, стоїть словами Михайла Токовініна, які якнайкраще відображають суть і сенс правильного вибору системи управління контентом: «CMS має насамперед захищати ваші інвестиції у проект. Нерідко стикаєшся з випадками, коли CMS стає причиною переробки сайту. Це докорінно неправильно. CMS має не заважати розвивати проект, не обмежувати вас у виборі хостингу чи постачальника послуг».