Технологические аспекты выбора CMS

Очень рад началу нашего сотрудничества с Ильей и компанией J-Vista. Доклад был одним из лучших в профессиональной секции.

Выложили презентацию на SlideShare (http://www.cmsmagazine.ru/cms-choose/)

Спасибо. Прочитал, но некоторые куски пробегал глазами, особенно про сравнение неинтересных мне CMS из рейтинга. Довольно мутно всё. На мой взгляд, на основе подобного подхода никто не будет делать выбор CMS для проекта.

Вы попытались определить чёткие объективные критерии для такого выбора, но CMS в 90% случаев выбирают субъективно. Если веб-разработчику (команде), нравится, например, TextPattern, то маловероятно, чтобы они стали делать новый сайт на UMI.CMS. Причем, даже если допустить, что новая CMS будет объективно лучше технически, не факт, что её выбор будет лучшим решением, учитывая затраты ресурсов на переобучение.

И немного оффтопа для этой темы. Не понимаю, зачем в CMS Magazine рейтинг строится именно так. Неужели кому-то важны суммарные ТИЦ и PR проектов?

Суммарный тИЦ внедрений позволяет определить распространенность системы. Причем, это не просто количество установок, а и косвенная оценка самих внедрений.

BrokenBrake, спасибо за отзыв!

Секция, где я выступал, называлась "инструментарий веб-студии". Тут более сложная задача - не выбор системы для отдельного проекта, а выбор основного инструмента для большинства проектов, которые выполняет команда. Ясное дело, к такому вопросу следует подходить более ответственно. В частности, полезно изучить технические особенности систем-кандидатов.

Во-первых, что значит "субъективно"? В смысле, "дизайн упаковки понравился"? :) Такое, слава Богу, уже не часто встретишь. Во-вторых, откуда цифра? )

Я соглашусь, что большинство студий при выборе CMS не руководствовались каким-то систематическим подходом, процесс выбора не был формализован. Ну, грубо говоря, генеральный услышал про X.CMS, предложил программистам попробовать, понравилось, вот система и выбрана. Или, например, студия делала сайты на своей системе, потом пришел новый сотрудник, сказал, что на X.CMS быстрее и проще, попробовали, понравилось... ну и т.д. Оданко, это самое "понравилось" в любом случае имеет под собой ряд объективных критериев. Я лишь попытался формализовать часть из них.

У нас после конференции была интересная дискуссия с Shivana на эту тему. С одной стороны, внедрять технически отсталую систему только потому, что она привычнее - наверно, не совсем правильно. Но я категорически убежден, что решение о смене CMS не должно спускаться "сверху". Переучиваться против своей воли программисты не будут :) Но если к команде придет понимание: "надо что-то менять" - обязательно нужно выделить время на изучение конкурирующих систем. Иначе, маринуясь в собственном соку, легко отстать от жизни.

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

Во-первых, техническими характеристиками процесс выбора не ограничивается, я об этом много раз говорил. Просто технологии сложнее анализировать. Во-вторых, если в компании много времени тратится непосредственно на разработку (что особенно характерно для больших сложных проектов) - это как раз тот момент, который необходимо оптимизировать любыми средствами. Если компания планирует просуществовать хоть сколь либо долго, затраты обязательно окупятся. Например, если потратить на обучение неделю и ускорить реализацию месячного проекта хотя бы на 2 дня (10%) - затраты окупятся через 4 проекта :)

А кстати, почему неинтересных? Лидеры, как никак. Правда любопытно :)

Доклад был роскошный.

Самый главный недостаток доклада, то что он был короткий :))

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

При этом же надо было ухитриться никого не обидеть и не задеть, тебе это удалось )

Просто мастер!

А по сути доклада, давно сталкиваюсь с проблемой аргументации перед клиентами, почему мы им предлагаем именно систему управления Netcat, а не какую либо другую, в чём плюсы-минусы разных систем и т.п.

В общем пойду-ка я читать доклад, раз Илья говорит, что там информации больше, чем в устном докладе )

Спасибо, очень полезная статья. Автору респект, умную тему в закладки ☝

прекрасная статья

Ничего нового.., но тема раскрыта отлично)

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

Согласен.

Попса редко блещет красотой. Популярность обычно обсуловлена максимальной простотой для конечного пользователя, при этом зачастую в ущерб техническим решениям. Я не в курсе текущей ситуации, но когда несколько лет назад выбирал для себя основную CMS, был очень неприятно удивлён корявой реализации кода Joomla, WordPress и некоторых других (перебирал не один десяток). Это просто моё мнение, холиваров на эту тему поддерживать не буду.

Спасибо, интересные и доклад, и презентация PowerPoint. Про неткат лично я знал мало и никогда с ней не возился, про UMI - вообще только слышал, да и про Битрикс, который я, конечно, знаю намного лучше, прочел с интересом.

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