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

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

Когда всё падает — это нормально. Особенно в 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.

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

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

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


Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.

Оцените статью

Средняя оценка 4.8 / 5. Всего проголосовало 19

Телеграм Нетологии