Если мы посмотрим описание новой версии любого продукта, увидим, что в ней исправлены баги. Но каждый последний исправленный баг — предпоследний. И не важно, это пет-проект студента или продукт бигтеха с командой выпускников MIT.
При этом бизнес резонно ждёт, что софт будет просто работать: мы же четко все описали и спроектировали, почему нельзя сразу сделать без ошибок? Это расхождение в мировоззрении — вечный источник конфликтов между бизнесом и разработкой. Разрешается оно просто: нужно отойти от бинарного «работает / не работает».
Для начала разберемся, почему баги все-таки неизбежны?
Программы в общем выглядят как набор детерминированных инструкций «ЕСЛИ Х, ДЕЛАЙ Y», а вариантов их сочетаний просто прорва. Плюс разные ОС и железо, на которых наш софт работает. И собирается он, кстати, из разного другого софта: библиотек, компонентов, компиляторов и т.д. Проверить все это за разумное время нереально.
Поэтому сводимся к задаче не «доказать отсутствие багов», а выбрать, какие ошибки исключаем и сколько ресурсов на это тратим.
Как говорить об этом с бизнесом?
Стоимость разных классов ошибок можно прикинуть заранее. Разработка легко перечислит возможные риски, а вам нужно их оценить.
Падение прода у крупного e-commerce — это потеря Х миллионов выручки. Баг в возврате товара — просто испорченный клиентский опыт. Обходимая ошибка будет просто раздражать, а вот совсем неработающая фича завалит техподдержку.
📌 Короче: важны не сами баги, а какие они. И каких у нас точно нет.