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