Ответ
В этой ситуации я действую по принципу конструктивного диалога и эскалации на основе данных, а не мнений.
Алгоритм действий:
- Уточнение причины: Вежливо прошу разработчика пояснить причину отказа. Частые причины: "не воспроизводится", "не является багом по ТЗ", "низкий приоритет", "это фича".
- Подготовка доказательной базы:
- Воспроизводимость: Перепроверяю баг, записываю четкие шаги, добавляю видео/скриншоты, логи, данные об окружении.
- Соответствие требованиям: Сверяю описание проблемы с ТЗ, пользовательскими историями или дизайн-макетами. Если баг нарушает документацию — прикладываю ссылки.
- Оценка влияния: Четко описываю бизнес-риск: кого и как баг затрагивает (например, "блокирует покупку для 10% пользователей").
- Повторное обсуждение: Предоставляю разработчику обновленную информацию. Часто этого достаточно для разрешения спора.
- Эскалация: Если разногласия остаются, привлекаю третью сторону для принятия решения — тимлида, проджект-менеджера или продакт-оунера. Их задача — расставить приоритеты на основе бизнес-ценности.
Пример структурированного комментария в задаче:
**Проблема:** При нажатии кнопки "Сохранить" в форме X возникает ошибка 500.
**Шаги воспроизведения:**
1. Залогиньтесь как пользователь Y.
2. Перейдите на страницу Z.
3. Заполните поле "Имя" значением "Test'Name" (с апострофом).
4. Нажмите "Сохранить".
**Ожидаемо:** Данные сохраняются (как указано в ТЗ v1.2, п. 4.5).
**Фактически:** Ошибка "Internal Server Error" (скриншот и лог приложены).
**Влияние:** Пользователи не могут сохранить профиль, если в имени есть апостроф.
**Предложение:** Исправить санитизацию входных данных для поля "Имя".Если после эскалации принимается решение не чинить баг, я фиксирую это решение в задаче и, при необходимости, в документации (например, как известное ограничение).