Как стать автором
Обновить

Комментарии 131

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

1. Льготное продление (в первый месяц по истечение года, им пользуются почти все, кто вообще обновляется) — 22% от стоимости лицензии. Это — чуть больше 1/5, а не «полная».

2. Масса примеров, когда люди покупают продление через 2-3 года после окончания действия обновлений.

Делают они это явно не из-за косяков (а как тогда работают эти годы?), а для того, чтобы получить новый функционал.
Какая ж дезинформация, реальный кейс из практики. Некая компания создала продукт на лицензии «Управление сайтом — Бизнес». При покупке лицензии компанию не предупредили о том, что в CMS могут наличествовать критические ошибки, которые в принципе не разрешимы без обновлений. Год льготного продления прошёл спокойно, а вот через год и два месяца компания встала перед тем, что ряд инициатив тупо не внедрить, потому что в админке баг.

Как вы понимаете, менеджеры должны объяснять руководству, с какой стати они должны ещё раз вкладываться в уже ранее купленную лицензию.
Этот кейс хорошо подтверждает тезис о том, что Россия — страна, в которой наиболее быстро читается любое пользовательское лицензионное соглашение. ;))

Если серьезно, то, я думаю, Вы несколько лукавите.

1. Был баг, который Вы терпели в течение года? Или не замечали? Он был критичным, и его не исправляли?

2. Когда заканчивается период действия обновлений, приходит письмо о том, что надо купить продление. Со всеми условиями и т.п. Оно быстро и аккуратно удаляется в корзину или все-таки прочитывается?
Не лукавлю, менеджер не я. Баг не замечали: сайт был собран, работал в собранном виде нормально. Потом проект дошёл до той фазы, которая в статье называется «Постоянно добавлять к веб-решению новые „фичи“, развивать сайт быстро и уверенно, не отставая от конкурентов», и это случилось более, чем через год после покупки лицензии. Честное слово, не самый невероятный случай.

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

В общем, история как с бытовой техникой. Какая-то ломается через месяц после окончания гарантийного срока, а какая-то служит долго. Конечно, клиент сам дурак, что плохой чайник купил — он же в курсе был, что гарантия только год. В следующий раз купит хороший чайник.
Если через месяц после окончания гарантийного срока в чайник попробовать добавить функцию кофеварки — и он вдруг сломается… Да, вот тогда это будет вполне верная аналогия.
Ещё раз, там баг админки вашей, которую без оплаты почти полной стоимости лицензии не починить. Это не добавление функции кофеварки, это неработающая функция самого чайника.
Чтобы не было недопонимания — можете сказать конкретнее, о каком именно баге речь?

А то звучит то «платформа», то «админка». А это — несколько разные вещи. В разной степени влияющие на возможность развития проекта.
В панели управления «Контент → Информационные блоки → Редактирование любого информационного блока → Вкладка свойства → Настройка свойства». При сохранении появляется пустой экран, настройки не сохраняются.

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

Это все-таки не про админку (хотя и проявлялось в ней).

И если проявилось только через год, значит, за год с сайтом практически ничего не делали…
С ним действительно практически ничего не делали, кроме наполнения контентом — он спокойно себе стабильно работал в том виде, в котором его создали. Именно потому, что его сразу хорошо спроектировали и хорошо собрали.

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

А то, что после года обновления перестают быть доступными — ну так практически все платные системы поступают. Среди коммерческих cms найти ту, которая бы предоставляла пожизненные обновления, я не встречал (возможно есть, не спорю).

Так же, возникала какая-то ошибка, а белый экран по причине отключенного показа ошибок php. Может быть нужно было изучить проблему?
А вот тех. поддержка, скорее всего просто не стала вникать в суть проблемы, так как у вас стояла старая версия, а обновление, возможно (! именно возможно), могло бы решить проблему.
Я считаю, что баги продукта должны закрываться бесплатными обновлениями. Платные обновления должны быть с улучшениями. Т.е. отрефакторенный код, улучшена производительность, новый функционал — это все вполне себе можно давать за деньги. Но править свои косяки надо бесплатно.
Что, в принципе, не отменяет того факта, что пока неизвестно, баг ли это Битрикса.
Что, в принципе, не отменяет того факта, что пока неизвестно, баг ли это Битрикса.
Это да. Причем такой явный баг, когда при сохранении пользовательского свойства ничего не происходит не мог быть не замечен ни битриксом, ни разработчиками самого сайта. Появление его позже мог быть вызван другими причинами (например, разработчики модифицировали ядро, а потом сайт был обновлен).
Но как правило явные, откровенные баги в битриксе отсутствуют (критичные, влияющие на безопасность или вообще крах системы в целом).
А мелкие дефекты системы, обычно системами предоставляются платно (так как они критично не влияют на работу продукту).
Вы не выдумывайте лишнего, никто никаких ядер не трогал. Что это баг Битрикса известно, потому что это ранее подтвердила техподдержка и представитель Битрикса выше.
Номер обращения не подскажете?
208059
Думаю вам стоит проверить настройки хостинга. Я бы рекомендовал развернуть копию на VMBitrix 2.0 и посмотреть как все будет работать.
Думаю вам стоит для начала посмотреть какие ошибки выдает php или база данных ($DBDebug=true в dbconn.php). Вполне возможно что ваша проблема никак не связана кодом продукта, а развалилась таблица или недостаточно каких либо ресурсов.

А уж после этого делать выводы.
Потом проект дошёл до той фазы, которая в статье называется «Постоянно добавлять к веб-решению новые „фичи“, развивать сайт быстро и уверенно, не отставая от конкурентов»


Не понимаю, как вы все это рассчитывали сделать на неактуальном API ПО?

Мы если берем проект на Битрикс на доработку, то у нас одно из обязательных требований: возможность получения обновлений и ТП должны быть активны, так как разработчики не могут держать в голове, к примеру: «Какие там параметры эта и эта функции получали 2 года назад и что возвращали… а была ли эта функция там вообще?» ну и тд
Ну, все-таки не полную стоимость, а 22% от полной стоимости.
Согласен, неверная формулировка. Есть риск попасть на то, что придётся за лицензию заплатить дважды. :) Который как минимум в одном известном мне случае был реализован.
В хелпе или блоге своём это напишите. Зачем на хабре постить?
Я пишу для менеджеров веб-проектов как грамотно составить ТЗ и организовать процесс разработки и дальнейшей поддержки решения снизив ключевые риски на коробочном решении, в том числе нашем. Думаю, информация окажется полезной многим.
А как связано грамотное ТЗ и, например: «требований к качеству интеграции решений на Битрикс»?
В огороде бузина, а в Москве Битрикс :)

По ходу — текст составлен из кусков выдранных из рекламы писанной маркетологами и подогнан под многообещающий заголовок.
Я, как заказчик — ни когда не пойду в Битрикс… после таких текстов, ибо чувствую что мне только мозги будут парить умными словами, а не решением моих проблем и задач, и впаривать то, что под капотом (в коробке).

Ну а специалист, прочитав среди достоинств платформы в 2011 году: «Редактирование телефона», «Управление меню», «Управление числом новостей на странице» явно будет стараться держаться подальше ;).
Чтобы написать качественное ТЗ, нужно, согласитесь, немного разбираться в платформе и ее особенностях. Знать, что работает из коробки, а что дописывать.
Чтобы написать качественное ТЗ нужно просто знать, чего нужно получить, а потом уже выбирать платформу.
А потом окажется, что 90% функционала нужно писать с нуля. Я обычно изучаю фреймворки и коробки, прежде чем писать ТЗ, чтобы воспользоваться готовым функционалом и подтянуть к нему требования — так можно быстрее запуститься и снизить риски.
Ничего-ничего, мы вас потихоньку выгоним с рынка с вашим «чтобы сделать грамотное ТЗ, посмотри на функционал Битрикс». Ущербный подход из 90-х — начала 2000-х, когда никто ещё слыхом не слыхивал про нормальное проектирование и ориентацию на бизнес-задачи клиента, а не функционал «коробки».
С такой пиар и сэйлз машиной как у 1C этого не произойдет, а на тех кто будет реально в этом ковыряться и допиливать всем насрать.
Ну зачем тратить силы на выталкивания? :-) У фреймворков, к которым относится платформа Битрикс, своя ниша на рынке, у разработчиков — другая. Важно предупредить клиента, что если он закажет разработку «чего придумает», «с нуля», у команды с непонятной квалификацией, то рискует нарваться на:
— Срыв сроков
— Некачественную реализацию, что станет понятно не сразу, а когда объем данных или посещаемость проекта увеличится
— Нерасширяемую реализацию, что станет понятно также не сразу :-), а когда клиенту нужно будет добавить что-либо

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

То есть вместо того, чтобы решать задачу заказчика, вы подгоняете ее под битрикс?
Все таки, как то принято что сначала решают _что_ делать, а потом подбирают под это инструменты. А тут… Ну скажем честно — пиар одного инструмента и рекомендации подгонять ТЗ под то, что может инструмент ( как-то, видимо замалчивая то, что он не может). Как-то это не честно по отношению к клиенту.
Всегда ищется компромисс. По такому принципу, как вы описали могут делаться проекты с неограниченным бюджетом.
Да и если к вам обратился человек, вы скорее всего программируете на одном или нескольких языках, максимум, и на одном или нескольких фреймворках, CMS.
Задача может быть поставлена таким образом, что ее быстро и дешевое решение будет не возможно. Возможно, для ваших задач вообще не подойдут веб языки и вам придется использовать си.

Например, у битрикса есть админка. Такая, какая есть. Ее можно изменять, править, но в определенных пределах.
А если придет клиент и скажет: так вообще не хочу, хочу вот так, да и чтобы тут дизайн такой админки был и т. п. Я думаю ему это сделают (может быть даже на битриксе), но скажут «с вас еще одна сумма бюджета». После этого клиент крепко задумается, посмотрит, что все в принципе то не плохо и он не готов платить столько денег за не такие уж и значительные перемены в админке.
То есть, ущербность и ограничения платформы, а так же невозможность (или дороговизна) изменения админки(и не только) под задачи и требования клиента влекут повышенные затраты на доработку такой CMS, что в конечном счёте значительно увеличивает стоимость проекта. И в конечном счёте получается, что клиент должен получить не то, что он хочет, а то что ему навязывают.
И составление ТЗ (по вашему) выливается в подгонку под возможности битрикса, а не под конкретные потребности и требования заказчика.

Тогда автору и стоило указать, что берем ТЗ клиента, погоняем его (ТЗ) под готовую коробку битрикса и вперед — продано…
Любая CMS имеет те или иные ограничения. Поэтому речь идет не о правке текущей админки, а о, как альтернативе, разработки админки с нуля. И, само собой, такое решение будет стоит дороже, если его необходимо реализовать качественно.
А клиент — как правило он всегда находится в компромиссе между своими финансовыми пожеланиями и возможностями.
Порой приходят клиенты и говорят: «хочу сайт один в один как „в контакте“. Когда ему говорят стоимости такого решения, написанного с нуля, а как альтернативу предлагают какую-либо cms, которая неплохо реализует социальную сеть, а так же недорогую доработку, чтобы изменить некий фукнционал… Да, это уже не будет точь в точь контакт. Но и стоить он будет значительно меньше. И человек либо берет такое, либо разочаровывается в своих финансовых возможностях.
С ограничениями — согласен. Но если битрикс ограничен в возможности правки админки или ещё где — стоит подумать о смене CMS, на более гибкую и удобную клиенты. По автору получается: битрикс only…
Все остальное подгонка ТЗ под возможности и ограничения битрикса как платформы. В тексте 10 абзацев, 8 раз употреблено слово битрикс и ни одной другой системы.
Стоит статью переименовать "… что не забыть предусмотреть в ТЗ для Битрикса".
А то читатель подумает, что среди CMS есть только битрикс и придется свои идеи чётко подгонять под возможности и ограничения этой платформы.
Согласен. Но, по-моему, вы бьетесь о стену.
То есть вместо того, чтобы решать задачу заказчика, вы подгоняете ее под битрикс?


Можно заменить слово «Битрикс» например на «SAP R3» и так же долго возмущаться несправедливости этого Мира…
Этим мы снижаем риски Заказчика, продавая ему готовый настраиваемый функционал. Остается его как часто бывает частично расширить и сконфигурировать — эта процедура прозрачна и поддается адекватной оценке.
Простите, но в вашей статье нет ни слова о грамотном составлении ТЗ. Ни-еди-но-го-сло-ва.
Подробнее о составлении ТЗ в следующих постах. Тут — концепция, что точно должно быть.
Замените слово «Битрикс» на слово «CMS». И вы все равно получите очень неплохую статью для менеджера веб-проекта.
На что ни заменяйте, все равно к 2012 году каждой компании нужен штатный программист.

Возможность в CMS «Редактирование телефона» и «поиграть числом слов в анонсе новости, после которых ставится троеточие», это конечно супер, но давайте не будем никого обманывать.

А заголовок лучше бы взяли из подзаголовка «Как же «выжать» максимум пользы из Битрикс и интеграторов веб-решения?».
Одна из фундаментальных идей платформы Битрикс — управляемость веб-проекта менеджером, без привлечения программистов. Вам делают не технический конструктор с торчащими проводами и запахом горелой проводки, а полноценное управляемое бизнес-решение.
Другими словами, вы даете в аренду админку. В которой шаг влево — шаг вправо — смерть.

Извините, но есть куча опенсорс CMS с такой же миссией.

А вообще тогда непонятен ваш пиар своего API, или что там у вас. И попытки привлечь разработчиков программировать на Битрикс. А зачем? Если программиста-специалиста под Битрикс потом заменяет менеджер?

Вот случай. Звонят и говорят «у нас тут менеджер отредактировал главную и теперь там белый экран, а штатного программиста у нас нет». Оказалось тогда, он умудрился поставить
Админки гибко настраиваются. Задача разработки — подготовить бизнес-ориентированный веб-инструмент и передать его в эксплуатацию клиентом. Все четко и ясно.
Разработка — это процесс, а не результат. Большинство сайтов так или иначе наращиваются функционалом, какими-то сложными страницами со своей версткой, клиентским и серверным кодами.

Если на сайте этого не происходит, можно взять бесплатный WordPress, там из коробки тоже хорошая админка, да. Новости и телефоны менять можно. И кстати без претензии на целую инфраструктуру, в которой есть свои настройщики, консультанты, книги, но нет программистов от клиента.
Для программиста разработка, да, это процесс. Для бизнесмена — средство для получения результата.
С такими идеями вы тащили в 2000-е, когда богатые дядьки не знали, что такое интернет. Когда вы пришли и сказали: «Вот будет сайт, сможешь новости сам добавлять, программисту платить не надо».

А сейчас, извините-подвиньтесь. Информатизация ёпта.
Вы предлагаете продавать автомобиль с командой механиков/сварщиков в придачу? :-) Автомобиль имхо должен быть самодостаточным, а вот если нужно двигатель форсировать — пожалуйста, обращаемся к специалистам.
«продавать автомобиль с командой механиков/сварщиков в придачу»?
Нет, не предлагаю, не понятно, где вы это вычленили из моих комментариев.

Значит специалисты все-таки нужны? Определитесь уже, с какими вы претензиями продаете продукт))))

Кстати аналогия с авто неуместна и явно не в вашу пользу — я не видел бесплатных авто и не видел, чтобы за автомобиль нужно было платить производителю всю свою жизнь, за «лицензию».
Бесплатный авто нет, а вот платить за авто нужно всю его жизнь (может быть не производителю, а его дилеру или другим людям).
Автомобиль постоянно нуждается в обслуживании, в регламентных работах, в ТО и т. п. И все это стоит существенные деньги. И сделать вы сами, если не специалист, не сможете.
Но пи выборе автомобиля вы смотрите, чтобы он подходил под ваши задачи, кошелек и взгляды на вождение.
А вам предлагают купить ладу-калину и научиться ездить только на ней, в не зависимости от ваших задач и потребностей ;)
Если у вас денег на калину, а вы приходите в салон мерседеса — то вам только могут предложить купить калину, в соседнем салоне лады (ну или сами, если они их тоже продают — но такое не видел :) )
Никто, никого не заставляет использовать битрикс, друпал, вордпресс, фреймворки или вообще php.

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

Да и сравнивать авто и систему управления сайтом достаточно сложно.

Притом, что, еще раз повторю, в политике битрикса по поводу оплат, обновлений и т. п. нет ничего сверхъестественного — так делают практически все коммерческие системы!
Автомобиль имхо должен быть самодостаточным, а вот если нужно двигатель форсировать — пожалуйста, обращаемся к специалистам.
Ошибаетесь. Вам постоянно нужны будут специалисты. Чтобы пройти ТО, заменить расходники, поменять колеса (с летней резиной на зимнюю). Через какое-то время вам потребуется замена каких-то частей подвески и т. п. С нашим плохим бензином, потом вам может понадобиться промывка инжектора. С нашими плохими дорогами, вам придется менять шаровы, салентблоки и стойки не так уж и редко. Да, возможно вы в состоянии часть работ или все их сделать сами. Но и с ситуацией с сайтами такая возможность есть.
Сайт, в отличие от этого, может не нуждаться в программистах практически бесконечное время.
Почему же — обманывать…

Мой личный опыт работы в суппорте хостинга. Клиент и тех. поддержка:

— Поменяйте нам, пожалуйста, одну строчку (телефон) в одном файлике на сайте! Очень срочно!
— Мы не вмешиваемся в контент пользователей, это — задача Вашего разработчика.
— Он у нас уволился…
— Поменяйте сами. Мы все подробно расскажем, как зайти по FTP, как обновить и т.п.
— Мы не умеем! Надо очень срочно! Мы заплатим! Помогите!

Это — типичный если не ежедневный, то уж точно еженедельный (по несколько раз) диалог…
Слушайте, на меня капает что-то с потолка. Водичка?
Сам себя не похвалишь, ни кто не похвалит. Куча слабосвязанной воды налита…

Быстро или правильно?
Какая-то глупость рекламная. Можно быстро и качественно… :)
Если квалификация внедренца недостаточная, то и в битриксе он вам накосячит и в любой другой CMS несмотря на время…

Сложно разделить доступ к разным разделам админки веб-решения
нет проблем практически в любой приличной CMS

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

Уровни доступа могут быть в коробке, я пишу что ОНИ ДОЛЖНЫ БЫТЬ В ТЗ. Нередко на скорую руку и ногу делают одного админа, вшивают логику в код и мучаются годами.

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

Вы видимо не сталкивались с загнивающими веб-проектами, которые оживляют дефибрилляторами команды из десятков сходящих с ума программистов? :-)

Так, а я тут пытаясь постичь тайное третий раз перечитываю в поисках основной идеи помимо слова «битрикс». Так значит вы хотели написать «Уровни доступа могут быть в коробке и ОНИ ДОЛЖНЫ БЫТЬ В ТЗ»? Это даже не в блоге, в твиттере написать можно.
Вы погружаетесь в детали :-). Идея статьи — помощь менеджеру веб-проекта расставить правильные веса в ТЗ и получить работающее веб-решение, долгие годы, а не разваливающийся конструктор в 5 программистами в придачу. Даже такие простые принципы быстрой разработки, о которых пишется, постоянно игнорируются направо и налево, и от этого страдают… правильно, пользователи.
Честно. Не первый раз читаю ваши топики и комментарии. И такого количества воды я нигде не встречал. В чём основной посыл статьи? Если выделенная мной надпись — это погружение в детали, то где вообще смысл спрятан? В чём помощь менеджеру? Что конкретно он должен извлечь из данной статьи? Ну, помимо абстракций про разваливающееся не пойми что без Битрикса.
Ну раз вы 3 раза все прочитали и не поняли, боюсь ничем вам не смогу помочь.
Ещё раз честно. Не ожидал другого ответа.
Смысл статьи: «если хочешь снизить риски на поддержку и развитие веб-решения, неважно на какой коробке, то предусмотри управляемость системы в ТЗ (идут примеры), раздели роли и права, хорошенько подумай и напиши чем тебе нужно управлять (идут примеры) и не забудь про проведение нагрузочного тестирования, примеры которого есть на нашем сайте».
Ну и то хлеб, спасибо. Теперь хоть знаю что вы не бот. Есть, конечно, ещё о чём поворчать, но и без меня поворчат.
5 баллов! «Вы погружаетесь в детали :)» Не надо, товарищ, погружаться в детали. Это пустое…
С Agile как то мимо… Вы считаете, что если его применить в Drupal, то будет деградация качества? Я думаю что больше к этому ведут кривые руки и недостаточные знания.
Или всё же битрикс будет хорош и в таких «умелых» руках?

Drupal этим не страдает. Уровни доступа можно разделить в любой момент, даже после внедрения и добавления любых сущностей. Возможно вы не сталкивались с нормальными фреймворками, и дефибриллировали только самопись студентов. Отсюда и странные требования и выдуманные ограничения.

Загнивающие проекты — тупо переносятся данные. Ни кто, в здравом уме не пытается реанимировать (ну только если не нужно освоить хороший бюджет) ;)

А как у самого битрикса с тестами кода ядра и модулей?
Переносятся данные… а если они в ужасном деби-нормализованном состоянии и одну БД используют десятки проектов и каждый понимает колонки таблицы, названные «понятно» (f1,f2,f3,...) по-своему? А такие самописные проекты бывают и частенько.
Веб-проект с хорошей идеей, реализующей потребности пользователей, ни-ко-гда не умрёт из-за «не так» работающей CMS или использования Agile.

Посмотрите, например, на сайт www.couchsurfing.org/ — это вообще глухие 90-е. Понятия не имею, на какой CMS они там сидят, но я знаю, что его собрали быстро и ловко, и явно на чём-то диком и старом. Сайт периодически лежит, юзабилити на нуле. И что? Таких примеров — море.
Есть идея, а есть реализация. Когда код превращается в дом терпимости, программистов меняют каждую неделю — то идея точно загубится :-)
Указанные преимущества Битрикс — нормальные для любой развивающейся CMS, в том числе и для бесплатных.
Вы хотите сказать что Битрикс — не такая уж и отстойная? :)
Статья не о преимуществах Битрикс, а о том, как нужно писать ТЗ :-).
Чё правда !? По моему вы меня пытаетесь обмануть.
Присоединяюсь к предыдущему докладчику.
Не согласен. Я увидел только два слова в начале о том, что «трудно поменять телефон», а потом мощный заголовок:

«Как же «выжать» максимум пользы из Битрикс и интеграторов веб-решения?»

И пошло — бла-бла-бла, Битрикс, админка Битрикс, графики, Битрикс.
+ 1000 :) скорее всего это основной посыл.
Складывается впечатление, как в анекдоте: «Если других машин не видеть — то жигули классная тачка»
Большинство веб-проектов в рунете делают на Битриксе, хочется предостеречь от известной ошибки «сделаем быстро и плохо, а потом допишем» и ее следствий коллег менеджеров.
Ни чего себе заявление.
(из под стола) Поделитесь пруфом на вменяемую статистику по рунету?
Или кроме жигулей машин нет больше.
Я не защищаю Битрикс, но вот, например.
Это всего лишь чей-то каталог, инфа может быть неверной.
Ну это не совсем «чей-то каталог», а один из крупнейших ресурсов по теме. Они же делают Рейтинг Рунета.
Я делаю сайты на Drupal, но почему-то ни одного из них не отправил в этот каталог, и не слышал, чтобы кто-то из коллег или знакомых этого делал.

Возможно, издатели других CMS сами эти занимаются или стимулируют это.
Я владелец веб-студии, и могу отметить три федеральных ресурса, с которых к нам приходят клиенты:
1. Рейтинг призводителя CMS, на которой мы работаем (1С-Битрикс, кстати)
2. Рейтинг CMSMagazine
3. Рейтинг Тэглайн

Также клиенты к нам приходят по рекомендациям, по региональным рейтингам и из рекламы.
В среднем CMSMagazine и Рейтинг Рунета (это связанные проекты) дают 3 целевых посетителя в день.

Так что я бы не назвал его «всего лишь чей-то каталог». Объективно, сейчас это самый полный каталог веб-студий и их работ в пределах бывшего СССР.
3 целевых это три звонка?
наверное, не совсем корректно выразился: 3 посетителя в день, включая выходные.
конвертация посетителей в звонки не 1:1, конечно. но, тем не менее, сути это не меняет — это не просто какой-то рейтинг. многие заказчики говорили, что смотрят на позиции компании в рейтингах.
Одна из самых вменяемых: itrack.ru/research/cmsrate/

Правда, это статистика именно по CMS. На абсолютном большинстве сайтов тиражируемой CMS нет.

Битрикс не первый в «общем зачете», но среди платных CMS — безусловный лидер.
Отдел соцмедиа компании Битрикс прочитал статью «Как тонко продвигать продукт в социальных сетях» в газете Московский Комсомолец выпуска 2009 года.
Трудно поменять телефон в подвале, потому что программист не пркрутил соответствующий функционал к админке, и Битрикс тут никаким образом не спасет положение. Тот же WordPress умеет редактировать копирайт без привлечения программиста, только этот функционал нужно прикрутить к подвалу.
Ну так в чем соль? Как и битрикс, так и WordPress могут это делать, но при условии, если админ предусмотрел это. Если нет, то тут уже система не спасет.
В битриксе, кстати, это дело редактируется «с лица». Но множество программистов почему то упускают такие моменты, и различные элементы просто «зашивают» в шаблоне.
Точно. Платформа Битрикс предоставляет много инструментов именно для клиента, но не всегда клиент о них знает, и не всегда ему о них говорят разработчки :-)
И слава Богу!
Кстати Ucoz умеет все то же самое, но его все равно никто не считает хорошим движком. И Umi умеет. Так что подобные вещи в Битриксе не стоит называть его преимуществами перед остальными движками.
Ну так никто не говорил, что этого нет больше ни где. Наличие только этой фичи, не говорил автоматом о том, движок хороший.
НЛО прилетело и опубликовало эту надпись здесь
Из-за таких как вы, клиента приходится погружать в тех. подробности, «как это работает», и соотвественно, тратить ~2 часа на предварительной стадии переговоров.
А чуть позже объяснять, почему в редакторе тизера новости его PR менеджеру никогда не понадобится тэг H1.

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

Вы портите рынок разработки сайтов, не работайте больше в этой области – и этот день станет лучшим в жизни многих людей.
Никто никого насильно не заставляет использовать битрикс. Если бы битрикс был бы очень плохим и ужасным движком, с огромной кучей багов, недостатков и т. п. — его бы никто и не покупал.
Никто не говорит что он плох и ужасен и в нём много багов. Его поддержкой и развитием занимается большая компания, в которой есть квалифицированные сотрудники. Но:
  • Маркетологи 1С привили рынку мнение, что собрать сайт с помощью конструктора лучше, чем сделать решение под конкретного клиента, и, самое главное, у лдей создаётся впечатление что на выходе получается качественный сайт.
  • Из идеологии системы слудует её перегруженность бесполезным для половины клиентов кодом
  • Как следствие, тормоза и не самый простой интерфейс управления
  • Ко всему прочему, это ещё и PHP с низким порогом вхождения, и, как следствие, обилие низкоквалифированных кодеров на рынке интеграции

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


Скажите, а у вас есть примеры подобных, доступных ИТ-директору тестов производительности других систем?
Которые были бы именно для системы в стандартной поставке?
Я (и думаю, что не только я) был бы рад ссылкам на подобные сравнения, это бы очень нам помогло в общении с клиентами.
Извините, но IT-директору должно быть достаточно этого

О какой производительности мы говорим при 199 запросах на одну страницу?
Извините, но не уловил связи между конкретным сайтом с большим числом статики, которая отдается например, через nginx, и производительностью динамических страниц CMS
Производительность динамических страниц CMS я даже не вижу смысла обсуждать – отренденный код должен лежать в кэше и забираться оттуда + навешиваться динамические блоки (если они есть). Следовательно, имеем один запрос к кэшу + в зависисмости от ситуации по одному-два запроса на динамический блок.

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

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

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

А вот для больших проектов или проектов в сфере интернет-коммерции время создания динамических страниц, работа с кэшем и гарантированная возможность работы под большой нагрузкой — это очень важно. И я не видел подобных тестов от других систем. Думаю, что это достаточно дорого и не всем доступно.
Если у вас есть действительно пример подобных тестов для других систем — покажите. Давайте обсудим результаты
Или вы об этой производительности?
возможно, вы будете удивлены, но 1С-Битрикс действительно за последние два года очень много сделал для повышения производительности и выяснения причин в случаях низкой производительности.

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

как-то так.

ссылку комментировать, если позволите, не буду.
Считаю, что довольный клиент не пойдет писать хорошие отзывы, а вот недовольный — будет кричать на каждом углу о том, что ему не понравилось. В результате негатива всегда больше, особенно в интернете.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
не, так дело не пойдет. вы меня втягиваете в дискуссию, из которой нет нормального выхода.

давайте разберемся в сути.

1. Есть мнение, что все скрипты и стили должны быть в малом количестве файлов.
2. Есть мнение, что это неважно

Насколько я понимаю, разработчики 1С-Битрикс в настоящее время придерживаются мнения №2, но, при этом, вполне себе толерантны к мнению №1 и желающие могут его реализовать.

Поэтому, какой бы вариант не выбрал заказчик, для него есть решение.

Также ниже см. вариант, который мы используем для разработки проектов на 1С-Битрикс (если вам интересно, конечно)
НЛО прилетело и опубликовало эту надпись здесь
У меня есть мнение что сайт должен приносить прибыль и стабильно работать. Это главный критерий успешного проекта.
Остальное зависит от многих факторов, возникавших при создании сайта. Ни один из этих факторов мы не знаем.
А есть другое мнение, что стили можно разделить на несколько и всегда подключать только общие стили, а на нужных страницах нужные файлы стилей подключать и нужные файлы скриптов.
С одной стороны — это множество мелких файлов, с другой — все это кешируется прекрасно браузером, при этом ничего лишнего не будет в кеше. (например, если пользователь никогда не заходил на страницу сложной фотогалереи, то к нему и не подгрузиться тяжелый скрипт данной галерии).

Да и вообще, сейчас, когда безлимитный скоростной интернет доступен массовой оптимизация размеров страниц отходит на второй план. Сейчас основной тупняк сайтов составляет не объем трафика, а нехватка ресурсов на просчет динамики в скриптах на php.
Хотел бы рассказать о концепции выделения стилей во много разных файлов, когда это требуется и когда нет. Мысли, которые здесь написаны, основаны на моем опыте разработки клиентских проектов.

Есть большая разница между тиражными решениями и решениями «под клиента». В первых вы должны обеспечить их работу несмотря ни на что, во вторых — вы можете оптимизироват код под конкретную задачу.

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

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

Как-то так.
НЛО прилетело и опубликовало эту надпись здесь
простите, на моем сайте — это на каком?
НЛО прилетело и опубликовало эту надпись здесь
Я не являюсь сотрудником компании 1С-Битрикс. Обо мне вы можете узнать, прочитав информацию в профиле пользователя
Нет-нет. Вы сейчас обьясняете почему битрикс не делает так как нужно, с точки зрения проблем битрикса.

Сайт должен не только зарабатывать деньги но быть качественным.

Я отхватил фана сотрудничая, как приглашённый конслуьтант, с компанией интегратором битрикса на проекте в котором каталог over 30k, с нестандарными полями в каждом товаре и системой нечёткого поиска. После того как клиент на пару с интегратором выел весь бюджет полтора раза (я говорю и о потери потенциальной прибыли из-за затягивания сроков), за половину стартового бюджета была нанята команда из 2-х человек, и в течении 4х дней в бой выкатили решение на Django, которое делало от 1 до 2 запросов в БД с одним уровнем JOIN'a на страницу. При этом админка была достаточна проста, кастомизируема и решала все бизнес-задачи – стандартная Django CRUD.

Итого: 4ре дня на код бэкэнда, половина бюджета и отличная скорость.
Речь идёт о посещаемости ~150 000 в день. Интегратор же предлагал покупать железо и лицензию Oracal. Что, по-мимо всего прочего, ещё и себестоимость поддержки сайта поднимало. Сейчас проект крутится в облаке на 4Гб оперативки.

На тему тиражных решений – любое решение должен делать профессионал. А драг'n'дропать блоки и получать странно выглядящий сайт на выходе, который ешё и с трудом заводится на минимальной конфигурации это извечно-русское желание сэкономить. Стратегия вашей компании этому потвортствует и плодит таких клиентов. Именно поэтому я и сказал что вы портите рынок web-dev'a
Oracle, разумеется, только что перебирал веер пластика Oracal, вот и опечатался.)
Вполне возможно, что в приведенном вами примере интеграторы не хватило опыта, знаний продукта и.т.д. Битрикс предлагает большой набор инструментов для быстрого создания качественных сайтов.

А «запороть» проект можно на любой CMS.

Тогда возникает вопрос какого чёрта они имеют сертификат партнёра Битрикса?

Битрикс отвратительно скейлится, для посещаемого проекта это постоянная заноза в заднице IT-отдела.

Кстати, зайдите на сайт евросети – там тоже битрикс. Вечером в течении пары месяцев можно было ждать по несколько секунд ответа сервера. Или там тоже опыта не хватило?
1. Для получения сертификата достаточно пройти онлайн тестирование, естественно это не гарантирует что прошедший его 100% специалист и что он сам его проходил.
Сейчас готовится «Чек лист качества» с помощью которого можно будет оценивать качество интеграции.

2. Битрикс хорошо масштабируется и имеет все необходимые для этого инструменты. В том числе и модуль «Веб кластер». Часто проблемой становится не Битрикс а непосредственно «продвинутые» IT отделы компаний. Для решения проблем производительности есть встроенные инструменты отладки и анализа настроек хостинга, а также VMBitrix и rpm пакет для оптимальной настройки сервера.

3. Что касается Евросети то у них были определенные проблемы, как в качестве внедрения так и с настройками «хостинга». Наиболее серьезные проблемы мы помогли им выявить.
1. Вы считаете такое положение вещей нормальным?

2. Да не надо настраивать ОС на сервере с помошью rpm'a. Так же, как не надо докупать железо, чтобы запустить сайт который в пике имеет 5 одновременных запросов. Надо предлагать рынку архитектурно верные решения для каждой ниши. Если говорить о highload то битрикс тут беспомощен, и проект на нём может развиваться только экстенсивно. Битрикс, для облегчения жизни конечным «руководителям», пошёл по тупиковой ветви развития. Для типового решения он слишком прожорлив, для Highload слишком монолитен и неоптимизирован. Я согласен из любой системы можно сделать конфетку на продакшн решении, если есть бюджет. Можно кластер построить или докупить железо – вопрос – зачем? Единственное за счёт чего битрикс вылез из линейки UMI-NetCat и прочие это имя 1С и и мощный маркетинг.

3. Интегратор скликал он-лайн тестирование? Право, странно читать. Я готов поверить что изначально система и БД были неотимизированы, но мы ведь скоро ядро будем так патчить, чтобы запустить прожорливую систему с нормальной скоростью.
1. Онлайн курсы и тестирование не панацея, но помогает как познакомиться с системой так и протестировать сотрудника. Иногда люди заканчивая очную форму обучения в университете имеют нулевые знания, согласитесь на фоне этого сложно требовать абсолютной истины от бесплатных онлайн курсов.

2. Производительность это не только количество запросов на страницу. Бывают случаи когда быстрее работает 20 запросов вместо 5.

Что же касается архитектуры то Битрикс предлагает хорошее решения для широкого спектра задач.

А правильная настройка сервера сыграет роль даже при раздаче статического сайта (разницу между скоростью отдачи статики nginx и apache думаю никто не будет отрицать)

3. Я не говорил, что они скликали тестирование, как собственно что ошибки делал партнер, мне это не известно. Единственное, что могу сказать, это что они не связаны с ядром Битрикса.
Все-таки, вы очень хорошо уходите от прямого вопроса, с которого начали.
Вопрос звучит так:
у 1С-Битрикс есть результаты независимого нагрузочного тестирования.
Есть ли подобные результаты у других систем?

Примеры нескольких проектов, которые работают не так, как должны были, конечно, важны, однако важны и примеры хорошо работающих проектов.
Можно сколько угодно скатываться в частности, ответа на вопрос о независимом тестировании не прибавится.
НЛО прилетело и опубликовало эту надпись здесь
Действительно хорошие сайты должны обслуживаться веб-студией. Потому что, как ни крути, но сотрудники клиента постоянно норовят скопипастить что-то из Word'а или забабахать ОГРОМНЫЙ ШРИФТ, выделив его красным, обосрав всю задумку дизайна.
Сайты, которые можно самостоятельно перекручивать в хвост и в гриву обычно как запревшие и выглядят.

P.S. Тем не менее, все фишки относительно возможности редактирования должны присутствовать, это делает дешевле техподдержку.

По поводу ежегодного обновления.
Рабочий сайт, который приносит деньги, обычно стоит раз в 10-20 дороже Битрикса. Например, визитка, меньше 100К у нормальной студии не стоит, а для нее подходит Битрикс Старт за 5 тыщ вполне. Раз в год 1200 р заплатить, если сайт не для галочки был сделан, ничего не стоит.

Если делается на Бизнесе за полтос, то надо отдавать себе отчет, что сайт должен быть таким, чтобы 10ка в год на обновление ядра не покосила весь бизнес, иначе это тупое разводилово от веб-студии и себя самих.
Тем более, что большинство функционала можно реализовать на старте. Мы в свое время реализовали простую социальную сеть на версии «старт». А часть сайтов вообще уложились в «первый сайт».
А если для бизнеса лицензия за 50 — это дорого, то нефиг выпендриваться и за эти же деньги заказывать крутой дизайн.

Причем, что мне нравиться у платных систем: если там что-то работает не так, как нужно и было бы логично или с ошибкой (а систем без ошибок не бывает. даже в космических ракетах в ПО иногда бывают ошибки) — за это отвечает битрикс.
А если система бесплатная — то ничего никто тебе не обязан. Можно долго лазить по форумам, интересоваться у других таких же людей и так ни к чему не придти.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий