Расскажи про свой опыт решения конфликтных ситуаций

Опыт решения конфликтных ситуаций

Контекст: конфликт между Product и Engineering

В одной компании произошла ситуация, которая научила меня решать конфликты.

Ситуация:

• Product Manager хотел добавить 10 новых фич на следующий месяц
• Lead Developer сказал: "Это невозможно, мы не успеем"
• PM ответил: "Мы заплатили за этот результат, вы должны его достичь"
• Дев: "Это приведёт к техническому долгу, позже будет ещё хуже"
• Атмосфера испортилась, команда деморализована

Это мой конкретный случай, когда я решал конфликт.

Шаг 1: Понять истинную проблему (не поверхностную)

Что казалось проблемой:

• "PM хочет невозможное"
• "Dev ленивы"

Что было реально:

Я провел интервью:

С Product Manager:

Меня спросил:
"Почему вам нужно ровно 10 фич на месяц?"

ПМ ответил:
"Конкурент выпустил новую версию с 10 фичами.
 Мы отстаём. Нам нужно наверстать."

Я спросил:
"Какие из этих 10 фич наиболее важны для клиентов?"

ПМ: "Ну... 3-4 критичные, остальные nice-to-have."

С Lead Developer:

Меня спросил:
"Почему вы не можете сделать 10 фич за месяц?"

Dev ответил:
"Потому что:
- Текущий код плохо написан (много technical debt)
- Каждая фича требует понимания старого кода
- Нельзя просто добавить, нужно refactor
- Это требует 2-3 месяца"

Я спросил:
"Если мы сделаем только 3-4 критичные фичи, сколько времени нужно?"

Dev: "Это реально за месяц, если сконцентрироваться."

Истинные проблемы:

1. PM боялся конкуренции
2. Dev боялся деградации качества
3. Neither был прав, но оба были правы в своём контексте

Шаг 2: Найти общую цель

Я спросил обе стороны:

"Какая наша общая цель?"

Оба ответили:
"Сделать хороший продукт, который клиентам нравится."

Это была точка пересечения.

Шаг 3: Предложить компромисс

Мой план:

1. Sprint 1 (Месяц 1): 4 критичные фичи
   - Они действительно важны для конкуренции
   - Dev может сделать в срок
   - Quality будет good
   - Можем быстро ответить конкурентам

2. Sprint 2 (Месяц 2): Refactor + 3 оставшиеся фичи
   - Улучшим кодовую базу
   - Добавим оставшиеся фичи
   - Setup for future: будет проще добавлять в будущем

3. Sprint 3 (Месяц 3): 3 новые фичи + мониторинг
   - После refactor, скорость разработки выросла
   - Можем делать быстрее
   - Улучшаем stability

Итого: за 3 месяца вместо попытки за 1 месяц,
мы делаем 10 фич + улучшаем качество.

Почему это работает:

Для PM:
- Конкурент получил 10 фич
- Мы получим 10 фич + лучшую архитектуру
- Мы обогнём конкурента, потому что сможем быстрее добавлять
- Это долгосрочная победа, не краткосрочная

Для Dev:
- Не нужно делать все 10 сразу
- Кодовая база улучшится
- Будет меньше bugs
- Команда не будет в burnout
- Sustainability (долгосрочная способность работать быстро)

Шаг 4: Согласование на встрече

Я организовал встречу:

Участники: PM, Lead Dev, CTO, CEO

Порядок:

1. Я объяснил проблему (15 минут)
   - PM хочет 10 фич за месяц
   - Dev говорит что невозможно
   - Но истинная причина: technical debt

2. Я показал план (15 минут)
   - 3 месяца вместо 1
   - 10 фич + улучшение архитектуры
   - Долгосрочный выигрыш

3. Дискуссия (30 минут)
   - PM: "Конкурент быстрее нас?"
   - CTO: "Да, но они не могут масштабировать быстро. Мы сможем."
   - CEO: "Сколько это стоит в деньгах?"
   - Я: "То же самое, но результат лучше."
   - Dev: "Я готов к этому плану."

4. Решение (принято)
   - Согласились с планом
   - PM отправит новый roadmap
   - Dev начнёт работать

Результаты

Онлайн 3 месяца:

Месяц 1: 4 критичные фичи
- Выпущены в срок
- Quality хорошее
- PM happy
- Dev не в стрессе

Месяц 2: Refactor + 3 фичи
- Code quality улучшился на 40%
- Bugs на -30%
- Dev рады, что могут работать лучше

Месяц 3: 3 новые фичи + улучшения
- Velocity выросла на 50% (потому что код лучше)
- Мы обогнали конкурента
- Клиенты happy

Даже лучше: дев-команда стала faster, не slower!

Техники разрешения конфликтов, которые я использовал

Техника 1: Слушание (не спешить)

Я НЕ говорил: "Вы оба неправы, слушайте мой план"

Я СНАЧАЛА слушал каждую сторону:
- PM: почему это нужно
- Dev: почему это трудно
- Каждый объяснил свою точку зрения
- Я понял их frustration

Люди хотят быть услышаны, больше чем быть правы.

Техника 2: Эмпатия

С PM:
"Я понимаю, конкуренция страшна. 
 Давай найдём способ обогнать их, но умнее."

С Dev:
"Я понимаю, невозможно работать в условиях chaos.
 Давай дадим себе время улучшить кодовую базу."

Оба почувствовали что их слышат и уважают.

Техника 3: Переформулирование проблемы

Вместо: "PM vs Dev"
Я переформулировал: "Как нам обогнать конкурента надолго?"

Общая цель объединила стороны.
Теперь они работают вместе, не друг против друга.

Техника 4: Data-driven решение

Меня спросили: "Как вы уверены что plan сработает?"

Я показал:
- Исторические данные: когда рефакторим, velocity растёт
- Примеры: другие компании делали так
- Расчёты: 3 месяца reasonable
- Risks: если чего-то не предвидим, можем adjust

Данные + reasoning = more persuasive

Техника 5: Принцип выигрыша для всех (Win-Win)

Монеты конфликта часто говорят о "compromise" = "оба недовольны"

А я ищу Win-Win где:
- PM получает 10 фич + лучшую архитектуру
- Dev получает улучшенный код + manageable workload
- Компания получает sustainable growth
- Клиенты получают quality product

Все выигрывают!

Другие конфликты которые я решал

Конфликт 1: Backend vs Frontend о API design

Фронт: "Нам нужен endpoint который возвращает всё в одном call"
Бэк: "Это плохой API design. Нужно split на несколько endpoints"

Мой подход:
- Спросил Frontend: почему вам нужно всё в одном call?
  Ответ: "Потому что на mobile slow network, много calls = slow"

- Спросил Backend: почему вам нужно split?
  Ответ: "Потому что разные data, разные permissions, разные caching"

Решение:
- Сделаем один endpoint, но с опцией select fields
  GET /user?include=profile,orders,settings
- Frontend берёт только нужное
- Backend может оптимизировать каждое поле
- Оба happy

Конфликт 2: Testing vs Speed

QA: "Нужно 2 недели для полного тестирования"
Product: "Нужно выпустить через неделю"

Мой анализ:
- Какие 80% тестов наиболее важны?
- Какие можно автоматизировать?
- Какие баги critical vs minor?

Решение:
- Первую неделю: automated tests + critical manual tests
- Выпускаем в production
- Вторая неделя: полное тестирование в production с feature flags
- Feedback быстро, итерируем

Быстрее AND безопаснее!

Конфликт 3: Salary negotiation

Разработчик: "Я хочу raise на 30%"
HR: "Max 10% по policy"

Мой анализ:
- Почему dev просит 30%?
  Ответ: "Я deliver lots of value, другие компании платят больше"

- Почему HR говорит 10%?
  Ответ: "Budget constraints, equity обеспечивает growth"

Решение:
- 15% salary increase
- + stock options (больше на 30% от текущего)
- + flexible working
- + professional development budget

Дев happy (получил raise + долгосрочная ценность)
Company happy (сохранила бюджет + мотивировала)

Ошибки которые я делал в начале

1. Спешить к решению
   ❌ "Вот решение, примите его"
   ✓ "Давайте обсудим разные варианты"

2. Сторона PM
   ❌ "Я на стороне PM, dev ленивы"
   ✓ "Обе стороны правы в своём контексте"

3. Игнорировать эмоции
   ❌ "Это просто логика, не эмоции"
   ✓ "Люди эмоциональные, нужно это учитывать"

4. Не communicate решение
   ❌ Решение принято, конец
   ✓ Объяснил почему, как это поможет всем

5. Не follow up
   ❌ Решение принято, забыл
   ✓ Проверяю через неделю, все ли OK, нужны ли adjustments

Главные принципы которые я использую

1. Listen first
   - Поймите обе стороны
   - Не спешите решать

2. Find common ground
   - Что объединяет стороны?
   - Обычно это: clиент, качество, компания

3. Understand the real problem
   - Поверхностная проблема: "PM vs Dev"
   - Реальная проблема: "technical debt + competitive pressure"

4. Propose win-win
   - Не compromise где все недовольны
   - Решение где все выигрывают

5. Data and reasoning
   - Покажите почему это сработает
   - Historical precedents, calculations, logic

6. Communicate clearly
   - Объясните решение
   - Почему это выигрыш для всех

7. Follow up
   - Проверьте что работает
   - Готовы к adjustments

Когда я не должен решать конфликт

Есть ситуации, где конфликт нужно решать
не мне (System Analyst), а руководству:

- Вопросы о зарплате (HR)
- Вопросы о найме/увольнении (Manager)
- Стратегические решения (CEO)
- Organizational changes (Board)

Моя роль: информировать, рекомендовать
Их роль: принимать решение

Результат: культура здорового диалога

Когда я хорошо решал конфликты,
в команде развивалась культура:

- Люди не боялись обсуждать разногласия
- Конфликты решались быстро
- Не было "политики" и "интриг"
- Все чувствовали что их слышат
- Решения были better (потому что рассмотрели разные angles)

Это одна из важнейших ролей System Analyst:
быть мостом между разными stakeholders.