Чинить нельзя откладывать: как мы приоритизируем баги в B2B-продукте

Привет, Хабр! В одной из прошлых статей мы рассказывали, какие фреймворки приоритизации бэклога фич существуют и почему в итоге запилили свой. Сегодня поговорим про вторую сторону медали: баги.

Если для оценки фич индустрия создала десятки методов (от RICE до MoSCoW и WSJF), то с багами все скромнее: общепринятых подходов сравнительно немного,  и нам в итоге они не подошли.

У нас зрелые B2B-продукты, крупные корпоративные клиенты и высокие требования к качеству релизов. Поэтому пришлось эволюционировать: от стандартных матриц мы постепенно дошли до собственной короткой формулы, которая сегодня закрывает большинство кейсов на тимлидерских встречах по релизу.

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

Обзор существующих подходов к приоритизации багов

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

• Атрибуты Severity и Priority

Самый частый подход. У бага заполняются два атрибута: Severity (насколько серьезно баг ломает систему) и Priority (насколько срочно его чинить). Значения обычно от High и Low. Итоговый приоритет либо вычисляется через матрицу сопоставления, либо просто перемножением двух показателей.

• Ручной триаж

Багам присваивают категории — например, от P0 («бросить все и чинить сейчас») до P4 («самый низкий приоритет»). Распределение происходит на основе внутренних методичек команды. Просто, но сильно зависит от опыта и здравого смысла того, кто триажит.

• Фреймворки для фич, адаптированные под баги

Иногда к багам применяют MoSCoW, KANO, RICE или WSJF. Это требует адаптации, потому что методы изначально создавались для оценки новой функциональности и плохо учитывают специфику поломок (например, наличие обходного пути или то, что баг — это «откат», а не новая ценность).

• Оценка ценности и рисков

Подсчет ROI, матрицы «ценность vs трудозатраты» или оценка рисков, где серьезность бага умножается на частоту его возникновения.

Для нашего продукта ни один из подходов в чистом виде не подошел: B2B-специфика, крупные заказчики, эскалации от поддержки и необходимость быстро принимать решения на релизных встречах требовали чего-то более компактного и однозначного. Так появилась первая версия нашей формулы.

Изначальная формула приоритизации багов

На скорую руку мы внедрили простой подход: оцениваем баг по трем параметрам и складываем. Чем меньше итоговая сумма, тем выше приоритет.

• Regress — это регресс или нет: 0 (это регресс, раньше работало) / 1 (не регресс).

• Reach — охват пользователей: 0 (более 5 клиентов) / 1 (от 2 до 5 клиентов) / 2 (предположительно почти никого не затрагивает).

• Criticality — критичность: 0 (нельзя пользоваться продуктом) / 1 (есть обход) / 2 (всем все равно).

По первым буквам параметров — Regress, Reach, Criticality — формула получила внутреннее название RRC.

Под «пользователем» здесь и далее мы понимаем компанию-клиента, которая купила продукт.

Пример

Продукт некачественно распознает текст, напечатанный редким декоративным шрифтом. Клиент в тикете подчеркивает, что в предыдущих релизах качество распознавания было выше, прикладывает скриншоты. Жалоба пока только от одного клиента, формально обход есть (можно поправить вручную). Но по сути программа не выполняет свою основную функцию, поэтому считаем, что обхода нет.

• Regress = 0 (раньше работало)

• Reach = 2 (только один клиент)

• Criticality = 0 (фактически обхода нет)

Итог: 0 + 2 + 0 = 2.

Звучит логично, но в реальной работе у формулы быстро обнаружились слабые места. Тестировщики использовали ее неохотно: подавляющее большинство багов QA находят сами в процессе работы, и реальной статистикой потенциального охвата владеет в основном техподдержка. Поэтому Reach приходилось ставить наугад. А еще формула никак не выделяла случай, когда баг прилетает напрямую от крупного клиента с эскалацией — а это для B2B критично.

Альтернативная формула SWDBE (которую мы не приняли)

Параллельно продуктовая команда предложила свой вариант: формулу, которая должна была учесть интересы крупных клиентов и сложность исправления. Назвали ее SWDBE по первым буквам параметров:

• Severity — 1–13 баллов, где 1 — минорная ошибка и значение по умолчанию, а 13 означает поломку ключевого сценария и невозможность пользоваться продуктом;

• Workaround — 0.5 или 1 (есть ли обход);

• Demand — 1–3 (запросов от клиентов нет или есть от двух и более);

• Blocker — 1 или 2 (где 1 — не блокер, 2 — блокер у одного или нескольких клиентов. Этот параметр выставляет продакт);

• Effort — 0,5, 1 или 2 (где 0,5 — ошибка, которую можно поправить за 15 минут, 2 — ошибка, сопоставимая с полным рефакторингом кода одного из компонентов продукта. Этот параметр выставляет разработчик).

Итоговый балл: произведение первых четырех параметров делится на Effort. Порог качества продукта оценивался в 5 баллов.

Вот как выглядит сопоставление одного подхода с другим 

Идея в целом хорошая, но команда от нее отказалась. Слишком много переменных, дроби, параметры из разных команд (продакт, разработка, QA) — для повседневной приоритизации багов это превращалось бы в долгое и нудноватое расставление приоритетов вручную.

Новая формула RRC: что изменилось

В итоге мы пошли по пути доработки первой версии, а не построения чего-то принципиально нового. Получилось вот что.

Regress — оставили как есть:

• 0 — это регресс

• 1 — это НЕ регресс

Reach — переформулировали градации, чтобы тестировщикам было проще ставить значение без обращения в техподдержку, и добавили специальное значение для эскалаций:

• 0 — встретится больше чем у половины пользователей

• 1 — меньше половины пользователей заметят это

• 2 — редкий дефект (никто не заметит)

• −3 — эскалация от клиента

Criticality — упростили до двух состояний, убрав «всем все равно» (этот случай и так покрывается через Reach):

• 0 — сломан ключевой сценарий работы

• 1 — сломан один из редких сценариев работы

Главное нововведение — значение «−3» для эскалации. Если крупный клиент сообщает о критической проблеме, итоговая сумма уходит в минус, и баг автоматически перебивает по приоритету любые внутренне найденные дефекты. Это снимает с тестировщиков необходимость гадать про охват и одновременно фиксирует наш B2B-приоритет: критическая ситуация у клиента для нас важнее.

Сравнение версий

По первым буквам параметров — Regress, Reach, Criticality — формула получила внутреннее название RRC.

Как это работает на практике

Обновленная матрица оценок здорово сократила время на обсуждение состава релизов. Быстро принимаются решения по большинству некритичных багов, а углубленные обсуждения остаются только на действительно критичных.

• баги с RRC = 0 (или меньше) — обязательный фикс к релизу;

• баги с RRC = 4 — откладываются «до лучших времен»;

• все, что между, разбирается точечно.

Дополнительный бонус в том, что формулу легко превратить в формальный критерий качества релиза. Например, «все баги с RRC ≤ 1 должны быть закрыты до релиза». Это переносит субъективные споры из плоскости «мне кажется, надо чинить» в плоскость «вот конкретная цифра, фиксим или нет?».

Плюсы и минусы

Плюсы:

• прозрачный механизм эскалации быстро гасит долгие споры между QA, разработкой и продактами

• формула проста в применении, тестировщики калибруются между собой за пару спринтов

• позволяет сформулировать четкие критерии качества для допуска к релизу.

Минус:

• подход узкоспециализирован под конкретный тип продукта — зрелый B2B-инструмент с крупными корпоративными клиентами. Для B2C, ранних стадий продукта или массовых сервисов с миллионной аудиторией формулу пришлось бы серьезно переделывать.

Что в итоге

Главный урок, который мы вынесли из обоих экспериментов (и с фичами, и с багами): универсального фреймворка не существует. Любой метод приоритизации — это инструмент, который должен соответствовать вашему продукту, типу клиентов и стадии зрелости компании. Иногда лучшее решение — взять простую базовую конструкцию и доработать ее под себя, а не городить сложную систему с десятком переменных.