Когда сообщать о своей ошибке
Сообщать о найденной ошибке бывает нужно раньше, чем удастся объяснить её причину. Я ориентировался бы на то, должны ли другие уже сейчас изменить свои действия: остановить запуск, перестать доверять данным или помочь с восстановлением. Ожидание готового исправления оставляет их работать без сведений, которые у нас уже есть.
Например, импорт обновляет заявки из внешней системы, а комментарии к ним дописывают вручную. После изменения импорт начал заменять некоторые комментарии пустыми строками. Разработчик заметил два случая, но ещё не знает, сколько заявок затронуто и получится ли вернуть содержимое.
Пока он ищет причину, кто-то может повторно запустить импорт и потерять ещё часть данных. Или попросить заново прислать сведения, которые пока удаётся восстановить. Этих последствий уже достаточно для предупреждения. При этом два найденных случая ещё не позволяют назвать полный масштаб ошибки или уверенно связать её с последним изменением.
Что написать в первом сообщении
«Кажется, я всё сломал. Сейчас разбираюсь» передаёт состояние автора, но почти ничего не объясняет остальным. Можно ли продолжать работу? Опасно ли запускать импорт? Кто может помочь? Прежде чем действовать, придётся обо всём расспросить.
Для нашего примера полезнее такое сообщение:
В двух заявках пропали ручные комментарии после утреннего импорта. Сегодня я менял этот код, проверяю связь с изменением. Автоматические запуски отключил, работающих импортов сейчас нет; вручную пока тоже не запускайте. Сколько заявок затронуто и можно ли вернуть комментарии, ещё не знаю. К 10:40 напишу, что удалось проверить.
Сначала понятно, что произошло с данными и какое действие опасно повторять. Разработчик не скрывает своего участия, но и не объявляет связь с изменением доказанной.
«В двух заявках» означает два найденных случая. Это не то же самое, что «пострадали только две»: для второго утверждения пришлось бы проверить всё остальное. Одно слово «только» может дать основание продолжить работу там, где её ещё стоит остановить.
Время следующего сообщения тоже не означает срок исправления. К 10:40 можно рассказать, что удалось выяснить, даже если причина ещё не найдена. А подробную историю изменения кода пока стоит оставить для последующего разбора. Сейчас важнее понять, можно ли пользоваться данными и что уже остановлено.
Кто должен увидеть предупреждение
Сообщения в общем чате недостаточно, если люди, которым оно нужно, его не прочитали. В нашем примере это прежде всего тот, кто запускает импорт вручную. Я бы обратился к нему отдельно и попросил подтвердить, что предупреждение получено.
Если импорт ещё выполняется, а у автора изменения нет доступа для остановки, первое сообщение будет другим. Тому, кто может его остановить, нужно написать прямо:
Импорт продолжает выполняться, остановить его сам не могу. Можешь отключить следующие автоматические запуски и помочь безопасно остановить текущий? Напиши здесь, что уже остановлено. Пока проверяю, какие комментарии уже изменились.
До подтверждения нельзя сообщать остальным, что импорт остановлен. Просьба ещё не стала выполненным действием, а отключение следующих запусков само по себе не останавливает текущий. Если сообщение не читают, понадобится тот способ связи, которым в команде пользуются для срочных вопросов.
Руководителю может понадобиться знать об ошибке по другой причине: пока разработчик восстанавливает данные, ранее обещанная задача не движется. Тем, кто ждёт её результата, тоже нужно пересмотреть планы. Молчание не сохраняет прежнего срока.
Как попросить помощь
После первого предупреждения хочется сделать всё самому: код мой, ошибка, вероятно, тоже моя. Но здесь нужно одновременно проверить импорт и найти прежние комментарии. Знание изменённой функции ещё не означает, что разработчик лучше всех разберётся с восстановлением данных.
К тому, кто знает, где искать прежние данные, можно обратиться так:
Нашёл место, которое записывает пустой комментарий, если во входных данных нет поля. Проверяю, какие заявки прошли через этот код. Помоги найти прежние значения до утреннего запуска. Пока ничего не восстанавливай поверх текущих записей, сначала сравним изменения.
Последняя просьба существенна: после импорта в заявках могли появиться новые комментарии. Если заменить их старой копией, появится ещё одна потеря данных.
Здесь понятно, какую часть проверки разработчик оставляет себе и с чем просит помочь. Если помощь пока недоступна, это повод обсудить с руководителем, какую другую работу можно отложить.
К 10:40 новых подтверждённых случаев может не быть. Но обещанное сообщение всё равно нужно:
По ручным запускам ещё собираем данные, поэтому число затронутых заявок пока не уточняю. Проверка исправления ещё не закончена: пока проверили только найденный случай, импорт остаётся выключенным. Прежние комментарии ищем отдельно. В 11:20 напишу о ходе проверки и восстановления.
Теперь ясно, что уже проверили и почему импорт ещё нельзя включать. «В процессе» не дало бы этой информации.
Если прежняя оценка была неверной
Допустим, разработчик проверил утренний запуск и написал: «Нашёл 24 заявки, остальные не затронуты». Затем обнаружился пустой комментарий после ручного импорта.
Недостаточно молча поправить первое сообщение. Его уже могли прочитать, пересказать и использовать в работе. Исправление должно дойти до тех же людей:
Исправляю своё сообщение про остальные заявки: я проверил только утренний запуск и преждевременно сделал вывод обо всех данных. Нашлась ещё одна затронутая заявка после ручного импорта. Проверяем все запуски новой версии. Число 24 пока не описывает полный масштаб проблемы.
Это ещё одна собственная ошибка, уже в оценке. Её можно назвать прямо, без длинного самообвинения: отозвать неверный вывод и объяснить, что теперь проверяют.
Новый случай пока не доказывает, что пострадала каждая заявка. Если заменить «остальные не затронуты» на «значит, потеряли всё», уверенная догадка останется догадкой. Лучше отделить найденные случаи от тех, о которых ещё ничего не известно.
Что именно исправлено
Починка кода не возвращает потерянные комментарии. Сообщение «всё исправил» может закрыть вопрос раньше, чем закончится работа с последствиями.
В нашем условном примере итог мог бы выглядеть так:
Проверили все запуски новой версии и нашли 31 заявку с потерянными комментариями. Прежний текст удалось вернуть в 29. В двух заявках старых значений не нашли; с теми, кто их ведёт, договорились восстановить сведения отдельно. Новые комментарии, написанные после импорта, сохранили. Исправленный импорт запустили на проверенном наборе, затем включили обычный запуск.
По такому сообщению понятно, что удалось вернуть и где работа продолжается. Две заявки не исчезли за общим словом «исправлено». Оставшуюся работу действительно взяли на себя, а не просто получили пересланное сообщение.
Извинение можно написать рядом: «Из-за моего изменения часть комментариев потерялась. Простите, что добавил вам эту работу». Теперь связь с изменением подтверждена. Извинение не заменяет сведений о данных, но подробный технический отчёт тоже не отменяет того, что другим пришлось потратить время на последствия.
К чему вернуться после восстановления
Когда срочная работа закончилась, можно разобраться с исходным решением. В нашем случае разработчик предположил, что отсутствие поля в импорте означает пустой комментарий. Это поведение не проверили на заявке, куда текст дописали вручную.
Я бы начал с собственного выбора: «Я решил сохранять пустую строку и не проверил, что произойдёт с ручным текстом». Затем уже выяснял бы, где должно было быть описано правило и почему тестовые заявки не помогли заметить ошибку.
Если правило нигде не записано, а тестовые данные всегда создавались без комментариев, обещание «буду внимательнее» их не изменит. После разбора нужно добавить пропущенный случай в проверку и определить поведение отсутствующего поля. Это не отменяет участия автора изменения, но и не сводит всё объяснение к его невнимательности.
Хорошая формулировка не гарантирует спокойной реакции на ошибку. Если писать в общий чат трудно, можно сначала обратиться напрямую к тому, кто способен помочь остановить импорт и сохранить данные. Для этого ему нужно знать о случившемся, даже пока вы не готовы обсуждать свою ошибку со всей командой.
Первое сообщение часто труднее всего отправить именно потому, что в нём ещё нет решения. Хочется вернуться уже с исправлением. Но пока мы его готовим, кто-то может запустить импорт снова. Предупредить об этом нужно раньше.