Array Array - Getting Real

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

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

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

Выпустите обновление через 30 дней после выпуска

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

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

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

Покажите, что ваш продукт живет — продолжайте блог продукта после выпуска

Не переставайте писать в блог после выпуска продукта. Покажите, что ваш продукт живет, с помощью блога, который вы часто обновляете ( как минимум раз в неделю, а если можете — то и чаще).

Что туда можно включить:

* Частые вопросы

* Как работать с программой

* Советы и решения

* Новые функции, обновления, исправление ошибок

* Разговоры/пресса

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

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

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

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

Как редактор Lifehacker, я постоянно просматриваю блоги любимых приложений, таких как Google, Flickr, Yahoo, del.icio.us и 37signals. И я большей вероятностью буду упоминать их, чем те, которые высылают односторонние пресс-релизы из ниоткуда и не поддерживают общения со своими пользователями и поклонниками.

Не используйте «бета» в качестве козла отпущения

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

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

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

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

Это только я такой, или мы все находимся в бета-версии, все время?

Разделите ваши ошибки по приоритетам (и даже проигнорируйте некоторые из них)

Если вы нашли ошибку в вашем продукте — это не повод впадать в панику. Все программы содержат ошибки, это просто неоспоримый факт.

Не нужно сразу же исправлять каждую ошибку. Большинство ошибок надоедливы, но не смертельны. Те, которые надоедливы, могут быть отложены. Ошибки типа «что-то тут выглядит не так» и подобные можно без ущерба отложить на некоторое время. А уж если ошибка ломает вашу базу данных — тогда, конечно, она должна быть исправлена немедленно.

Определите приоритет каждой ошибки. Сколько пользователей от нее страдают? Насколько серьезна проблема? Заслуживает ли ошибка немедленного внимания, или может подождать? Что можно сделать прямо сейчас, чтобы помочь наибольшему количеству пользователей? Часто добавление новой функции может быть более важным, чем исправление существующей ошибки.