Что будешь делать если сотрудник не хочет работать с другим сотрудником?

Стратегия разрешения конфликта между сотрудниками

Как Project Manager с 10+ лет опытом, я рассматриваю подобную ситуацию не просто как личный конфликт, а как проектный риск, угрожающий коммуникациям, командной динамике, срокам и качеству продукта. Мой подход будет системным, многоуровневым и сосредоточенным на интересах проекта, а не на поиске виноватых.

Поэтапный план действий

1. Немедленная реакция и сбор информации Первым делом я проведу индивидуальные встречи с каждым из сотрудников в формате confidential 1:1. Цель — понять корень проблемы, не создавая атмосферу суда. Я задам открытые вопросы:

• «Расскажите, с какими сложностями в совместной работе вы столкнулись?»
• «Что, на ваш взгляд, мешает эффективному взаимодействию?»
• «Каков идеальный, с вашей точки зрения, вариант решения?»

Ключевое правило на этом этапе — активное слушание и эмпатия, но без принятия чьей-либо стороны. Я буду фиксировать не эмоции, а конкретные факты и инциденты, влияющие на работу (пропущенные дедлайны из-за задержки информации, некорректный тон в таск-трекере, противоречивые технические решения).

2. Анализ и оценка влияния на проект На основе полученных данных я проанализирую ущерб:

• Тактический: Срывы сроков по текущим задачам, рост количества багов из-за плохой коммуникации.
• Стратегический: Падение морали команды, формирование коалиций, репутационные риски.
• Прямые потери: Снижение velocity команды, простои, необходимость переделки работы.

Я обновлю RAID-лог (Risks, Assumptions, Issues, Dependencies), внеся этот конфликт как Issue (проблему) или Risk (риск) с высокой вероятностью и воздействием.

# Пример записи в RAID-лог (концептуально)
Issue ID: T-022
Описание: Конфликт между разработчиком А (бэкенд) и разработчиком Б (фронтенд) блокирует интеграцию модуля Х.
Приоритет: High
Влияние: Срыв этапа интеграции (Milestone 3), оценка задержки — 5 дней.
Владелец: [Мое имя, PM]
План действий: 1. Проведение медиации. 2. Временное перераспределение задач. 3. Уточнение контракта интерфейсов (API).
Статус: In Progress

3. Медиация и поиск решения Если конфликт носит профессиональный характер (разные подходы к работе, конкурирующие технические решения), я организую совместную встречу — структурированную медиацию. Её алгоритм:

• Установить правила: уважение, один говорящий, без перебиваний.
• Каждая сторона излагает свою позицию, используя «Я-высказывания» («Я чувствую, что мои предложения не рассматриваются…» вместо «Он никогда не слушает!»).
• Совместно определяем проблему как общую: не «А против Б», а «Мы против проблемы интеграции API».
• Фасилитируем поиск рабочего решения: четкие договоренности о процессе (например, «все интерфейсы утверждаем в пул-реквестах», «ежедневный 15-минутный sync-up по интеграционным вопросам»).

4. Эскалация и организационные меры Если медиация не удалась или конфликт глубоко личный/этический, я, как PM, обязан эскалировать проблему:

• Горизонтальная эскалация: Привлечение Team Lead или Tech Lead для технического арбитража и пересмотра зон ответственности.
• Вертикальная эскалация: Информирование Functional Manager (руководителя линейного подразделения) или HR Business Partner. Предоставление им собранных фактов и вариантов решений: временное разведение по разным задачам/подкомандам, пересмотр ролей в проекте.

5. Рабочее решение «здесь и сейчас» Параллельно с разрешением конфликта я должен обеспечить выполнение плана проекта:

• Временное архитектурное решение: Перераспределить задачи так, чтобы минимизировать точки пересечения конфликтующих сторон. Например, назначить временного «интегратора» — третьего разработчика.
• Формализация интерфейсов: Жестко задокументировать контракты между их модулями (API spec, протоколы взаимодействия), сведя коммуникацию к обсуждению конкретных pull request.

6. Системные выводы и профилактика После решения ситуации я проведу ретроспективу, чтобы извлечь уроки на уровне процессов:

• Нужно ли улучшить onboarding?
• Достаточно ли четко прописаны RACI-матрицы (Responsible, Accountable, Consulted, Informed) в проекте?
• Стоит ли внедрить регулярные team-building мероприятия или тренинги по коммуникациям?
• Возможно, необходимы более четкие Definition of Done и код-ревью для снижения субъективных оценок.

Ключевые принципы, которых я придерживаюсь

• Проект превыше личности: Решение должно быть направлено на успех проекта, а не на угождение конкретному человеку.
• Конфиденциальность: Информация с 1:1 встреч не разглашается.
• Без осуждения: Я управляю поведением и процессами, а не выношу вердикты о характерах.
• Документирование: Все договоренности фиксируются письменно (в задачах, меморандумах, протоколах встреч).

Такой подход позволяет не просто «заткнуть дыру», а превратить конфликт в точку роста для команды и отладить процессы, предотвращая подобные ситуации в будущем.