Текст книги "Getting Real"
Автор книги: 37signals
Жанр:
Программирование
сообщить о нарушении
Текущая страница: 8 (всего у книги 8 страниц)
Публикуйте ваши неудачи
Выпустите плохие новости и уберите их с дороги
Если что-либо пошло не так, расскажите людям. Даже если они не заметили.
Например, сайт Basecamp однажды не работал в течение нескольких часов среди ночи. 99% наших пользователей никогда бы об этом и не узнали, но мы все равно поместили сообщение о непредвиденном сбое в нашем блоге Everything Basecamp. Мы считаем, что наши пользователи заслуживают того, чтобы об этом знать.
Вот пример нашего сообщения в случае неполадок: «Мы приносим свои извинения за сбои в работе сайта сегодня утром. У нас были проблемы с базой данных, что привело к замедлению работы программы и ее сбоям для некоторых пользователей. Мы решили эту проблему и работаем над тем, чтобы она больше не повторялась. Благодарим за терпение и еще раз просим прощения за неполадки.»
Будьте открыты, честны и прозрачны, как только возможно. Не держите секретов и не прячьтесь. Информированный пользователь – ваш лучший пользователь. Кроме того, вы поймете, что ваши неудачи в глазах ваших пользователей не так уж и плохи. Пользователи обычно счастливы предоставить вам пространство для маневра, когда знают, что вы с ними честны.
Заметим еще по поводу новостей, плохих и хороших. Когда появляются плохие новости, выпустите их сразу. Хорошие новости, с другой стороны, выпускайте медленно. Если вы можете продлить прекрасные чувства, сделайте это.
Будьте оперативны, прямы и честны
Это может показаться странным, но лучший вариант развития событий – когда компания сама сообщает плохие новости. Такой проактивный подход избавит вашу компанию от попадания в ослабленное, оборонительное положение.
– Грег Шервин(Greg Sherwin), Вице-президент по технологиям приложений (Vice President of Application Technology) компании CNET[52]52
http://www.cnet.com/
[Закрыть], и Эмили Авила(Emily Avila), руководитель компании Calypso Communications[53]53
http://www.calypsocom.com/
[Закрыть] (из книги A Primer for Crisis PR[54]54
http://www.clickz.com/showPage.html?page=836871
[Закрыть])
После выпуска
Настройка через месяц
Выпустите обновление через 30 дней после выпуска
Быстрое обновление показывает движение. Показывает, что вы прислушиваетесь к советам пользователей. Показывает, что у вас еще есть «порох в пороховницах». Оно дает вторую волну разговорам. Оно подкрепляет первоначальные положительные эмоции, связанные с вашим продуктом. Оно дает пищу для обсуждения и сообщений в блогах.
Мысли о грядущем быстром обновлении также помогают вам перед выпуском сосредоточиться на наиболее критических компонентах. Вместо того, чтобы втискивать в программу новые и новые детали, вы можете просто совершенствовать имеющиеся. Потом вы сможете выпустить продукт «в люди». А когда он уже там, вы начнете собирать отзывы пользователей и узнаете, какие области потребуют внимания на следующем этапе.
Этот подход с маленькими шажками хорошо оправдал себя в случае Backpack. Вначале мы выпустили базовый продукт, а потом, несколькими неделями позже, добавили новые функции, такие как Backpack Mobile для карманных компьютеров и поддержку тэгов, так как именно эти функции запрашивались клиентами чаще всего.
Продолжайте выпуск сообщений
Покажите, что ваш продукт живет – продолжайте блог продукта после выпуска
Не переставайте писать в блог после выпуска продукта. Покажите, что ваш продукт живет, с помощью блога, который вы часто обновляете ( как минимум раз в неделю, а если можете – то и чаще).
Что туда можно включить:
* Частые вопросы
* Как работать с программой
* Советы и решения
* Новые функции, обновления, исправление ошибок
* Разговоры/пресса
Блог не только показывает, что ваша программа живет, он еще делает вашу компанию более человечной. Еще раз, не бойтесь держать тон дружественным и личным. Маленькие компании иногда считают, что им надо все время выглядеть большими и сверх-профессиональными. Это похоже на бизнес-версию комплекса Наполеона. Не бойтесь выглядеть небольшими. Радуйтесь тому, что можете говорить с клиентами как с друзьями.
Он живет
Часто обновляемый блог продукта – лучшее свидетельство тому, что продукт находится в активной разработке, его любят, и свет в его окошке не гаснет. Заброшенный блог – свидетельство заброшенного продукта, знак того, что его водители уснули за рулем.
Поддерживайте общение с пользователями в блоге продукта, будьте прозрачны и щедры в подаче информации. Пусть философия вашей компании будет видна. Выложите ссылки на конкурентов и открыто обсуждайте их. Анонсируйте добавление новых функций и держите комментарии открытыми для обратной связи.
Продукт живет, когда он говорит со своими пользователями и слушает их. Часто обновляемый блог продукта поддерживает прозрачность, чувство сообщества и лояльности к вашей марке. Дополнительно вы получаете бесплатную рекламу.
Как редактор Lifehacker, я постоянно просматриваю блоги любимых приложений, таких как Google, Flickr, Yahoo, del.icio.us и 37signals. И я большей вероятностью буду упоминать их, чем те, которые высылают односторонние пресс-релизы из ниоткуда и не поддерживают общения со своими пользователями и поклонниками.
Не бета, а лучше
Не используйте «бета» в качестве козла отпущения
В наши дни кажется, что все постоянно находится в бета-версии. Неумирающая бета-версия говорит пользователям, что вы не так уж и хотите выпускать завершенный продукт. Она говорит: «Пользуйтесь вот этим, но если оно несовершенно – это не наша вина».
Бета сваливает все на пользователя. Если вы сами не уверены в вашей версии, то как клиенты могут быть в ней уверены? Приватные бета-версии – это нормально, а общедоступные – это фигня. Если нечто недостаточно хорошо для всеобщего потребления – не давайте это публике.
Не ждите, что ваш продукт достигнет совершенства. Этого не случится. Возьмите на себя ответственность за то, что вы выпускаете. Выпустите это и назовите новой версией. В противном случае вы просто ищете отговорки.
Бета ничего не значит
Можете обвинять Google со товарищи в таких проблемах. Сейчас пользователи научены программистским сообществом, что понятие «бета» в действительности ничего не значит.
Не все ошибки в программе созданы равными
Разделите ваши ошибки по приоритетам (и даже проигнорируйте некоторые из них)
Если вы нашли ошибку в вашем продукте – это не повод впадать в панику. Все программы содержат ошибки, это просто неоспоримый факт.
Не нужно сразу же исправлять каждую ошибку. Большинство ошибок надоедливы, но не смертельны. Те, которые надоедливы, могут быть отложены. Ошибки типа «что-то тут выглядит не так» и подобные можно без ущерба отложить на некоторое время. А уж если ошибка ломает вашу базу данных – тогда, конечно, она должна быть исправлена немедленно.
Определите приоритет каждой ошибки. Сколько пользователей от нее страдают? Насколько серьезна проблема? Заслуживает ли ошибка немедленного внимания, или может подождать? Что можно сделать прямо сейчас, чтобы помочь наибольшему количеству пользователей? Часто добавление новой функции может быть более важным, чем исправление существующей ошибки.
Также не создавайте ореол страха вокруг ошибок. Они случаются. Не ищите постоянно, кого бы обвинить. Меньше всего вам нужно, чтобы ошибки прятались под ковер, вместо того, чтобы открыто обсуждаться.
И помните то, что мы говорили ранее о важности честности. Если клиенты жалуются на ошибку, будьте с ними честны. Скажите, что вы заметили эту проблему и работаете над ней. Если вы не собираетесь работать на ней прямо сейчас, объясните, что вы заняты теми областями продукта, которые помогут большему числу пользователей. Честность – лучшая политика.
Переждите шторм
Подождите, пока страсти улягутся, перед тем как действовать
Если раскачивать лодку, появляются волны. Когда вы добавляете новую функцию, изменяете правила или удаляете что-нибудь – реакции будут разными, и часто отрицательными.
Избегайте паники и желания быстро все поменять в ответ. Да, вначале страсти кипят. Но если вы переждете этот начальный период, который составляет 24-48 часов, все уляжется. Большинство пользователей реагируют на изменения до того, как они действительно изучили и использовали то, что вы добавили (или смирились с тем, что вы удалили). Так что расслабьтесь, и не двигайтесь, пока не пройдет некоторое время. И тогда уж вы сможете предложить более продуманный ответ.
Помните также, что отрицательные реакции почти всегда звучат громче, чем положительные. Вам даже может показаться, что вы слышите только отрицательные отзывы, тогда как большинство пользователей довольно изменениями. Убедитесь, что вы не отказываетесь глупо от необходимого, но противоречивого решения.
Не отставайте от соседей
Подпишитесь на новости о ваших конкурентах
Подпишитесь на новости и о своих продуктах, и о продуктах конкурентов (это всегда мудро – следить за передвижениями противника). Используйте сервисы, такие как PubSub, Technorati, Feedster и другие, чтобы быть в курсе (в качестве ключевых слов используйте названия компаний и продуктов). С помощью RSS эта постоянно меняющаяся информация будет доставлена прямо к вам, так что вы будете всегда в курсе.
Остерегайтесь монстра разбухания
Более зрелый – не значит более сложный
С развитием событий не бойтесь противостоять разбуханию. Всегда будет соблазн расширять продукт в объеме. Но это делать не обязательно. То, что продукт растет и становится более зрелым – не должно значить, что и более сложным.
Не обязательно быть ручкой для письма в открытом космосе, которая пишет вверх ногами. Иногда можно просто быть карандашом. Не нужно становиться швейцарским армейским ножом. Можно быть просто отверткой. Не нужно создавать часы для ныряния на 5000 метров, если ваши потребители – люди сухопутья, которые просто хотят узнать, который час.
Не раздувайте просто ради раздувания. Именно так получаются разбухшие программы.
«Новое» не обязательно значит «улучшенное». Иногда наступает точка, когда лучше просто оставить продукт как есть.
Это – одно из главных преимуществ построения сетевого программного обеспечения по сравнению с традиционным. Производители традиционного программного обеспечения, такие как Adobe, Intuit и Microsoft, должны каждый год продавать вам новые версии. И, так как они не могут просто продать вам новую версию, они должны оправдать расходы добавлением новых функций. Здесь и начинается разбухание.
В случае сетевого программного обеспечения, основанного на модели подписки, клиенты платят помесячно за право использования сервиса. Вам не нужно продавать им новые версии путем добавления всё новых и новых свойств, нужно только обеспечивать текущий сервис, значимый для них.
Двигайтесь по течению
Будьте открыты для новых путей и изменения направлений
То, что придает красоту сетевым приложениям – это их изменяемость. Вы не упаковываете программу в коробочку, поставляете пользователю, а потом ждете новой версии в течение многих лет. Напротив, вы можете вносить изменения по пути. Примите мысль, что ваша первоначальная идея могла быть не самой лучшей.
Посмотрите на проект Flikr. Он начинался как онлайновая игра для нескольких игроков, которая называлась «Бесконечная Игра» (The Game Neverending). Создатели проекта быстро поняли, что возможность совместного использования фотографий была куда более значимой, чем сама игра (которая в конце концов оказалась на полке). Учитесь признавать свои ошибки и менять курс.
Будьте серфером. Наблюдайте за океаном. Смотрите, где образуются большие волны, и соответственно корректируйте курс.
Заключение
Заводите моторы
Готово!
Ну хорошо, вы это сделали! Надеемся, вы с нетерпением ждете момента, чтобы начать применять Getting Real в своих программах. Сейчас самое лучшее время, чтобы создавать отличные программы, используя минимум ресурсов. При наличии хорошей идеи, страсти, времени и навыков – выше только небо.
Несколько мыслей в заключение:
Воплощение
Каждый может прочесть книгу. Каждый может придумать идею. У каждого есть родственник, работающий веб-дизайнером. Каждый может завести блог. Каждый может нанять кого-то еще, чтобы вместе наваять какой-то код.
Разница между вами и всеми остальными в том, как хорошо вы воплощаете. Успех достигается именно безупречным воплощением.
При создании программного обеспечения это значит, что нужно правильно воплотить множество вещей. Вы не можете просто написать хорошую спецификацию, а потом не выполнить своих обещаний. Безупречный дизайн интерфейса не поможет, если в коде полно трюков. Самая замечательная программа многого не стоит, если в результате плохого продвижения о ней никто так и не узнал. Чтобы преуспеть, нужно скомбинировать все эти элементы.
Главное – сохранять равновесие. Если вы гнетесь слишком далеко в каком-то направлении – вы на пути к падению. Постоянно ищите свои слабые звенья и сосредоточьтесь на них, пока не приведете их в порядок.
Люди
Стоит еще раз повторить, что главный элемент построения успешного сетевого приложения – это люди, работающие над ним. Мантры, проектирование от эпицентра, меньшее количество кода и все остальные замечательные идеи ничего не значат, если у вас нет людей, способных воплотить эти идеи.
Вам нужны люди, страстно любящие свое дело. Люди, заботящиеся о своем искусстве – и считающие свое дело искусством. Люди, чувствующие гордость за свою работу вне зависимости от наличия денежного вознаграждения. Люди, совершенствующие продукт до самых мелких деталей, даже если 95% пользователей их не заметит. Люди, которые стремятся создать отличный продукт и на меньшее не согласны. Люди, которым нужны люди... то есть не совсем, но мы не могли не вспомнить песню Барбры Стрейзанд. В любом случае, когда вы нашли таких людей – держитесь за них. В конце концов, от людей в вашей команде зависит успех или неуспех вашего проекта – и вашей компании.
Больше, чем просто программы
Также стоить заметить, что подход Getting Real применим не только к построению сетевых программ. Когда вы ближе познакомитесь с его идеями, вы обнаружите их повсюду вокруг себя. Например:
Силы особого назначения, такие как «Зеленые Береты» или «Альфа», используют малые бригады и быстрое развертывание для выполнения задач, для которых другие подразделения слишком велики или слишком медлительны.
Рок-группа White Stripes ограничивается в своем творчестве простыми средствами: два человека, простые песни, по-детски незамысловатая партия ударных, использование студии по минимуму и т.д.
iPod фирмы Apple отличается от конкурирующих продуктов тем, что в него не встроены ни радио, ни диктофон.
В американском футболе в результате быстрой атаки можно захватить большой участок поля за счет уменьшения «бюрократии» и толкотни.
Успешные кулинарные книги и телевизионная передача Рэйчел Рэй основаны на идее 30-минутных блюд в стиле Get Real.
Эрнест Хэмингуэй и Рэймонд Карвер использовали простой и ясный язык, который, тем не менее, производит сильное впечатление.
Шекспир с наслаждением творил в тесных рамках сонета, четырнадцатистрочного лирического стихотворения, написанного пятистопным ямбом.
И так далее...
Безусловно, подход Getting Real нацелен прежде всего на то, чтобы создавать хорошие программы. Но нет причин, чтобы на этом он и ограничивался. Возьмите эти идеи и попытайтесь применить их к другим аспектам вашей жизни. Может быть, вы будете приятно удивлены некоторыми результатами.
Будьте на связи
Сообщите нам, насколько полезным оказался для вас подход Getting Real. Отправьте нам письмо по электронному адресу gettingreal [at] 37signals [dot] com.
Также следите за новинками от 37signals – заходите на сайт Signal vs. Noise[58]58
http://www.37signals.com/svn
[Закрыть] – наш блог о Getting Real, удобстве использования программного обеспечения, проектировании и еще о многом другом.
Спасибо за то, что прочитали нашу книгу, удачи вам!
Ресурсы 37signals
Сайт 37signals
Блог Signal vs. Noise
Basecamp – Web-based project collaboration
Campfire – Web-based group chat for business
Backpack – Web-based information organizer
Writeboard – Web-based collaborative writing
Ta-da List – Web-based dead-simple to-do lists
Ruby on Rails – Open-source web application framework
Translation
Thanks to the following translators: Alex Molov, Andrey Duka, Oksana Shakula, Eugene Erin, Vladimir Oleynik, Andrey Beletsky
