Очевидно, что продукт будет хорошо распространяться только тогда, когда он нужен пользователю. Причём степень этой самой нужности определяет только сам пользователь и никто другой.

Из этой простой и всем понятной истины вытекает, что для успешного проекта должно выполняться два условия:

· результат должен быть нужен пользователю;

· пользователь должен понимать, что результат ему действительно нужен.

Первое условие достаточно объективно и хорошо понятно людям с техническим мышлением. А поскольку именно такие люди чаще всего возглавляют открытые разработки, то его выполнение считается вполне достаточным для успеха.

Со вторым условием на практике всё обстоит значительно сложнее. Подход «от пользователя» более свойственен бизнесу, а технические специалисты относятся к разного рода «маркетингам» с известной долей ироничного скепсиса.

Тем не менее, второе условие так же важно, как и первое. Бессмысленно говорить о полезности продукта, если сам пользователь про это ничего не знает.

Изобретатель и консультант Майкл Дехаан, живущий в г. Кэри (Северная Калифорния) считает, что для успешного развития свободного продукта следует прежде всего стереть грань между бизнес-подходом и техническим мышлением. На сайте OpenSource.com он предлагает несколько приёмов, при помощи которых можно добиться положительного результата.

Он объясняет свою точку зрения тем, что успешный проект должен не столько разрабатывать некое оригинальное и интересное с точки зрения программистов решение, сколько создавать рыночный продукт, на который есть реальный спрос. Но при этом следует стремиться не продать что-то пользователю, а помочь ему решить какие-то его проблемы.

Это возможно только тогда, когда потенциальные пользователи максимально вовлечены в проект. В идеале именно они должны ставить задачу разработчикам. Для этого Дехаан предлагает следующее.

Ориентация на широкую аудиторию

Если разработчики хотят привлечь как можно больше пользователей, то их проект должен быть интересен как можно бо́льшему числу пользователей. На практике это простое правило выполнить очень непросто.

Любая конкретизация уменьшает потенциальную аудиторию. Никакое специализированное решение не может быть интересно всем.

С другой стороны, людей привлекает именно конкретика, а не общие слова. Если пользователь не увидит в продукте решения какой-либо собственной проблемы, то он моментально утратит к нему всякий интерес.

Таким образом, позиционирование продукта должно выходить за некоторые рамки, захватывая «смежные области». Но при этом необходимо следить за том, чтобы это расширение привлекло больше пользователей, чем отпугнуло.

Дехаан приводит простой пример. Если в разработке утилиты применяется язык Go, то её позиционирование как «приложение Go» сможет привлечь пользователей из сообщества Go, но уменьшит интерес к проекту со стороны поклонников десятков других языков программирования. В этом случае проект, скорее всего, будет в проигрыше.

Если же утилита предназначена для работы в облачном окружении, то упоминание облаков сможет заинтересовать всех, кто интересуется этим вопросом. Поскольку таких пользователей много, то проект окажется в выигрыше.

Следовательно, при позиционировании проекта следует расширять его узкие рамки в тех направлениях, которые привлекут больше пользователей. И, соответственно, не акцентировать внимание на некоторых его качествах, способных сузить потенциальную аудиторию продукта.

Простота и информативность

Дехаан рассказывает, что попадая на сайт обычного стартапа пользователь часто видит массу бессмысленных фраз, бессодержательных клипартов и т. п. Как правило, это вызывает у посетителя только ощущение напрасно потерянного времени.

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

Рассказывая о своём продукте, лучше придерживаться среднего между этими двумя подходами. Открытые продукты лучше всего распространяются, если потенциальный пользователь может быстро понять, что они собой представляют и для чего нужны.

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

Можно включить в описание скриншоты и диаграммы там, где это уместно. Можно использовать видеоматериалы, но их краткое содержание должно быть представлено в письменном виде для тех, у кого нет времени смотреть ролики.

При этом следует быть максимально честным. Если продукт заведомо не интересен какой-то группе пользователей, то лучше пусть они поймут это быстро, а не начнут через некоторое время везде писать о том, что их ввели в заблуждение.

Проекту нужны реально заинтересованные пользователи, а не число «лайков» в соцсетях для отчёта перед начальством. Более того, «качество» участников не менее важно, чем их количество.

Инвестиции в документацию

Заинтересовать потенциального пользователя — только часть задачи. К сожалению, нередки случаи, когда новый участник проекта потратит пару часов на установку и запуск приложения, ничего не поймёт и бросит эту задачу.

Дехаан считает инвестиции в документацию совершенно необходимыми и максимально приоритетными для каждого проекта. Для оценки её качества и полноты он предлагает применять правило обеденного часа — если этого времени достаточно, чтобы пользователь смог начать полноценно работать, то она составлена хорошо. Если нет, то её надо переделывать.

К тому же никогда не стоит недооценивать значение «вау-эффекта». Если у пользователя всё быстро заработало, то его энтузиазм значительно вырастает.

При подготовке документации следует учитывать, что с ней будут работать пользователи с различным уровнем технических знаний. В частности, если документация состоит исключительно из кода с комментариями, то развитие проекта будет крайне затруднено.

Дехаан ещё раз подчёркивает чрезвычайную важность документации. Этим делом нельзя заниматься наспех и между прочим.

Сбор новых идей

Даже заинтересованного пользователя надо постоянно удерживать. Лучший способ это сделать — организовать хорошую обратную связь.

Важно понимать, что в открытом проекте именно пользователь — наиболее заинтересованное лицо, поэтому общение с ним играет важную роль. Форма тут не имеет большого значения. Списки рассылки, IRC, разнообразные чаты... Чем больше коммуникационных систем, тем лучше. Встроенный инструментарий GitHub хорош только для программистов, не следует рассчитывать только на него.

Обратная сторона разнообразия — каждый способ связи требует постоянного внимания. «Беспризорный» канал принесёт больше вреда, чем пользы.

Но самое главное — пользователь должен видеть, что его идеи востребованы. Поэтому каждый такой случай должен стать известным, что также требует некоторых усилий.

Использование плагинов

Как правило, идей у пользователей достаточно много. Вряд ли все они должны быть воплощены в основном коде продукта. Чрезмерно «раздутая» программа — это тоже нехорошо.

Поэтому архитектура приложения с самого начала должна быть модульной и предполагать возможность использования плагинов для расширения его функциональности. Если целесообразность реализации какой-либо идеи в основном коде вызывает большие споры, то она реализуется в плагине — такой подход устроит всех.

Применение плагинов позволит сохранить тех пользователей, которым недостаточно основной функциональности продукта. А их может быть немало.

Сохранение баланса

Сообщество пользователей — безусловно полезная для проекта структура. Но не стоит думать, что на него можно возложить функции основного генератора идей.

Напротив, чем выше активность сообщества, тем бо́льшая изобретательность требуется от лидеров проекта. Именно они должны разделять вопросы на краткосрочные и долгосрочные, формировать тактику и стратегию развития продукта.

Лидеры должны с самого начала соблюдать разумный баланс между обслуживанием сообщества и самостоятельной работой. Если в течении какого-то длительного промежутка времени лидер не предлагает своих личных идей, то его авторитет упадёт настолько сильно, что перспективы дальнейшего руководства станут весьма туманными.