Как организовать работу с багами🐛

Несколько стратегий быстрого исправления багов, управления приоритетами и размером бэклога.

Исправление багов — не самое любимое занятие разработчиков. Это сложный процесс, требующий координации действий всех его его участников.

Задумайтесь, как это происходит. Пользователи сообщают о багах в службу поддержки, затем эти баги воспроизводятся тестировщиками, изучаются менеджерами и в итоге направляются инженерам для устранения.

В этот процесс вовлечено множество людей. У каждой команды может быть свой алгоритм работы с багами, но он всегда включает некоторые основные шаги:

1. ✍️ Сообщение о баге — баг заносится в бэклог (или о нем сообщается разработчикам в Slack 🥲).
2. 🚥 Определение приоритета — баг проходит сортировку, ему присваивается приоритет. Это может быть сделано силами QA, PM или инженерами.
3. 🔨 Исправление — баг отправляется инженеру, который его исправляет.

На этих этапах большинство проблем возникает при определении приоритета бага. Кто принимает решение о назначении приоритета? Как при этом избежать конфликтов? Сколько времени мы должны потратить на это? Давайте разберемся. 👇

👥 Заинтересованные стороны

Когда дело доходит до определения важности того или иного бага, у каждой стороны, участвующей в процессе, есть свое видение.

• 🏅 Служба поддержки первая узнает о проблемах пользователей и может предложить обходные пути для их решения.
• 🎨 PM рассматривает, насколько проблема серьезна как для пользователей, так и для бизнеса в целом.
• 🔍 QA интересует, насколько нарушен функционал.
• 🔨 Инженеров заботит, как баг отражается на работе программного обеспечения.

Каждая точка зрения правомерна, они дополняют друг друга, поскольку никто не видит полной картины. Если у вас нет четкого алгоритма действий, это может привести к следующим неприятным последствиям:

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

🎯 Цели

Учитывая все вышеперечисленное, приходим к выводу, что процесс исправления багов должен преследовать две цели:

• Расстановка основных приоритетов — продуктивное общения участников, при котором время не тратится впустую.
• Быстрое исправления багов — порядок выполнения не должен приводить к увеличению времени.

Как достичь этих целей? Вот несколько стратегий. 👇

🔍 Отделяйте серьезность бага от приоритета

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

Приоритет

Приоритет зависит от того, какой вред баг наносит бизнесу. Насколько снижаются доходы? Как баг мешает пользователям?

Приоритет должен быть определен PM при участии службы поддержки, когда пользователи сообщают о сбоях. Во многих статьях вы прочитаете, что приоритет показывает, насколько быстро должен быть исправлен баг. Мне такая трактовка никогда не нравилась, поскольку “быстрее” и “лучше” — не одно и то же. Если вы сосредоточитесь на скорости устранения бага, забывая об общей цели, это плохо скажется на результатах работы.

Серьезность бага \ Severity

Серьезность бага — это то, насколько сильно поврежден функционал и программное обеспечение. Этот интерфейс еще можно использовать? Почему происходит сбой?

Серьезность оценивается QA и инженерами. В первую очередь они должны обращать внимание не на то, насколько актуальна неисправная функция, а на то, как на нее влияет данный конкретный баг. Также инженеры должны определить, не является ли баг симптомом более серьезной ошибки, — возможно, “под капотом” кроется более значительная неисправность, чем кажется.

Процесс

К исправлению бага вам следует приступать после того, как как вы установили его серьезность и приоритет:

1. Высокий приоритет + высокая серьезность — например, не работает функция авторизации и пользователи не могут получить доступ к приложению.
2. Высокий приоритет + низкая серьезность — например, “пользовательское соглашение” недоступно до тех пор, пока пользователи не совершат платеж.
3. Низкий приоритет + высокая серьезность — например, на некоторых устройствах в определенных браузерах не проходит оплата товара.
4. Низкий приоритет + низкая серьезность — например, слишком большая кнопка не вписывается в дизайн.

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

Такой подход работает по двум причинам:

• Разделение ответственности дает возможность избежать конфликтов между бизнес-подразделениями и технической частью команды, поскольку каждая сторона занимается своим делом.
• Точная сортировка позволяет установить единые четкие правила для определения порядка работ при исправлении бага.

📋 Не давайте бэклогу разрастаться

Является ли описанный выше процесс идеальным при исправлении багов? Нет. Но его должно быть достаточно для того, чтобы быстро исправлять ошибки.

Как понять, достаточно ли быстро вы исправляете баги? Простой показатель нормального KPI заключается в том, что бэклог небольшого размера и дальше не растет. Очень важно, чтобы соблюдались оба условия:

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

Возьмите за правило, чтобы объем невыполненной работы был как можно меньше. Большие бэклоги разрушают ощущение, что есть прогресс в работе и демотивируют команду.

Если несмотря на ваши усилия бэклог чрезмерно разрастается, подумайте о том, чтобы объявить, что какие-то проблемы решить не удалось и попросту "сжечь" задачи, которым больше нескольких месяцев. Мысль об этом может вас пугать, но важные проблемы все равно рано или поздно всплывут, поэтому вы не упустите ничего серьезного.

⏱️ Тратьте фиксированное время на поддержку

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

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

Сколько времени вы отведете под эти задачи, решать вам и вашей команде; по моему опыту, многие добивались успеха, выделяя под них 20-30% времени.