# Приоритизируйте баги по влиянию на пользователя

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/quality-bugs/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/quality-bugs/index.md
- **Раздел:** Качество продукта
- **Время:** 60 минут на первый разбор

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

## Результат

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

## Приоритет — это вред пользователю, а не громкость обсуждения

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

## Что понадобится

- **Доступ:** Crashlytics, AppMetrica или другой отчёт об ошибках плюс текущий список задач в Jira, Linear или таблице.
- **Коллеги:** QA или разработчик и представитель поддержки на 20 минут для подтверждения технического следа и частоты жалоб.
- **Период:** Ошибки, обращения и отзывы за последние 14 дней; отдельно отметьте версии приложения и платформы.

## Термины простыми словами

- **Crash-free rate — Доля пользователей без аварийного закрытия приложения:** Определение: Чем ближе показатель к 100%, тем меньше пользователей столкнулись с вылетом приложения за выбранный период. Пример: Crash-free users 99,5% означает, что 0,5% пользователей столкнулись хотя бы с одним вылетом.
- **ANR — Зависание Android-приложения:** Определение: Android фиксирует ANR, когда интерфейс слишком долго не отвечает на действия пользователя. Пример: Пользователь нажал кнопку, экран завис, и Android предложил закрыть приложение.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

## Когда применять

Backlog растёт, команда спорит о срочности, а в работу попадает последний громкий запрос вместо самой опасной проблемы.

## Где искать подтверждение

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

- **Crash- и ANR-отчёты**
  - **Источник:** Смотрите число затронутых пользователей, версию приложения, устройство, стек ошибки и повторяемость.
  - **Если доступа нет:** Если отчётов нет, попросите разработчика воспроизвести проблему и сохранить видео, логи и условия появления.
- **Поддержка и отзывы**
  - **Источник:** Сгруппируйте обращения по одной причине: вход, статус, платёж, потеря данных, пустой экран или непонятное сообщение.
  - **Если доступа нет:** Если теги не настроены, вручную разберите 30 последних обращений и заведите пять простых категорий.
- **Ключевой сценарий**
  - **Источник:** Сравните успешность действия до и после появления ошибки: вход, регистрация, сохранение, верификация или операция.
  - **Если доступа нет:** Без аналитики проведите десять повторов на затронутой версии и зафиксируйте долю неуспешных попыток.

## Разберите список ошибок за пять шагов

1. **Соберите всё в одну таблицу.** Объедините дубли из crash-отчётов, QA, поддержки и отзывов. Одна пользовательская проблема должна быть одной строкой.
   - **Где сделать:** Jira, Linear или общая таблица с ссылками на исходные сигналы.
   - **Пример:** Три тикета «бесконечный статус», «операция зависла» и «не вижу результат» объединены в одну проблему.
2. **Опишите вред простыми словами.** Запишите, что не может сделать пользователь и что он рискует потерять. Не оставляйте в названии только код ошибки.
   - **Где сделать:** В поле «Влияние на пользователя» каждой задачи.
   - **Пример:** Не «API 504», а «после подтверждения пользователь не видит итоговый статус и повторяет действие».
3. **Подтвердите масштаб.** Укажите число затронутых людей, платформу, версию, частоту и период. Если числа нет, честно отметьте уровень уверенности.
   - **Где сделать:** Рядом с техническим следом и ссылкой на обращения.
   - **Пример:** 84 пользователя за 7 дней; только Android 12; подтверждено 12 обращениями и одним кластером ошибок.
4. **Назначьте приоритет и обходной путь.** Сначала безопасность, деньги, данные и блокировка ключевого действия. Пока идёт исправление, поддержка должна знать безопасную помощь пользователю.
   - **Где сделать:** В колонках P0–P3, владелец, срок и обходной путь.
   - **Пример:** P0; владелец — серверная команда; срок — сегодня 18:00; поддержка проверяет статус по идентификатору.
5. **Закройте по данным, а не по релизу.** После исправления повторите сценарий и убедитесь, что исчезли технический сигнал и пользовательские жалобы.
   - **Где сделать:** В задаче через 24–72 часа после выпуска исправления.
   - **Пример:** Кластер ошибок не появляется, 20 тестов успешны, новых обращений по теме нет двое суток.

## Примеры из практики

- **P0: статус операции завис:** Проблема затронула 84 пользователей за неделю: результат не виден, люди повторяют действие. Есть финансовый и доверительный риск — владелец и безопасный ответ поддержки нужны сегодня.
- **P1: пустая история на Android 12:** Масштаб меньше, но ключевые данные недоступны. В задаче фиксируются версия, видео воспроизведения, временный перезапуск и проверка обращений через 48 часов после hotfix.

## Готовый артефакт: Таблица приоритетов, понятная всей команде

Пять строк достаточно для первого решения. Не прячьте влияние за техническим названием ошибки.

| Проблема | Влияние и масштаб | Обходной путь | Решение |
| --- | --- | --- | --- |
| Статус операции завис | Деньги/доверие · 84 пользователя | Поддержка проверяет вручную | P0 · исправить сегодня |
| Не приходит код входа | Блокирует вход · Android 12 | Повтор через 60 секунд | P0 · Android-разработчик |
| Пустая история | Данные не видны · версия 4.2 | Перезапуск приложения | P1 · срочное исправление |
| Push ведёт на главную | Лишний шаг · 11% переходов | Открыть раздел вручную | P2 · следующий релиз |
| Съехала иконка | Только внешний вид | Не требуется | P3 · дизайн-долг |

Правило: P0 блокирует или искажает деньги, данные, безопасность либо основной путь. У каждого P0 есть владелец, срок, сообщение для поддержки и способ проверить исправление.

## Чек-лист приоритизации

Критичная задача должна одинаково читаться продуктом, поддержкой и разработкой.

- [ ] Проблема названа через действие и вред пользователю.
- [ ] Есть платформа, версия, период и подтверждённый масштаб либо уровень уверенности.
- [ ] Ошибки денег, данных, безопасности и доверия отмечены отдельно.
- [ ] Для P0/P1 назначены владелец, срок и безопасный обходной путь.
- [ ] Заранее записано, какими данными подтвердится исправление.

## Как понять, что исправление сработало

- **Технический сигнал:** Исчез конкретный crash-кластер, ANR или код ошибки на затронутой версии.
- **Пользовательский путь:** Восстановилась доля успешных входов, сохранений, операций или другого сломанного действия.
- **Поддержка и доверие:** Новые обращения по теме прекратились, а пользователям с прошлой проблемой дан понятный ответ.

## Главное правило

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

---

- [HTML-версия](https://playbook.affpartners.io/ru/practices/quality-bugs/index.html)
- [Все практики](https://playbook.affpartners.io/ru/)