Мир, труд, конструктив: чему нас учат ссоры в команде

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

Привет! Меня зовут Елизавета Саленок, и я уже 8 лет занимаю позицию продакт-менеджера, 3 из них в Битрикс24. По долгу службы я веду команды, в которых есть специалисты разных компетенций. По сути я проводник между гениальными решениями продуктового отдела и людьми, ответственных за техническую реализацию этих самых идей. В этой статье я собрала свой опыт управления командами и решения конфликтов.

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

«Тишина = эффективность» — миф.
На деле это часто индикатор подавленной инициативы: сотрудник предпочитает согласиться «на публику», а потом чинить по‑тихому — или вовсе саботировать решение, которое считает ошибочным.

«Ругаются только токсики» — тоже миф.
Жаркая дискуссия сама по себе не токсична. Опасность начинается, когда обсуждение скатывается в личности или уходит в подковерные бурчание.

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

Когда команда учится воспринимать трение как штатную диагностику, спринты становятся короче, а «скелеты» не накапливаются в бэклоге годами.

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

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

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

Кстати, переделки так и не ушли в прод, так как, когда разработчик все-таки написал код, бизнес-реалии продиктовали требование приступить к другим задачам, поэтому работа ушла в стол.

Это был классический сценарий избегания. Когда человек не отказывается прямо, но и не идёт навстречу. Он не говорит «нет», но и не начинает делать.

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

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

Хуже всего, что обе стратегии — реакция не на суть конфликта, а на отсутствие среды, в которой можно безопасно обсуждать разногласия. Люди боятся быть «слишком резкими» — и молчат. Боятся быть проигнорированными — и атакуют первыми. А продукт в это время стоит на месте.

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

Вовремя поднятый конфликт показывает, что именно в корпоративной машине неисправно:

Параллельно конфликт даёт бонус-информацию — людям не всё равно. Если бы было все равно, они бы тихо закрывали задачи, убивая в себе инициативность.

Спор может остаться продуктивным, если соблюдать эти правила:

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

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

Самые частые поводы я наблюдала десятки раз.

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

И формально обе стороны правы. Только вот никакой общей цели у команды при этом нет, зато есть конфликт метрик.

Неразделённая ответственность
Бывает и так: зона кажется общей, но в реальности она — ничья. Два продакта курируют один модуль. Один отвечает за B2B-функциональность, другой — за кастомизацию. Но в багтрекере задачи перемешаны, процессы не отстроены, и каждый из них считает, что его голос должен быть последним.

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

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

И даже если внешне спор о задаче, по факту — борьба за статус.

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

За несколько лет в продуктах я поняла, что работа с конфликтами держится на трёх китах: культура, навыки и лидерство.

Культура в команде — это не мотивационные постеры и не тосты на корпоративе. Это то, что считается нормальным.

Например, у нас ретроспектива — это не ритуал покаяния, а рабочая встреча, где можно сказать: «Ребят, в прошлом спринте мы немного просели, вот несколько причин…». Просто как факт, чтобы сделать вывод и двигаться дальше.

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

Конфликт чаще всего портит не суть, а форма. Люди говорят «что за фигня» вместо «у меня есть сомнения», перебивают вместо уточнения, защищаются вместо вопроса.

Поэтому команде нужно прокачивать навыки коммуникации.

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

Лидеру важно не становиться ни судьей, ни «батей», который делит банан между дерущимися детьми, а фасилитатором пространства, в котором конфликт — не катастрофа, а способ добраться до истины.

Как это выглядит на практике?

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

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

Так шаг за шагом команда становится не тише, а сильнее.