Столкнулся недавно с идеей «Zero Bug Policy» (ZBP). Речь про политику нулевой терпимости к багам. Концепция простая: увидел баг — бросай всё и чини. Звучит как мечта: ошибки все исправлены, релизы предсказуемы, клиенты счастливы, а техподдержка пьет смузи(ю) 🙂

Но мой опыт показывает, что такие идеалистичные лозунги часто ведут в ад переработок и демотивации. Давайте разберемся, почему Zero Bug Policy — это чаще всего утопия, которая может навредить бизнесу больше, чем помочь.

Сладкая ложь Zero Bug Policy

На бумаге все выглядит идеально:

• Нашли баг? Все бросаем и чиним. Никаких новых фич, пока в бэклоге есть хоть одна ошибка.
• Результат? Код всегда в идеальном состоянии. Качество продукта стремится к 100%.

Звучит как мечта любого IT-директора. Но дьявол, как всегда, в деталях.

Почему это почти никогда не работает. Cуровая реальность

1. Экономика против перфекционизма. Представьте, что вы делаете уборку в квартире. Убрать 95% грязи относительно быстро и легко. А вот вычистить оставшиеся 5% проблемно. Пыль за шкафом, налет на кране в труднодоступном месте займет столько же времени, сколько вся предыдущая уборка.

В разработке тот же принцип Парето, только в кубе. Исправление 80% багов занимает 20% времени. А вот охота за последними, редкими и трудновоспроизводимыми ошибками — это колоссальные затраты. Стоит ли неделя работы дорогого разработчика исправления бага, который возникает у одного пользователя из тысячи при специфическом стечении обстоятельств? С точки зрения бизнеса, думаю почти никогда.

2. Что вообще считать «багом»? Вот тут и начинается самое интересное.

• Опечатка на кнопке это баг?
• Неидеальное выравнивание элемента на странице при разрешении экрана 1366×768 тоже баг?
• Отсутствие валидации на редко используемом поле точно баг?

Если команда обязана исправлять всё, она утонет в мелочах. Разработчики будут тратить время на косметику, вместо того чтобы пилить фичи, которые приносят деньги. Бизнес за это спасибо точно не скажет.

3. Цена промедления. Пока ваша команда гоняется за съехавшей кнопкой, конкуренты выкатывают новые функции и захватывают рынок. ZBP замедляет разработку. Бизнес теряет не только деньги на зарплатах разработчиков-перфекционистов, но и упущенную выгоду.

Здравый смысл вместо утопии. Сортируем баги

Вместо лозунга «ноль багов» зрелые компании используют прагматичный подход — систему приоритетов и оценку критичности. Можно использовать что-то типа матрицы Эйзенхауэра но для багов:

• Критический: Ошибка, блокирующая основную функциональность. Пользователь не может выполнить ключевой сценарий (например, оплатить заказ). Реакция: Бросаем всё, чиним немедленно. Релиз без исправления невозможен.
• Серьезный: Серьезная ошибка, которая нарушает некритичную функциональность или не имеющая простого обходного пути. Реакция: Должна быть исправлена в ближайшем релизе.
• Незначительный: незначительная проблема, которая не мешает работе, но создает неудобство. Есть обходной путь. Реакция: Исправляется, когда есть свободные ресурсы.
• Косметический: Косметическая ошибка: опечатка, съехавший элемент интерфейса. Реакция: Попадают в бэклог и исправляются «пачкой» раз в квартал или когда совсем нечем заняться.

Такой подход позволяет принимать экономически взвешенные решения. Мы не игнорируем баги, мы управляем ими, соотнося затраты на исправление с потенциальным ущербом для бизнеса.

Когда ZBP все-таки имеет смысл?

Но не все так однозначно как я написал. Есть области, где цена ошибки — это человеческая жизнь или миллионные финансовые потери. Софт для кардиостимуляторов, автопилотов, систем управления АЭС или банковского процессинга. Там ZBP вовсе не прихоть, а жизненная необходимость, подкрепленная соответствующими бюджетами, сроками и процессами (например, многоуровневым тестированием и формальной верификацией).

Но давайте будем честны, большинство из нас не пишет софт для NASA. Наша задача — создавать ценность для бизнеса, а не стремиться к недостижимому идеалу.

Вывод: Zero Bug Policy красивая, но опасная идея для большинства IT-компаний. Она подменяет цель (создание работающего и прибыльного продукта) средством (достижение стерильного кода). Гораздо эффективнее внедрить четкую систему классификации багов и принимать решения, основанные на здравом смысле и экономике.

А как у вас в компаниях? Пытались внедрить Zero Bug? Или сразу пришли к системе приоритетов? Делитесь опытом и подводными камнями в комментариях.