[Январь]

В связи с ограниченным количеством людей готовых принять участие в разработке и поддержке проектов - считаю что:

1. Дизайн.
1.1. Работку дизайнеров следует организовать моноблоком. То есть ни один из дизайнеров не привязан ни к одному из конкретных проектов. О структуре (я надеюсь вы понимаете, что так или иначе, но на данном этапе развития КОБ от структурированных систем не уйти) моноблока дизайнеров.
1.2. Есть 1 управленец - его основная задача - контроль и распределения нагрузки среди дизайнеров. Он постоянно имеет связь с каждым из своих дизайнеров.
1.3. В период формирования блока - он (управленец) вырабатывает логику "важности" задания, отталкиваясь от которой впоследствии заказчики будут формулировать свои требования к нему.
1.4. Дизайнеры принимают задание к исполнению только от него (управленца).
1.5. Надо сказать - по хорошему в блоке пригодился бы консультант для оценки поступающих на вход запросов. Но я отталкиваюсь от "ограниченного" количества участников разработки.

И так - на вход к дизайнерам попадает запрос с просьбой выполнить тот или иной заказ. В запросе определена срочность. Управленец определяет так же сложность (баннер и видеоролик - не одно и то же). Отталкиваясь от этого - передает заказ на исполнение дизайнерам (либо одному дизайнеру). Возвращает результат работы заказчику - управленец. Он же предусматривает зону в которой будет вестись согласование и "отладка" материалов с заказчиком.

2. Группа контроля.
Скорее всего понадобится группа контроля - чьей основной задачей - будет проверка синхронизации информации на сайтах, проверка информации на соответствие КОБ, ведение статистики и т.д. Эта группа должна иметь прямую связь с каждой из групп разработки. Именно эта группа должна заниматься логикой концептуального дизайна, внедрением акций и своевременным оповещением о разработке новых материалов. Замечу - блок дизайнеров не должен работать отталкиваясь от требований участников этой группы. Это на первых порах научит их (контролеров) - четко формулировать задания, поможет понять в чем суть сопутствующих сложностей, какие оптимальные пути решения складывающихся ситуаций (если оные будут иметь место). Эта группа НЕ должна иметь связи с группой владельцев. "Чтобы сохранить информацию - ее не надо повторять".

3. Группа разработки. Минимум 2 человека.
3.1. Контент-менеджер - именно он должен считаться старшим в группе. Именно он получает техническое задание, следит за строгим соблюдением задания программистом. Тут дело в том - что программисты как правило имеют склонность сделать как проще. Если поищите - найдете множество открытых цмсок в сети, систем свободных для "вброса" шелов и т.д. Он же - ведет контент сайта. Он не принимает решений по модернизации сайта или по внедрению новых модулей.
3.2. Программист - обслуживает (да да, именно обслуживает) требования контент-менеджера. Модернизирует систему управления, разрабатывает сайт так как это определяет контент-менеджер (со ссылкой на группу контроля), за исключением случаев технического идиотизма запроса. В этом плане программист является техническим консультантом (и к его словам следует прислушиваться)...

...

Группа контроля должна разработать некий алгоритм взаимодействия для исполнения "задуманного". Вот мой пример:

Общая алгоритмика.

1. В группе контроля принимается решение о начале нового проекта.
2. Группа контроля определяет направленность проекта (об этом ниже).
3. От группы контроля к владельцам идет запрос на регистрацию хостинга. Группа владельцев вырабатывает "код" проекта (ниже).
4. Группа контроля в блок дизайнеров передает информацию о концепции запускаемого проекта, ПРИ ЭТОМ СРАЗУ (а не через неделю) обуславливая свое видение и свои пожелание. Сразу же обговаривается структура, логика разделов, цветовая схема и т.д.
5. После предоставления выполненного задания от группы дизайнеров - материалы либо утверждаются, либо возвращаются на доработку.
6. Группа контроля передает техническое задание и макеты в группу разработки которая закрепляется за проектом.
7. Группа владельцев передает правда доступа к ресурсу (ключ) программисту группы которая назначается на проект синхронизируя действия с группой контроля (ключ в группу контроля не попадает).
8. Менеджер группы разработки следит за точностью исполнения полученного задания.
9. Проверка, тестирование, публикация.

Что-то подобное должно быть для каждой группы.

Пояснение. Называйте группы как хотите - у нас они называются УМИР, РМА, УИТ и Дизайн-Студия. По функционалу:
УИТ - владельцы ресурсов.
РМА - группа контроля.
УМИР - программисты и маркетологи.
Дизайнеры - тоже люди...

Далее. Несколько аспектов:

1. Разрабатывать множество проектов одного содержания но разного дизайна - бестолкова. Есть смысл выделить общую линию (например КОБ), а далее от проекта к проекту менять осубою специфику, например один сайт КОБ + военная история, другой сайт КОБ + экономика, третий - КОБ + передовые теории и т.д. В таком случае эффективность перекрестной рекламы возрастет.
2. У вас этого нет (либо я не встречал) - собственной баннерной системы. А весчь полезная, на статичном сайте в первую очередь привлекает внимание - движущийся объект.
3. Не замечал у вас, хотя это довольно известный привем. Каждый угол - это стрелка (указатель). Дизайнер должен знать, что принято наиболее важную информацию размещать так, чтобы на нее указывало больше количество углов элементов расположенных на странице...

Это если в целом. На самом же деле следует все это разложить на частные моменты, внимательно рассмотреть, обдумать о описать в более полном виде (я старался указать лишь ключевые моменты)...

Итог. Минимальный размер группы = 3 человека (владелец может принять на себя функции любого участника разработки (но это не правильно)), лучше 4. Одна группа (я вас уверяю) сможет без помех вести 5-10 проектов, в зависимости от потока информации на проект и загрузки (жизненной) каждого из участников группы...

Так же как вариант - объединение групп в сообщество для подключения к сложным проектам и т.д.

Далее можно поговорить об азах сетевой рекламы, но наверное в следующий раз...