Чтение онлайн

И в то же время запрос №1 наших пользователей состоит в том, чтобы мы сохранили программу Basecamp простой.

Вот еще пример: несмотря на жалобы, мы решили не поддерживать IE5 в наших продуктах. Это составляло 7% нашего рынка. Тем не менее мы решили, что более важно позаботиться об остальных 93%. Исправление ошибок и тестирование под IE5 просто не стоило потраченного времени. Уж лучше мы будем совершенствовать наш продукт для других пользователей.

Как компания-разработчик программного обеспечения, вы должны вести себя как фильтр. Не все, что кто-либо предлагает, является правильным ответом. Мы рассматриваем все запросы, но

потребитель не всегда прав. Бывают времена, когда вам просто приходится кого-то разозлить. C’est la vie.

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

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

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

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

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

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

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

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

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

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

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

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

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

компанию от попадания в ослабленное, оборонительное положение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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