Приведи пример из практики, где у дефекта низкий приоритет и высокая серьезность

Сочетание низкого приоритета и высокой серьезности дефекта: практический пример

В моей практике классическим примером дефекта с низким приоритетом (Priority), но высокой серьезностью (Severity) является визуальный баг, который не мешает основному функционалу, но выглядит катастрофически с точки зрения пользовательского опыта. Приведу конкретный случай из проекта по разработке финансового веб-приложения.

Описание дефекта

Название: На странице отчета по операциям в определенном браузере (Microsoft Edge Legacy) при использовании масштабирования 125% происходит полное "рассыпание" таблицы: границы ячеек исчезают, текст накладывается друг на друга, делая данные нечитаемыми.

Серьезность (Severity): S1 (Блокирующий / Critical)

• Критерии: Функциональность (просмотр отчета) полностью недоступна для значимой части пользователей при определенных, но воспроизводимых условиях. Бизнес-логика не выполняется — пользователь не может потребить ключевую информацию.

Приоритет (Priority): P4 (Низкий)

• Критерии: Баг воспроизводится только в устаревшей версии браузера (Edge Legacy), доля пользователей которой в нашей аналитике составляла менее 2%. Функционально в других браузерах (Chrome, Firefox, новый Edge) и в стандартном масштабе 100% в том же Edge Legacy все работало корректно. Есть обходной путь для пользователя — сбросить масштаб на странице или использовать другой браузер.

Почему такое сочетание не является противоречием?

Это кажущееся противоречие разрешается через понимание разницы между терминами:

• Severity (Серьезность) — объективная мера воздействия дефекта на функциональность системы. В данном случае воздействие максимальное: функция непригодна к использованию.
• Priority (Приоритет) — субъективное решение команды о порядке исправления дефектов, основанное на бизнес-логике, рисках, влиянии на пользователей и стоимости исправления.

Обоснование решения команды

На планнинге мы приняли решение отложить исправление на несколько спринтов, аргументировав это следующим:

1. Ограниченный охват аудитории: Менее 2% трафика, при этом браузер был официально deprecated.
2. Наличие обходного пути: В справке приложения и в сообщении об ошибке мы указали, как решить проблему (Ctrl+0 для сброса масштаба).
3. Высокая стоимость исправления: Проблема была связана с глубокими особенностями рендеринга таблиц в старом движке Edge. Для ее устранения потребовалось бы переписать компонент таблицы с использованием другого подхода, что оценивалось в 5-7 человеко-дней.
4. Более высокий приоритет других задач: В тот момент в бэклоге находились функциональности, критичные для запуска нового регуляторного отчета, что напрямую влияло на доходы компании.

Итог и выводы

Дефект был задокументирован следующим образом в Jira и исправлен значительно позже, в рамках большого рефакторинга UI-компонентов:

Заголовок: [Edge Legacy] При масштабе 125% на странице /report/transactions таблица становится нечитаемой
Описание:
Steps to Reproduce:
1. Открыть Microsoft Edge Legacy (версия 44).
2. Перейти на страницу "Отчет по операциям".
3. Установить масштаб браузера 125% (Ctrl + "+").
4. Наблюдать наложение текста и исчезновение границ.

Expected Result: Таблица отображается корректно при любом стандартном масштабе браузера.
Actual Result: Данные в таблице невозможно прочитать.

Severity: S1 (Critical) - основная функция недоступна.
Priority: P4 (Low) - низкий охват аудитории, есть обходной путь, высокая стоимость исправления.

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