|
Professor Seleznov
|
Баги — неизбежная часть разработки.
В этой статье расскажу наш опыт: как мы внедрили Zero Bug Policy в MetaMap (B2B fintech, ~200 человек в IT, распределённая команда, скоринг благонадежности заёмщиков через ML) и за месяц сократили бэклог с 77 до 18 багов. А главное — как это изменило культуру и отношения с клиентами.
Проблема: баги по принципу «кто громче»
До внедрения политики баги приоритизировались хаотично:
- По громкости — кто из клиентов громче кричит, тот и получает фиксы
- По ARR (Annual Recurring Revenue) — крупный клиент = высокий приоритет (даже если баг минорный)
- По срочности — всё, что звучит срочно, становится срочным
Мы активно масштабировали организацию и росли с 50 до 500 человек после раунда инвестиций. В итоге довольно быстро получили проблемы такого подхода:
- Support и CSM (customer success managers) не могли дать клиентам внятные сроки
- Разработчики постоянно переключались между задачами
- Баги без «громкого» владельца могли копиться месяцами
- 60 из 77 багов не имели даже примерной даты исправления
Это типичная ситуация в растущих продуктовых компаниях. Пока команда маленькая, всё держится на личных договорённостях. При масштабировании система ломается.
Решение: Zero Bug Policy
В итоге мы пришли к тому, что хотим попробовать Zero Bug Policy - это системный подход к обработке багов с гарантированными SLA.
Ключевые принципы
1. Каждый баг имеет Due Date или ETA for ETA
Нет такого понятия как «баг без даты». Если не можем дать точную дату — даём дату, когда дадим дату (ETA for ETA). Это критично для коммуникации с клиентами.
2. Приоритеты определяют скорость реакции
Триажирование - процесс назначения отвественной команды на багу и проставления сроков фикса (самого срока или даты, когда соориентируем клиента).
| Приоритет |
Триаж |
Взять в работу |
Проставить Due Date |
| Critical |
Немедленно (в рабочее время) |
< 2 рабочих дней |
< 2 рабочих дней |
| Moderate |
< 48 часов |
≤ 20 рабочих дней |
≤ 10 рабочих дней |
Вот еще что важно проговорить: 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. Правило двух спринтов
Если бэклог багов не очищается за 2 спринта — останавливаем новые фичи и фокусируемся на багах. Это жёсткое правило, которое заставляет команду не накапливать долг.
Внедрение: 4 фазы за месяц
Фаза 1: Инвентаризация (неделя 1)
Прошлись по всему бэклогу багов:
- Каждому багу присвоили приоритет (Critical / Moderate) или закрыли
- Каждому багу присвоили владельца (удобно вешать на лидеров команд)
- Каждому багу дали Due Date или ETA for ETA
Что обнаружили: 60 из 77 багов не имели никаких сроков. Многие висели месяцами без движения.
Фаза 2: Планирование capacity (неделя 1-2)
Согласовали с каждым лидером вертикали (у нас таких было 4):
- 30% capacity на баги — это обязательство
- Баги включены в планирование спринта наравне с фичами
- Sign-Off / подпись (в notion в документе) от всех руководителей
Почему это важно: без формального sign-off команды будут «забывать» про баги в пользу фич.
Народ спрашивал "а как же мы оценим багу, фиг знает что там исправлять". Просто смотрели на время реализации багов и ориентировались на исторические даты (метрики потока - Lead Time + Throughput по багам отлично помогают прогнозировать).
Фаза 3: Bug Squashing (недели 2-4)
Интенсивная работа по сокращению бэклога:
- Недельный burndown chart (цель: -25% от изначального количества багов каждую неделю)
- Все новые баги проходят триажирование в течение 48 часов
- Еженедельная коммуникация на All Hands
Результат к концу месяца:
- 77 → 18 багов в бэклоге
- 60 → 11 багов без Due Date
Фаза 4: Sustain (ongoing)
Переход в режим поддержания:
- SLA мониторинг (должны факапить не больше 10%)
- Смотрим на месячные тренды (сколько приходит багов, сколько остается)
- Изменения размера бэклога багов (месяц к месяцу) ≤ 10%Особые случаи
Особые случаи
ML и Data Science баги
ML баги — отдельная история. Нельзя «пофиксить» модель для одного edge case без риска сломать другие.
Наш подход:
- Если это software issue (код) — обрабатываем как обычный баг
- Если это бага , связанная с поведением модели — создаём Research-задачу
- Research планируется в следующий спринт
- После research даём ETA for ETA
Это позволяет не обещать невозможного, но и не игнорировать проблему.
Won't Fix
Не все баги нужно чинить. Если баг в неподдерживаемом продукте или регионе:
- Status: Closed
- Resolution: Won't Fix
- Коммуникация клиенту с объяснением
Прозрачность ВСЕГДА важнее, чем попытка угодить всем.
Переоткрытие
Если клиент даёт разумный контекст, почему баг критичен — переоткрытие разрешено. Но это исключение.
Метрики успеха
Все приоритеты:
- Количество созданных багов: Trend не растёт месяц-к-месяцу
- Отклонение в размере бэклога багов ≤ 10%
- Изменения Due Date > +1 неделя - должно стать на 50% реже
Critical-приоритет:
- Взять в работу < за 2 рабочих дня
- Дать Due Date < за 2 рабочих дня
Moderate:
- Взять в работу ≤ 20 рабочих дней
- Дать Due Date ≤ 10 рабочих дней
Трекинг метрик
Еженедельно:
- Пробитие SLA breach (триажирование в течение 48-hour , SLA на взятие в работу)
- Сколько раз промахивались по Due Date
- Общее количество багов против того, можем ли мы это покрыть 30% ёмкостью
Ежемесячно:
- Анализ трендов роста количества багов
- Здоровье беклога багов (закрывается больше или столько же, чем приходит новых)
Связь с эффективностью команды
Zero Bug Policy — это не изолированная практика. Она работает в контексте эффективности команды.
- Zero Bug Policy работает, когда качество — стратегический приоритет. Если руководство говорит «фичи важнее» — эта практика умрёт. Хотя как только активно начнут отваливаться клиенты и вы начнете терять деньги, вы сразу задумаетесь о качестве.
- Это инструмент предсказуемости. Клиент знает, когда будет фикс. Команда знает, сколько ёмкости уходит на баги.
- Политика работает только при психологической безопасности. Если разработчики боятся признавать баги — они будут их скрывать.
Бизнес-результат
Для нас главным результатом стало изменение культуры:
- Support и CSM получили инструмент — они могут давать клиентам реальные сроки
- Разработчики получили ясность — понятно, что и когда чинить
- Клиенты получили предсказуемость — даже если фикс бага не завтра, они знают когда. Чаще всего клиентам не надо фиксы как можно раньше, им важнее что они знают что баги пофиксят в оговоренное время.
Заключение
Zero Bug Policy - это про системный подход и предсказуемость. Это про доверие и прозрачность перед клиентами.
Но цифры — следствие. Основная причина — изменение культуры: высокое качество и быстрое реагирование стало частью нашей прозрачности и обязательств перед клиентами (что потом повысило NPS на 15%).
Ссылки
О Zero Bug Policy, метриках потока и управлении качеством я пишу в своём Telegram-канале.-Источник
|
|
|
