Должен ли я отправить письмо с извинениями по электронной почте или мгновенное сообщение после внесения ошибки в продукте?

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

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

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

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

Нет, это была ошибка команды, а не только твоя.

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

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

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

Нет, абсолютно нет.

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

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

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

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

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

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

Другие люди уже сказали, почему вы не должны. Добавлю еще одну причину...

Покажите, чего вы ожидаете от других людей в вашей команде/организации.

Вы ожидаете, что остальная часть вашей команды будет рассылать электронные письма «mea culpa», когда они облажались? Я, конечно, надеюсь, что нет.

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

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

Всегда помните правило 70 : « Неудача — это не вариант, это обязательно. Выбор заключается в том, позволить ли неудаче быть последним, что вы делаете ». Рано или поздно что-то всегда пойдет не так. Что отличает вас и вашу организацию как профессионалов, так это то, как вы справляетесь с неудачами.

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

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

Сейчас думаю о Джиме Кэри в фильме "Лжец, лжец" . 🤡

Не отрицайте, что совершили ошибку, а в остальном просто отпустите ее. Это разработка программного обеспечения, и это чрезвычайно сложная задача. Всем известно, что все делают ошибки. Черт, вы не можете делать это без ошибок ... поэтому кто-то придумал термин: "D'oh!" 🤦‍♂️

Сейчас также хорошее время для небольшого «самоанализа улучшения процессов». Как это произошло? Как эта проблема прошла весь процесс предварительного выпуска и не была обнаружена? Что мы можем теперь сделать с этим предварительным релизом, чтобы такая штука снова не попалась? Обсудите это с командой — совершенно без извинений.

Не повредит сказать: «Извини, мой плохой», но это не помешает тому, чтобы это повторилось.

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

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

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

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

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

Похоже, что это может быть первое, учитывая следующее:

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

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

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

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

Позвольте мне познакомить вас с концепцией Code Golf.

Концепция Code Golf в вопросах, связанных с приведенными выше, заключается в том, чтобы, учитывая пространство задач, решить его с наименьшим количеством байтов. Учитывая язык, используемый в некоторых из этих случаев, их код намеренно более расплывчатый, специально для сохранения байтов информации о размере файла.

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

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

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

TL:ДР; Вы бы извинились, если бы у вас было что-то вроде нестандартного использования GOTO для достижения неясных способов намеренного обхода сред тестирования Dev и QA, чтобы проблема попала в производство, но если это не так, вы должны быть в порядке - все делают ошибки, которые попадают в производство до того, как будут обнаружены хотя бы один раз.