Как и зачем выстраивать коммуникации с пользователями

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

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

На конференции HighLoad++ Весна 2021 я рассказал, как выстроить коммуникации, чтобы пользователи были на вашей стороне и не отвлекали вас от «пожарного» спасения прода. По мотивам доклада выпустил первую часть, а сегодня поговорим о том, как вести коммуникацию с пользователями, зачем это нужно и о чем говорить, когда вроде бы не о чем Видео выступления можно посмотреть здесь.

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

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

Про доверие

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

Почему важно доверие? Если пользователи вам не доверяют, то это может усложнить решение инцидентов. Вы получите кучу коммуникаций, оборванные телефоны и мессенджеры: «А когда почините?», «Что происходит?!», «Почему?», «Да я вас всех уволю!». Все это как минимум отвлекает.

Когда они вам доверяют и уверены в вашей компетенции, то действуют иначе: «У наших ребят проблемы, они чинят, мы держим за них кулачки — они классные, чем мы можем помочь?». Если вы сообщили им о проблеме и уже чините — они верят, что вы им не врете. И, как минимум, они не будут мешать и придут за апдейтом в указанные вами сроки. А как максимум — у пользователей бывают неожиданные компетенции, которые могут вам помочь после инцидента. Также пользователи будут охотнее прислушиваться к вашим рекомендациям, что упрощает тушение пожаров, а порой и вовсе предотвращает их.

Это означает, что и внутри команды люди должны друг другу доверять. Если они боятся признаться, что накосячили, вы можете очень долго чинить инцидент, который могли бы решить быстрее. Хороший пример прозрачности — GitLab. В нем очень много метрик, и все они доступны на публичных дашбордах. Потому что когда мы видим сервис, который говорит, что uptime 100%, мы думаем: «Ну, допустим… SLA можно посчитать по-разному». GitLab же не стесняется показывать даже неудобные метрики, чем и формирует наше доверие.

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

Каналы коммуникации

Тут всё очень индивидуально.

Не бывает плохих каналов, бывают неподходящие — например, где-то люди читают почту оперативно, где-то — нет. По моему опыту, инженеры почту читают реже, но более гарантированно, поэтому для оперативной коммуникации может подойти Slack, Telegram и прочие мессенджеры. А вот чтобы точно увидели — используйте почту. Очень круто, когда пользователи могут получать лишь ту информацию, которая им нужна. Например, в почтовой рассылке, когда человек подписывается только на то, что ему надо. Или подписывается на нужный канал в телеграме.

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

Цель канала коммуникации — быть актуальным, оперативным и читаемым. Если пользователи массово отключают уведомления для вашего телеграм канала то вы, скорее всего, делаете что-то неправильно. Например, пишете ночью или что-то не достойное уведомления, по мнению пользователя.

Даже если ваши пользователи используют дополнительный экзотический канал коммуникации, пробуйте его тоже. Если у вас нет какого-то стандарта, а пользователям будет так удобно, а значит — это правильно. У нас в компании есть внутренний регламентированный инцидент-менеджмент, мы там заводим инциденты. Это всё работает по почте, но только для менеджеров. И они довольны — потому что это канал коммуникации для них. Обычно использование еще одного способа связи не стоит вам почти ничего, а пользователи, которым это важно, чувствуют заботу.

Как сказал Элиот Карвер, один из злодеев Бондианы: «Секрет хорошей истории — не кто, что или когда, но почему». Этот вопрос пользователи задают обо всём, что вы делаете. Просто задают не вам. Поэтому отвечая на «Почему?», вы формируете базу пользователей, которые вам доверяют. И дальше вы уже можете доносить до людей какие-то ценные вещи.

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

А еще пишем про:

Анонсы работ

Мы пишем анонсы работ с «человеческим лицом». Конечно, у нас есть официальные процессы согласования работ, но там сухой формализм, здесь же — более просто и понятно. Круто, если из заголовка читателю сразу понятно, нужно ему это или нет. Потому что дальше будут читать только те, к кому ваш анонс относится (в примере — только пользователи Ceph).

Пользователи при этом не любят обновления — с ними связаны даунтаймы, и считают, что «чиним один баг — получаем десять». Поэтому объясните, какие баги вылечит обновление, и какой новый функционал появится. Тогда пользователь и даунтайм подождет спокойно. А может наоборот, вы сами поймете, что обновление, кроме рисков и даунтайма ничего не приносит и подождете более заметных изменений. Если есть какая-то срочность — объясните почему.

Новый функционал

Очень часто пользователи не знают про новые фичи.

Мы пишем небольшие обзоры нового функционала. На скриншоте — пример обновления Гитлаб. Изменения описываем кратко, где нужно — даем ссылки на подробное описание. Ну и ссылка на полный список изменений, для тех, кому интересно.Конечно, мы подсвечиваем тот функционал, который считаем нужным и интересным, и можем что-то упускать. Это так же должно быть понятно из ваших сообщений.

Анонсы важных изменений

Это история про вещи, которые еще не сломались, но могут. Причем иногда даже не на вашей стороне. Например, в git 2.31.0 меняются по умолчанию названия веток с master на main. Казалось бы, это клиентский git на ноутбуках пользователей, нам до него какое дело? Но люди придут с вопросами к нашей команде. Я могу сэкономить и свое, и их время, написав этот анонс и подсветив изменение. Например: «В новом репозитории пушится ветка main, и пайплайны не будут пайплайнтиться, потому что они у вас на другую ветку захардкожены».

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

FAQ

В разработке то же самое.

Если вас о чём-то спросили больше двух раз, то стоит ответить на этот вопрос массово всем сразу. Даже тем, кто еще не спросил. Пользователи научатся чему-то новому, а у вас будет меньше одинаковых вопросов.

Можно написать в Вики и дать ссылку. Даже если кто-то этот ответ не увидит или сейчас ему не надо, вы потом сможете просто пересылать ссылку на ответ.

Полезные советы

Это почти как FAQ, только когда вас еще не спросили, а вы уже всем ответили. Например, я внезапно узнал, что в Jira можно клонировать задачи. Особенно это удобно, когда там много полей и компонент, но есть готовый шаблон. Я поспрашивал людей и понял, что они в большинстве тоже об этом не знают. А рассказав об этом, мы решили проблему, которая еще не наступила.

Кратко!

Экономьте чужое время — выкидывайте всё, что не несет смысла. Вот прям всё. И «Добрый день, достопочтенные глубокоуважаемые коллеги» — тоже. Чем сообщение легче, меньше, тем оно читается быстрее и тем больше шансов, что его дочитают. Конверсия опять же повышается — не будут спрашивать то, о чемвы длинно писали, а они не осилили. Было/стало, оцените разницу:

Структурированно

Разбивайте текст на абзацы по смыслу, выделяйте главное жирным шрифтом. Мы все читаем сначала выделенное, а потом уже всё остальное. Не тратьте время своих пользователей, оставьте «дрожащий на ветру кластер Kubernetes вспорхнул в закат» для фанфиков по Гарри Поттеру. Здесь всё же другой жанр

Информационно

Конечно же, это всё придумал не я. Есть отличная книга Максима Ильяхова, я лишь использую его советы на практике. В книге намного больше того, что хорошо ложится на IT-коммуникации, я рассказал лишь про самое базовое.

Вот примеры на основе информационного стиля:

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

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

Еще я считаю, что пользователи — наши друзья, даже если они об этом еще не знают. Мы хотим давать им лучший сервис, который только сможем. Но лучший сервис — это не только про «девяточки» в SLA. Это еще и про User Experience.

У нас уже довольно давно есть devops, который вроде бы про коммуникации. Потом в него начали вставлять еще какие-то слова — например появился DevSecOps. Я считаю, что самое время вспомнить про пользователей и начать уже делать DevUserOps.

В этом году нас ждёт ещё два HighLoad++: 20-21 сентября в Санкт-Петербурге и 25-26 ноября — в Москве.

Питерское расписание уже готово. Билеты можно купить здесь.