Как продуманный баг-репорт помогает удерживать пользователя

0
148
views

Перевод статьи «Buggy software, loyal users: why bug reporting is key to user retention».

Баг-репорт и лояльность пользователя

В ваших программах есть баги. И в моих тоже.

Не важно, сколько вы тестировали свое ПО и сколько QA его тестировал: какие-то баги все равно проскользнут. И если только вы работаете не в NASA, скорее всего вы в любом случае не можете себе позволить достаточно хорошее тестирование.

Это означает, что баги будут находить ваши пользователи. Они обнаружат, что ваш сайт не работает в IE 8.2. Они кликнут на кнопку и перед их глазами возникнет пустой экран. Где обещанный вами функционал? ПОЧЕМУ ОН НЕ РАБОТАЕТ?!

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

Итак, мы имеем программу с багами и недовольных пользователей. Что делать? К счастью, ответ на этот вопрос еще в 1970 году дал экономист Альберт Отто Хиршман.

Уход, сообщение о проблеме и лояльность

В своем научном труде «Exit, Voice and Loyalty» Хиршман указывает, что у пользователей, недовольных продуктом, есть два выхода. Только два, не больше:

  1. Уйти, то есть, отказаться от использования вашего продукта.
  2. Озвучить возникшие проблемы.

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

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

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

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

Что нужно сделать и как нужно поступать, чтобы ваши пользователи, обнаружив баг, чувствовали, что вы к ним прислушиваетесь?

  1. Репорт о баге должен требовать как можно меньше усилий со стороны пользователя.
  2. Пользователям нужно отвечать.
  3. Если вы решили исправить баг, разобраться в проблеме вам поможет репорт.
  4. Нужное исправление должно дойти до пользователя.

Давайте рассмотрим все это подробнее.

Пользователь обнаружил баг

Баг-репорт

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

При более быстрой коммуникации также повышается вероятность, что вы сможете извлечь пользу из сообщения. Если баг проявился 10 секунд назад, пользователь, скорее всего, будет помнить, что произошло. Несколько часов спустя вы уже можете услышать что-то вроде «на экране был летающий лось… или гиена». Помните: пользователи вашей программы – люди, а люди не отличаются хорошей памятью (мы порой забываем об этом).

Чтобы пользователь сообщал о багах достаточно быстро (и вообще сообщал о них), этот процесс должен быть как можно проще. Каждый дополнительный шаг (например, создание аккаунта в трекере проблем) отсекает некоторое количество пользователей, желавших сообщить о баге.

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

И, конечно, на этой странице нет никаких пометок о том, как и куда вам нужно сообщить о проблеме, с которой вы столкнулись. Фактически, вы не знаете, интересно ли это вообще людям, поддерживающим данный сайт.

Не надо так поступать со своими пользователями.

Улучшение баг-репортов

Предположим, что вы включили ссылку на страницу для баг-репортов. Также предположим, что вашему пользователю не придется прыгать через обруч, проходить проверку по email, а затем заполнять 200 полей, которые JIRA или Bugzilla считают абсолютно необходимыми, и выбирать из выпадающего списка самый частый кошмарный сон своего детства. Будем считать, что форму для отправки репорта легко найти и заполнить, как это и должно быть.

Но… вам нужна кое-какая информация от пользователя. Например, версия программы, которую он использует, операционная система и т. д. Эти сведения вам действительно необходимы.

Но пользователь лишь хочет поскорее отправить свое сообщение; любой запрос относительно дополнительной информации может подтолкнуть его уйти. Что делать?

Есть одно решение: включить эту информацию в баг-репорт вместо пользователя.

Например, я пользовался отличным редактором Spacemacs и, как это всегда бывает с новым ПО, столкнулся с необходимостью отправить баг-репорт. Такова жизнь.

Чтобы сообщить о баге в Spacemacs вам нужно лишь нажать соответствующую кнопку. Вы попадаете на страницу для баг-репортов. В вашем редакторе. И там уже есть такие сведения, как версия Spacemacs и Emacs, а также информация о ваших настройках. От вас требуется лишь нажать на кнопку «Отправить».

Баг-репорт, пример.

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

Также прошу заметить, что это гораздо лучше, чем автоматический репорт об отказе системы. Мне, пользователю, нужно принять участие и пояснить, что во всем этом было для меня важно. У меня не возникают мысли вроде «угу, ты отправил информацию, но давай будем честными: ты же не думаешь, что кто-то будет ее читать, правда?».

Практически то же самое можно сделать для консольных инструментов или веб-приложений. При появлении ошибки или в случае возникновения проблем у пользователя (например, когда он набирает yourcommand —help):

  1. Попросите пользователя об обратной связи – в окне терминала или веб-страницы – а затем заполните за него баг-репорт.
  2. Соберите как можно больше информации автоматически и включите ее в баг-репорт, чтобы пользователь мог писать только о том, что его реально беспокоит.
Реакция на баг-репорт

Реакция на баг-репорт

Следующее, что вам нужно сделать, это отреагировать на сообщение о баге. Баг в Spacemacs, о котором я им сообщил, до сих пор сидит там, печальный и одинокий, и это несколько раздражает. Я понимаю, это open source проект, им занимаются волонтеры и все такое (вот здесь в игру вступает лояльность).

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

Реагируйте на баг-репорты по вашим программам, рассказывайте пользователям, что вы делаете / намерены сделать для решения возникшей проблемы. И – нет, сообщение, написанное роботом, не достаточно хороший вариант.

Диагностика бага

Если вы решили исправить баг, вы можете это сделать… если разберетесь, в чем, собственно, дело. Когда диагностировать корни проблемы невозможно или слишком дорого, вы ее не исправите. А это означает, что ваши пользователи по-прежнему будут от нее страдать.

Давайте взглянем на обычный баг-репорт: «Я кликнул «Сохранить», а ваша программа закрылась и стерла все мои мечты и надежды».

Это довольно плохо: пользователь недоволен и, как это часто случается, у вас слишком мало информации, чтобы понять, что происходит.

Даже если баг-репорт составлен хорошо, бывает сложно воспроизвести проблему. Тестирование происходит в контролируемой среде, что облегчает исследование и воспроизведение. В реальном мире все происходит иначе, так что успехов вам в попытках воспроизвести этот баг.

Помните, ранее мы говорили о необходимости автоматически включить в баг-репорт побольше информации. Вы же это сделали, верно? И включили туда все релевантные логи?

Если нет, то самое время об этом подумать. У вас должен быть доступ к логам, причем это те сведения, которые вам нужно получать автоматически, чтобы пользователь мог сообщать только о своей проблеме. (При этом не забывайте о защите пользовательских данных и конфиденциальности!)

Внесение исправлений должно быть быстрым

Внесение исправлений

Итак, вы диагностировали и исправили баг: проблема решена! Ну, или почти решена. Если пользователь не получил исправление бага, все это было напрасной тратой времени.

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

Идеальный цикл

Если вы сделали все правильно,

  1. Ваши пользователи знают, что вы к ним прислушиваетесь, и предпочитают заявить о проблеме, а не просто уйти.
  2. Временами вы будете получать полезные баг-репорты, что позволит вам улучшить свой продукт.
  3. Все ваши пользователи будут быстро ощущать пользу от вносимых вами изменений.

Конечно, многие баги могут и должны быть выловлены заранее. И многие пользователи не сообщат вам о возникших проблемах, если вы их специально об этом не попросите.

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