Відкритий процес роботи над проектом

Чи можливе створення по справжньому Відкритої студії для спільної реалізації веб-проектів?

Сподіваюся для деяких з вас, це питання так само актуальне, як і для мене.

Працював у закритих студіях і співпрацюю з ними зараз як фрілансер. При цьому ні співпраця зі «звичайною» студією, ні самостійне виконання замовлень не вважаю правильним...

Думаючи над способом організувати студію - саме студію, зі свої стилем, з командною роботою над проектом, з єдиною відповідальністю перед клієнтом, але при цьому Відриту: де за місце колективу виступає спільнота професіоналів (можливо і не велике), обов'язки зведені до мінімуму (беремо участь тільки в тому що цікаво), а весь прибуток ділиться між учасниками проекту - я детально розписав свої думки щодо функціонування відкритого механізму розподілу робіт всередині студії з моменту подачі заявки клієнтом.

Отже, Відкритий процес роботи над проектом. Який він?

Для початку, визначимо...

Спільнота, про яку я кажу - відкрито, кожен хто володіє потрібним рівнем здібностей і визнає вироблені цінності може легко вступити в нього і при бажанні вийти. На першому місці стоять особисті інтереси кожного, а не зобов'язання один перед одним.

Сила спільноти, я вважаю, не в широті (кількості учасників), а у формі - якості складу, здатності мислити в одному напрямку. Це не спільнота масштабу фри-ланс.ру.

Спільнота студії я бачу не великим, щоб не розгубити певний стиль. Чоловік 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

Пропоную в ній згуртуватися, знайти спільно відповіді на питання і спробувати втілити наші думки в життя:)