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