Немного позже расскажу об одном из подходов к проектированию информационных систем, который здорово вписывается в VF. На примере реальной системы, обещаю :)

Согласен. Мотивы могли быть разные. Нужна более подробная информация о деталях проведения этой встречи.

>> Один из предыдущих постов я посвятил этой модели, хотя её можно кратко описать фразой «обмен труда на знания/навыки».

Тоже интересный момент. Предположим, у меня будет некая команда, состоящая из "учеников". Я могу делегировать ряд задач, связанных с реализацией им, посвятить их в детали организации процесса разработки и т.д. Команда растет в профессиональном плане.

Риски "ученика" здесь стремятся к нулю.

С другой стороны я трачу свое время на то, чтобы команда выросла до определенного уровня и была действительно полезна. Если знакомы с моделью FSNP (Forming - Storming - Norming - Performing), то риски "мастера" заключаются в этапах Forming и Storming.

Проснется утром "ученик" Вася, выпьет пива и подумает: "А пошло оно все!", и пойдет погулять или вовсе оставит затею чему-нибудь научиться. Случится раз - стану меньше доверять команде, случится второй - лучше сделаю сам (быстрее и надежнее).

Я все это к тому, что ты собираешься привлечь в свой сервис не только "учеников", но и "гуру". И мотивацию нужно продумывать для всех.

Обучение, knowledge sharing, развитие навыков работы в команде - это конечно здорово. Именно так в свое время я начал расти в сторону software development. Но в твоей идее есть очень много "но".

Больше всего беспокоет словосочетание "формально-технически объединяло". Дело в том, что на данном этапе у "светлых голов" (давайте уже их называть менторами) нет никаких предпосылок участвовать в проекте, кроме, наверное, одной - развитие менторских навыков.

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

Чтобы обеспечить материальную составляющую, понадобится ввести членские взносы для "золотых рук". Т.о. может появиться "команда" (хотя на этом этапе это слишком громкое слово).

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

Теперь о "плюшках". Беспорядочные оценки - это плохо. В определенный момент целью разработчиков становится оценка, а не получение опыта и знаний, компетентность и т.д.

Хотелось бы узнать твое мнение на этот счет.

P.S. Конечно же предложения по этим замечаниям есть.

С этим не поспоришь. :)

Спасибо Майклу Тайсону (Michael Tyson) за великолепную тему для Wordpress.