Принцип "No Known Bugs", он же "Zero Bug Policy"

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

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

👉Дисциплина. Как только вы начинаете отдавать приоритет вообще всем багам, даже в том случае, когда появляются споры, баг ли это или фича, приходится тратить меньше когнитивных усилий на принятие решения о приоритизации.
👉Нужно держать перед глазами конечную цель. Она не в скорости закрытия багов, а в том, чтобы система, за которую вы отвечаете, была качественной, и вы могли бы строить поверх нее новые фичи с уверенностью.
👉Рефрейминг – относиться к багам как к незапланированным продуктовым улучшениям. Ведь любой баг – это отклонение системы от идеального поведения, а значит его исправление – приближение ее к этому поведению, следовательно улучшение. Таким образом приоритизация между багами и фичами превращается в то, что в приоритизированный заранее бэклог продуктовых улучшений периодически прилетают незапланированные, которые по умолчанию оказываются сверху списка. Такая вот ментальная бухгалтерия.

Один из главных плюсов такого подхода – повышение мотивации команды инвестировать в практики, ведущие к повышению качества: лучшее понимание пользователя, автоматизация, architecture decision records, грамотная декомпозиция.