Менеджер проектов в IT — это человек, который отвечает за результат, но не имеет формальной власти. И если дедлайны горят, а разработчик с тестировщиком устроили баттл уровня "Мортал Комбат", именно к тебе все приходят с вопросом "ну так что делаем?". В такие моменты PM рискует стать крайним: клиент ждёт результат, команда ждёт справедливости, а бизнес ждёт, что ты не превратишь конфликт в пожар.
Введение
Конфликт в команде звучит как что-то из психологии: "разные точки зрения", "проблемы коммуникации", "эмоциональное выгорание". На деле же всё проще и жёстче. Разработчик может сказать тестировщику "пиши баги нормально", тестировщик в ответ — "кодируй без багов". А ты сидишь между ними, как судья без свистка, но с KPI по срокам.
Я видел десятки кейсов: кто-то тушил конфликты авторитетом, кто-то уходил в сторону "разберитесь сами", а кто-то сгорал, потому что становился громоотводом и для команды, и для бизнеса. Давайте честно разберёмся, как PM-у разруливать конфликты и не оставаться крайним.
Теория: откуда вообще берутся конфликты в IT-командах
IT ≠ гармония
Команды состоят из людей. Люди разные: интроверты и экстраверты, "идеалисты" и "пофигисты". Добавьте сюда давление дедлайнов, баги на проде и непонимание требований — и у вас рецепт конфликта готов.
Конфликт = не всегда плохо
Важно понять: конфликт — это не катастрофа. Иногда он полезен. Если разработчик и дизайнер спорят, как лучше сделать интерфейс, это может привести к качественному решению. Вопрос в том, перерастёт ли спор в конструктив или в токсичное "ты всегда всё ломаешь".
Роль PM-а = фасилитатор, а не судья
Ты не прокурор и не судья. Твоя задача — не "назначить виноватого", а помочь команде найти общее решение. Как только ты выбираешь сторону, доверие ломается.
Практика: что реально помогает PM-у
1. Слушай обе стороны
Самая частая ошибка — выслушать того, кто громче кричит. Нужно дать слово всем. Иногда выясняется, что корень проблемы вообще в неверно описанной задаче, а не в том, что "Петя тупит".
2. Фокусируйся на задаче, а не на личностях
Никогда не допускай, чтобы обсуждение переходило на "он всегда так делает". Верни разговор к конкретике: "у нас баг в билде", "сроки сорваны", "непонятные требования".
3. Используй правило "доски"
Запиши проблему на доске (физической или виртуальной) — и обсуждайте именно её. Как только люди видят проблему вне себя, накал снижается.
4. Делай шаг назад
Иногда лучше вынести конфликт "из комнаты". Отправь людей остыть, потом собери митинг. Горячие споры редко заканчиваются конструктивом.
5. Фиксируй договорённости
Любое решение должно быть зафиксировано: в Jira, в Confluence, хотя бы в чате. Иначе завтра конфликт вспыхнет снова — и виноват будешь "ты, потому что не закрепил".
Мини-кейсы из практики
Кейс 1. "Баг или фича?" Разработчик залил новую функциональность, тестировщик завалил его багами. Разраб ответил: "Это не баг, это фича". Слово за слово — конфликт.
Что помогло: я вынес спор в формат "третьей стороны". Вместо "ты неправ" обсуждали "как это влияет на пользователя". В итоге договорились оформить всё через acceptance criteria, и эмоции улеглись.
Кейс 2. "Почему мы опять всё переделываем?" Дизайнер и продакт не могли договориться: макеты не принимались, потому что бизнес менял требования на ходу. Дизайнер взорвался: "Я не буду рисовать десятый раз!"
Что помогло: я собрал короткий митинг "post-mortem" прямо посреди спринта. Вместо поиска виноватого разобрали, где именно требования были недоопределены. Дизайнеру пообещали freeze макетов хотя бы на спринт. Конфликт ушёл.
Кейс 3. "Разработчик vs. клиент" Клиент на демо сказал: "Функция работает не так, как я хотел". Разработчик вскипел: "Так было в ТЗ!" Начался открытый спор.
Что помогло: я быстро остановил встречу, предложил фиксировать все "хотелки" как change request. Команда перестала чувствовать, что клиент "ругается на них", а клиент понял, что изменения будут учтены, но не бесплатно и не "прямо завтра".
Типичные ошибки PM-ов в конфликтах
- Становиться крайним — обещать клиенту одно, а команде другое. В итоге все недовольны, и виноват только ты.
- Назначать "виноватого" — даже если очевидно, что кто-то облажался. Лучше говорить "у нас сбой в процессе", а не "Вася сломал билд".
- Затягивать — конфликт не рассасывается сам по себе. Чем дольше ты ждёшь, тем больше эмоций и меньше шансов на конструктив.
- Уходить в "я не при делах" — если PM самоустраняется, команда теряет точку опоры.
Заключение
Разруливать конфликты — это не про "быть добрым" или "всем угодить". Это про умение держать рамку, слушать и переводить эмоции в действия.
Хороший PM в конфликте:
- не ищет виноватого, а ищет решение;
- фиксирует договорённости, чтобы завтра всё не началось заново;
- сохраняет нейтральность, но не уходит в сторону;
- защищает команду от давления бизнеса и бизнес от сбоев команды.
Тогда ты останешься не "крайним", а тем, кто реально держит проект под контролем.