Проектный менеджмент - сложная и серьёзная наука, которой учат во всяких престижных бизнес-учебных заведениях и пишут умные книги. И в самом деле, вряд ли возможно "на коленке" написать ERP-систему, или собрать iPhone-6.

Другая крайность - попытка решить задачу "нахрапом", - "А чё там делать-то! раз, два и заработало!". Особенно велик соблазн такого подхода в сайтостроительстве, где любой чих тут же отображается в браузере, и создаёт иллюзию больших свершений малыми силами. К тому же любой web-мастер, имеет представление обо всех аспектах создания сайта, хотя бы понемногу, и ему кажется, что в принципе любое задание он сможет выполнить сам "вечером в выходные".

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

Приведу в пример себя.
Я архитектор. Хорошо представляю схему потоков данных, общее построение систем, и целостность информации в них. Знаю (на уровне подсознания) SQL и могу быстро и качественно составить и схему БД и архитектуру системы.
Владею php, что называется "без словаря". Но ООП на php, - уже хуже. Написание модулей и снипетов под Drupal 6 - "со словарем", а API D7 еще не изучал, но могу разобраться довольно быстро. Темизация - на уровне HTML со вставками переменных (верстка). CSS - код знаю, могу форматировать, позиционировать, но художественный результат предвидеть не могу (что будет красиво, а что нет). Макеты страниц - вообще не предлагать. JS - стараюсь избегать при программировании, так как опыта чуть-чуть, хотя основы языка знаю. Ну и так далее.

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

Но в жизни все менее драматично, и куда более целесообразнее использовать в каждой сфере своего специалиста, чем любой ценой все делать в одиночку. Такая "экономия" приводит к тому, что результат получается долгий и не очень качественный.
А значит, нужна координация нескольких специалистов, что и приводит к возникновению проекта.

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

В выполнении таких задач (минипроектов) очень даже можно использовать Сообщество, по следующим причинам:

• нет необходимости в подборе команды - специалисты есть под рукой
• не надо содержать "лишних" участников - команда собирается на время проекта и состоит из необходимых специалистов
• ресурсы Сообщества позволят создать среду разработки минимальными средствами
• придумайте сами :-)

Для серьёзного, крупного IT-проекта этого конечно недостаточно, но для минипроекта подобная модель очень эффективна.
Но сначала определим, а что же такое минипроект.

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

Предлагаю минипроектом считать проект, для которого:

• - Требуется не более одного исполнителя каждой специализации
• - Каждое задание исполнитель может выполнить не более чем за неделю
• - Длительность всего проекта не более месяца (не учитывая чисто механическую работу, например по внесению информации)

Если вспомнить азы проджект-менеджмента, то для реализации минипроекта могут понадобиться:

• - Заказчик
• - Руководитель
• - Аналитик
• - Архитектор
• - Друсерфер
• - Программист PHP
• - Программист JS
• - Программист SQL
• - Дизайнер
• - Верстальщик (темизатор)
• - Тестер
• - SEO - оптимизатор
• - Сисадмин

Давайте подробнее рассмотрим каждую роль в проекте.

Заказчик.
Это обязательная роль. С неё, собственно, и начинается проект.
Заказчик должен иметь намерение выполнить проект, и обеспечить мотивацию команды. Либо оплатить, либо убедить :-) . Предполагается, что проекты могут быть не только коммерческие, на заказ. Любой участник Сообщества может иметь мечту создать то-то или то-то, но одному не под силу. Он может "убедить" поучаствовать в проекте других участников, например, для портфолио, для опыта, для создания команды... Да мало ли!
Тут предлагаю сделать следующее: в качестве Заказчика может выступать только участник Сообщества. То есть, если мой друг Вася просит "сделать ему сайтик", то в качестве Заказчика выступает не Вася, а я, который этот заказ вношу. И оплату обеспечиваю тоже я.
В таком решении есть несколько плюсов. Во-первых, заказы не вносятся в систему "левыми" людьми. Во-вторых, за каждого физического заказчика отвечает кто-нибудь из Сообщества, который принял Кодекс. Этим уменьшается вероятность "кидалова".
В-третьих, участник сообщества всегда может объяснить, чего же на самом деле требуется, чего далеко не всегда можно добиться от людей, далеких от IT.
В обязанности Заказчика проекта входит также общение с физическим заказчиком. Таким образом, для внешнего потребителя, Сообщество персонифицируется.

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

• Определить состав работ, и этапы выполнения;
• Оценить длительность этапов и стоимость (если это коммерческий заказ);
• Согласовать с Заказчиком;
• Составить задания участникам команды (по крайней мере на первый этап);
• Собрать команду (выложить ТЗ с указанием компетенций);
• Определить сроки и график выполнения ТЗ;
• Контролировать исполнение;
• Передать Заказчику результат в согласованные сроки;
• Обеспечить награждение участников (оплата, отзывы, прочее, как было договорено);
• Закрыть проект.

На деле, как я подозреваю, часто Заказчик и Руководитель - это будет одно и то же лицо. Но не всегда. Например, если участник Сообщества просто дизайнер, но у него есть заказчик из внешнего мира, то он может заявить проект, с поиском Руководителя.

Теперь об исполнителях. Не обязательно в каждом проекте должны участвовать все сразу. Это зависит от задачи, и определяется Руководителем.
Опишем вкратце функционал каждого.

Аналитик - работает с предметной областью, и переводит "хотелки" заказчика на системный язык. Физические заказчики могут вообще не иметь представления о работе сайтов и информационных систем. Просто "хочу, чтоб это..., того..., Да, и еще зелёного побольше!". Такую задачу ставить разработчикам нельзя, и даже опасно.

Аналитик должен разобраться в том, что имеет ввиду заказчик, и в том, что же он на самом деле хочет.
Зачастую роль Аналитика выполняет Заказчик проекта, поскольку, раз он привел клиента, то он лучше всех должен представлять, что же ему нужно. Но это необязательно. Заказчик может отказаться быть аналитиком, и тогда Руководитель должен будет выбрать Аналитика из Сообщества.
Результат работы Аналитика - Техническое Задание на весь проект, которое должен будет принять заказчик.

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

Друсерфер - замечательная специальность! Изюминка Сообщества! В его обязанности входит отыскивать среди тьмы модулей и тем на Drupal.org те, которые выполняют требуемый функционал. Или обратная задача: а чтО умеют существующие модули?
Этот участник проекта получает задания в процессе работы Архитектора, может быть и Аналитика.
Результат работы - отчет о возможностях модулей, и предложения по их использованию в данном проекте.

Роли разнообразных программистов, дизайнеров и тестеров, я полагаю, в комментариях не нуждаются, - тут все ясно. Они получают ТЗ от Руководителя, и его исполняют в срок. Не обязательно на каждом проекте должно быть присутствие всех.

SEO - его работа не требует наличия архитектора, но требует работы аналитика. Но, как правило, в случае SEO-проекта, SEO-оптимизатор является также и Аналитиком..

Сисадмин - может потребоваться, когда заказ включает оптимизацию БД и серверов.

Как это видится.
Я вижу сервис минипроектов следующим образом:

1. Регистрация желающих из числа участников сообщества (обязательно) участвовать в минипроектах. При регистрации обязательно указать компетенции (можно несколько). Список компетенцией приведён выше.
2. Регистрация проектов.
   У кого есть проект, описывает суть задачи, и автоматически становится Заказчиком проекта. Он также может взять на себя роль Руководителя, или запросить Руководителя для проекта.
   Тогда все зарегистрированные в сервисе участники, которые указали компетенцию "Руководитель" получают уведомление.
3. Когда кто-либо, или сам Заказчик принимают роль Руководителя, проект считается начатым. Руководитель может заявить в проект различные роли с описание их задач, и соответствующие специалисты получат уведомления.
4. Руководитель контролирует выполнение задач, принимает результат и передаёт его Заказчику (то есть может быть и самому себе :-)), Заказчик обеспечивает выполнение договоренностей с исполнителями.

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

В качестве "пробного шара" можно заявить первый минипроект - "создание функционала Минипроектов на сайте петербургского Drupal сообщества drupalspb.org".
Если администрация сайта выступит Заказчиком, то я беру на себя обязанности Руководителя и Аналитика проекта.