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

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

Вот ссылки на предыдущие разборы кейсов:

• Разбор кейса 1. Начало проекта.
• Разбор кейса 2. Риски.
• Разбор кейса 3. Оценка даты завершения и размера команды.
• Разбор кейса 4. Коммерческое предложение (Proposal)
• Разбор кейса 5. Коммуникация о проблемах на проекте
• Разбор кейса 6. Коммуникация на проекте.
• Разбор кейса 7. Отчет по проекту.
• Разбор кейса 8. Согласование запросов на изменение (CR).

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

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

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

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

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

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, считается плохой практикой, применять только в крайнем случае), статистический анализ предыдущих оценок и затрат этого разработчика для вычисления коэффициента точности его оценок, чтобы следить за динамикой его изменения в дальнейшем, поиск ментора для работы со слабым знанием технологии или языка программирования и так далее.

Из практики:

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

Заключение

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

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

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