Какую конфликтную ситуацию удалось решить в команде?

Решение конфликтной ситуации в команде

Контекст конфликта

Я работал Product Manager'ом в финтех-компании с командой из 3 инженеров, дизайнера и аналитика. В начале одного квартала возникла напряжённая ситуация, когда команда разработки была недовольна способом приоритизации задач, а я был разочарован скоростью разработки.

Симптомы конфликта:

• Инженеры говорили, что требования часто меняются и недостаточно подробные
• На планированиях звучали критические замечания в сторону друг друга
• Дизайнер рассказал мне, что в чате пишут недовольные комментарии
• Производительность упала на 15% за спринт
• На ретроспективе царила напряжённая атмосфера

Анализ корневых причин

Вместо того, чтобы сразу начинать тушить пожар, я провел 1-on-1 разговоры с каждым членом команды:

От инженеров услышал:

• Мы не знаем, почему вы меняете приоритеты в середине спринта
• Требования слишком высокоуровневые, много уточнений после начала разработки
• Создаётся впечатление, что PM не думает о нашей нагрузке

От дизайнера:

• Технические ограничения не учитываются при дизайне
• Инженеры критикуют дизайн, но без конструктивных предложений

От аналитика:

• Метрики никто не смотрит, решения принимаются на интуиции

Мои выводы:

• Это не конфликт между людьми, а конфликт процессов
• Недостаток прозрачности — команда не понимает why решений
• Отсутствие общего видения — каждый работает в своём мире
• Слабая коммуникация между инженерами и дизайнером

План решения

1. Встреча всей команды (рефрейминг)

Я организовал встречу с открытой повесткой (не планёрка, а именно диалог):

Мой opening: Я заметил, что в последние недели в команде появилось напряжение. Я несу за это ответственность как PM. Проблема не в людях — это процесс. Давайте вместе разберёмся, что не работает, и найдём решение. Я прошу честную обратную связь.

Структура встречи:

1. Каждый высказал, что его беспокоит (без критики)
2. Я показал связь между проблемами
3. Придумали общее видение: мы хотим разрабатывать качественный продукт с предсказуемым процессом

2. Новые процессы

Стабильность спринта:

• Требования блокировались за 3 дня до спринта
• Изменения в спринте только в экстренных случаях
• Результат: инженеры получили предсказуемость

Детализация требований:

• Я начал писать User Story с Acceptance Criteria вместо просто идей
• Добавил Definition of Done
• Инженеры теперь знают, что именно ожидается

Синхронизация дизайн-инженеры:

• Еженедельные tech design syncs (15 мин) перед спринтом
• Дизайнер показывает макет, инженеры говорят о ограничениях
• Результат: больше нет ситуаций, когда дизайн нельзя реализовать

Данные в решениях:

• Каждый спринт начинается с метрик, которые мы хотим улучшить
• На ретро смотрим, удалось ли их улучшить
• Аналитик помогает интерпретировать результаты

3. Культура обратной связи

• На ретроспективах стали давать I appreciate feedback перед критикой
• Учили команду различать проблема в человеке vs проблема в процессе
• Я личным примером показал, что OK ошибаться и просить помощь

Результаты

Через месяц:

• Производительность восстановилась и выросла на 12%
• На планированиях наступила спокойная атмосфера
• Инженеры начали сами предлагать улучшения процесса
• Дизайнер и инженеры стали коллаборировать, а не критиковать

Через квартал:

• NPS команды поднялся с 4 до 8
• Скорость разработки стабилизировалась
• На найме новых людей старые сотрудники сказали: вот это команда, в которой я хочу работать

Ключевые уроки

1. Проблема = процесс, не люди

• Конфликты часто не в характерах, а в системе, которая их создаёт

2. Слушай перед решением

• 1-on-1 разговоры дали информацию, которой не было на встречах

3. Прозрачность решает

• Когда люди понимают why, они перестают конфликтовать

4. Системность важнее единовременных мер

• Не достаточно одной встречи — нужны новые процессы

5. Ответственность PM

• Я не свалил вину, а принял ответственность за создание условий

Вывод: лучший способ решить конфликт в команде — это создать прозрачные процессы, где каждый понимает цели и свою роль. Люди конфликтуют не потому что они плохие, а потому что система создаёт трение.