На вопрос “А у вас сервис — качественный?” можно получить совершенно разные ответы:
- от разработчиков можно услышать: “ничего критичного нет, остались минорчики”;
- тестировщик возразит, что “у нас куча багов, которые не пофикшены с прошлого релиза”;
- менеджер пожмет плечами: “основное работает, нам нужно новые фичи зарелизить”.
Налицо “конфликт” субъективных мнений. Нетривиально понять, сколько времени нужно тратить на фиксы багов, а сколько — на дальнейшее развитие сервисов.
На помощь приходит метрика Zero Bug Policy (ZBP) с очень простой идеей:
- Каждому открытому багу выставляется вес согласно критериям.
- Подсчитывается сумма всех весов.
- Каждый день значение пересчитывается, и рисуется график суммы багов сервиса.
- На графике проводится горизонтальная линия “максимальной забагованности”, которую нельзя пересекать.
Если график ZBP превысил допустимый уровень забагованности, то выделяется больше времени на фикс багов. Если график ZBP в пределах нормы, то можно спокойно пилить фичи.
В простейшем случае в качестве критериев для выставления весов может использоваться приоритет багов:
- низкий — 1
- средний — 10
- критичный — 100
- блокер — 1000
Но лучше для разметки весов использовать более бизнес-ориентированные компоненты: важность юзкейса, процент затрагиваемых пользователей, “дыры” в безопасности, влияние на деньги и т.д.
А приоритет бага выставлять уже в зависимости от накопленного веса. Тогда будет меньше споров, почему один баг — минорный, а другой — критичный.
Невозможно найти все баги, и часть из них проскакивает наружу. Поэтому мы дополнительно считаем процент багов, найденных коллегами. Стремимся, чтобы этот процент был минимален :)
И отдельно, конечно, читаем фидбек и жалобы наших пользователей. У нашей команды саппорта также есть ряд метрик по скорости первого ответа, скорости решения проблем пользователей и т.д.
DORA советует:
- внимательно относиться к фидбеку пользователей
- подключать службу безопасности на ранних этапах