Разбор ситуации(кейса) 9 для ПМа. Конфликты в команде.

Продолжаем разбор кейсов для ПМа. Вот ссылки на предыдущие разборы кейсов:

Девятый кейс про работу с наиболее часто встречающимися конфликтами в команде проекта.

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

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

Виды конфликтов в трудовом коллективе.

  • Межличностный.  Конфронтация двух людей выполняет ряд функций: познавательная – люди обмениваются знаниями и взглядами на мир; конструктивная – выстраивается логическая цепочка и понятийный аппарат по какому-либо вопросу; развивающая – участники все-таки соглашаются на какие-либо условия друг друга, так как стремятся сохранить хорошие отношения; инструментальная – в некоторых случаях конфронтация может стать способом избавления от какой-либо проблемы; деконструктивная – ведь ситуация может привести к ухудшению или прекращению общения. Только последний вид требует вмешательства руководителя
  • Межгрупповой. В межгрупповом конфликтовании нет ничего личного или индивидуального, а есть разные позиции одной группы по отношению к другой. Формы протекания межгрупповой конфронтации: — столкновение – агрессивная форма, сопровождающаяся причинением вреда; — избегание – плавный уход одной конфликтующей стороны от встречи с другой; — господство – один из социумов имеет больше преимуществ и возможностей; — соперничество – стремление получить определенные блага и богатства; — аккомодация – в результате давления один из конфликтующих социумов поддается давлению со стороны другого; — ассимиляция – в результате один из социумов постепенно перенимает уклад жизни и законы существования другого. 
  • Между человеком и группой.Причины появления конфликта между человеком и группой: — преднамеренное несоблюдение общегрупповых норм в угоду своих потребностей и ценностей; — непреднамеренное несоблюдение общепринятых правил в силу неопытности или непонимания их; — непринятие порядка работы в коллективе из-за ряда обстоятельств личностного характера; — разногласия в целеобразовании, поставленных задачах и методах из решения; — борьба за лидерство; — противоборство лидеров; — неудачные моменты и поиск виновного. Формами протекания противостояния могут быть: открытая и скрытая агрессия, притеснение, обвинения, нападки, блокада и санкции, критика, нарушение личностного пространства и др.

Алгоритм решения конфликтов в команде

  1. Определите, требует ли конфликт решения. Отличайте конструктивный рабочий конфликт, который не стоит решать, от деструктивного перехода на личности или реализации амбиций в ущерб рабочему процессу
  2. Определите, какие цели в конфликте преследуют конфликтующие. Зачем им надо конфликтовать? Нуждаются ли они в помощи или могут решить конфликт самостоятельно.
  3. Переводите участников конфликта от общих суждений к конкретным фактам. Задавайте уточняющие вопросы. Эти методы помогут им полнее понять ситуацию и уйти от излишних эмоций.
  4. Задавайте вопросы для выяснения мотива каждого из конфликтующих. Выяснив мотивы вы выясните пути решения конфликта. 
  5. Не принимайте ни одну из сторон конфликта и не принимайте решение за конфликтующих. Не критикуйте и не выносите суждений на этом этапе.
  6. Выслушайте обе стороны и попросите высказаться, какое решение конфликта они видят, договоритесь о совместном процессе. Каждый участник конфликта должен согласиться сотрудничать в разрешении конфликта.
  7. Выработайте пути решений.
  8. Достигните соглашения. Определите, что и как должно быть сделано, составьте план и временные рамки. Убедитесь, что ответственность за соглашение и действия лежит на сторонах конфликта и они это признают.
  9. Приступите к реализации решения

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

Кейсы конфликтов в команде.

Условие кейса 1:

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

Решение:

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

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

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

Подведем итог. Воспользуйтесь алгоритмом решения конфликтов выше. Вот как он будет выглядеть в данном случае:

  1. Соберите аналитика и техлида вместе с вами и выслушайте позицию каждого по сути конфликта, включая описание как, по их мнению, должно было быть.
  2. Не давайте скатываться в эмоции, общие обвинения и абстрактные заявления. 
  3. Запишите озвученные факты, аргументы и желаемый результат каждой из сторон с их слов. Не критикуйте, не выносите суждений, не принимайте ни одну из сторон.
  4. Выясните мотивы, чтобы выработать варианты решения. Если вашей экспертизы не хватает или вы не являетесь достаточным авторитетом для сторон конфликта, то возьмите паузу и привлеките третью сторону в качестве авторитетного мирового судьи.
  5. Разберите каждый аргумент из взаимных обвинений отдельно, попробуйте дополнить информацию, обучить. Спросите, какие действия можно предпринять по исправлению объективной проблемы, если такая будет среди аргументов. Предлагайте свой собственный план решения только в крайнем случае, иначе вся ответственность за исполнение перейдет на вас.
  6. Вовлекайте аналитика и техлида в выработку приемлемого решения конфликта, убедитесь, что они согласны взять на себя ответственность за исполнение решения.
  7. Если аналитик или техлид отказываются вести конструктивный диалог, предупредите о последствиях такого поведения и действиях, которые вы будете вынуждены предпринять с вашей стороны, как руководителя, для сохранения команды проекта (перевод на другой проект, увольнение, большой минус на регулярном performance review при обсуждении зарплаты и т.д.)
  8. Контролируйте исполнение решения.

Из моей практики:

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

Условие кейса 2:

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

Решение:

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

Вам стоит показать разработчику, что вы его услышали и серьезно относитесь к тем потенциальным рискам, которые он озвучивает: 

  1. напишите список решений, которые ваш разработчик считает неверными, затем попросите его написать аргументацию к каждому пункту.
  2. обсудите этот список с техническим контактом на стороне клиента, попросите его разъяснить, почему он принял то или иное решение, как он это аргументирует
  3. в случае сомнений, привлеките эксперта в вашей компании извне вашего проекта, который может дать еще одно мнение по поводу списка спорных решений и аргументов со стороны вашего разработчика и технического контакта на стороне клиента. 
  4. оцените озвученные риски вместе с командой и внесите их в реестр рисков. Если клиент не видит ваш реестр, то укажите эти риски в вашем регулярном отчете, который вы предоставляете клиенту. Если отчет еще не скоро — то хотя бы напишите email, где распишите риски, их влияние и ваш план митигации этих рисков. Поставьте в копию вашего разработчика или перешлите ему копию отдельно. 
  5. попросите вашего разработчика контролировать увеличение вероятности риска или его наступление, чтобы вовремя сообщить клиенту. 

Из моей практики:

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

Условие кейса 3:

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

Решение:

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

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

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

Из моей практики:

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

Условие кейса 4:

Разработчик очередной раз не уложился в оценку. При этом у остальной команды хороший результат. Как дать обратную связь?

Решение:

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

Решайте проблему, а не человека! Худшее, что вы можете сделать, это публично “разнести” разработчика перед командой фразами в стиле “опять ты, Петров, нас подвел”, “да ты надоел уже постоянно косячить”, “следующий раз не уложишься — я тебя оштрафую или уволю нафиг” и так далее. Все это приведет к глубокой демотивации и деморализации разработчика и, скорее всего, для вас и этого проекте этот разработчик будет потерян навсегда, работая, в лучшем случае, в пол силы, а то и вовсе саботируя процесс, мстя вам за унижение. Вы не можете “воспитать” человека или получить результат воззвав к его совести. Вы можете ругать его, выплескивая на него свой негатив, но, поскольку он уже не в силах изменить прошлое, это деморализует его, поставит в защитную позицию и не даст вам выйти на конструктивное решение этой проблемы на будущее.

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

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

Отдельно можно выделить случаи, когда изначальный план реализации не был согласован с техлидом и корректируется уже в процессе работы после получения обратной связи от техлида или архитектора. В этом случае больше внимания стоит уделить обсуждению задачи на командном планировании итерации (спринта) или согласовывать план реализации перед началом работы над задачей. Другая категория ошибок — когда описание задачи неоднозначное и допускает разные толкования, а также если требования меняются в ходе реализации. Это сигнал для бизнес-аналитика или менеджера, что не все в порядке с процессом сбора требований.

После того, как вы выяснили, в чем причина превышения оценки, составьте вместе с разработчиком список действий, которые вы можете предпринять для того, чтобы уменьшить вероятность повторения этой проблемы в будущем. Такими действиями могут быть: чек-лист оценки на самые частые ошибки, проверка правильности понимания с бизнес аналитиком, согласование плана реализации задачи с техлидом перед началом работы. Это позволит разработчику чувствовать себя увереннее и поддержит его мотивацию на дальнейшую работу. Стройте разговор с разработчиком так, чтобы он нес ответственность за выработку решения. Спрашивайте: “как ты думаешь, что тебе мешает оценить точнее?”, “Что я могу сделать, чтобы тебе помочь?”, “как ты считаешь, что надо сделать, чтобы бы тебе было легче не забыть проверить на вот эти частые ошибки при следующей оценке?”.

Отдельно менеджер может составить список собственных действия для предотвращения повторения этой проблемы, такие как: добавление буфера к оценке разработчика, перед передачей оценки клиенту (estimate padding, считается плохой практикой, применять только в крайнем случае), статистический анализ предыдущих оценок и затрат этого разработчика для вычисления коэффициента точности его оценок, чтобы следить за динамикой его изменения в дальнейшем, поиск ментора для работы со слабым знанием технологии или языка программирования и так далее.

Из моей практики:

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

Заключение

Отсутствие конфликтов — один из признаков группового мышления (groupthink) когда ни одно решение не воспринимается критически и не подвергается сомнению. Групповое мышление команды проекта было названо одной из причин в расследования крушения космического корабля Аполло.  Противоположность отсутствию конфликтов — когда их очень много и они парализуют работу команды, превращая ее в хаос. Важно соблюсти тот баланс, когда конфликты остаются конструктивными, дают возможность выработать наилучшее решение, внедрять новые методы работы, инструменты и подходы. В заключение я советую вам обратить внимание на групповую динамику, чтобы лучше понимать, на каких этапах жизни команды возникает наибольшее число конфликтов и как поддерживать их в нужном русле.

Дополнительное чтение по теме

  1. 7 эффективных стратегий поведения в конфликте
  2. Методы разрешения конфликтов: как и когда их применять
  3. Управление конфликтами в команде – эквилибристика или жизненная необходимость?
  4. 10 советов по решению конфликтов в коллективе
  5. Подход к разрешению конфликтов по методу IBR