Getting Real
Шрифт:
И в то же время запрос №1 наших пользователей состоит в том, чтобы мы сохранили программу Basecamp простой.
Вот еще пример: несмотря на жалобы, мы решили не поддерживать IE5 в наших продуктах. Это составляло 7% нашего рынка. Тем не менее мы решили, что более важно позаботиться об остальных 93%. Исправление ошибок и тестирование под IE5 просто не стоило потраченного времени. Уж лучше мы будем совершенствовать наш продукт для других пользователей.
Как компания-разработчик программного обеспечения, вы должны вести себя как фильтр. Не все, что кто-либо предлагает, является правильным ответом. Мы рассматриваем все запросы, но потребитель
Добавим к вышесказанному: крайне важно, чтобы вы, как компания-разработчик, любили свой продукт. А вы не сможете его любить, если он наполнен кучей вещей, с которыми вы не согласны. И это еще один довод в пользу того, чтобы отказать пользователям в выполнении запросов, в необходимость которых вы не верите.
В хорошей компании
Используйте форум или чат, чтобы пользователи имели возможность помогать друг другу
Форумы и сетевые групповые чаты — хороший способ дать пользователям возможность задавать вопросы и помогать друг другу. Путем убирания посредника — то бишь вас — вы обеспечиваете открытый поток общения и экономите свое время.
На форумах наших продуктов пользователи предлагают идеи и решения, оставляют запросы, истории и многое другое. Мы появляемся время от времени, чтобы предложить помощь — но прежде всего, форумы — это место, где люди помогают друг другу и делятся своим опытом работы с продуктом.
Вы будете удивлены тому, насколько люди хотят помогать друг другу.
Публикуйте ваши неудачи
Выпустите плохие новости и уберите их с дороги
Если что-либо пошло не так, расскажите людям. Даже если они не заметили.
Например, сайт Basecamp однажды не работал в течение нескольких часов среди ночи. 99% наших пользователей никогда бы об этом и не узнали, но мы все равно поместили сообщение о непредвиденном сбое в нашем блоге Everything Basecamp. Мы считаем, что наши пользователи заслуживают того, чтобы об этом знать.
Вот пример нашего сообщения в случае неполадок: «Мы приносим свои извинения за сбои в работе сайта сегодня утром. У нас были проблемы с базой данных, что привело к замедлению работы программы и ее сбоям для некоторых пользователей. Мы решили эту проблему и работаем над тем, чтобы она больше не повторялась. Благодарим за терпение и еще раз просим прощения за неполадки.»
Будьте открыты, честны и прозрачны, как только возможно. Не держите секретов и не прячьтесь. Информированный пользователь — ваш лучший пользователь. Кроме того, вы поймете, что ваши неудачи в глазах ваших пользователей не так уж и плохи. Пользователи обычно счастливы предоставить вам пространство для маневра, когда знают, что вы с ними честны.
Заметим еще по поводу новостей, плохих и хороших. Когда появляются плохие новости, выпустите их сразу. Хорошие новости, с другой стороны, выпускайте медленно. Если вы можете продлить прекрасные чувства, сделайте это.
Это может показаться странным, но лучший вариант развития событий — когда компания сама сообщает плохие новости. Такой проактивный подход избавит вашу компанию от попадания
52
http://www.cnet.com/
53
http://www.calypsocom.com/
54
http://www.clickz.com/showPage.html?page=836871
После выпуска
Настройка через месяц
Выпустите обновление через 30 дней после выпуска
Быстрое обновление показывает движение. Показывает, что вы прислушиваетесь к советам пользователей. Показывает, что у вас еще есть «порох в пороховницах». Оно дает вторую волну разговорам. Оно подкрепляет первоначальные положительные эмоции, связанные с вашим продуктом. Оно дает пищу для обсуждения и сообщений в блогах.
Мысли о грядущем быстром обновлении также помогают вам перед выпуском сосредоточиться на наиболее критических компонентах. Вместо того, чтобы втискивать в программу новые и новые детали, вы можете просто совершенствовать имеющиеся. Потом вы сможете выпустить продукт «в люди». А когда он уже там, вы начнете собирать отзывы пользователей и узнаете, какие области потребуют внимания на следующем этапе.
Этот подход с маленькими шажками хорошо оправдал себя в случае Backpack. Вначале мы выпустили базовый продукт, а потом, несколькими неделями позже, добавили новые функции, такие как Backpack Mobile для карманных компьютеров и поддержку тэгов, так как именно эти функции запрашивались клиентами чаще всего.
Продолжайте выпуск сообщений
Покажите, что ваш продукт живет — продолжайте блог продукта после выпуска
Не переставайте писать в блог после выпуска продукта. Покажите, что ваш продукт живет, с помощью блога, который вы часто обновляете ( как минимум раз в неделю, а если можете — то и чаще).
Что туда можно включить:
* Частые вопросы
* Как работать с программой
* Советы и решения
* Новые функции, обновления, исправление ошибок
* Разговоры/пресса
Блог не только показывает, что ваша программа живет, он еще делает вашу компанию более человечной. Еще раз, не бойтесь держать тон дружественным и личным. Маленькие компании иногда считают, что им надо все время выглядеть большими и сверх-профессиональными. Это похоже на бизнес-версию комплекса Наполеона. Не бойтесь выглядеть небольшими. Радуйтесь тому, что можете говорить с клиентами как с друзьями.