Как только вы начали бояться своей технологии, вскоре появятся новые причины для страха.
Петля страха затягивается так:
- Небольшие правки приводят к непредсказуемым, пугающим или дорогостоящим последствиям.
- Мы начинаем бояться изменений.
- Мы стараемся делать все правки как можно более мелкими и локальными.
- Кодовая база наполняется заплатками, исключениями и особыми случаями.
- Страх усиливается.
Страх начинается, когда безобидная правка неожиданно вызывает проблему. Даунтайм в продакшне или просто раздражающий баг. Ошибка может привлечь внимание руководства. Ничто так не внушает страх, как заседание директоров по поводу вашего дефекта в коде!
Возникла такая нервотрёпка, потому что разработчик не смог предсказать все последствия изменения. Возможно, набор тестов был недостаточным. Или всплыл особый случай, который наблюдается только в продакшне. (Например, у единственного клиента, чьи настройки данных отличаются от всех остальных). Какова бы ни была конкретная причина, результат такой: «Я не знал, что это произойдёт».
Несколько подобных событий — и вот уже разработчики и менеджеры проектов не хотят ничего трогать за пределами своей узкой сферы. Они прячут голову в песок, как страусы.
Проблема в том, что у такого поведения будут последствия. Неизбежно начнёт ухудшаться кодовая база, нарастать потребность в крупных изменениях и увеличиваться объём рефакторинга в билдах без релиза.
Порочный круг замыкается, когда один из этих страусов становится виновником чужого бага. С этого момента цикл страха становится самоподдерживающимся. Цена даже маленьких изменений продолжает расти без конца. Время, необходимое для выпуска изменений, тоже увеличивается.
Переломный момент
Это может закончиться тремя способами:
- Кардинальный рефакторинг кода (обычно с другой командой) под девизом «уж теперь мы сделаем это правильно!» См. также: синдром второй системы и «Что никогда нельзя делать, часть I».
- Масштабный аутсорсинг.
- Продажа поражённых активов другой компании.
Как избежать петли
Цикл страха начинается, когда люди воспринимают техническую проблему как личную. В первый раз, когда простое изменение кода привело к большим и непредсказуемым последствиям, нужно вызвать «технический спецназ» — команду спецов. Они определят, почему система это позволила и какие технические изменения помогут избежать такого в будущем.
Трибунал — худшая реакция на неудачу.
Разница между «техническим спецназом» и трибуналом заключается в том, как конкретные люди подходят к этой проблеме. Чтобы избежать петли страха, требуется мудрое руководство. Ищите людей с опытом работы в DevOps и управлении техническими проектами.
Как разорвать петлю
Как и многие петли с подкреплением, цикл страха невероятно трудно разорвать. До сих пор я не наблюдал ни одного случая успешного выхода из него. Если он начался в вашей компании, то очень хотелось бы услышать о вашем опыте!
Автор: m1rko
