Комментарии 7
У нас обращения в обратную связь собираются прямо на сайте, и напрямую в Jira не направляются, потому что если не требуется вмешательство разработчиков, то вопрос решается на линии операторов / администраторов.
В случае бага или необходимости доработки, оператор, ответственный за обращение, прямо на его странице создает тикет в Jira.
В случае бага или необходимости доработки, оператор, ответственный за обращение, прямо на его странице создает тикет в Jira.
А что за текст заблюрен на скриншоте?
Расскажите, как вы работаете с бэклогом тикетов из техподдержки.
Если баг воспроизводится и тестировщик ставит задачу, но сам баг редкий / некритичный / по другой причине не приоритетный, то как определяется, когда (если) задача берётся в работу?
Кто «грумит» этот бэклог? Продуктовый менеджер? На основе каких данных?
Или просто фиксированный объём человекочасов в каждом релизе фиксируется для исправления багов из бэклога саппорта?
Как правило, самая сложная в решении проблема — не рассортировать таски, а выделить ресурсы (особенно если не всё соответствует стратегическим планам компании) — интересно почитать, как вы решаете именно эту проблему
Если баг воспроизводится и тестировщик ставит задачу, но сам баг редкий / некритичный / по другой причине не приоритетный, то как определяется, когда (если) задача берётся в работу?
Кто «грумит» этот бэклог? Продуктовый менеджер? На основе каких данных?
Или просто фиксированный объём человекочасов в каждом релизе фиксируется для исправления багов из бэклога саппорта?
Как правило, самая сложная в решении проблема — не рассортировать таски, а выделить ресурсы (особенно если не всё соответствует стратегическим планам компании) — интересно почитать, как вы решаете именно эту проблему
Полуавтоматизированная приоритезация + SLA.
Каждый багрепорт перед погрузкой в трекер оценивается по ряду факторов:
У каждого пункта каждого параметра есть свой вес, сумма весов определяет критичность одной проблемы относительно другой для выстраивания приоритетов.
Критические и Блокирующие баги покрыты внутренним SLA, по ним билд с исправлением обязан быть в течение 1 и 3 суток соответственно.
Стандартные по приоритету багрепорты падают в общий бэклог, но могут двигаться в нём без очереди после появления нескольких пользовательских жалоб, требований от магазинов приложений или других факторов, повышающих критичность.
Каждый багрепорт перед погрузкой в трекер оценивается по ряду факторов:
- Вероятность встречи пользователя и этого бага. Оценивается по сложности сценария и длине пути пользователя для достижения проблемы.
- Потенциальная массовость. Например, если проблема воспроизводится только на iPad Mini под iOS 10, то это плохо. Но не так плохо, как если бы баг проявлялся на всех устройствах.
- Затронутый компонент приложения. Любая функция должна работать, но чтение писем всё таки важнее, чем смена аватарки.
- Влияние проблемы на компонент. Оценивается деструктивное действие: ухудшает работу с функцией или блокирует её работу.
У каждого пункта каждого параметра есть свой вес, сумма весов определяет критичность одной проблемы относительно другой для выстраивания приоритетов.
Критические и Блокирующие баги покрыты внутренним SLA, по ним билд с исправлением обязан быть в течение 1 и 3 суток соответственно.
Стандартные по приоритету багрепорты падают в общий бэклог, но могут двигаться в нём без очереди после появления нескольких пользовательских жалоб, требований от магазинов приложений или других факторов, повышающих критичность.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как тикеты в саппорт превращаются в тикеты в Jira