Большинство людей предпочло бы избегать конфликтов. Как специалисты по проектам, мы знаем, что это неизбежно, и мы также знаем, что несогласие может быть конструктивным. Но при этом мы не любим конфликты, и большинство из нас надеется, что кто-то другой возьмёт на себя их разрешение. Что ж, с гибкими командами это может быть сложно, потому что команда должна быть самоорганизованной, а значит, никто не должен вмешиваться и исправлять что-то за нас. Что с этим делать?
Возможно, вы не склонны доверять статьям, в которых обсуждается управление конфликтами. Я уверен, что их авторы действуют из лучших побуждений, но говорить о стандартных моделях управления конфликтами, которым уже несколько десятков лет и которые не относятся к гибким концепциям, не очень полезно. В этой статье я хочу использовать другой подход. Никаких моделей, никаких уровней эскалации конфликта, только мой собственный опыт работы с конфликтами в гибкой команде. Без причинения какого-либо длительного ущерба и, возможно, даже с усилением команды в процессе.
Agile = больше конфликтов?
Давайте начнём с признания факта, что вероятность возникновения конфликта в Agile-командах намного выше, чем при большинстве других подходов к работе. Это не есть плохо, это просто неизбежно происходит из-за природы самоорганизованных команд. Отсутствие роли, которая принимает все решения от имени команды, означает, что решения принимаются на основе консенсуса, и что консенсус достигается только после рассмотрения, обсуждения и уточнения различных точек зрения. А на базовом уровне конфликт – это не что иное, как разногласия по поводу подходов.
Распространенное утверждение, что «конфликт может быть положительным» имеет под собой основание: когда рассматриваются и обсуждаются различные подходы, это часто приводит к лучшему общему решению, чем если бы один человек навязывал свой подход всей команде. Конфликт действительно может быть положительным, но не всегда. Такой позитивный настрой требует, чтобы команда была способна отделить разногласия по поводу определённой части работы от своих индивидуальных отношений с коллегами. И этот уровень разделения бывает трудно поддерживать, особенно когда команде не хватает контролирующей и регулирующей силы.
Это приводит к идее о том, что гибкие команды должны хорошо понимать различные модели управления и разрешения конфликтных ситуаций, чтобы распознавать проблемы и работать вместе над решением. Вот почему сторонники таких моделей также обычно являются сторонниками гибкого командного коучинга, проводимого либо скрам-мастером, либо специальным тренером. Что же, позвольте мне сказать, что я также большой поклонник гибких тренеров, и скрам-мастер явно играет ключевую роль в том, чтобы команда оставалась прочной и сосредоточенной. Но я ещё и прагматик. Успешное разрешение конфликта должно происходить изнутри, тогда оно станет успешным в долгосрочной перспективе. Внешнее вмешательство не решает никаких основных проблем в команде, оно просто маскирует их.
Разделение работы и личного конфликта
Ключом к управлению конфликтами в гибкой команде является способность проводить границу между разногласиями по работе и личными разногласиями. Когда мы работаем в «нормальных» условиях, мы все понимаем, что эти два понятия разделены. У нас могут быть разногласия по поводу того, как следует выполнять работу, но мы все равно можем наслаждаться компанией наших коллег, ходить с ними на кофе или обедать и болтать о вещах вне работы. Но когда напряжение в проектной ситуации нарастает, границы, разделяющие эти два элемента, могут быстро размыться. Лучшие Agile-команды – это те, которые не допускают размытости. Они не позволяют разногласиям по работе перерастать в личные разногласия.
Такое понимание требует, чтобы любой член команды мог привлечь внимание к тому, что конфликт становятся личным. Один из наиболее эффективных способов, который я видел, придумал скрам-мастер, который купил каждому в своей команде маленького плюшевого слона. Этих слонов брали с собой на каждое собрание. Если кто-то в команде думал, что разногласия становятся личными – вне зависимости от того, был ли он непосредственно вовлечён в конфликт – он бросал своего слона в центр стола для совещаний, выкрикивая «слоны в комнате!». И это было сигналом, что споры зашли слишком далеко и их нужно остановить.
Это сработало, потому что все члены команды пользовались доверием и уважением, а слоны помогали снизить напряжение. Трудно злиться, когда посреди стола сидит игрушка! И поскольку любой член команды мог вызвать ситуацию, когда разногласия заходят слишком далеко, было меньше шансов дойти до границы, после которой нанесён необратимый ущерб. Эта команда по-прежнему сталкивалась с определёнными конфликтами, но эти конфликты всегда касаются того, как добиться наилучшего результата проекта.
Разрешение личных конфликтов
Но мы живём в реальном мире. Бывают моменты, когда возникают личные конфликты, независимо от того, сколько у нас плюшевых слонов. И с ними нужно разбираться быстро и решительно, иначе все может легко разгореться, нанося непоправимый урон команде. Я видел ситуации, когда гибкие команды распадались, а участники расходились по другим командам, потому что они просто не могли больше работать вместе после того, как произошёл серьёзный личный конфликт. Это плохо для команды и для организации.
В традиционной проектной среде ответственность за разрешение командного конфликта возлагается на менеджера проекта, а в гибкой команде решать должна сама команда. Если требуется тренер или скрам-мастер, значит, команда не выполнила свои обязательства перед собой. Это коллективная ответственность: в разрешении ситуации должна быть задействована вся команда, а не только один или два человека, вовлечённых в конфликт.
Это может быть сложно. Всегда существует риск того, что конфликт между двумя людьми привлечёт других членов команды, которые «встанут на чью-то сторону». Но я бы предпочёл пойти на такой риск, чем вообще не заниматься конфликтом. Если команда обычно может хорошо работать вместе, они должны иметь возможность открыто говорить о причинах разногласий, понимать, почему ситуация накалилась, и соглашаться двигаться вперёд. Я не настолько наивен, чтобы думать, что раны заживут сразу, но команда должна сосредоточиться на будущем, а не возвращаться к прошлому.
Это требует от команды осознать, что любой личный конфликт ведёт к провалу всей команды. Конечно это конкретные люди поссорились друг с другом, но каждый в команде допустил такое развитие событий, поскольку не проявил ситуацию, не распознал предупреждающие знаки и не спрогнозировал в перспективе к чему может привести то, что началось как незначительное разногласие. Для разрешения конфликта все члены команды должны согласиться с общими правилами:
- Закрытый спор больше никто не будет открывать вновь
- Никто не станет вести себя иначе по отношению к коллеге
- Любой член команды будет пресекать любую активность, которая, по его мнению, противоречит указанным выше пунктам
Это не так уж сложно. Я не уверен в необходимость просить членов команды извиниться друг перед другом – они поймут это сами, и это будет более значимо, чем если бы на них не оказывали давление. Если команда по-настоящему привержена этим правилам, они смогут быстро преодолеть конфликт. И развитие проекта будет затронуто лишь на небольшой промежуток времени.
Выводы
Конфликт в Agile-командах отличается из-за отсутствия чёткой контролирующей роли в команде. Для команды важно иметь возможность разрешать конфликты внутренне, потому что так будет укрепляться сплочённость людей. Нет проблем с привлечением тренеров и скрам-мастеров, обеспечивающих поддержку, но это должно быть сделано таким образом, чтобы команда сохраняла свободу принятия решения. Мы ожидаем, что наши agile-команды будут действовать самоорганизованно для всех остальных аспектов проекта, поэтому мы не можем лишить их этой свободы, как только возникнут разногласия. Если мы это сделаем, мы заставим людей задаться вопросом, насколько они действительно свободны управлять своей собственной работой, и это серьёзный риск для будущей производительности команды.
Энди Джордан
Оригинал статьи: https://www.projectmanagement.com/articles/643731/Handling-Conflict-on-Agile-Teams
