# Zero Bug Policy: Как мы сократили бэклог багов с 77 до 18 за 4 недели
Каноническая страница: https://plainews.ru/posts/zero-bug-policy-snizhenie-bekloga
Опубликовано: 2026-05-26T07:02:59.589Z

Узнайте, как внедрить Zero Bug Policy в B2B финтех. Пошаговый гайд по триажированию и сокращению технического долга без срыва релизов.
Ваш бэклог багов — это не список проблем, а показатель системного сбоя в управлении продуктом. Мы внедрили Zero Bug Policy, и за месяц сократили бэклог с 77 до 18 багов, изменив не только метрики, но и корпоративную культуру.

Если вы чувствуете, что команда постоянно «тушит пожары» (firefighting), а стратегические фичи откладываются из-за хаотичного потока багов — этот гайд для вас. Мы разбираем практические шаги, которые превратят хаос в предсказуемый, управляемый процесс.

## Почему «по громкости» — худший способ приоритизации багов

В растущих продуктовых компаниях, особенно в финтехе, баги часто приоритизируются по принципу «кто громче кричит».

В нашей практике это выглядело так:

1. **По клиенту:** «Крупный клиент = баг в приоритете», даже если баг некритичный.
2. **По срочности:** Всё, что кричит «Срочно!», становится срочным, игнорируя фактическую критичность.
3. **По ARR:** Попытка привязать приоритет к суммарному доходу (Annual Recurring Revenue) клиента.

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

**Важно понять:** Ваш бэклог должен управляться не эмоциями и не продажами, а объективной угрозой для способности продукта зарабатывать деньги в следующем квартале.

## 4 столпа Zero Bug Policy: Как превратить хаос в SLA

Zero Bug Policy — это не просто обещание «не иметь багов». Это системный подход к обработке дефектов с жестко заданными Service Level Agreements (SLA). Мы выделили четыре ключевых принципа, которые должны стать законом в вашей команде.

### 1. Каждый баг должен иметь Due Date (или ETA for ETA)

Самая частая ошибка: баг висит в бэклоге без даты. Это не задача, а потенциальная дыра в бюджете.

Внедрите правило: **нет такого понятия, как «баг без даты».** Если вы не можете дать точную дату исправления (Due Date), вы обязаны дать дату, когда вы дадите эту дату (ETA for ETA).

Это критически важно для коммуникации с клиентами. Вместо «Мы посмотрим» вы говорите: «Мы проведем триажирование и дадим вам точную оценку к среде».

### 2. Приоритеты должны быть техническими, а не коммерческими

Мы жестко отбросили привязку приоритета к ARR клиента. Критичность должна определяться технической угрозой:

| Приоритет | Условие (Что это значит) | SLA (Как быстро чинить) | | :--- | :--- | :--- | | **Critical** | Production Down, Data Loss, Security Breach. | Немедленно (в рабочее время) | | **Moderate** | Снижает ключевой функционал, но есть обходные пути. | < 2 рабочих дней | | **Low** | Косметический дефект, не влияет на бизнес-процессы. | Won't Fix (закрываем) |

**Правило:** Если это не угрожает вашей способности зарабатывать деньги в этом месяце, это не *Critical*. Использование этого правила требует дисциплины от менеджеров и продакт-оунеров.

### 3. Фиксированная ёмкость для долга (Capacity)

Нельзя, чтобы работа над багами была «если останется время». Это должна быть константа.

Мы зафиксировали 30% общей емкости команды (capacity) на обработку багов. Эта квота должна быть включена в планирование спринта наравне с новыми фичами.

### 4. Правило двух спринтов

Чтобы избежать накопления технического долга, введите жёсткое правило:

> Если бэклог багов не очищается (или не снижается) за два спринта подряд, **останавливаются все новые фичи**, и вся команда фокусируется исключительно на багах.

Это вынуждает команду системно работать над долгом, а не просто «догонять» поток новых задач.

## Как внедрить Zero Bug Policy: Пошаговый гайд (4 фазы)

Внедрение — это не спринт. Это проект, который занимает 1–2 месяца. Вот как мы прошли путь от хаоса к порядку.

### Фаза 1: Инвентаризация и аудит (Неделя 1)

Ведите единый источник правды (Jira, Notion и т.п.). Цель: присвоить каждому существующему багу метаданные.

**Задача:** Пройтись по всему бэклогу (например, 77 багам). **Действия:**

1. **Присвоить приоритет:** Critical, Moderate или Low.
2. **Назначить владельца:** Лидер команды, который будет отвечать за его фикс.
3. **Установить срок:** Due Date или ETA for ETA.

*Результат:* Вы поймете, сколько багов висят без даты и кто за них отвечает.

### Фаза 2: Планирование Capacity (Недели 1-2)

Это самый важный и сложный этап, потому что он требует официального согласия.

**Задача:** Вписать 30% времени на баги в план спринта. **Действия:**

1. **Согласование:** Проведите встречу со всеми лидерами вертикалей. Установите, что 30% — это обязательное условие.
2. **Оценка:** Используйте исторические данные (Lead Time и Throughput по багам) для оценки объема работы. Не спрашивайте «сколько времени на баг?», спрашивайте «сколько багов мы можем убрать за N дней при выделении 30%?»
3. **Оформление:** Получите формальный Sign-Off (подпись) от всех ключевых стейкхолдеров.

### Фаза 3: Bug Squashing (Недели 2-4)

Переходим в режим активного сжигания долга.

**Действия:**

1. **Burndown Chart:** Создайте еженедельный график, где видно, насколько вы приблизились к цели по сокращению бэклога. Цель: стабильное уменьшение.
2. **Триажирование:** Все новые баги должны проходить триажирование в течение 48 часов. Это гарантирует, что каждый новый дефект попадает в систему с присвоенным приоритетом и датой.
3. **All Hands Communication:** Еженедельно информируйте команду о прогрессе. Это повышает прозрачность и вовлеченность.

### Фаза 4: Sustain (Ongoing)

Zero Bug Policy — это не одноразовая акция. Это операционная модель.

**Метрики для мониторинга:**

- **SLA Compliance:** Процент багов, которые были исправлены в рамках заявленного SLA (должен быть > 90%).
- **Тренд бэклога:** Ежемесячный анализ: сколько багов пришло, сколько ушло, и какой остаток. Изменение размера бэклога должно быть стабильно низким (менее 10% роста).

## Особые случаи: Когда баги не в коде

Иногда «баг» — это не ошибка в коде, а проблема в модели или процессе. Здесь нужна отдельная методология.

### 1. ML-баги и Data Science

Нельзя просто «пофиксить» модель для одного редкого случая (edge case), не рискуя сломать общую стабильность.

**Правильный подход:**

1. **Классификация:** Определите, это *Software Issue* (проблема в коде, API) или *Model Behavior Issue* (проблема в данных/поведении модели).
2. **Research Task:** Если это Model Behavior Issue, не присваивайте ему Due Date. Создайте Research-задачу.
3. **ETA for ETA:** После проведения исследования, дайте клиенту ETA для решения.

### 2. Won't Fix (Не будет исправлено)

Прозрачность — ваш лучший друг. Если баг в устаревающем продукте или не относится к текущей функциональности, не тратьте на него ресурсы.

**Процесс:**

1. **Статус:** Closed.
2. **Резолюция:** Won't Fix.
3. **Коммуникация:** Четко объясните клиенту, почему этот баг не будет исправлен.

## Подводные камни

- **Недостаточное руководство:** Если не закреплено правило о 30% capacity и «Правиле двух спринтов», команда всегда вернется к старой привычке «тушить пожары».
- **Излишний акцент на ARR:** Постоянное использование «Affected ARR» как единственного критерия приоритета ведет к нерациональному выделению ресурсов.
- **Игнорирование ML-слоя:** Попытка «починить» сложную модель как обычный баг приведет к непредсказуемым и дорогим регрессиям.

## Что попробовать дальше

Вместо того чтобы просто чинить баги, начните работать над превентивными мерами:

1. **Автоматизация тестирования:** Инвестируйте в E2E (End-to-End) и интеграционное тестирование, чтобы минимизировать поступление багов в бэклог.
2. **Code Review:** Усильте процесс ревью кода, заставляя разработчиков не просто исправлять, а документировать, почему они это исправили.
3. **Продукт-аналитика:** Используйте данные, чтобы доказать, что баг действительно критичен, а не просто «выглядит плохо» на скриншоте.

## Источники

- Habr ML: Кейс. Zero Bug Policy: как мы снизили бэклог багов в 4 раза за месяц