24 жовтня 2009

Оригінал: Web App Trends: Users as Developers
Автор: Joshua Porter
Переклад: Максим Додчук

Існує така легенда про появу eBay: П'єр Омідьяр (Pierre Omidyar) заснував eBay для того, щоб його дружина могла продавати і купувати контейнери для цукерок PEZ, які вона колекціонувала. Цю історію переказували тисячі разів і багато людей думають, що сайт з'явився завдяки силі любові. Насправді, поява сайту не було викликано одним лише проявом почуттів: Омідьяр справив оцінку бізнес потенціалу сайту перед тим, як взятися до роботи.

Омідьяр насправді використовував свій сайт для поповнення колекції своєї дружини. Він одночасно був одним із перших користувачів і найпершим розробником eBay. Користувачем і розробником водночас – для багатьох це може звучати незвично. Ми сприймаємо ці дві ролі мало сумісні. Користувачі – це ті, хто користуються продуктом. Розробники – ті, хто створюють продукт.

Що виходить, коли одна людина одночасно грає обидві ролі? Що відбувається, коли користувач є розробником і навпаки? З цього може вийти потужна комбінація, можуть виникнути нові переваги, якими не володіють ті, хто розробляє продукти для інших, переваги, які вони не можуть повторити.

У мене відкрилися старі рани

Команда веб-розробників з компанії 37signals створила програму Basecamp, тому що у них була проблема з менеджментом проектів.

«Basecamp був створений для вирішення проблеми: нам, як студії дизайну, був потрібен простий спосіб спілкування про проекти з клієнтами. Ми почали створювати через екстранет сторінки, які оновлювали вручну. Змінювати HTML вручну кожного разу при оновленні проекту – не найприємніше заняття. Ті проектні сайти завжди виявлялися застиглими і застарілими. Зрештою, ми їх закинули. Але ситуація не влаштовувала нас, тому що нам все одно було потрібно засіб для організації спілкування з замовниками.»

«Ми почали з пошуку серед існуючих рішень. Але кожен з інструментів, які ми розглядали: або 1) не робив всього того, щоб було нам потрібно, або 2) були переповнені не потрібної нам додатковою функціональністю: створення рахунків оплати, жорсткий контроль доступу, діаграми та графіки ... Ми знали, що повинен бути кращий спосіб вирішення наших проблем, і вирішили самі розробити його.»

Рани є і в інших

Далі все відбувається за одним сценарієм: той, у кого занили рани раптом розуміє, що такі самі рани є і в інших людей. Майк МкДермент (Mike McDerment), один із засновників Freshbooks, веб програми для ведення бухгалтерії, так описує те, що відбувалося з ними:

«У січні 2003 ми заснували свою компанію, де займалися веб-дизайном і розробкою для різних замовників. А потім ми створили Freshbooks, спочатку для себе, тому що нашому бізнесу була необхідна ефективна система роботи з рахунками. Ми зібралися і з головою поринули в роботу.»

Їжте самі свій собачий корм

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

Христина Уодтке (Christina Wodtke), під час роботи над додатком PublicSquare, движком для веб-публікації, використовувала наступний підхід. Перед тим як випустити додаткову функціональність, вона проводила невелике тестування програми, запустивши свій відомий сайт, онлайн журнал Boxes and Arrows, на самій останній, бета версії движка. Таким чином вона вбила одним пострілом двох зайців: користувалася додатком сама і проводила тестування, збираючи відгуки про реальне використання від інших користувачів.

Вкладайте душу в роботу

Цей підхід, користувачі-в-ролі-розробників, може бути більш ефективніше інших підходів. Ден Цедерхольм (Dan Cederholm), один з творців соціальної мережі для любителів вина Corkd, так описує свою захопленість роботою:

«Існує велика різниця в твоїй роботі, коли ти продаєш свій час, працюючи на чужому проекті, і коли ти сам працюєш на себе. Коли працюєш на себе, то в тебе з'являється відчуття господаря і почуття причетності, втягнення в роботу. (Почуття господаря і почуття залученості можуть виникати і окремо один від один, але разом це просто гримуча суміш.) Коли ви наймаєте на проект фріланс розробників або дизайнерів, то вони не викладаються «на повну», частина їх уваги займають речі, відмінні від вашого проекту. Тому на виході ви часто отримуєте незграбні рішення, створені на швидку руку, а контракт вже закінчився, сайтом вже користуються. На Cork'd ми були в абсолютно іншій ситуації, коли ми випустили продукт, який вважали «готовим» майже з усіх боків, а потім продовжили працювати над його покращенням, спираючись на відгуки користувачів, з тією ж залученістю, з тою же увагою до деталей , як і при початковій стадії розробки.»

Новий підхід

На перший погляд, здатність спроби розробляти для самих себе значно підвищити вашу ефективність, може здатися, м'яко кажучи, дивною. Однак, починаючи з eBay, продовжуючи чотирма компаніям, згаданими в цій статті, безліччю інших, все більша кількість компаній вибирають саме таку модель розробки, і вона стає критичною частиною їхнього успіху. Достатньо порівняти два продукти: один створений користувачами, а інший – ні. Різниця буде очевидна. При такому підході проектувальники краще розуміють проблему, вони пропрацювали рішення для більшості зустрічаються труднощів, вони більше залучені до роботи, в кінці кінців.