Я не говорю, что нельзя. Пожалуйста, делайте на друпале. Я говорю о тенденциях. Wordpress гораздо более дружественный и человечный по своей концепции для большинства пользователей. Я говорю в том числе и об офсайте.
Кроме того, четкая заточенность вордпресса для блогов, упрощает работу с ним и понимание. Это как tumblr - просто сервис для заметок, не более. Но, очень хороший сервис.
Роман, почему бы "мнооого денег" не отдать специалистам, вместо того чтобы разбираться самому? Вы специалист в электронной коммерции, а кто-то специалист в навигации и быстрых скриптах. Пусть каждый занимается своим делом.
Пути развития индустрии — обширная тема, но чтобы не уходить от темы обсуждения, скажу следующее: пока в разработке сайтов есть такая составляющая как дизайн, не приходится всерьез говорить о том, чтобы поставить разработку на поток. Дизайн корпоративного сайта - по определению штучный продукт. Потому что задачи у корпоративного сайта такие - выделиться среди конкурентов. И прибыль здесь именно в высокомаржинальности продукта, а не в объемах.
Невозможно создать индивидуальный дизайн, заложив возможность без ущерба менять местами блоки, добавлять новые и проч. Поэтому конструктор кубиков - лапша для не слишком посвященных в тему клиентов.
Как часто энтузиазм клиентов приводит к тому, что спустя полгода на сайт без слез не взглянешь. Не может вебмастер на стороне клиента заменить команду разработчиков, состоящую из "узких" профи.
Обилие типовых решений порождает желание выделиться. Отсюда происходит берет начало противоположный тренд - потребность в сложных, индивидуальных решениях. Я пишу, ориентируясь на них.
Друзья! Речь не идет о том что бы делать с нуля. Речь идет о функциональности "конструктора" для клиента. В среде клиентов живет миф о том, что сайт можно будет самим развивать без разработчиков. И этот миф активно поддерживается разработчиками.
зачем? чтобы программист вместо того, чтобы показать чистый
функционал копался со стилями?
Скорее, процесс разработки дизайна должен идти исходя из общей концепции и функциональности описанной в бэклоге (как уже писал zarincheg), но без жесткой привязки к спринтам по времени.
Момент запараллеливания, зависит от специфики проекта. Если в проекте довольно сложные интерфейсы, отображение которых требует отдельного программирования (AJAX-фичи и т.п.), то все необходимые для пилотного запуска интерфейсы вместе со всей дизайн-концепцией и логотипом должны быть готовы не перед последним спринтом, разумеется.
Разница в подходе. Дизайн - это всегда от общего к частному. Не случайно zarincheg упомянул про логотип. Без этой фитюлки, не имеющей никакого отношения к разработке модулей, невозможно определиться со стилевым решением сайта. А логотип в свою очередь определяется названием и общей концепцией проекта.
Параллелить и привязывать к рамкам спринта разработку логотипа и модуля пользователи бессмысленно.
Наверное из моего текста это не очевидно, но меня как раз интересовала проблема синхронизации процессов разработки дизайна и программной части. Ведь вопросы функциональности, рассматриваемые на ревью спринта имеют мало общего с разработкой логотипа.
Я лишь предположил. Более того, по сказанному, разумеется нельзя судить о компании в целом. Это лишь пример, который побудил меня вспомнить о рассматриваемом вопросе.
Вот кто-нибудь написал бы очерк из опыта планирования бюджета социальной сети с нуля. А то я слышу, что одноклассники зарабатывают по лимону зеленых в месяц и все еще в минусе... Никак не возьму в толк, что же съедает такие деньги? Неужто серверные мощности? Тогда хотелось поподробнее узнать об этом.
хм... строго говоря "гарантом" успеха всего проекта не является, конечно. Имеется ввиду, что без учета других факторов, именно присутствие решающего лица, сокращает время и возможное недопонимание.
Вообще нужно быть внимательнее :), спасибо за замечание!
что касается первичного разговора, то ТЗ в принципе относится к другому, более позднему этапу и как правило, обсуждается с другими людьми на стороне исполнителя.
Кроме того, четкая заточенность вордпресса для блогов, упрощает работу с ним и понимание. Это как tumblr - просто сервис для заметок, не более. Но, очень хороший сервис.
Для внешнего сайта - нецелесобразно абсолютно. Внешний сайт - это индивидуальное решение. Moss - типовое по сути.
Невозможно создать индивидуальный дизайн, заложив возможность без ущерба менять местами блоки, добавлять новые и проч. Поэтому конструктор кубиков - лапша для не слишком посвященных в тему клиентов.
функционал копался со стилями?
Скорее, процесс разработки дизайна должен идти исходя из общей концепции и функциональности описанной в бэклоге (как уже писал zarincheg), но без жесткой привязки к спринтам по времени.
Момент запараллеливания, зависит от специфики проекта. Если в проекте довольно сложные интерфейсы, отображение которых требует отдельного программирования (AJAX-фичи и т.п.), то все необходимые для пилотного запуска интерфейсы вместе со всей дизайн-концепцией и логотипом должны быть готовы не перед последним спринтом, разумеется.
Параллелить и привязывать к рамкам спринта разработку логотипа и модуля пользователи бессмысленно.
Для внимательных же клиентов, всегда есть возможность устранить все непрозрачности на этапе согласования ТЗ.
Вообще нужно быть внимательнее :), спасибо за замечание!