Ить об ошибке

Как сообщить, что вы всё уронили: шаблон действий в ситуации, когда всё пошло не по плану

Когда всё падает — это нормально. Особенно в IT. Даже Марку Цукербергу периодически приходится извиняться, когда сбой в работе соцсетей приводит к миллиардным потерям. Надеемся, что у вас таких потерь не будет, поэтому поговорили с разработчиками, тимлидами и менеджерами. Спросили, что и как нужно делать, когда всё плохо, чтобы не навредить карьере. 

Почему вообще сообщать об ошибках сложно

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

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

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

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

Поэтому мы собрали мнения и истории, которые помогут построить свой алгоритм действий в сложных ситуациях, не отвлекаясь на сомнения и выбор линии поведения.

Чем быстрее, тем быстрее

Кевин Риггл, специалист по информационной безопасности и консультант, рекомендует сразу определить, в какой из чатов вы сообщите о проблеме. Причём критерием выбора должна быть скорость: люди, которым важно знать о проблеме, должны максимально быстро отреагировать на сообщение. Но оповещение не должно затрагивать ту часть команды, которую не коснутся перебои в работе. 

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

Назовите проблему сразу же

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

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

Кира 2Pizza, ведущий разработчик

Антонина Лебединская, бизнес-тренер, эксперт по менеджменту и личной эффективности и преподаватель Нетологии, предлагает использовать самые простые и короткие формулировки. Чем более далека от технической части аудитория, которая получит письмо, тем проще нужно писать. В детали погружаться не нужно вовсе. Если же в деле есть важные детали, лучше дать ссылку на документ или дашборд, где с ними можно ознакомиться. Ничего объяснять для начала тоже не надо: может быть, вы и сами ещё не понимаете, в чём проблема. Тем более не надо оправданий о том, что «оно само». Вообще ничего не нужно, кроме факта.

Добрый день, коллеги.

Сегодня стала недоступна функция Х.

Проявить эмпатию, если это уместно

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

Приносим извинения за этот инцидент. 

Мы понимаем, что эта функция крайне важна для вашей работы в системе. 

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

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

Рассказать, как и когда все исправите 

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

Михаил Корнеев, тимлид, автор YouTube-канала «Хитрый питон»

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

Макс, привет!

У нас случился security-провал, ставлю тебя в известность. У нас xxx, и из-за этого yyy (описание ситуации и вероятных последствий). 

Что делаем, чтобы исправить:

1. Я запросил у Васи информацию, которая нам поможет информировать NNN.

2. Завёл тикет, в рамках которого поправим ZZZ.

3. Договорился с Петей, что теперь в чек листе будет отдельная задача на проверку xxx.

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

Специалисты работают над исправлением ситуации.

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

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

Назначить ответственного

Елена Степанова, разработчик и product owner из Nokia, считает, что нужно назначить человека, который будет координировать весь процесс, пока проблема не решится. Это должен быть сотрудник, который достаточно компетентен, чтобы разобраться с технической проблемой. К тому же, с хорошоими коммуникационными навыками. Если у вас в команде есть проджект-менеджер — то вам повезло, эту ответственность можете смело делегировать ему.

Елена Степанова, разработчик и product owner из Nokia

Внутри команды у нас сообщения предельно прямолинейные и простые: сломали вот это, коллега N занимается анализом, выглядит не очень сложно, починим в течение суток. Главное — указать:

— какие компоненты задействованы и на что влияет поломка

— кто отвечает за решение проблемы 

— какой примерный срок починки

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

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

Контакт ответственного нужно дать всем заинтересованным лицам. Возмущение сотрудников тоже придётся принимать на себя ответственному — негативные реакции были, есть и будут, но на них, как правило, некогда отвлекаться.

Не искать виноватых

Каждый сбой — это повод проверить, что не так в рабочем процессе. Но нужно чувствовать разницу: искать причину ошибки, а не кого-то, на кого свалить неудачу. Когда инцидент уже произошёл, велик риск начать поиск виноватых, погрязнуть во взаимных обвинениях и конфликте, считает Product Adviser Александр Дученчук. Но это то, чего делать как раз не нужно. Проблему вы решите, а отношения испортятся. 

 Александр Дученчук, Product Adviser 

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

Приходит срок релиза API, бэкенд готов, всё круто. Но! Сайт-то висит старый, со старым бэком, и там сотни тысяч юзеров, и никто не подумал, что мы не сможем релизить продукты с разными и рассинхронизипованными базами. А сроки-то названы, под них подвязан инвестраунд следующий. Перед нами два варианта: либо мы строим синхронизацию между старой и новой базой на время, пока делаем сайт, либо ничего не релизим и уходим в разработку сайта. Приходим к инвесторам, объясняем честно ситуацию, признаёмся, что не спланировали полностью миграцию, предлагаем оба варианта решения. 

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

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

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

Сообщить, когда всё наладится

Когда все восстановите, обязательно напишите ещё одно письмо — оно будет короче и приятнее. Пишите в те же чаты и тем же адресатам на почту, даже если на первое сообщение никто из них не отреагировал. Схема та же: заголовок с важным фактом, коротко — раскрыть суть.

Функция х снова работает

Добрый день

Работа приложения восстановлена в полном объёме

Если заметите сбои — пишите ххх

Пример большого и подробного письма

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

Тема: Производственный сбой в базе данных

Кластер первичной базы данных перестал отвечать на запросы в 0:02 UTC — 17:02 по тихоокеанскому времени. Через тридцать секунд производство переключилось на вторичную базу данных и предупредило об инциденте. 

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

Я куратор инцидента. Координация через канал отработки отказа # 2021-03-15-production-failover в Slack.

Представитель по связям с клиентами: Джейла М.

Специалисты в данной области: Алисия С., Дэйв Д.

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

Сообщения об ошибке — простая на первый взгляд вещь, поэтому обычно им уделяется не очень много внимания. Тем не менее не всякое сообщение об ошибке можно назвать правильным и полезным. Хорошее сообщение должно информировать пользователя о том, что что-то пошло не так, объяснить причину, а также сообщить, как он может решить проблему.

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

Чтобы этого не произошло, при создании сообщения об ошибке вам нужно сделать следующее:

1. Проверить орфографию и пунктуацию

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

2. Конкретизировать проблему

Будем честны — сообщения вроде «произошла ошибка» или «что-то пошло не так» вряд ли можно назвать полезными. Чтобы они стали таковыми, нужно объяснить пользователям, что конкретно произошло и как конкретно они могут это исправить.

Даже глобальные корпорации не застрахованы от таких неудач. Вот такая ошибка встречалась при установке Windows 10 (и сейчас уже стала мемом):

На самом деле при такой ошибке требовалось изменить языковые настройки, но из сообщения выше это было, естественно, не очень очевидно

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

3. Предоставить достаточное количество информации

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

Тут надо:

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

4. Писать вежливо и в дружелюбном ключе

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

Пример неудачного сообщения об ошибке:

Пример удачного сообщения:

5. Использовать микротекст

Микротекст — короткий текст-подсказки рядом или под графами, которые помогают понять, как правильно заполнить то или иное поле. Полезный прием, который может сэкономить время и нервы пользователей. Иногда микротекст отображается при наведении курсора на значок справочной информации.

6. Можно добавить немного юмора

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

Или другой известный пример (страницы 404 очень часто креативно оформляют):

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

Почему сообщения об ошибках имеют значение

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

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

Подумайте о различии между этими двумя уведомлениями.

Например, после такого сообщения непонятно, что делать дальше:

^{«Произошла ошибка»}

Второе сообщение содержит рекомендацию к действию, оно более конкретно:

^{«Вы не в сети. Проверьте соединение и попробуйте снова»}

Так что же могут сделать разработчики?

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

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

Если вы не можете исправить основную проблему и сообщение все-таки необходимо, подумайте о тексте. Когда что-то идёт не так, и приложение «не работает», порекомендуйте что-то полезное. Оповещение должно помочь пользователю решить проблему и продолжить работу.

Советы по написанию полезных сообщений об ошибках

1. Скажите, что произошло и почему

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

Представьте, что вы хотите скачать, скажем, Spotify Premium, и вы нажимаете на ссылку, чтобы начать бесплатную пробную версию. Затем вы попадаете на страницу и видите что-то вроде этого:

^{«Извините, у вас недостаточно прав для этого»}

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

В этом случае важно сообщить пользователю, почему это произошло (например, он уже подписывался на бесплатную пробную версию раньше).

^{«Похоже, что вы уже приобретали пробную версию ранее, а это значит, что у вас нет доступа к этому предложению. Но вы можете оформить подписку за 9$ в месяц»}

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

2. Предложите следующий шаг

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

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

^{«Ошибка. Приложение устарело»}

Это говорит о том, что что-то пошло не так, но это не предполагает следующего шага. Лучше сделать четкий заголовок и создать призыв к действию в виде кнопки загрузки.

^{«Приложение устарело. Скачайте новую версию, чтобы продолжить работу»}

3. Найдите нужный тон

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

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

Итак, выбирая правильный тон, начните с вопросов:

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

Вы бы сказали это в повседневном диалоге? Чтение сообщения вслух поможет вам точно определить слова или фразы, которые необходимо пересмотреть.

Выводы

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

В следующий раз, когда вы будете писать сообщение об ошибке, помните об этих советах:

• Скажите что произошло и почему
• Предложите следующий шаг
• Найдите правильный тон
• И, наконец, не забудьте прочесть сообщение вслух и убрать лишние слова

^{Оригинал статьи: The Next Web}

система выбрала этот ответ лучшим

Войти на сайт

или

Забыли пароль?
Еще не зарегистрированы?