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

На высоком уровне (по крайней мере, в моих глазах) это защитный механизм. «Если происходит что-то плохое и это не связано со мной, значит, я в безопасности». Конечно, я полагаю, что в какой-то степени это правильно, но при этом отсутствует вся суть команды. Мы выигрываем как команда, и мы проигрываем как команда. Есть несколько причин, по которым разработка программного обеспечения является командным видом спорта, я перечислю некоторые из них:

  • Мы можем сотрудничать в разработке кода, две головы лучше, чем одна.
  • Если люди застряли, иногда полезно поговорить об этом с другими.
  • Другие люди, возможно, пробовали подобное в прошлом, но это не сработало, они могут объяснить, почему.

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

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

Я до сих пор помню один день в офисе, когда в систему закралась ошибка загрузки данных. По сути, у нас было два изменения, которые были в очень похожих областях (не помогает то, что они были в пакетах SSIS, которые невозможно объединить). Как только они были объединены в основную ветвь, сборка/автоматизированные тестовые прогоны загрузки данных начали давать сбой. Итак, во-первых, это здорово! Наша автоматизация обнаружила проблему до того, как она попала в производство. А потом случилась игра в обвинения. Поскольку эти два человека были в двух разных спринтерских командах, это стало чем-то вроде политики «кто это сделал, ты должен это исправить». Хуже всего было то, что разработчик, который обвинял меня, чувствовал, что жаждет крови, цель атаки, мой товарищ по команде, который был гораздо более тихим разработчиком, поэтому они не защищались. Они потерпели поражение и были разбиты.

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

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

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

Первоначально опубликовано на https://blog.judd.dev.