Модуль 5 · Урок 19
Severity, priority і evidence-based triage
Severity описує ступінь впливу на stakeholders або requirements. Priority визначає порядок/термін роботи з урахуванням severity, reach, release, workaround, compliance, dependencies та вартості затримки.
Severity не дорівнює priority
| Сценарій | Severity | Priority | Чому |
|---|---|---|---|
| Rare data corruption, no workaround | Critical | Immediate/high | Велика незворотна шкода. |
| Typo on campaign landing before launch | Minor | High | Низький product impact, але близький release/brand visibility. |
| Critical failure in retired feature | Critical | Deferred after decision | Високий theoretical impact, але feature недоступна й видаляється. |
Матриця допомагає, але не замінює context. Кожна оцінка має rationale і owner.
Triage — командне рішення
Не голосуйте без product context
QA приносить reproducibility та evidence; Product — stakeholder/business impact; Engineering — component scope/effort/risk; Support/Operations — real frequency й workaround; Security/Legal — спеціальні obligations. Остаточна priority не повинна бути прихованою властивістю автора ticket.
«Low» не означає «ніколи»
Deferred items потребують risk owner, target/review date і trigger для перегляду. Інакше backlog накопичує невидимий борг.
Практика triage
Заповніть `triage-register.csv`: severity basis, priority basis, frequency, scope, decision, owner, target, risk if deferred і participants. Поясніть один кейс high-severity/low-priority та low-severity/high-priority.
Офіційне джерело
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.