Теория разбитых окон, успешно обработанная на преступности в NY, показывает как системное исправление мелких проблем позволяет кардинально улучшить качество ситуации. В истории с “разбитыми окнами” для улучшения ситуации в целом начали с исправления мелких нарушений.
Насколько это важно в программном проекте? Давайте сначала определим разбитые окна в программном проекте:
- Неэффективный код — код который выполняется заметно медленно, не оптимальный
- Код без проверки ошибок — быстрое решение на “авось”
- Сознательный выпуск не проверенного решения — никто не тестировал, вроде работает
- Постоянное накопление технического долга без возврата к решению долга
- Отсутствие автоматизации, все на ручнике
Попускательство в каждой такой мелочи создает культуру приемлемости жизни в проекте с разбитыми окнами — грязно и криво — но зато быстренько. Мы такое часто называем “хуяк-хуяк и в продакшен”. Системный выпуск программного обеспечение в условиях разбитых окон – это огромные риски для проекта.
Безусловно мы не можем работать в идеальных условиях — это нормально фиксировать технический долг. Что мы должны делать в ситуации когда нам надо зафиксировать проблему как долг
- Мы должно проговаривать в чем суть проблемы
- Почему мы сейчас принимаем решение отложить эту проблему
- Какие риски связаны с этой проблемой сейчас и почему мы их принимаем
- Когда мы вернемся к решению технического долга
- Мы должны установить рамки дозволенного — что мы допускаем как долг, а что — нет
При этом не допускается чтобы была сформирована среда в которой принимается пониженный стандарт качества — в среде в которой можно создавать сырой продукт.
