Меня часто спрашивают...

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

В любом продукте, каким бы замечательным и полезным он не был, есть бэклог багов. Какие-то из них правятся сразу на тестировании, какие-то считаются не критичными и терпеливо ждут своего часа.

Все методы приоритезации мы рассматривать не будем, но поговорим о нескольких популярных методах или всеми любимых фреймворках, итак:

Метод MoSCoW — Must Have (обязательно), Should Have (нужно), Could Have (желательно), Won't Have (можно перенести). «О» тут добавлено для легкого мнемонического запоминания, не ищите смыслы.

Метод определяет 4 группы, где параметры попадания задачи в ту или иную группу задаются на ваше усмотрение. Это может быть влияние на финансовые показатели, путь клиента в продукте, потребности бизнеса и заодно учитывать трудозатраты на исправление: аналитика, дизайн, разработка и т.д.

Must Have — наиболее приоритетные баги, обычно правятся сразу на регрессах/смоуках и не лежат в бэклоге, но бывают исключения.

Should Have — то, что не рушит напрямую путь пользователя, но исправление принесет ощутимую пользу.

Could Have — минорные баги, которые правят по мере появления свободного ресурса команды или в рамках работы над определенной фичой/этапе в продукте.

Won't Have — эти ребята могут жить в бэклогах годами, к примеру небольшие UI-дефекты, аффектящие на малое кол-во пользователей.

Как правило, на работу с багами первой категории рекомендуется тратить не менее 60% багофикс-ресурсов команд, остальные 40% распределяются между тремя категориями.

Такой подход довольно эффективен, но требует четкого определения критериев для каждой категории.

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