Форум "Осознание" - Концепция Общественной Безопасности

Сразу несколько моментов.

1. Очерк - целевой. Если вам это не интересно или не подпадает под вашу деятельность, не читайте. Никаких щепетильных исторических реалей вы тут не встретите.
2. В очерке я указываю свое мнение - погрешность не исключена. Если вы можете конструктивно поправить - поправьте.

Поехали.

Задача - организовать разработку сайтов под эгидой КОБ для внедрения информации и развития информационного звена КПЕ.

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

1. Вопрос о владельцах. Необходимо определить состав группы которая будет нести ответственность за:
1.1. Доменные имена.
1.2. Зоны хостинга.
Примечание к п.1.
Если есть возможность оплатить выделенный сервер - это оптимальный вариант из сравнительно простых. Оптимальный - потому, что это обеспечит сравнительно быструю работу системы. Если такой возможности нет - не следует держать все сайты в пределах одного хостера. Таким образом в течении 2-3 месяцев можно будет без обращения внимания на рекламу - определить - кто предоставляет действительно хорошие услуги, а кто нет. Тут же надо отметить, что заказывать доменное имя у хостера никак нельзя, даже если реклама "хостинг + доменное имя бесплатно" - искушает. Связано это с тем - что хостер может отказаться предоставить информацию об аутентификации на http://nic.ru и потребовать продление делегирования доменов через свои структуру. Это может привести к потере доменного имени. В частности по такой схеме работает компания Агава, иначе работает - МастерХост...

2. Вопрос управляющей системы.
2.1. В сети можно найти все что угодно, в том числе и различные CMS. Вопрос в том - что лучше? А быть может в том - что подходит? Если попотеть - можно найти и поломанные Битриксы и Смарти и прочие. Тут следует спросить себя - а стоит ли начинать разработку на базе того, что может принести проблемы в будущем? Это больше вопрос о серьезности затеваемого проекта.
2.2. Если в перспективе намечается разработка не одного, а нескольких сайтов - то следует сразу определиться с тем, на основе какой CMS-ки все они будут разработаны - это важно - CMS-ка должна быть уникальна для всех ресурсов. С чем это связано? В первую очередь с тем, что работать с этой системой управления (контент-менеджеры) будут скорее всего не сами разработчики (программисты), а люди которые в программирования понимают не особо. Таким образом если разные сайты построены "экспериментальным" методом (хочу попробовать это - так возьму да и попробую) - контент-менеджера придется обучать работать с разными системами - а это вызовет следующие сложности. Дело в том, что существует множество подходов к разработке баз, а потому - различные CMS-ки реализуют различные логические схемы. Пример - если неандертальцу показать как забить гвоздь, а потом дать болт - он попробует его забить точно так же как умеет... И еще кое что. Если система управления будет единой - то все контент-менеджеры вместе и в отдельности - смогут управлять каждым из сайтов, что обеспечит их взаимозаменяемость на случай болезни, отпуска и похищения инопланетянами... Кроме того система управления должна быть максимально интуитивно-понятной (ясно почему)… В целом надо рассчитывать не на то – какая она «крутая» (система), модная или мне нравится, а на тех – кто будет с ней работать…
2.3. Если вопрос стоит о разработке зеркал лишь с измененными дизайнами – этот пункт не принципиален. Если вопрос стоит о разработки сайтов различной направленности – в том числе и для организации перекрестной рекламы, а равно собственной баннерной сети – следует учесть, что «расширяемость» системы управления подпадает под один из наиболее важных пунктов при ее выборе. Именно это (невозможность или отсутствие предусмотренной возможности расширения управляющей системы) – обычно вызывает наибольшие трудности связанные с доработкой или редизайном.

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

продолжение >

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

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 проектов, в зависимости от потока информации на проект и загрузки (жизненной) каждого из участников группы...

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

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