Автор: Дмитрий Лавров, эксперт ritlid по работе с командами. Специализация — командная динамика, фасилитация, конфликты в управленческих группах. Дата публикации: 23 мая 2026.

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

Вопрос не в том, будет ли конфликт в проектной команде. Вопрос в том, когда он появится, насколько рано его заметит руководитель и что он с этим сделает. Конфликт, разобранный на стадии напряжения, занимает один разговор. Конфликт, дошедший до открытого противостояния или саботажа, может стоить проекту нескольких недель и части команды.

В этом материале — разбор того, как конфликты возникают именно в проектном контексте, чем они отличаются от конфликтов в постоянных командах, и что конкретно делает руководитель на каждой стадии. Подробный разбор типологии конфликтов и их стадий — в материале «Типы конфликтов в команде».

Проектная команда работает в условиях, которые системно повышают конфликтный потенциал. Это не вопрос характеров участников — это структурная особенность формата.

Первый фактор — временность. Участники знают, что команда существует ограниченный срок. Это снижает мотивацию инвестировать в отношения и договорённости: зачем выстраивать доверие, если через три месяца все разойдутся? Одновременно это создаёт дефицит времени на «притирку» — в постоянной команде конфликты сглаживаются со временем, в проектной этого времени нет.

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

Третий фактор — неравномерная нагрузка и ответственность. В проекте всегда есть те, кто несёт больший вес, и те, кто участвует номинально. Если это не проговорено явно, возникает ощущение несправедливости — один из самых устойчивых триггеров конфликта.

Четвёртый фактор — неопределённость ролей. В проектной команде роли часто не закреплены так жёстко, как в функциональных подразделениях. Кто принимает финальное решение по дизайну? Кто отвечает за коммуникацию с заказчиком, если проджект-менеджер недоступен? Белые пятна в ответственности — питательная среда для конфликта.

Конфликты в проектных командах не случайны. Они концентрируются вокруг нескольких типовых ситуаций, которые повторяются независимо от отрасли и масштаба проекта.

Сценарий 1. Конфликт приоритетов между участниками из разных подразделений. Разработчик в проектной команде одновременно ведёт три задачи в своём отделе. Когда руководитель проекта требует ускорить поставку, разработчик физически не может — и молчит об этом, потому что не хочет выглядеть некомпетентным. Напряжение накапливается, дедлайн срывается, начинается поиск виноватых.

Сценарий 2. Конфликт экспертных позиций. Два специалиста с разным профессиональным бэкграундом видят решение задачи по-разному. Технический директор настаивает на одной архитектуре, продуктовый менеджер — на другой. Оба правы в рамках своей логики. Если у команды нет механизма разрешения таких разногласий, дискуссия превращается в позиционный конфликт, где каждый защищает не решение, а свою правоту.

Сценарий 3. Конфликт вокруг признания вклада. Один участник сделал основную работу, другой представил результат заказчику и получил похвалу. Или наоборот: один взял на себя риск и провалился, другой дистанцировался и теперь не несёт последствий. Ощущение несправедливого распределения признания и ответственности — один из самых эмоционально заряженных конфликтов в проектной команде.

Открытый конфликт — это финальная стадия. До неё конфликт проходит несколько фаз, каждая из которых видна, если знать, на что смотреть.

Ранние сигналы, которые часто игнорируются:

• Участники перестают задавать вопросы на общих встречах — переходят в двусторонние переписки или молчат
• Сроки начинают «плыть» без объяснений — задачи выполняются, но с задержкой, которую никто не комментирует
• Появляются формальные коммуникации там, где раньше были неформальные: вместо звонка — письмо с копией руководителю
• Один из участников начинает избыточно документировать договорённости — это сигнал, что он готовится к защите своей позиции
• На встречах команды кто-то регулярно опаздывает или находит причину не участвовать

Более поздние сигналы, когда конфликт уже в активной фазе:

• Публичные разногласия на встречах с заказчиком или стейкхолдерами
• Эскалация через голову руководителя проекта к функциональным руководителям
• Открытые обвинения в некомпетентности или нелояльности
• Отказ от совместной работы — участник выполняет только свою часть и не взаимодействует с конкретным человеком

Инструментарий руководителя зависит от того, на какой стадии находится конфликт. Одно и то же действие — например, прямой разговор с участниками — даёт разный результат на стадии напряжения и на стадии открытого противостояния.

Стадия 1. Напряжение (конфликт ещё не осознан участниками как конфликт).

Задача руководителя — создать условия, при которых напряжение можно назвать вслух без последствий. Это не «поговорить по душам», а структурированный разговор один на один с каждым участником: что мешает работе, где ощущается трение, что нужно изменить. Важно не интерпретировать услышанное публично — собрать информацию, не создав новых поводов для конфликта.

Стадия 2. Осознанное разногласие (участники понимают, что у них разные позиции).

Здесь работает структурированная дискуссия: каждая сторона формулирует свою позицию и интересы за ней. Руководитель выступает фасилитатором, а не арбитром. Цель — перейти от «кто прав» к «что нам нужно для результата». Если разногласие экспертное — полезно привлечь третью сторону с авторитетом в предметной области.

Стадия 3. Открытый конфликт (участники не могут или не хотят взаимодействовать).

На этой стадии прямая фасилитация руководителем проекта часто не работает — он воспринимается как сторона или как источник проблемы. Нужен внешний фасилитатор или старший руководитель, у которого есть авторитет у обеих сторон. Задача — не примирить, а восстановить минимальный рабочий контакт, достаточный для завершения проекта.

Стадия 4. Последствия (конфликт формально завершён, но осадок остался).

Это стадия, которую чаще всего пропускают. Руководитель закрывает конфликт и идёт дальше. Но участники помнят, как их услышали (или не услышали), как распределили ответственность, кто «выиграл». Если не провести ретроспективу конфликта — те же паттерны воспроизведутся в следующем проекте с теми же людьми.

Конфликт в проектной команде редко бывает только межличностным. Чаще за ним стоит системная проблема: нечёткие роли, отсутствие механизма принятия решений, перегруженность участников параллельными задачами, нереалистичные ожидания заказчика.

Собственник ритейл-сети, 50 лет, оборот около 4 млрд ₽, обратился с запросом: «У нас третий подряд проект, который разваливается из-за конфликтов между командами. Меняем людей — ситуация повторяется». В ходе работы выяснилось, что проблема не в людях: в компании не было единого механизма приоритизации задач между проектами и операционкой. Каждый руководитель проекта решал этот вопрос по-своему, через личные договорённости. Когда договорённости не срабатывали — начинался конфликт. Решение потребовало не смены участников, а изменения структуры управления проектами.

Это важный принцип: если конфликты в проектных командах повторяются с разными составами — искать нужно не в характерах людей, а в системе, которая их окружает.

Подходит, если:

• Вы руководитель проекта или спонсор, и конфликт в команде уже влияет на сроки или качество результата
• Вы CEO или собственник, и видите повторяющийся паттерн конфликтов в проектных командах
• Вам нужен внешний фасилитатор для разбора конкретной ситуации — человек без истории в вашей компании
• Вы хотите выстроить систему управления конфликтами в проектной среде, а не тушить пожары по одному

Не наш формат, если:

• Конфликт носит юридический или трудовой характер — это зона HR и юристов, не фасилитаторов
• Вы ищете тренинг «как избегать конфликтов» — мы работаем с реальными ситуациями, а не с теорией бесконфликтного общения
• Один из участников конфликта уже принял решение уйти или уволить другого — здесь нужно управленческое решение, а не фасилитация

Главное отличие — временной горизонт и структура подчинения. В постоянном подразделении есть время на притирку и единая вертикаль власти. В проектной команде — жёсткий дедлайн, матричная подчинённость и участники, у которых есть другие приоритеты за пределами проекта. Это делает конфликты в проектном контексте более острыми и быстро развивающимися. Подробнее о видах конфликтов — в материале «Конфликты в команде: виды».

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

Полностью — нет. Снизить вероятность острых конфликтов — да. На старте проекта важно явно зафиксировать роли и зоны ответственности, механизм принятия решений при разногласиях и правила эскалации. Это не гарантия бесконфликтности, но это создаёт структуру, внутри которой конфликты разрешаются быстрее.

Три признака: участники перестают разговаривать напрямую и общаются только через посредников или письменно; появляются коалиции — «наши» и «не наши»; конфликт начинает влиять на людей, которые не являются его участниками (остальная команда вынуждена выбирать сторону или работать в условиях постоянного напряжения). На этой стадии без внешнего вмешательства конфликт редко разрешается сам.

Замалчивание — это тоже форма конфликта, просто пассивная. Руководителю стоит не пытаться «вскрыть» конфликт публично, а создать безопасные условия для индивидуальных разговоров. Вопрос «что мешает работе прямо сейчас?» даёт больше, чем «есть ли у нас конфликт?». Подробнее о причинах, по которым конфликты в командах не называются вслух, — в материале «Конфликты в команде: причины».

ritlid работает с управленческими командами в трёх форматах: разовая стратегическая сессия, квартальное сопровождение «Команда в потоке» и годовое партнёрство. Выбор формата зависит от масштаба задачи и горизонта, на котором нужен результат. Если конфликт в проектной команде — это симптом системной проблемы, а не разовая ситуация, — имеет смысл начать с разговора. Напишите на info@rittlid.ru: состав команды, контекст проекта, с чем именно столкнулись. Ответим в течение рабочего дня. Через кнопку «Записаться на консультацию» в футере тоже можно, но письмо с контекстом даст более точный ответ по формату работы.