Петля страха

Как только вы начали бояться своей технологии, вскоре появятся новые причины для страха.

Петля страха затягивается так:

1. Небольшие правки приводят к непредсказуемым, пугающим или дорогостоящим последствиям.
2. Мы начинаем бояться изменений.
3. Мы стараемся делать все правки как можно более мелкими и локальными.
4. Кодовая база наполняется заплатками, исключениями и особыми случаями.
5. Страх усиливается.

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

Возникла такая нервотрёпка, потому что разработчик не смог предсказать все последствия изменения. Возможно, набор тестов был недостаточным. Или всплыл особый случай, который наблюдается только в продакшне. (Например, у единственного клиента, чьи настройки данных отличаются от всех остальных). Какова бы ни была конкретная причина, результат такой: «Я не знал, что это произойдёт».

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

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

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

Переломный момент

Это может закончиться тремя способами:

1. Кардинальный рефакторинг кода (обычно с другой командой) под девизом «уж теперь мы сделаем это правильно!» См. также: синдром второй системы ^[1] и «Что никогда нельзя делать, часть I» ^[2].
2. Масштабный аутсорсинг.
3. Продажа поражённых активов другой компании.

Как избежать петли

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

Трибунал — худшая реакция на неудачу.

Разница между «техническим спецназом» и трибуналом заключается в том, как конкретные люди подходят к этой проблеме. Чтобы избежать петли страха, требуется мудрое руководство. Ищите людей с опытом работы в DevOps и управлении техническими проектами.

Как разорвать петлю

Как и многие петли с подкреплением, цикл страха невероятно трудно разорвать. До сих пор я не наблюдал ни одного случая успешного выхода из него. Если он начался в вашей компании, то очень хотелось бы услышать о вашем опыте!

Автор: m1rko

Источник ^[3]