Комментарии 39
не соглашусь с мнением:
«теперь они [программисты] избавлены от необходимости развития студийной CMS, что их никогда особо не радовало»
как говорят, плох тот программист, который не хочет или не пытался написать собственную CMS. Мой опыт это подтверждает, ведь задача по написанию собственного продукта — гораздо интереснее для программиста, чем работа с чужим
«теперь они [программисты] избавлены от необходимости развития студийной CMS, что их никогда особо не радовало»
как говорят, плох тот программист, который не хочет или не пытался написать собственную CMS. Мой опыт это подтверждает, ведь задача по написанию собственного продукта — гораздо интереснее для программиста, чем работа с чужим
Спорный вопрос. Если продуктов данного типа огромное множество на любой вкус, цвет и под любую задачу, то к чему изобретать велосипед? Не лучше ли потратить силы на что-то принципиально новое и по настоящему полезное. Хотя опять же повторюсь — вопрос очень спорный.
Ага, и плох тот программист, который любит писать документацию и дизайнить интерфейсы ;-)
Собственную CMS написать — это одно дело, а вот описать (а главное и сделать интерфейс), как ей пользоваться, чтобы и другим людям стало понятно и приятно — дело совсем другое.
Естественно, творческий процесс написания CMS её идеолога может и радует, но вот требования, предъявляемые руководством (читай — рынком) к ней — совсем не радуют :-)
Собственную CMS написать — это одно дело, а вот описать (а главное и сделать интерфейс), как ей пользоваться, чтобы и другим людям стало понятно и приятно — дело совсем другое.
Естественно, творческий процесс написания CMS её идеолога может и радует, но вот требования, предъявляемые руководством (читай — рынком) к ней — совсем не радуют :-)
Иметь собственную CMS, конечно, хорошо. Только вот у заказчика могут возникнут проблемы, если они захотят от вас уйти и отдать сайт на поддержку другой компании. Либо не возьмутся, либо попросят много денег для поддержки неизвестной CMS.
Но если разрабатывать CMS на основе какого-либо известного фреймворка (типа Zend Framework), где вся внутренняя структура прозрачна для любого программиста, который хоть раз что-нибудь делал на этом фреймворке, то проблему дальнейшего сопровождения во многом можно считать решенной.
Далее, если у вас собственная CMS да на проверенном временем фреймворке, то можно не беспокоиться о безопасности сайта, т.к. современным хакерам зачастую просто лень искать дырки в неизвестных местах, гораздо приятнее поиметь сайт на известной CMS с помощью недавно опубликованных эксплойтов.
Далее, если у вас собственная CMS да на проверенном временем фреймворке, то можно не беспокоиться о безопасности сайта, т.к. современным хакерам зачастую просто лень искать дырки в неизвестных местах, гораздо приятнее поиметь сайт на известной CMS с помощью недавно опубликованных эксплойтов.
Таким образом привязываем клиента к себе )))
перед тем как начинать писать свою CMS стоит по изучать чужие.
Благо сейчас их много и совсем не обязательно становиться первооткрывателем.
Благо сейчас их много и совсем не обязательно становиться первооткрывателем.
С точки зрения бизнеса переход на коробку одназначно удобное решение.
Но однотипный подгон коробки, это все таки скучно
Но однотипный подгон коробки, это все таки скучно
отличный подход от компании, пожелавшей остаться неизвестной по сдаче проекта — с одной стороны юридически все шито-крыто, с другой стороны — это действительно подстегнет заказчика. Взял на заметку, спасибо.
Да, как правило коробочные CMS имеют хорошую документацию, как пользовательсвкую так и девелоперскую + поддержка пользователей от производителя CMS, куда если что, всегда можно отправить заказчика, не тратя время на его обучение. Тут главные момент если руководитель студии выбрал это подход, всеми силами помочь и поучаствовать чтобы он выбрал ту коробку которая больше всего нравится программистам в плане того как там все внутри сделано. Нашей конторе пришлось перебрать 3 CMS (сделав на каждой по паре проектов) пока мы выбрали подходящую для нас коробку, и приятную (расширяемую и не кривую) для программистов и с хорошим саппортом и документацией для пользователей.
А почему речь идет только в духе коробке vs своя разработка?
Чем Open Source системы управления хуже коробочных платных?
На мой взгляд одни плюсы: стоимость системы равна нулю, документация присутствует (не спорю все зависит от конкретной CMS и дружелюбности сообщества), при достаточной развитости сообщества количество проблем сводится к нулю, фактически.
Чем Open Source системы управления хуже коробочных платных?
На мой взгляд одни плюсы: стоимость системы равна нулю, документация присутствует (не спорю все зависит от конкретной CMS и дружелюбности сообщества), при достаточной развитости сообщества количество проблем сводится к нулю, фактически.
ну наверно потому, что ТС работает в компании по разработке платной CMS.
хотя мой личный опыт по работе с коробкой и саппортом, сугубо негативный
хотя мой личный опыт по работе с коробкой и саппортом, сугубо негативный
ну тут так уж ситуация сложилась — наш нынешний партнер стал таковым, перейдя от использования собственной CMS к коммерческой коробке. Т.е. задачи сравнивать разные варианты не было — делимся опытом, который реально есть. А своя vs платная коробка vs бесплатная CMS — это холивар для отдельной статьи :)
Как правило документация у коробок лучше. В опен сорс проектах в лучшем случае более менее документация для программистов, и совсем бедная для пользователей. Нашим клиентам к примеру еще очень важен официальный саппорт куда они могу написать, позвонить и где они точно решат свой вопрос если у них все полетело. Канечно важно еще сама CMS есть такие коробки шо вообще туши свет, не понятно как и почему их вообще покупают. Лично я был противник что моя контора стала перепродавать сторонний продукт, на что шеф мне заявил что у него нет денег чтобы оплатить труд своих программистов чтобы сделать такую же. Повезло хоть в том что я выбрал то что хочу, и как минимум расширять функционал в ней приятно :)
Мы тоже перешли на коробку, на друпал. Очень рад, что не покупаем каждую копию кривой зазенкоденой херни
По-моему, студия должна держать на вооружении как CMS, так и framework. В случае нестандартных проектов, CMS не только не помогает процессу разработки, но и мешает. А есть еще варианты 2 в 1 (framework > CMS):
Sapphire > SilverStripe
Codeigniter > Expression Engine 2.0
Sapphire > SilverStripe
Codeigniter > Expression Engine 2.0
если раньше «стандартный» корпоративный сайт создавался 5 дней
— Однако) 5*8=40 человекочасов программиста чтобы настроить корпоративку это очень много.
— Однако) 5*8=40 человекочасов программиста чтобы настроить корпоративку это очень много.
Если со специфическими фичами (они почти всегда есть), версткой и отладкой — может получиться и больше.
Да, много. Но потому я и взял в кавычки «стандартный». Нередко созидательной работы было на день-два, а остальное — пустая трата времени на доработки/переработки функционала готовых модулей, инициированная бурной фантазией менеджера проекта или заказчика. Об этом я и рассказываю во втором абзаце данного поста:
«Стандартные модули UMI.CMS задают понятные ограничения для менеджеров по продажам, но с другой стороны, сами клиенты лояльны к такому строго описанному функционалу — помогает маркетинговая политика «коробочников»»
«Стандартные модули UMI.CMS задают понятные ограничения для менеджеров по продажам, но с другой стороны, сами клиенты лояльны к такому строго описанному функционалу — помогает маркетинговая политика «коробочников»»
>> важно презентовать дизайн в первый раз лично
это полезно только тогда, когда сайт принимает человек ответственный за его утверждение…
если Вы делали сайты для крупных компаний с жесткой иерархической структурой, то дальше менеджера, ну на крайняк начальника отдела Вас не пустят просто… (ну если дизайнер не Тема Лебедев, а высшее руководство — друзья подрядчика)
а принимают зачастую дизайн директора департаментов / комм.директора… а иногда и у генерального все это утверждается…
при этом менеджер, которому Вы «презентуете» это вряд ли сможет как то повлиять на решение своего руководства…
это полезно только тогда, когда сайт принимает человек ответственный за его утверждение…
если Вы делали сайты для крупных компаний с жесткой иерархической структурой, то дальше менеджера, ну на крайняк начальника отдела Вас не пустят просто… (ну если дизайнер не Тема Лебедев, а высшее руководство — друзья подрядчика)
а принимают зачастую дизайн директора департаментов / комм.директора… а иногда и у генерального все это утверждается…
при этом менеджер, которому Вы «презентуете» это вряд ли сможет как то повлиять на решение своего руководства…
не могу согласиться на 100%. Да, полезность такой рекомендации очевидна, если дизайн сдается напрямую лицу, принимающему решение.
С другой стороны, даже если дизайн сдается менеджеру, который дальше несет его на утверждение, личная презентация имеет не меньший смысл. Потому что менеджер по сути вместо вас будет обосновывать этот дизайн ЛПР'у.
Задача менеджера, в хорошем случае, — принять проект у разработчика, сдать руководителю и получить премию. Чем быстрее он это сделает, тем лучше для него. А задача разработчика — дать ему необходимую аргументацию, которую он, может быть, сам не захочет или не сможет сделать в силу квалификации.
Поэтому полезность есть в любом случае.
С другой стороны, даже если дизайн сдается менеджеру, который дальше несет его на утверждение, личная презентация имеет не меньший смысл. Потому что менеджер по сути вместо вас будет обосновывать этот дизайн ЛПР'у.
Задача менеджера, в хорошем случае, — принять проект у разработчика, сдать руководителю и получить премию. Чем быстрее он это сделает, тем лучше для него. А задача разработчика — дать ему необходимую аргументацию, которую он, может быть, сам не захочет или не сможет сделать в силу квалификации.
Поэтому полезность есть в любом случае.
> Ни в коем случае нельзя отправлять первые варианты дизайна по e-mail. [...] Основной момент здесь в том, чтобы заказчику не пришлось составлять свое первое впечатление о дизайне самостоятельно. Оно должно быть составлено с помощью автора.
Да-да, и каждому посетителю сайта в дальнейшем тоже нужно лично объяснять, почему дизайн сделан так, а не иначе.
Писали бы уже честно: проще залечить заказчика, чем переделывать.
Да-да, и каждому посетителю сайта в дальнейшем тоже нужно лично объяснять, почему дизайн сделан так, а не иначе.
Писали бы уже честно: проще залечить заказчика, чем переделывать.
«Пожалуйста, обратите внимание на цвет звездочки для специальной акции. У нас есть несколько вариантов, без вашего участия мы не можем определиться, какой будет лучше.»
Что это за неродивая дизайн-студия, которая не может выбрать цвет для звездочки. Если студия не может определиться даже у себя внутри с чем-то — это кошмар.
Что это за неродивая дизайн-студия, которая не может выбрать цвет для звездочки. Если студия не может определиться даже у себя внутри с чем-то — это кошмар.
Ну на самом-то деле речь шла о таком участии заказчика в разработке, которое никак не повлияет на конечный результат, зато даст почувтствовать себя причастным к творческому процессу.
Потом заказчик расскажет своим друзьям как они вместе дизайн «рисовали», мол круто было, мужики!
Дальше объяснять?
Потом заказчик расскажет своим друзьям как они вместе дизайн «рисовали», мол круто было, мужики!
Дальше объяснять?
Я говорю о приведенном глупом примере, что якобы студия не может решиться на какой-то из вариантов. Это играет на имидже компании. Объясняйте, дальше.
Я и говорю, лечка и развод. Представьте, что было б, если б таким же макаром делались автомобили или мобильные телефоны. «посмотрите сюда, в какой цвет нам покрасить вот этот болтик?»
Овцу с коровой не сравнивайте…
А принцип один и тот же — разработчику (если он профессионал) виднее, какого цвета должен быть болтик, звёздочка или что там ещё. И ему не надо советоваться с клиентом (который 99% не профессионал). Рецепт в топике — просто попытка сыграть на пухнущем ЧСВ заказчика. При этом заказчик может не быть профессионалом именно в кодинге или вёрстке, но жизненная позиция (бизнес) обязывает разбираться в психологии и понять, когда исполнитель профессионал, а когда дилетант, пытающийся имитировать бурную деятельность.
1. Заказчику абсолютно всеравно на какой CMS написан его проект (коробочной или внутренней). Он оперирует другими критериями.
2. Некоторые СMS настолько сложны в кастомизации, что легче написать свою.
3. Коробочные CMS охватывают «общие принципы» (то есть большая, среднестатистическая функциональность — которая не всегда нужна)
4. У каждой студии должна быть своя CMS, на которой она будет писать узкоспециализированные проекты. Для текучки использовать какую-либо коробку.
2. Некоторые СMS настолько сложны в кастомизации, что легче написать свою.
3. Коробочные CMS охватывают «общие принципы» (то есть большая, среднестатистическая функциональность — которая не всегда нужна)
4. У каждой студии должна быть своя CMS, на которой она будет писать узкоспециализированные проекты. Для текучки использовать какую-либо коробку.
Спасибо за статьи!
>Основная задача разработчика – удержать заказчика и после сдачи проекта, предоставляя различные услуги по его дальнейшему сопровождению
Можно подробнее этот пункт? Мне совсем не понятно — зачем удерживать заказчика?
Может я что-то не так понимаю, но при условиях $10-15/час за доп. разработку получается совсем не выгодно делать доводку сайта — лучше за это же время разработать несколько сайтов с нуля — profit будет выше.
Может надо поднимать стоимость часа работ, но ориентируемся на средне рыночную, а она именно такая в нашем регионе.
>Основная задача разработчика – удержать заказчика и после сдачи проекта, предоставляя различные услуги по его дальнейшему сопровождению
Можно подробнее этот пункт? Мне совсем не понятно — зачем удерживать заказчика?
Может я что-то не так понимаю, но при условиях $10-15/час за доп. разработку получается совсем не выгодно делать доводку сайта — лучше за это же время разработать несколько сайтов с нуля — profit будет выше.
Может надо поднимать стоимость часа работ, но ориентируемся на средне рыночную, а она именно такая в нашем регионе.
Многие CMS не поддаются такой кастомизации, которая нужна для создания определенного проекта. А перелетать от проекта к проекту меняя при этом CMS — глупо, ИМХО. Каждый раз приходится разбираться с кодом.
Как по мне, так намного лучше написать со временем что-то свое, универсальное, и делая каждый новый проект добавлять в эту универсальную CMS что-то новое, делая ее еще более универсальнее на будущее и каждый раз работая чуть меньше.
Для примера, сейчас я продолжаю писать свою 3-ю CMS, которая как конструктор позволяет собрать многое, при этом не является фреймворком в прямом смысле слова и достаточно удобна, чтобы говорить о том, что даже люди, плохо разбирающиеся в компах, могут на ней работать.
Как по мне, так намного лучше написать со временем что-то свое, универсальное, и делая каждый новый проект добавлять в эту универсальную CMS что-то новое, делая ее еще более универсальнее на будущее и каждый раз работая чуть меньше.
Для примера, сейчас я продолжаю писать свою 3-ю CMS, которая как конструктор позволяет собрать многое, при этом не является фреймворком в прямом смысле слова и достаточно удобна, чтобы говорить о том, что даже люди, плохо разбирающиеся в компах, могут на ней работать.
Хм, а вы пробовали поддерживать доставшуюся коробочную систему (к примеру Drupal) от внезапно «скончавшегося» программиста, где процентов 30 модулей написаны просто от отвратительно, процентов 20 вообще надо заменять, а остальные стандартные не устраивают :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Жизненные советы от владельцев веб-студий: как повысить рентабельность и снизить риски. Часть 2