Возможно ли создание по настоящему Открытой студии для совместной реализации веб-проектов?
Надеюсь для некоторых из вас, этот вопрос так же актуален, как и для меня.
Работал в закрытых студиях и сотрудничаю с ними сейчас в качестве фрилансера. При этом ни сотрудничество с «обычной» студией, ни самостоятельное исполнение заказов не считаю правильным…
Думая над способом организовать студию — именно студию, со свои стилем, с командной работой над проектом, с единой ответственностью перед клиентом, но при этом Отрытую: где за место коллектива выступает сообщество профессионалов (возможно и не большое), обязанности сведены к минимуму(участвуем только в том что интересно), а вся прибыль делится между участниками проекта — я подробно расписал свои мысли по функционированию открытого механизма распределения работ внутри студии с момента подачи заявки клиентом.
Итак, Открытый процесс работы над проектом. Какой он?
Для начала, определим…
Сообщество, о котором я говорю — открыто, каждый кто обладает нужным уровнем способностей и признает выработанные ценности может легко вступить в него и при желании выйти. На первом месте стоят личные интересы каждого, а не обязательства друг перед другом.
Сила сообщества, я считаю, не в широте(количестве участников), а в форме — качестве состава, способности мыслить в одном направлении. Это не сообщество масштаба фри-ланс.ру.
Сообщество студии я вижу не большим, чтобы не растерять определенный стиль. Человек 50, причем состав не постоянен (кто-то уходит, кто-то приходит).
Работа в студии начинается с заявки клиента. Вопросу «Как поступила заявка в студию?» предлагаю посветить отдельную тему.
Возможно, клиента привел один из участников сообщества, за что может расчитывать на благодарность (например, в праве выполнить часть работы по будущему проекту).
Возможно, наша выдуманная студия работает давно, достаточно известна и много заявок поступает напрямую через студийный сайт.
Сейчас же считаем, что заявка на реализацию проекта поступила и сообществу пора сплотиться для его исполнения.
Это может быть полностью сформированное ТЗ, бриф или просто сообщение о желании разработать нечто.
Все заявки видны участникам сообщества. Ответить могут лишь те из них кто обладает «умением» проект-менеджера. Ответ — это высказанная готовность работать по данной заявке. Ответ так же включает сумму, которую менеджер хочет получить за работу над заявкой или способ её расчета (например процент от бюджета проекта).
Решает сообщество! Задача будущего менеджера заявить о себе и показать всем, что он обладает нужными способностями. На основе представленой информации сообщество решит (например путем голосования) менеджер он или нет, а зоодно оценит уровень его умения (оценку предлагаю делать по нормированой шкале, например от 0 до 10).
— Если первый менеджер уже работает над двумя заявками, а второй лишь над одной, то выбирается второй. Это позволит распределять заказы равномерно по всему сообществу, при этом самые интересные заказы стремятся попасть к самым опытным менеджерам;
— При равном числе работ выбирается менеджер умение которого выше;
— При схожих умениях выбирается назвавший меньшую цену.
— Создать конкуренцию. На заявку могут ответить несколько менеджеров и при равных условиях победителем выйдет назвавший меньшую цену.
— Предложить менеджеру не гадание над цифрой, а выбор схемы оценки своей работы. Схем может быть несколько. Важно, что каждая из них утверждена сообществом и считается оптимальной (пример схемы — менеджер получает сумму равную 10% от бюджета проекта + составление ТЗ оплачивается по $15 за килознак). При этом можно позволить ему менять некоторые параметры (например, считает он данный проект сверх сложным — 10% смело меняет на 15%)
— Стоимость работы открыта. Эту сумму видят все участники проекта. Менеджер три раза подумает прежде чем завысить стоимость, потому что знает — любое его не верное дествие может попасть на арбитраж сообщества где его «карму» (умение) заметно опустят.
Менеджер выбран. Можно работать над заявкой.
Все понимают, что большинство заявок это просьба дать четкий ответ(указать цену и сроки) на плохо заданный вопрос (слишком сжатый бриф, не ясное ТЗ и т.п.).
Менеджер находится в очень не простой ситуации. С одной стороны он не может просить клиента оплатить разработку ТЗ, а затем ждать когда на него определяться исполнители и сформируется четкий бюджет(причем совсем не ясно, готов ли клиент его принять). С другой, назвав свою цену и сроки менеджер поставит сообщество в очень жесткие рамки, не всегда верные.
Как быть? Попробую снова совместить «несовместимое».
Для начала нужно как можно скорее обработать заявку. Менеджер задает клиенту уточняющие вопросы по заявке, ровно столько чтобы появилась возможность её примерной оценки исполнителями. Для примерной оценки ведь во многих случаях не требуется полноценое ТЗ (которое определенно нужно в процессе работы).
Менеджер разбивает обработанную заявку на части (например дизайн-верстка-программирование). И выносит их на оценку сообществу. Каждый в праве как ответить так и промолчать, при этом на оценщиков накладывается ряд обязательств и привилегий:
— Оценка заявки происходит в срок не более 12 часов с момента её публикации менеджером;
— Работа по заявке распределяется в первую очередь между теми исполнителями, которые участвовали в её оценке;
— Исполнитель не может отказаться от работы по заявке которую оценивал, если ни один исполнитель не выскажет желание по ней работать за указанную цену (в случае отказа он получит "-" в карму от сообщетсва, участвовать в друих проектах ему станет сложнее).
Пункты которые останутся без оценки менеджер оценивает самостоятельно исходя из свои соображений.
Теперь у менеджера есть все необходимые цифры и к тому же они утверждены сообществом. Можно формировать бюджет. Только снова загвоздка, исполнители не хотят мыслят одинаково и цифры у них сильно разнятся. Как правильно поступить?
Думаю стоит отдать этот вопрос на рассмотрение менеджеру. Он как как никто другой знает что хочет клиент, на какие суммы согласен. В однон случае он выберет наиболее дешевый вариант(клиенту важно выполнение задачи, но в деньгах он сильно поджат) в другом, наоборот поднимет планку до самого верха (клиент ценит качество и готов за это платить), в третьем — предложит клиенту выбрать бюджет самостоятельно (при этом клиент понимает, что бы он не выбрал — задача будет выполнена полностью и в срок, он лишь задает нужное ему качество исполнения).
Бюджет утвержден. Клиент полностью доверился студии и сделал свой первый взнос. Можно приступать к составлению ТЗ.
В ходе осмысления проекта пишется ТЗ из которого в свою очередь формируются задачи.
Задача должна быть не просто понятной и не только однозначно описывать предмет исключая двоякое понимание и скрытые места, ещё она должна представлять из себя нечто завершенное. В идеале исполнитель должен вникнуть лишь в саму задачу и не думать частью какого проекта она является. При этом собранные во едино решения этих задач представляют из себя целостный органичный объект.
Чем больше таких задач сможет выделить менеджер из ТЗ, тем выше его мастерство.
Задачи публикуются в сообществе и видны всем участникам. При публикации менеджер указывает какие категории участников могут ответить на задачу (например на задачу " собрать интерфейс на ExtGWT" могут ответить только программисты и только знакомые с ExtGWT).Так же менеджер указывает предельную стоимость задачи, выше которой происходит выход за рамки утвержденного бюджета. Ответивший на задачу считается исполнителем. При ответе исполнитель указывает стоимость своей работы.
Задачи имеют много общего с заявками. Можно сказать, что задача — это заявка сообщества для себя. Уровень знаний, выбор одного из нескольких исполнителей ответивших на задачу — эти вопросы можно решать аналогично заявкам у менеджеров.
Исполнители выбраны. Теперь их можно назвать проектной группой. Это уже не сообщетсво, а скорее коллектив, где успех проекта находится в руках каждого. При этом обособленость задач не исключает, что группе прийдется часто обмениваться результатами свей работы и плотно взаимодействовать.
Например в проекте участвуют два программиста, оба работают над некими функциональными модулями, причем модули логически завершенные и взаимодействуют через API. Казалось бы полная изоляция. Но при этом они имеют общий код проекта, могут наблюдать все в сборе, видят что сделано хорошо в работе другого, а что «я бы сделал лучше».
Ещё интересный момент — группы не будут «срастаться». Каждый раз нельзя с уверенностью сказать кто именно войдет в состав проектной группы и каждый раз можно наблюдать различные удивительные сплетения мыслей и реализаций.
Происходит обмен опытом. И это прекрасно.
Работа идет. Ждем её завершения.
Каким может быть финал? Уверен, что только положительным!
Если кто-то из исполнителей не справляется с задачей, это не причина валить проект. Сообщество гораздо шире коллектива. Замену нерадивому можно найти быстрее. Группы динамично меняются, личные связи не так сильны. Проблемы становиться проще решать в момент их зарождения, а не когда уже все упало. Маральные обязательства перед «коллегой» сведены к минимуму, можно смело просить его уйти, если тот стопорит работу -закинув вопрос менеджеру проекта или на рассмотрение всего сообщества.
Работа завершена! Пришло время собирать камни, а заодно дать оценку друг другу.
Проект менеджер пишет рецензию на каждого исполнителя, исполнители оценивают работу менеджера и свою лично, указывая сильные места в реализации задач. Общая рецензия и весь проект, в свою очередь, идут на суд сообщества, которое корректирует «карму» каждого из участников проекта.
Уходит время работы и приходит время творчеству. Когда интерес преобладает над знанием, а чувства шепчут — успех обязательно прийдет.
Все из нас имеют что-то скрытое. Даже то что мы хорошо умеем, в чем нас заслужено считаю «профи», когда-то было не доступно окружающим. Чтобы это извлечь потребовалось набить много шишек, как себе так и «коллегам», путем обмана вырывая у них из рук интересную работу, понимая что сделаешь её хуже чем сделали бы они. Или сознательно участвуя в «полном разврате», в работе за которую никто не хочет браться, от которой тошнит, лишь для того чтобы извлеч оттуда крупицу опыта и получить ещё один драгоценный отзыв в профиль.
Что будет, если сообщество лишь эксплуотирует умение мастеров, а отбросы (не интересную работу) сливает мало опытным участникам?
Во первых, мы станем заложниками своих же умений. Например, программист набивший хорошо руку на сборке сайтов в неткате, будет вынужден их собирать дальше. Даже когда ему эта работа приелась, хочется осваивать другие технологии — все его знают как сборщика сайтов в неткате и насколько ему просто взять хороший заказ по неткату, настолько же тяжело начать работу над чем-то иным.
Во вторых, отличный дизайнер, известный сообществу как не плохой верстальщик, который ещё не завоевал доверия но уже чему-то научился, скорее всего уйдет и долгое время проработает там где ему дадут «раскрыться».
Как поступить? Предлагаю ввести систему «свободных умений».
Это умение которое может быть чем угодно. Считаем, что каждый участник им обладает (в большей или в меньшей степени). Свободное умение можно использовать в ответах на задачи (или заявки) — при ответе просто считается, например, что свободное умение = опыту работы с фреймворком Symfony, и ответ участника рассматривается на равне с другими. Так же вводим ряд правил:
— Чем выше «карма» участника, чем больше он принес пользы сообщетсву, тем выше уровень его свободного умения;
— При ответе на задачу участник со свободным умением страхуется опытным исполнителем;
— Если задача выполнена хорошо — уровень свободного умения увеличивается + участнику приписывается умение в котором он выступал. Если плохо — то наоборот, следующий раз ему станет сложнее выступить в несвойственной ему работе.
Здоровое сообщество не относиться к себе потребительски! А помогает раскрытию потенциала каждого участника.
Чем хорошо сообщество? Способностью давать объективную оценку конфликтам между людьми, выступать арбитром!
Этим не может похвастаться ни одна «закрытая» студия. Её решение всегда субъективно по определению.
Решает ли конфликт опытный ПМ, или решают они в паре с руководством студии — решение всегда базируется на их субъективном восприятии картины, они (почти) всегда заинтересованны, очень сложно абстрагироваться от происходящих событий, каждое решение это результат лобирования чьих либо интересов.
Поэтому я до сих пор не могу позволить себе открытое участие в совместных проектах со студиями. Лобированию в отношения я предпочитаю баланс сил. Я всегда прошу авансы, а контроль над результатом отдаю только при наличии полной оплаты. Такая расстановка сил позволяет мне быть свободным от внутристудийных отношений. Не важно что думает дизайнер о верстальщике, а ПМ о всех вместе взятых. Меня это не касается. Тоже справидливо и по отношении студии ко мне. Мы можем открыто высказывать друг другу все что хотим, и это почти не отразиться на совместной работе, потому-что связаны мне не личными отношениями, а деньгами, потраченным временем и обязательством перед заказчиком.
Другая сторона медали — сокрытие результата вызывает много технических проблем, особено когда над проектом работает много лиц. Иногда получается наладить взаимодействия через API держа все свое у себя, иногда можно открыть часть кода при этом не теряя контроль над результатом, иногда приходится контроль отдать и побыть в не комфортных условия лобирования.
Что даст мне сообщетсво? Оно даст мне стать открытым и снять с себя лишний груз по контролю результата!
В открытой студии я готов не брать авансы и не скрывать код проекта над которым работаю — в той же мере в которой готов к работе через «Сделку без риска» на фриланс-ру. Потому-что знаю — деньги проекта не находится в руках заинтересованного человека с которым может возникнуть(а может и нет) конфликт, и любой конфликт может быть решен сообществом, которому я доверяю.
PS: Для тех кому близки идеи открытой студии создана группа — http://groups.google.ru/group/semaco
Предлагаю в ней сплотиться, найти совместно ответы на вопросы и попробовать воплотить наши мысли в жизнь :)
Надеюсь для некоторых из вас, этот вопрос так же актуален, как и для меня.
Работал в закрытых студиях и сотрудничаю с ними сейчас в качестве фрилансера. При этом ни сотрудничество с «обычной» студией, ни самостоятельное исполнение заказов не считаю правильным…
Думая над способом организовать студию — именно студию, со свои стилем, с командной работой над проектом, с единой ответственностью перед клиентом, но при этом Отрытую: где за место коллектива выступает сообщество профессионалов (возможно и не большое), обязанности сведены к минимуму(участвуем только в том что интересно), а вся прибыль делится между участниками проекта — я подробно расписал свои мысли по функционированию открытого механизма распределения работ внутри студии с момента подачи заявки клиентом.
Итак, Открытый процесс работы над проектом. Какой он?
Для начала, определим…
Сообщество, о котором я говорю — открыто, каждый кто обладает нужным уровнем способностей и признает выработанные ценности может легко вступить в него и при желании выйти. На первом месте стоят личные интересы каждого, а не обязательства друг перед другом.
Сила сообщества, я считаю, не в широте(количестве участников), а в форме — качестве состава, способности мыслить в одном направлении. Это не сообщество масштаба фри-ланс.ру.
Сообщество студии я вижу не большим, чтобы не растерять определенный стиль. Человек 50, причем состав не постоянен (кто-то уходит, кто-то приходит).
Работа в студии начинается с заявки клиента. Вопросу «Как поступила заявка в студию?» предлагаю посветить отдельную тему.
Возможно, клиента привел один из участников сообщества, за что может расчитывать на благодарность (например, в праве выполнить часть работы по будущему проекту).
Возможно, наша выдуманная студия работает давно, достаточно известна и много заявок поступает напрямую через студийный сайт.
Сейчас же считаем, что заявка на реализацию проекта поступила и сообществу пора сплотиться для его исполнения.
1. Начало процесса — заявка от клиента.
Это может быть полностью сформированное ТЗ, бриф или просто сообщение о желании разработать нечто.
Все заявки видны участникам сообщества. Ответить могут лишь те из них кто обладает «умением» проект-менеджера. Ответ — это высказанная готовность работать по данной заявке. Ответ так же включает сумму, которую менеджер хочет получить за работу над заявкой или способ её расчета (например процент от бюджета проекта).
Кто решает кому отвечать на заявки, а кому нет?
Решает сообщество! Задача будущего менеджера заявить о себе и показать всем, что он обладает нужными способностями. На основе представленой информации сообщество решит (например путем голосования) менеджер он или нет, а зоодно оценит уровень его умения (оценку предлагаю делать по нормированой шкале, например от 0 до 10).
Как поступить, если на одну заявку ответило два менеджера?
— Если первый менеджер уже работает над двумя заявками, а второй лишь над одной, то выбирается второй. Это позволит распределять заказы равномерно по всему сообществу, при этом самые интересные заказы стремятся попасть к самым опытным менеджерам;
— При равном числе работ выбирается менеджер умение которого выше;
— При схожих умениях выбирается назвавший меньшую цену.
Как бороться с жадностью менеджера? Как помочь ему объективно оценить свою работу?
— Создать конкуренцию. На заявку могут ответить несколько менеджеров и при равных условиях победителем выйдет назвавший меньшую цену.
— Предложить менеджеру не гадание над цифрой, а выбор схемы оценки своей работы. Схем может быть несколько. Важно, что каждая из них утверждена сообществом и считается оптимальной (пример схемы — менеджер получает сумму равную 10% от бюджета проекта + составление ТЗ оплачивается по $15 за килознак). При этом можно позволить ему менять некоторые параметры (например, считает он данный проект сверх сложным — 10% смело меняет на 15%)
— Стоимость работы открыта. Эту сумму видят все участники проекта. Менеджер три раза подумает прежде чем завысить стоимость, потому что знает — любое его не верное дествие может попасть на арбитраж сообщества где его «карму» (умение) заметно опустят.
Менеджер выбран. Можно работать над заявкой.
2. Оценка заявки.
Все понимают, что большинство заявок это просьба дать четкий ответ(указать цену и сроки) на плохо заданный вопрос (слишком сжатый бриф, не ясное ТЗ и т.п.).
Менеджер находится в очень не простой ситуации. С одной стороны он не может просить клиента оплатить разработку ТЗ, а затем ждать когда на него определяться исполнители и сформируется четкий бюджет(причем совсем не ясно, готов ли клиент его принять). С другой, назвав свою цену и сроки менеджер поставит сообщество в очень жесткие рамки, не всегда верные.
Как быть? Попробую снова совместить «несовместимое».
Для начала нужно как можно скорее обработать заявку. Менеджер задает клиенту уточняющие вопросы по заявке, ровно столько чтобы появилась возможность её примерной оценки исполнителями. Для примерной оценки ведь во многих случаях не требуется полноценое ТЗ (которое определенно нужно в процессе работы).
Менеджер разбивает обработанную заявку на части (например дизайн-верстка-программирование). И выносит их на оценку сообществу. Каждый в праве как ответить так и промолчать, при этом на оценщиков накладывается ряд обязательств и привилегий:
— Оценка заявки происходит в срок не более 12 часов с момента её публикации менеджером;
— Работа по заявке распределяется в первую очередь между теми исполнителями, которые участвовали в её оценке;
— Исполнитель не может отказаться от работы по заявке которую оценивал, если ни один исполнитель не выскажет желание по ней работать за указанную цену (в случае отказа он получит "-" в карму от сообщетсва, участвовать в друих проектах ему станет сложнее).
Пункты которые останутся без оценки менеджер оценивает самостоятельно исходя из свои соображений.
Теперь у менеджера есть все необходимые цифры и к тому же они утверждены сообществом. Можно формировать бюджет. Только снова загвоздка, исполнители не хотят мыслят одинаково и цифры у них сильно разнятся. Как правильно поступить?
Думаю стоит отдать этот вопрос на рассмотрение менеджеру. Он как как никто другой знает что хочет клиент, на какие суммы согласен. В однон случае он выберет наиболее дешевый вариант(клиенту важно выполнение задачи, но в деньгах он сильно поджат) в другом, наоборот поднимет планку до самого верха (клиент ценит качество и готов за это платить), в третьем — предложит клиенту выбрать бюджет самостоятельно (при этом клиент понимает, что бы он не выбрал — задача будет выполнена полностью и в срок, он лишь задает нужное ему качество исполнения).
Бюджет утвержден. Клиент полностью доверился студии и сделал свой первый взнос. Можно приступать к составлению ТЗ.
3. Задачи, проектные группы и исполнители.
В ходе осмысления проекта пишется ТЗ из которого в свою очередь формируются задачи.
Задача должна быть не просто понятной и не только однозначно описывать предмет исключая двоякое понимание и скрытые места, ещё она должна представлять из себя нечто завершенное. В идеале исполнитель должен вникнуть лишь в саму задачу и не думать частью какого проекта она является. При этом собранные во едино решения этих задач представляют из себя целостный органичный объект.
Чем больше таких задач сможет выделить менеджер из ТЗ, тем выше его мастерство.
Задачи публикуются в сообществе и видны всем участникам. При публикации менеджер указывает какие категории участников могут ответить на задачу (например на задачу " собрать интерфейс на ExtGWT" могут ответить только программисты и только знакомые с ExtGWT).Так же менеджер указывает предельную стоимость задачи, выше которой происходит выход за рамки утвержденного бюджета. Ответивший на задачу считается исполнителем. При ответе исполнитель указывает стоимость своей работы.
Задачи имеют много общего с заявками. Можно сказать, что задача — это заявка сообщества для себя. Уровень знаний, выбор одного из нескольких исполнителей ответивших на задачу — эти вопросы можно решать аналогично заявкам у менеджеров.
Исполнители выбраны. Теперь их можно назвать проектной группой. Это уже не сообщетсво, а скорее коллектив, где успех проекта находится в руках каждого. При этом обособленость задач не исключает, что группе прийдется часто обмениваться результатами свей работы и плотно взаимодействовать.
Например в проекте участвуют два программиста, оба работают над некими функциональными модулями, причем модули логически завершенные и взаимодействуют через API. Казалось бы полная изоляция. Но при этом они имеют общий код проекта, могут наблюдать все в сборе, видят что сделано хорошо в работе другого, а что «я бы сделал лучше».
Ещё интересный момент — группы не будут «срастаться». Каждый раз нельзя с уверенностью сказать кто именно войдет в состав проектной группы и каждый раз можно наблюдать различные удивительные сплетения мыслей и реализаций.
Происходит обмен опытом. И это прекрасно.
Работа идет. Ждем её завершения.
4. Каждому по заслугам.
Каким может быть финал? Уверен, что только положительным!
Если кто-то из исполнителей не справляется с задачей, это не причина валить проект. Сообщество гораздо шире коллектива. Замену нерадивому можно найти быстрее. Группы динамично меняются, личные связи не так сильны. Проблемы становиться проще решать в момент их зарождения, а не когда уже все упало. Маральные обязательства перед «коллегой» сведены к минимуму, можно смело просить его уйти, если тот стопорит работу -закинув вопрос менеджеру проекта или на рассмотрение всего сообщества.
Работа завершена! Пришло время собирать камни, а заодно дать оценку друг другу.
Проект менеджер пишет рецензию на каждого исполнителя, исполнители оценивают работу менеджера и свою лично, указывая сильные места в реализации задач. Общая рецензия и весь проект, в свою очередь, идут на суд сообщества, которое корректирует «карму» каждого из участников проекта.
Уходит время работы и приходит время творчеству. Когда интерес преобладает над знанием, а чувства шепчут — успех обязательно прийдет.
5. Потенциал.
Все из нас имеют что-то скрытое. Даже то что мы хорошо умеем, в чем нас заслужено считаю «профи», когда-то было не доступно окружающим. Чтобы это извлечь потребовалось набить много шишек, как себе так и «коллегам», путем обмана вырывая у них из рук интересную работу, понимая что сделаешь её хуже чем сделали бы они. Или сознательно участвуя в «полном разврате», в работе за которую никто не хочет браться, от которой тошнит, лишь для того чтобы извлеч оттуда крупицу опыта и получить ещё один драгоценный отзыв в профиль.
Что будет, если сообщество лишь эксплуотирует умение мастеров, а отбросы (не интересную работу) сливает мало опытным участникам?
Во первых, мы станем заложниками своих же умений. Например, программист набивший хорошо руку на сборке сайтов в неткате, будет вынужден их собирать дальше. Даже когда ему эта работа приелась, хочется осваивать другие технологии — все его знают как сборщика сайтов в неткате и насколько ему просто взять хороший заказ по неткату, настолько же тяжело начать работу над чем-то иным.
Во вторых, отличный дизайнер, известный сообществу как не плохой верстальщик, который ещё не завоевал доверия но уже чему-то научился, скорее всего уйдет и долгое время проработает там где ему дадут «раскрыться».
Как поступить? Предлагаю ввести систему «свободных умений».
Это умение которое может быть чем угодно. Считаем, что каждый участник им обладает (в большей или в меньшей степени). Свободное умение можно использовать в ответах на задачи (или заявки) — при ответе просто считается, например, что свободное умение = опыту работы с фреймворком Symfony, и ответ участника рассматривается на равне с другими. Так же вводим ряд правил:
— Чем выше «карма» участника, чем больше он принес пользы сообщетсву, тем выше уровень его свободного умения;
— При ответе на задачу участник со свободным умением страхуется опытным исполнителем;
— Если задача выполнена хорошо — уровень свободного умения увеличивается + участнику приписывается умение в котором он выступал. Если плохо — то наоборот, следующий раз ему станет сложнее выступить в несвойственной ему работе.
Здоровое сообщество не относиться к себе потребительски! А помогает раскрытию потенциала каждого участника.
6. Арбитраж.
Чем хорошо сообщество? Способностью давать объективную оценку конфликтам между людьми, выступать арбитром!
Этим не может похвастаться ни одна «закрытая» студия. Её решение всегда субъективно по определению.
Решает ли конфликт опытный ПМ, или решают они в паре с руководством студии — решение всегда базируется на их субъективном восприятии картины, они (почти) всегда заинтересованны, очень сложно абстрагироваться от происходящих событий, каждое решение это результат лобирования чьих либо интересов.
Поэтому я до сих пор не могу позволить себе открытое участие в совместных проектах со студиями. Лобированию в отношения я предпочитаю баланс сил. Я всегда прошу авансы, а контроль над результатом отдаю только при наличии полной оплаты. Такая расстановка сил позволяет мне быть свободным от внутристудийных отношений. Не важно что думает дизайнер о верстальщике, а ПМ о всех вместе взятых. Меня это не касается. Тоже справидливо и по отношении студии ко мне. Мы можем открыто высказывать друг другу все что хотим, и это почти не отразиться на совместной работе, потому-что связаны мне не личными отношениями, а деньгами, потраченным временем и обязательством перед заказчиком.
Другая сторона медали — сокрытие результата вызывает много технических проблем, особено когда над проектом работает много лиц. Иногда получается наладить взаимодействия через API держа все свое у себя, иногда можно открыть часть кода при этом не теряя контроль над результатом, иногда приходится контроль отдать и побыть в не комфортных условия лобирования.
Что даст мне сообщетсво? Оно даст мне стать открытым и снять с себя лишний груз по контролю результата!
В открытой студии я готов не брать авансы и не скрывать код проекта над которым работаю — в той же мере в которой готов к работе через «Сделку без риска» на фриланс-ру. Потому-что знаю — деньги проекта не находится в руках заинтересованного человека с которым может возникнуть(а может и нет) конфликт, и любой конфликт может быть решен сообществом, которому я доверяю.
PS: Для тех кому близки идеи открытой студии создана группа — http://groups.google.ru/group/semaco
Предлагаю в ней сплотиться, найти совместно ответы на вопросы и попробовать воплотить наши мысли в жизнь :)