Getting Real

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

В хорошей компании

Используйте форум или чат, чтобы пользователи имели возможность помогать друг другу

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

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

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

Публикуйте ваши неудачи

Выпустите плохие новости и уберите их с дороги

Если что-либо пошло не так, расскажите людям. Даже если они не заметили.

Например, сайт Basecamp однажды не работал в течение нескольких часов среди ночи. 99% наших пользователей никогда бы об этом и не узнали, но мы все равно поместили сообщение о непредвиденном сбое в нашем блоге Everything Basecamp. Мы считаем, что наши пользователи заслуживают того, чтобы об этом знать.

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

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

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

Будьте оперативны, прямы и честны

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

— Грег Шервин(Greg Sherwin), Вице-президент по технологиям приложений (Vice President of Application Technology) компании CNET [52] , и Эмили Авила(Emily Avila), руководитель компании Calypso Communications [53] (из книги A Primer for Crisis PR [54] )

52

http://www.cnet.com/

53

http://www.calypsocom.com/

54

http://www.clickz.com/showPage.html?page=836871

После выпуска

Настройка через месяц

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

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

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

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

Продолжайте выпуск сообщений

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

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

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

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

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

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

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

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

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

Он живет

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

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

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

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

— Джина Трапани (Gina Trapani), веб-разработчик и редактор Lifehacker [55] , путеводитель по производительности и программному обеспечению

55

http://www.lifehacker.com/

Не бета, а лучше

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

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

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