Александр Королев – От напряжения к пониманию: практики управления конфликтами в ИТ-команде (страница 5)
• Доверительный круг – стоя в кругу, участники по очереди покачиваются, а остальные поддерживают.
• Игра "Две правды и ложь" – каждый называет два правдивых факта о себе и одну ложь; остальные угадывают ложь.
• Общая карта – коллективное рисование карты (например, "путь к успеху проекта"), где каждый добавляет что-то своё.
• Совместное решение загадок или escape room – командные квесты для развития координации и взаимного уважения.
Не обязательно применять всё из вышеописанного, но использование хотя бы некоторых практик, техник, мероприятий или игр может значительно помочь команде в формировании доверия друг к другу. Важно подбирать методы исходя из особенностей коллектива и личности руководителя, чтобы они действительно работали, а не вызывали обратный эффект.
Общая цель
"Команда без цели – это просто группа людей, занятых чем-то одновременно." (Неизвестный автор)
Другим способом снизить вероятность конфликтов является ясная и понятная цель для всей команды. Когда все работают над общей задачей, люди готовы закрыть глаза на раздражители, которые могли бы привести к конфликту, и направить свою энергию на достижение результата. Команда становится сплочённой и действует как единое целое. Но далее ситуация может пойти следующим образом:
Ситуация первая: Цель достигнута – проект создан и переходит в фазу поддержки и доработок.
На этом этапе команда может потерять интерес: кто-то испытывает эйфорию от успеха, кто-то ощущает снижение нагрузки, а у кого-то возникает чувство, что дальнейшая работа потеряла смысл. Может появиться общее мнение: «Главная цель уже достигнута, а всё остальное – не так важно».
В такой момент задача руководителя – показать команде ценность нового этапа. Нужно перераспределить задачи, обозначить приоритеты и четко озвучить новые цели: устранение технического долга, рефакторинг, внедрение улучшений. Правильная мотивация на этом этапе помогает команде сохранить драйв и работать как единое целое.
В моей практике был такой случай. Нужно было срочно реализовать один объёмный и очень важный проект. Предыдущая команда пыталась справиться с задачей, но не смогла, и её начальник был уволен, а сотрудники отстранены от работы над проектом. Решено было собрать полностью новую команду вместе с её руководителем.
Новички оказались под огромным давлением. Все понимали, что ещё одна неудача будет иметь серьёзные последствия. И тем не менее, именно в этой ситуации команда стала невероятно сплочённой. Было всё: взаимопомощь и поддержка, доброжелательное руководство, готовое откликнуться на любую просьбу, добровольные переработки ради общего успеха. Люди искренне увлеклись проектом, работали с энтузиазмом и отдачей. Совместные посиделки, дружеские разговоры, смех в офисе – всё это создавало особую атмосферу. Один из коллег с большим опытом сказал, что такого удовольствия от работы у него никогда раньше не было.
Проект был завершён и сдан – успешно. Были премии, повышения, похвальные речи и всеобщее признание. На этом этапе казалось, что команда стала настоящей семьёй.
Но потом цель пропала. Руководству предложили отложить дальнейшую работу над проектом и помочь другому отделу, и оно согласилось. Для команды это стало ловушкой: наработки присвоил другой отдел, а сама группа осталась без общей задачи. Теперь люди занимались разрозненными заданиями, каждый сам за себя. Ключевые игроки начали уходить, возникла скрытая борьба за влияние и лидерство, нагрузка распределялась неравномерно, а дружеская атмосфера ушла. Вчерашние друзья становились соперниками, рабочие будни стали серыми и унылыми.
Как видно из этого примера, именно наличие общей цели поддерживало дружбу, сплочённость и энергию команды. Как только цель исчезла, команда развалилась, конфликты выросли, а работа потеряла смысл.
Вывод: чтобы команда была сплочённой, избегала конфликтов и добивалась успеха, у неё всегда должна быть одна общая, чёткая и ясная цель.
Ситуация вторая: Цель проекта перестаёт быть понятной. В процессе работы могут возникнуть причины, не зависящие от команды, которые ставят проект под угрозу закрытия. Таких причин может быть много, но все они неизменно сказываются на атмосфере в коллективе.
Вспоминается такой проект: команда разрабатывала систему с GPS-датчиками, закрепляемыми на контейнерах с грузом. Идея была проста – в любой момент можно было узнать точное местоположение контейнера. С точки зрения программного обеспечения всё работало отлично. Но возникла проблема с аккумуляторами для датчиков: выяснилось, что они не смогут обеспечить требуемое время автономной работы. Из-за этого проект оказался под угрозой закрытия, но разработка при этом продолжалась.
Команда была в курсе этой критической проблемы и понимала, что финансирование в любой момент могут внезапно остановить. По этой причине она стала работать менее интенсивно, утратился прежний вдохновлённый энтузиазм. Возникли конфликты на почве различных противоречивых программных подходов, даже фактически саботировалось одно перспективное инновационное решение, которое очень впечатлило заказчика. Рабочая нагрузка стала постепенно падать, и двое ключевых разработчиков в итоге переключились на другие проекты, хотя формально продолжали числиться в команде. Никто не понимал, чего ожидать от неопределённого проекта, который в любой момент могли полностью закрыть.
В такой непростой и неопределённой ситуации крайне сложно найти новую ясную и мотивирующую цель, имеющую реальный смысл. Как минимум необходимо довести проект до стабильного состояния, устранить все критические ошибки, провести тщательное тестирование. Возможно, удастся сохранить какую-то ценную часть проекта и использовать её в других разработках, переписав фрагменты кода в виде подключаемых модулей. Но новая общая цель в этой ситуации абсолютно необходима, ведь без неё могут быстро возникнуть острые конфликты, усилиться текучка кадров и, в худшем случае, произойти полное разрушение команды.
Ситуация третья: Заказчик внезапно меняет планы и стратегические цели проекта, и команда перестаёт понимать, что именно она делает. Постоянно переписываются крупные или мелкие куски кода, теряется общий смысл работы.
Такая ситуация, к сожалению, не редкость. Бывает, что на стороне заказчика происходят кадровые перестановки, и новые люди радикально меняют требования к проекту. Либо на каком-то этапе могут случаться резкие корректировки, требующие масштабных переделок.
Я наблюдал в своей практике ситуацию, когда поменялся Product Owner проекта, и новый руководитель начал сильно менять требования. Это демотивировало команду, и вскоре начались острые конфликты. Внезапно самый эффективный разработчик стал неуспевающим, другой покинул проект, вместе с ним ушёл один из тестеров. Качество сделанной работы стремительно падало, и проект в итоге был закрыт.
В такой нестабильной ситуации у людей пропадало понимание того, что они делают и зачем. Чтобы снизить риск подобных последствий, необходимо постоянно напоминать команде о глобальной, стратегической цели проекта и выяснять у заказчика причины и смысл новых изменений, чтобы донести их всей команде. Иногда смысл изменений действительно остаётся непонятным. В этом случае стоит собрать команду и совместно выработать адаптивную стратегию: возможно, изменить архитектуру проекта так, чтобы можно было в любой момент корректировать отдельные части, не переписывая весь код.
Важно донести до команды идею, что, несмотря на любые непредсказуемые изменения, основная задача – это достижение глобальной цели продукта. Если цель становится неясной и теряет смысл, необходимо задавать вопросы и прояснять её, чтобы каждый участник команды понимал и разделял её. Цель должна быть ясной, конкретной и понятной всем.
Далее приведены идеи известных авторов о важности общей цели для команды; здесь они даны в моей интерпретации через призму профилактики конфликтов:
1. Stephen R. Covey (1989), The 7 Habits of Highly Effective People
Кови подчёркивает важность общей цели и согласованности действий. В логике его подхода это можно рассматривать как фактор, помогающий снижать недопонимание и риск внутренних конфликтов, особенно в межфункциональных проектах.
2. Patrick Lencioni (2002), The Five Dysfunctions of a Team
В его модели отсутствие вовлечённости часто связано с неясностью цели. Он отмечает, что ясная цель формирует приверженность и снижает неуверенность. В этой книге эта мысль интерпретируется через призму конфликтов: ясность целей помогает перейти от скрытого недовольства к более здоровым обсуждениям.
3. Simon Sinek (2009), Start With Why
Команды работают лучше и с меньшими внутренними конфликтами, если понимают «почему» – глубинную цель проекта или компании. Когда участники разделяют это «почему», они чаще проявляют эмпатию, поддержку и гибкость в совместной работе.
4. Simon Sinek (2014), Leaders Eat Last
Лидер должен создать «безопасную среду» (Circle of Safety), где люди чувствуют себя защищёнными и понимают общую цель. Такая среда снижает тревожность и уменьшает склонность к враждебному поведению внутри команды.
5. J. Richard Hackman (2002), Leading Teams: Setting the Stage for Great Performances