Ответ
Мой подход основан на объективности, эмпатии и ориентации на решение, а не на личности.
Алгоритм действий:
- Выявление корня проблемы: Отделяю симптом ("разработчик не принимает мой баг-репорт") от причины (недостаточные шаги воспроизведения, разное понимание требований, техническая сложность).
- Сбор фактов и данных: Готовлю четкую доказательную базу перед обсуждением.
- Для бага: шаги воспроизведения, логи, скриншоты/видео, данные об окружении.
- Для разногласий по задаче: требования из тикета, комментарии аналитика, аналоги из прошлого.
- Конструктивный диалог:
- Обсуждаю проблему на нейтральной территории (встреча, а не чат).
- Использую "я-сообщения" ("Я вижу, что...", "Мне непонятно...").
- Активно слушаю позицию другой стороны.
- Поиск компромисса и решение: Предлагаю варианты, которые учитывают интересы проекта, а не личные предпочтения.
Конкретный пример: Ситуация: Разработчик оспаривает критичность бага, считая его edge-кейсом. Мои действия:
- Уточнил у Product Owner'а частоту и бизнес-влияние сценария.
- Подготовил данные: "Сценарий возникает при 2FA, которую используют 15% премиум-пользователей. Логи показывают 500 ошибку на бэкенде".
- Предложил на встрече два варианта:
- Вариант А: Исправить сейчас, так как влияет на ключевую аудиторию.
- Вариант Б: Завести тикет с lower priority, но добавить graceful degradation (показать пользователю понятное сообщение). Итог: Команда и PO выбрали Вариант Б как оптимальный по соотношению effort/value, конфликт был исчерпан.
Ключевой принцип: Фокус на общей цели — качестве продукта и удовлетворенности пользователя.