Ответ
Алгоритм действий для конструктивного разрешения ситуации:
-
Уточнить и подтвердить воспроизведение:
- Перепроверить шаги, окружение и тестовые данные. Убедиться, что баг стабилен.
- Предоставить максимально четкое описание, включая ожидаемый и фактический результат.
Шаги: 1. Добавить в корзину товары А и Б. 2. Удалить товар А. Ожидаемо: Итоговая сумма уменьшается на стоимость товара А. Фактически: Сумма остается неизменной.
-
Обсудить аргументацию:
- Выяснить причину отказа: "не баг" (поведение соответствует требованиям), "дубликат", "невоспроизводимо", "низкий приоритет".
- Свериться с требованиями (User Story, спецификация) или соглашениями о поведении системы.
-
Оценить критичность:
- Определить влияние на пользователей и бизнес. Если баг блокирующий или критичный, обосновать это.
-
Привлечь третью сторону (при необходимости):
- Если дискуссия зашла в тупик, обратиться к тест-лиду, менеджеру проекта или продакт-оунеру для принятия финального решения на основе приоритетов.
-
Зафиксировать результат:
- Внести итоговое решение (исправить, отложить, отклонить) в баг-трекер с комментариями для прозрачности истории.
Ключевой принцип: Фокус на качестве продукта, а не на конфликте. Задача — найти истинную причину и оптимальное решение для проекта.
Ответ 18+ 🔞
Ага, слушай, вот ты нашёл баг, отправил его в работу, а тебе в ответ — «не баг, работает как задумано». Или, что ещё веселее, «невоспроизводимо». И ты сидишь такой, смотришь на этот комментарий, и у тебя в голове одна мысль: «Да я же, блядь, только что на нём катался, как на велосипеде! Как это невоспроизводимо?!». Спокойно, не кипятись. Давай по уму, без криков и танцев с бубном.
Первым делом, не надо сразу писать гневный роман на три страницы. Надо уточнить и подтвердить, что ты не придумал это во сне. Собери всё, как на блюдечке: точные шаги, на какой он срал-системе, какие данные, скриншоты, логи. Чем подробнее, тем лучше. Засунь это всё в описание бага, чтобы любой, кто откроет, мог тупо скопировать твои шаги и получить тот же пиздец. Типа так:
Шаги:
1. Зайти под юзером test@example.com (пароль: 123).
2. На странице /cart добавить товары с ID 777 и 888.
3. Нажать крестик у товара 777.
Ожидаемо: В блоке "Итого" сумма уменьшается на 1500 рублей.
Фактически: Сумма остаётся 3000 рублей, будто товар не удалился.Вот. Теперь у оппонента меньше шансов сказать «ой, а у меня не так».
Дальше — обсудить аргументацию. Спроси вежливо, но настойчиво: «А на каком основании "не баг"?». Может, выяснится, что по ТЗ так и должно быть, а ты просто не в курсе. Или это дубликат какого-то старого косяка, который уже чинят. Или они просто пальцем в небо ткнули, потому что им лень разбираться. Твоя задача — докопаться до сути. Сверься с требованиями, со спецификацией. Если там чётко сказано, что сумма должна пересчитываться, а она не пересчитывается — у тебя железный аргумент. Если же в требованиях дыра размером с чёрную дыру — это уже другой разговор.
Теперь оцени, насколько это всё критично. Если из-за этого бага пользователи не могут оформить заказ — это, блядь, пожар, надо тушить вчера. Если же где-то в админке кнопка на два пикселя съехала и её видит только ты — может, и правда, не стоит из-за этого городить огород. Объясни, какой ущерб это наносит. «Из-за этого мы теряем деньги» или «это вводит пользователей в заблуждение» звучит куда убедительнее, чем «мне не нравится, как это выглядит».
Если диалог упёрся в стену непонимания, и вы уже пятый круг ходите по одному и тому же — привлекай третью сторону. Это не стукачество, а эскалация. Обратись к тест-лиду, проджекту или продакт-оунеру. Скажи: «Слушайте, тут спорная ситуация, нужен арбитр». Пусть человек, отвечающий за продукт, решит: чинить сейчас, чинить потом или оставить как есть. Часто бывает, что разработчику просто влом, а когда сверху спускают приказ — магия, всё находится.
И наконец, зафиксируй результат. Какое бы решение ни приняли — «исправить», «отложить на потом» или «закрыть как не баг» — оно должно быть записано в тикете. Чтобы через месяц не началось: «А кто это решил? Мы такого не говорили!». Прозрачность, ебать, наше всё.
Главный принцип, который надо помнить: цель — не доказать, что ты умный, а они — идиоты. Цель — сделать продукт лучше. Всё остальное — просто шум. Действуй по фактам, а не по эмоциям, и всё получится. Ну, почти всегда.