🚫🐞 Zero Bug Policy: как мы сократили бэклог багов в 4 раза

- Уменьшили бэклог с 77 → 18 багов за месяц.
- 80% всех багов - с датами фиксов, которые сбываются.
- Разбор всех новых багов в течение 2 дней.

📝 Контекст

Кейс с прошлой работы: в MetaMap мы быстро росли. Команд добавлялось, фичей становилось больше, клиентская база расширялась. Бэклог багов рос - 77 открытых, у 60 ни сроков, ни ответственного.

Приоритизировали хаотично:
- кто громче кричит,
- у какого клиента больше ARR,
- насколько панически звучит запрос 😅.

Поддержка не могла обещать клиентам конкретики. Разработка откладывала баги из спринта в спринт (знакомо?). Дефект попадал в бэклог и пропадал куда-то за горизонт событий черной дыры.

⚙ Что сделали

Ввели Zero Bug Policy. Три правила:

• Critical — production down, data loss, security breach. Бросаем всё, чиним сейчас
• Moderate — следующий спринт, 30% capacity
• Low багов нет — мы их сразу закрываем и информируем, почему не будем чинить
• Баг висит > 2 спринтов — останавливаем фичи, разбираемся с долгом

High / Major нет принципиально. Оставили только три уровня

Каждому багу — Due Date или хотя бы «дата, когда мы назовём дату».

Результат

Через месяц: 77 → 18. Поддержка впервые стала говорить клиентам «исправим тогда-то» — и сдерживала слово. Доверие между отделами и пользователями восстановилось.

Наконец-то собрал этот опыт в полноценный пост на Хабре — с механикой, SLA и тем, как это работает на практике. А также как это дело интегрировать в вашу компанию.