Когда всё падает — это нормально. Особенно в IT. Даже Марку Цукербергу периодически приходится извиняться, когда сбой в работе соцсетей приводит к миллиардным потерям. Надеемся, что у вас таких потерь не будет, поэтому поговорили с разработчиками, тимлидами и менеджерами. Спросили, что и как нужно делать, когда всё плохо, чтобы не навредить карьере.
Почему вообще сообщать об ошибках сложно
Рабочий процесс не идеален, ошибки случаются по разным причинам, мы не всегда в этом виноваты, а даже если и виноваты, то и это тоже естественно. Но когда ошибка случается, коммуникация с коллегами затрудняется.
Так работают наши психологические механизмы. У каждого из нас есть набор представлений о себе, и в этот набор по умолчанию входит установка «я прав». Момент, когда нужно рассказать о неполадках в работе, разрушает эту установку и нам становится неприятно и неловко.
Исследования показывают, что непризнание вины может повысить самооценку.
Хотя исследования психологии правонарушений говорят, что признание в ошибках делают люди, которые готовы изменить поведение. Когда случаются неприятности, мы тратим время на выбор тактики и стратегии поведения, и это может привести к худшим последствиям: сроки исправления затянутся, коллеги обидятся.
Поэтому мы собрали мнения и истории, которые помогут построить свой алгоритм действий в сложных ситуациях, не отвлекаясь на сомнения и выбор линии поведения.
Чем быстрее, тем быстрее
Кевин Риггл, специалист по информационной безопасности и консультант, рекомендует сразу определить, в какой из чатов вы сообщите о проблеме. Причём критерием выбора должна быть скорость: люди, которым важно знать о проблеме, должны максимально быстро отреагировать на сообщение. Но оповещение не должно затрагивать ту часть команды, которую не коснутся перебои в работе.
Это может быть рабочий чат в мессенджере, соцсетях или сообщение на электронную почту, а скорее всего — всё вместе. Главное — оповестить всех членов команды, кого может затронуть инцидент. В Atlassian также рекомендуют использовать специальную Status page или виджеты и пуши, чтобы сообщать об инцидентах клиентам. В крупных компаниях, как правило, такие механизмы уже отработаны, но не факт, что все знают и помнят, как ими пользоваться.
Назовите проблему сразу же
Сбои в работе — тот случай, когда можно пропустить даже приветствие. Если вы пишете в мессенджер, начните сообщение с заголовка. Если чат большой и активный, привлекайте внимание к сообщению — выделите текст жирным начертанием, поставьте эмодзи. Если вы решили извещать команду по электронной почте, опишите суть в теме письма. Например, «производственный сбой в базе данных». Не нужны общие фразы и оценки, такие как «у нас неприятности», «пишу, чтобы сообщить об ошибке» и так далее. Сразу переходите к делу.
Мне совершенно всё равно, как будет сказано, хоть матом. Главное, чтобы сразу же сказали, что и где упало и что с этим делали. Когда случилась проблема, обычно уже не до процедур. Часто начинают паниковать. Но важно уметь спокойно разбираться и чинить, пока тебя дёргают со всех сторон — это отдельный скилл. Он приходит с опытом.
Кира 2Pizza, ведущий разработчик
Антонина Лебединская, бизнес-тренер, эксперт по менеджменту и личной эффективности и преподаватель Нетологии, предлагает использовать самые простые и короткие формулировки. Чем более далека от технической части аудитория, которая получит письмо, тем проще нужно писать. В детали погружаться не нужно вовсе. Если же в деле есть важные детали, лучше дать ссылку на документ или дашборд, где с ними можно ознакомиться. Ничего объяснять для начала тоже не надо: может быть, вы и сами ещё не понимаете, в чём проблема. Тем более не надо оправданий о том, что «оно само». Вообще ничего не нужно, кроме факта.
Добрый день, коллеги.
Сегодня стала недоступна функция Х.
Проявить эмпатию, если это уместно
Этот пункт зависит от того, кому вы сообщаете об ошибке. Как правило, конечным пользователям и клиентам принято сообщать, что вы сожалеете, что поставили их в неловкую ситуацию.
Приносим извинения за этот инцидент.
Мы понимаем, что эта функция крайне важна для вашей работы в системе.
Эта формулировка нейтральная и подходит для широкой аудитории: разных клиентов, руководителей, бизнес-отделов, бухгалтерии.
Конечно, это нужно далеко не всегда. Допустим, у вас неформальные отношения в команде и вы пишете в соседний отдел, где принято общаться на сленге и в целом царит суровая атмосфера. Формальный подход вызовет недоумение, зато можно сказать: «Понимаю, как мы все влипли, будем выбираться».
Рассказать, как и когда все исправите
Даже если вы пока не знаете, как и что сделаете, хотя бы сообщите, что уже работаете над вопросом. Ну а если вы пишете руководству, можете указать подробности в теле письма или в сообщении в чате.
Михаил Корнеев, тимлид, автор YouTube-канала «Хитрый питон»
На мой взгляд, важно уведомлять команду оперативно, но при этом сообщить достаточно подробную информацию о том, что произошло, какие могут быть последствия и что делается для исправления. Недавно мы нашли проблему в безопасности, довольно заметную. Конечно, сразу об этом сообщили. Я удалил конкретику из письма, а то, что осталось, можно использовать как шаблон:
Макс, привет!
У нас случился security-провал, ставлю тебя в известность. У нас xxx, и из-за этого yyy (описание ситуации и вероятных последствий).
Что делаем, чтобы исправить:
Я запросил у Васи информацию, которая нам поможет информировать NNN.
Завёл тикет, в рамках которого поправим ZZZ.
Договорился с Петей, что теперь в чек листе будет отдельная задача на проверку 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.
Представитель по связям с клиентами: Джейла М.
Специалисты в данной области: Алисия С., Дэйв Д.
В письме обозначено, когда произошёл инцидент, в чём суть проблемы, какие у неё последствия, кто ей занимается и в каком чате команда может обсудить решение. Это самые важные детали, которые позволят в любой момент вернуться к письму и увидеть, что произошло и кто за что отвечает, пока инцидент не исчерпан.
