Приведи пример конфликта с разработчиком

Пример конфликта с разработчиком и его разрешение

Да, конфликты между QA и разработчиками неизбежны. Вот конкретный пример, как я справился с одной сложной ситуацией.

Ситуация

Мы готовили релиз функциональности "Покупка подписки". Я нашел баг в интеграции с платежной системой. Когда пользователь отменяет платеж, система переводит подписку в состояние "Pending", но должна перевести в "Cancelled".

Я создал баг-репорт: Priority: High, так как это влияет на доход компании.

Конфликт

Разработчик Иван (опытный, с 8 лет опыта) ответил резко:

"Это не баг. Система работает как задумано. Состояние Pending нужно для отслеживания платежей. Ты не понимаешь логику."

Тон был пренебрежительный. Он не согласился даже посмотреть мой баг-репорт детально.

Мой первый импульс: Ответить в том же тоне и настоять на своем. Но это только усугубило бы конфликт.

Как я решил

Шаг 1: Остыть и переоценить

Вместо того, чтобы ответить сразу, я:

• Сделал перерыв на 30 минут
• Еще раз проверил баг: воспроизвел его с видео
• Изучил спецификацию платежной системы
• Изучил код изменений в этом спринте

Шаг 2: Попросить встречу один на один

Несмотря на конфликт, я отправил сообщение:

"Иван, спасибо за обратную связь. Мне хочется лучше понять дизайн. Давай созвонимся на 15 минут, чтобы я убедился, что я правильно воспроизвел проблему."

Тон был:

• Вежливый и уважающий его опыт
• Не обвиняющий
• Открытый к тому, что я неправ

Шаг 3: На встречу пришел подготовленным

Приготовил:

• Видео воспроизведения бага
• Логи из система
• Ссылку на требования платежной системы (из документации)
• Вопросы, а не утверждения:
  • "Почему документация платежной системы говорит, что Cancelled должен быть конечным состоянием?"
  • "Как Pending помогает отследить платеж, если пользователь уже получил сообщение от платежной системы что отмена успешна?"

Шаг 4: Слушал больше, чем говорил

Да, Иван говорил в защиту своего решения. Я слушал внимательно, задавал уточняющие вопросы, не перебивал.

Оказалось, что у него была причина для Pending:

• Он мыслил о сценарии где платеж отменяется, но платежная система отправляет confirmation
• Он хотел отслеживать такие рассинхронизации

Это была ЛЕГИТИМНАЯ причина, о которой я не думал.

Шаг 5: Нашли компромисс

Мы обсудили:

1. Что баг не в Pending состоянии, а в том, что система НЕ ПЕРЕХОДИТ в Pending при рассинхронизации
2. В текущей версии система полностью игнорирует сценарий рассинхронизации
3. Мой баг-репорт был неправильно сформулирован

Решение:

• Он поменял фокус: вместо фиксить логику Pending, она должна логировать ошибку при рассинхронизации
• Я понял, почему это сложнее чем я думал
• Мы оба согласились что это Medium priority (не High)

Результаты

Короткосрочно:

• Баг был переклассифицирован и правильно задизайнен
• Иван начал уважать мое мнение
• Мы больше не конфликтовали

Долгосрочно:

• После этого случая Иван всегда внимательно читал мои баг-репорты
• Когда я находил баги, он спрашивал "Это как вчера?" и слушал.
• Мы стали работать как одна команда
• После нескольких месяцев он предложил мне помочь с архитектурой платежей (я помогал находить баги в дизайне)

Что я выучил

1. Не переходить на личности Конфликт о баге, не о том, кто прав.

2. Быть открытым что я могу ошибаться Я на 80% уверен в баге, но на 20% могу ошибаться.

3. Слушать разработчика У него может быть контекст, который я не знаю.

4. Готовить доказательства Видео, логи, спецификация — это мой язык.

5. Уважать expertise Иван был прав что Pending нужно. Я был прав что бага такая есть. Оба были частично правы.

6. Встреча один на один лучше чем slack В чате легко конфликтовать, в разговоре — легче договориться.

Общая рекомендация

Конфликты между QA и разработчиками нормальны. Ключ — это как их решать:

• Не личное — о дефектах, не об ошибках человека
• Подготовка — докажи свою позицию
• Слушание — может быть разработчик прав
• Компромисс — часто оба правы частично
• Уважение — ценить expertise друг друга

Лучший результат — это когда QA и разработчик становятся партнерами, а не противниками.