Чтобы определить приоритет бага, необходимо учитывать следующие факторы:
• Ущерб для пользователей: может ли баг нанести серьезный или долгосрочный ущерб пользователям? Не возникнет ли риск нарушения безопасности или конфиденциальности их данных? Могут ли они потерять данные?
• Ущерб для компании: может ли баг нанести крупный или долгосрочный ущерб компании? Может ли это серьезно навредить ее репутации?
• Влияние на показатели: оказывает ли баг серьезное воздействие на ключевые показатели компании? Влияет ли на затраты или доходы? Вредит ли привлечению, активации, удержанию, доходу или рекомендациям (модель AARRR)? Является ли он причиной большого количества обращений в службу поддержки?
• Масштаб воздействия: скольких пользователей затронул этот баг? Пропорционально ли он повлиял на важных (платежеспособных или крупных) клиентов? Больше или меньше пользователей он затронет в будущем?
• Обходные пути: существуют ли способы обойти баг? Найдет ли пользователь обходной путь самостоятельно?
• Простота исправления: легко ли его устранить? Сколько времени для этого потребуется?
• Сейчас или потом: своевременно ли исправлять баг сейчас? Что дешевле: отладить его сегодня или сделать это позже? Запланированы ли какие-то маркетинговые мероприятия, касающиеся этой части продукта?
• Рентабельность по сравнению с другими задачами: как затраты и выгоды, связанные с исправлением бага, соотносятся с затратами и выгодами, которые возникнут, если сосредоточиться на внедрении новых функций?
При сортировке багов первое, что делает хороший PM, это пытается их понять, конкретизировать и как можно скорее устранить. Именно здесь и пригодится аналитический подход к решению задач.
• Ущерб для пользователей: может ли баг нанести серьезный или долгосрочный ущерб пользователям? Не возникнет ли риск нарушения безопасности или конфиденциальности их данных? Могут ли они потерять данные?
• Ущерб для компании: может ли баг нанести крупный или долгосрочный ущерб компании? Может ли это серьезно навредить ее репутации?
• Влияние на показатели: оказывает ли баг серьезное воздействие на ключевые показатели компании? Влияет ли на затраты или доходы? Вредит ли привлечению, активации, удержанию, доходу или рекомендациям (модель AARRR)? Является ли он причиной большого количества обращений в службу поддержки?
• Масштаб воздействия: скольких пользователей затронул этот баг? Пропорционально ли он повлиял на важных (платежеспособных или крупных) клиентов? Больше или меньше пользователей он затронет в будущем?
• Обходные пути: существуют ли способы обойти баг? Найдет ли пользователь обходной путь самостоятельно?
• Простота исправления: легко ли его устранить? Сколько времени для этого потребуется?
• Сейчас или потом: своевременно ли исправлять баг сейчас? Что дешевле: отладить его сегодня или сделать это позже? Запланированы ли какие-то маркетинговые мероприятия, касающиеся этой части продукта?
• Рентабельность по сравнению с другими задачами: как затраты и выгоды, связанные с исправлением бага, соотносятся с затратами и выгодами, которые возникнут, если сосредоточиться на внедрении новых функций?
При сортировке багов первое, что делает хороший PM, это пытается их понять, конкретизировать и как можно скорее устранить. Именно здесь и пригодится аналитический подход к решению задач.
