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

Баги — неизбежная часть разработки.

В MetaMap мы внедрили Zero Bug Policy и за месяц сократили бэклог с 77 до 18 багов. 60 багов из 77 до старта не имели даже примерной даты исправления. Через месяц таких осталось 11.

Главный результат — не красивая цифра. Support и CSM получили реальные сроки для клиентов, разработчики — ясные правила, клиенты — предсказуемость.

Проблема: баги по принципу «кто громче»

До внедрения политики баги приоритизировались хаотично:

• по громкости — кто из клиентов громче кричит, тот и получает фиксы;
• по ARR — крупный клиент получает высокий приоритет, даже если баг минорный;
• по срочности — всё, что звучит срочно, становится срочным.

После раунда инвестиций мы активно масштабировались: организация выросла с 50 до 500 человек. Довольно быстро стали видны проблемы такого подхода:

• Support и CSM не могли дать клиентам внятные сроки;
• разработчики постоянно переключались между задачами;
• баги без «громкого» владельца могли копиться месяцами;
• 60 из 77 багов не имели даже примерной даты исправления.

Это типичная ситуация в растущих продуктовых компаниях. Пока команда маленькая, многое держится на личных договорённостях. При масштабировании такая система ломается.

Решение: Zero Bug Policy

Zero Bug Policy — это системный подход к обработке багов с гарантированными SLA.

1. Каждый баг имеет Due Date или ETA for ETA

Нет понятия «баг без даты». Если мы не можем дать точную дату исправления, даём дату, когда сможем назвать эту дату. Это и есть ETA for ETA.

Для клиента это критично. Ему часто важнее понятная дата и честная коммуникация, чем самый ранний возможный фикс.

2. Приоритеты определяют скорость реакции

Триажирование — это назначение ответственной команды и сроков: либо даты исправления, либо даты, когда команда сможет сориентировать клиента.

Critical — это не «важный клиент». Critical — это production down, data loss, security breach. Всё остальное — Moderate. Мы специально убрали из Jira приоритет Major, чтобы не размывать правила.

Если у бага приоритет Low, мы закрываем его как won't fix. И явно говорим клиентам: этот дефект сейчас не в приоритете; вот список дефектов, которые мы действительно чиним.

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

Я не советую навешивать на баги affected ARR. Продажи быстро посчитают суммарный бюджет всех клиентов, которых баг теоретически затрагивает. При этом сам баг может оставаться некритичным. Объективному триажу это мешает.

3. Фиксированная capacity на баги

30% capacity команды выделяем на баги. Это константа. Moderate-баги попадают в эту квоту.

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

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

Внедрение: 4 фазы за месяц

Фаза 1: инвентаризация

Прошлись по всему бэклогу багов:

• каждому багу присвоили приоритет: Critical, Moderate или закрыть;
• каждому багу назначили владельца — удобно закреплять такие задачи за лидами команд;
• каждому багу дали Due Date или ETA for ETA.

Что обнаружили: 60 из 77 багов не имели никаких сроков. Многие висели месяцами без движения.

Фаза 2: планирование capacity

Согласовали с каждым лидером вертикали:

• 30% capacity на баги — это обязательство;
• баги включаются в планирование спринта наравне с фичами;
• руководители дают формальный sign-off.

Без формального sign-off команды будут «забывать» про баги в пользу фич. Это не злой умысел. Это обычная конкуренция за внимание.

Отдельный вопрос — как оценивать баг, если заранее непонятно, что именно чинить. Мы смотрели на исторические данные по исправлению багов. Метрики потока — Lead Time и Throughput по багам — хорошо помогают прогнозировать такие очереди.

Фаза 3: Bug Squashing

Интенсивная работа по сокращению бэклога:

• недельный burndown chart с целью сокращать изначальный бэклог на 25% каждую неделю;
• все новые баги проходят триажирование в течение 48 часов;
• еженедельная коммуникация на All Hands.

Результат к концу месяца:

• 77 → 18 багов в бэклоге;
• 60 → 11 багов без Due Date.

Фаза 4: Sustain

Дальше политика переходит в режим поддержания:

• SLA-мониторинг: нарушений должно быть не больше 10%;
• месячные тренды: сколько багов приходит и сколько остаётся;
• изменение размера бэклога месяц к месяцу — в пределах 10%.

Особые случаи

ML и Data Science баги

ML-баги — отдельная история. Нельзя «пофиксить» модель для одного edge case без риска сломать другие сценарии.

Наш подход:

• если это software issue в коде — обрабатываем как обычный баг;
• если это баг, связанный с поведением модели, — создаём research-задачу;
• research планируем в следующий спринт;
• после исследования даём ETA for ETA.

Так команда не обещает невозможного и при этом не игнорирует проблему.

Won’t Fix

Не все баги нужно чинить. Если баг относится к неподдерживаемому продукту или региону:

• Status: Closed;
• Resolution: Won’t Fix;
• клиент получает объяснение.

Прозрачность важнее попытки угодить всем.

Переоткрытие

Если клиент даёт разумный контекст, почему баг критичен, его можно переоткрыть. Это исключение, а не второй скрытый процесс приоритизации.

Метрики успеха

Для всех приоритетов:

• количество созданных багов: тренд не растёт месяц к месяцу;
• изменение размера бэклога багов ≤ 10%;
• переносы Due Date больше чем на неделю становятся на 50% реже.

Для Critical:

• взять в работу за 2 рабочих дня или быстрее;
• дать Due Date за 2 рабочих дня или быстрее.

Для Moderate:

• взять в работу ≤ 20 рабочих дней;
• дать Due Date ≤ 10 рабочих дней.

Трекинг метрик

Еженедельно:

• нарушения SLA: триажирование в течение 48 часов и SLA на взятие в работу;
• сколько раз промахнулись по Due Date;
• хватает ли 30% capacity команды на текущее количество багов.

Ежемесячно:

• ретроспектива по трендам в количестве багов;
• поиск системных улучшений;
• здоровье бэклога: закрытых багов должно быть не меньше, чем новых.

Связь с эффективностью команды

Zero Bug Policy — не изолированная практика. Она работает в контексте эффективности команды.

Качество должно быть стратегическим приоритетом. Если руководство говорит «фичи важнее», практика быстро умрёт. Обычно о качестве вспоминают, когда начинают отваливаться клиенты и деньги. Лучше не ждать этого момента.

Это инструмент предсказуемости. Клиент знает, когда будет фикс. Команда знает, сколько ёмкости уходит на баги.

Политика держится на психологической безопасности. Если разработчики боятся признавать баги, они будут их скрывать.

Бизнес-результат

Для нас главным результатом стало изменение культуры:

• Support и CSM получили инструмент — они могут давать клиентам реальные сроки;
• разработчики получили ясность — понятно, что и когда чинить;
• клиенты получили предсказуемость — даже если фикс будет не завтра, они знают дату.

Чаще всего клиентам не нужно, чтобы все баги чинили как можно раньше. Им важнее понимать, что дефект не потеряли и исправят в оговорённое время.

Заключение

Zero Bug Policy — это системный подход к качеству, предсказуемости и прозрачной коммуникации с клиентами.

Цифры 77 → 18 выглядят эффектно. Настоящая причина изменений глубже: высокое качество и быстрое реагирование стали частью обязательств перед клиентами. Позже это подняло NPS на 15%.

Баг без даты — это не технический долг. Это обещание, которое команда пока не произнесла вслух.

Связанные материалы

• Исходная версия кейса на Хабре
• Треугольник эффективности команды — как смотреть на цели, людей и поток вместе
• Monte Carlo Simulation for Throughput Forecasting — как использовать flow-метрики для прогнозирования
• 5 причин, почему Story Points не работают — почему flow-метрики важнее оценок