Ответ
Приоритизация строится на оценке влияния на бизнес и пользователей, срочности и затратах ресурсов. Часто используется комбинация методов.
| 1. Матрица влияния/срочности (Eisenhower): | Срочно | Не срочно | |
|---|---|---|---|
| Важно | Критические баги, блокеры релиза. Сделать немедленно. | Новая функциональность, улучшения. Запланировать. | |
| Не важно | Некоторые запросы поддержки, мелкие правки. Делегировать/запланировать. | "Хотелки", косметические изменения. Отложить/исключить. |
2. Метод MoSCoW:
- Must have: Критические задачи, без которых релиз невозможен (баги, нарушающие основной функционал, security issues).
- Should have: Важные, но не блокирующие задачи. Сильно влияют на UX, но есть обходные пути.
- Could have: Желательные улучшения, не влияющие на основные сценарии (оптимизация, мелкие улучшения UI).
- Won't have (this time): Задачи самого низкого приоритета, которые можно отложить на будущее.
3. Практический пример приоритизации багов:
- P0 (Критический): Падение приложения, потеря данных, невозможность совершить покупку.
- P1 (Высокий): Серьёзная ошибка в ключевом сценарии (некорректное отображение цены, падение в конкретном браузере).
- P2 (Средний): Ошибка в неосновном функционале, опечатка в тексте.
- P3 (Низкий): Косметическая проблема, не влияющая на функционал (смещение на 1px).
Решение всегда согласуется с продукт-менеджером и командой, учитывая дорожную карту и сроки релиза.