Пользователи в роли разработчиков
Геннадий Драгун, Lead Information Architect EPAMПеревод статьи Joshua Porter, “Users as Developers”
Существует такая легенда о появлении eBay: Пьер Омидьяр основал eBay для того чтобы его жена могла продавать и покупать контейнеры для конфет PEZ, которые она коллекционировала. Эту историю пересказывали тысячи раз и многие люди думают, что сайт появился благодаря силе любви. На самом деле, появление сайта не было вызвано одним лишь проявлением чувств: Омидьяр произвёл оценку бизнес потенциала сайта перед тем, как взяться за работу.
Омидьяр на самом деле использовал свой сайт для пополнения коллекции своей жены. Он одновременно был одним из первых пользователей и самым первым разработчиком eBay. Пользователем и разработчиком одновременно - для многих это может звучать непривычно. Мы воспринимаем эти две роли мало соместимые. Пользователи – это те, кто пользуются продуктом. Разработчики – те, кто создает продукт.
Что получается, когда один человек одновременно играет обе роли? Что происходит, когда пользователь является разработчиком и наоборот? Из этого может получиться мощная комбинация, могут возникнуть новые преимущества, которыми не обладают те, кто разрабатывает продукты для других, преимущества, которые они не могут повторить.
…Просто у меня открылись старые раны
Команда веб разработчиков из компании 37signals создала приложение Basecamp, потому что у них была проблема с менеджментом проектов:
«Basecamp был создан для решения проблемы: нам, как студии дизайна, был нужен простой способ общения о проектах с клиентами. Мы начали создавать через экстранет страницы, которые обновляли вручную. Измененять HTML вручную каждый раз при обновлении проекта — не самое приятное занятие. Те проектные сайты всегда оказывались застывшими и устаревшими. В конечном счёте, мы их забросили. Но ситуация не устраивала нас, потому что нам все равно было нужно средство для организации общения с заказчиками.
Мы начали с поиска среди существующих решений. Но каждый из инструментов, которые мы рассматривали: или 1) не делал всего того, чтобы было нам нужно, или 2) были переполнены не нужной нам дополнительной функциональностью: создание счетов оплаты, жёсткий контроль доступа, диаграммы и графики… Мы знали, что должен быть лучший способ решения наших проблем, и решили сами разработать его.»
Раны есть и у других
Дальше все происходит по одному сценарию: тот, у кого заныли раны вдруг понимает, что точно такие же раны есть и у других людей. Майк МкДермент, один из основателей Freshbooks, веб приложения для ведения бухгалтерии, так описывает то, что происходило с ними:
«В январе 2003 мы основали свою компанию, где занимались веб дизайном и разработкой для различных заказчиков. А потом мы создали Freshbooks, изначально для себя, потому что нашему бизнесу была необходима эффективная система работы со счетами. Мы собрались и с головой окунулись в работу.»
Ешьте сами свой собачий корм
После осознания того, что проблема беспокоит не только вас одних, не следует сразу бросаться в разработку решения для всех сразу, решив, что вы-то уже знаете все о своей проблеме. Подождите, продолжайте разрабатывать для себя, сами попользуйтесь продуктом достаточно долго. Поиграйтесь с ним, покрутите его так и так, убедитесь, что вы предлагаете действительно необходимую функциональность, а не дополнительные плюшки.
Кристина Уодтке, автор книги « Информационная архитектура: чертежи для сайта », при работе над приложением PublicSquare, движком для веб публикации, использовала следующий подход. Перед тем как выпустить дополнительную функциональность, она проводила небольшое тестирование приложения, запустив свой известный сайт, онлайн журнал Boxes and Arrows, на самой последней, бета версии движка. Таким образом она одним выстрелом убила двух зайцев: пользовалась приложением сама и проводила тестирование, собирая отзывы о реальном использовании от других пользователей.
В работу вкладывайте душу
Этот подход, пользователи-в-роли-разработчиков, может быть более эффективнее других подходов. Ден Цедерхольм, один из создателей социальной сети для любителей вина Corkd, так описывает свою увлеченность работой:
«Существует большая разница в твоей работе, когда ты продаешь своё время, работая на чужом проекте, и когда ты сам работаешь на себя. Когда работаешь на себя, то у тебя появляется чувство хозяина и чувство причастности, вовлеченности в работу. (Чувство хозяина и чувство вовлеченности могут возникать и отдельно друг от друг, но вместе это просто гремучая смесь.) Когда вы нанимаете на проект фриланс разработчиков или дизайнеров, то они не выкладываются «на полную», часть их внимания занимают вещи, отличные от вашего проекта. Поэтому на выходе вы часто получаете неуклюжие решения, созданные на скорую руку, а контракт уже закончился, сайтом уже пользуются. На Cork’d мы были в абсолютно иной ситуации, когда мы выпустили продукт, который считали ‘готовым’ почти со всех сторон, а потом продолжили работать над его улучшением, опираясь на отзывы пользователей, с той же вовлеченностью, с тем же вниманием к деталям, как и при начальной разработке.»
Новый подход
На первый взгляд, способность попытки разрабатывать для самих себя значительно повысить вашу эффективность, может показаться, мягко говоря, странной. Однако, начиная с eBay, продолжая четырьмя компаниям, упомянутыми в этой статье, бесчисленным множеством других, всё большее количество компаний выбирают именно такую модель разработки, и она становится критической частью их успеха. Достаточно сравнить два продукта: один создан пользователями, а другой - нет. Разница будет очевидна. При таком подходе проектировщики лучше понимают проблему, они проработали решения для большинства встречающихся сложностей, они больше вовлечены в работу, в конце концов.
