От напряжения к пониманию: практики управления конфликтами в ИТ-команде

Введение

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

Иногда конфликты проявляются открыто, а иногда прячутся за внешним спокойствием. Если сделать вид, что их нет, они не исчезнут – напротив, будут зреть в тени и постепенно разъедать команду изнутри, лишая её энергии, доверия и смысла общих усилий.

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

Особенно это важно в командах разработки в ИТ. Такая команда – особая и хрупкая экосистема, где каждый по-своему уникален и талантлив. Здесь встречаются люди с разными характерами, взглядами и подходами к работе. В одной команде можно увидеть:

• Интровертов, для которых любое обсуждение – уже стресс;

• Перфекционистов, воспринимающих компромисс как личное поражение;

• Бунтарей, игнорирующих иерархию и «менеджерские игры»;

• Технарей, для которых люди – непредсказуемые переменные в уравнении.

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

Руководитель команды разработки должен уметь работать с конфликтами профессионально. Это не про жёсткие приказы и наказания, которые только создают видимость решения и подавляют проблему лишь на время. В такой работе важны внимательность к деталям, способность сохранять объективность и готовность разобраться, что именно стало искрой для спора. Зачастую корень конфликта не лежит на поверхности, а скрывается глубже – в разнице подходов к работе, несовпадении ожиданий или недосказанности в коммуникации. Поэтому важно не просто выслушать обе стороны, а постараться понять их мотивы, рассмотреть ситуацию целиком и учесть контекст: сроки проекта, распределение нагрузки, текущее настроение и атмосферу в команде. И главное – найти решение, которое не только сгладит разногласия здесь и сейчас, но и укрепит команду, снизит риск повторения подобных ситуаций и поможет ей двигаться дальше более уверенно.

Конфликты, о которых идёт речь в этой книге, взяты из реальной практики. Это не придуманные истории и не учебные примеры, созданные для упрощения темы. Каждая ситуация живая, со своими особенностями и множеством скрытых деталей. В одном случае могут переплетаться сразу несколько типов конфликтов: межличностный, профессиональный, статусный или ценностный. В реальной работе такие границы почти никогда не бывают чёткими, и то, что помогает в одном проекте, может оказаться бесполезным в другом. Здесь нет универсальных рецептов – важно уметь видеть контекст, замечать динамику происходящего и разбираться в нюансах, чтобы понять, что на самом деле лежит в основе противоречия.

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

Кроме того, книга уделяет внимание общим особенностям конфликтов в ИТ-командах. Читатель узнает, как их вовремя замечать и какие признаки указывают на начало напряжённости.

Рассматриваются методы профилактики конфликтов и практические инструменты, которые помогают не просто гасить ссоры, а решать их конструктивно. Это позволяет команде двигаться дальше без потерь в атмосфере и продуктивности.

Автор показывает, как понимать, когда спор перерастает в проблему, и какие приёмы реально работают в жизни команды, помогая сохранить доверие и сотрудничество между коллегами.

Эта книга – не просто сборник отдельных кейсов. Она объединяет многолетний опыт автора с проверенными подходами из профессиональной и академической литературы.

Цель книги – систематизировать знания и предложить читателю понятные, практичные методы работы с командной динамикой.

Она даёт инструменты, которые помогают руководителю видеть конфликты не как угрозу, а как возможность для роста и развития команды.

Что такое конфликт

У конфликта есть много определений, но ближе всего мне это:

«Конфликт – это процесс, начинающийся, когда одна сторона воспринимает другую как мешающую достижению её целей».

Оригинал : “Conflict is the process which begins when one party perceives that another has frustrated, or is about to frustrate, some concern of his.”

Thomas, K. W. (1976). Conflict and conflict management.

Конфликт – не всегда плохо. Он может быть деструктивным, а может быть продуктивным, всё зависит от того, к чему он приведёт. С одной стороны, он способен подтолкнуть к улучшению работы или продукта, с другой – обернуться разладом в команде, уходом сотрудников и падением эффективности. Эта мысль подробно раскрыта у Robbins, S. P. (2005). Organizational Behavior.

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

Конфликт с точки зрения команды, как системы

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

• W. Edwards Deming (1993). The New Economics for Industry, Government, Education

• Ludwig von Bertalanffy (1968). General System Theory: Foundations, Development, Applications

• Kurt Lewin (1947). Frontiers in Group Dynamics

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

С другой стороны, у системы есть внутренняя структура – правила, процессы, роли, иерархии – которые она старается сохранять и поддерживать. Любые изменения, даже если они кажутся логичными или полезными отдельным участникам, часто сталкиваются с сопротивлением. Это сопротивление не обязательно злонамеренное: система «защищает» себя, чтобы сохранить стабильность и предсказуемость. Подобно живому организму, она реагирует на вмешательства, оценивая риски и последствия, иногда замедляя изменения, чтобы не потерять устойчивость.

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

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

Как правило, система начинает меняться в нескольких случаях:

1. Когда она перестаёт эффективно выполнять свои функции и двигаться к цели. Система «чувствует», что прежние механизмы работы больше не дают результатов, и возникает необходимость поиска новых способов.

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

3. Когда вмешивается тот, кто стоит над системой. В нашем случае – это владелец компании. Его решения и действия могут инициировать изменения, направлять систему в новое русло или задавать новые правила игры.

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

5. Когда устраняются силы, стабилизирующие старое состояние системы. В нашем контексте это ключевые игроки в команде: если их убрать или изменить их влияние, команда как система начнёт перестраиваться и адаптироваться к новым условиям.

С точки зрения руководителя команды разработки, команда – это полноценная система. Она существует ради конкретной цели: проекта, над которым работает. Любые конфликты, внутренние или с внешними участниками, воспринимаются как воздействие на систему. Задача руководителя – понимать это воздействие и действовать так, чтобы система сохраняла работоспособность и адаптировалась к возникающим трудностям.

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

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

Специфика конфликтов в команде программистов

Конфликты в командах разработки имеют свои особенности, напрямую связанные с природой самой работы и тем, как она организована. Однажды я услышал фразу: «Программист – это станок и человек, который за ним работает, в одном лице». Мне нравится этот взгляд: он сразу объясняет специфику работы и те причины конфликтов, которые в ней неизбежно возникают.

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

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

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

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

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

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

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

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

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

В современной практике выделяют несколько причин конфликтов, характерных для программистов, работающих в одной команде:

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

2. Технические споры. В командах регулярно обсуждаются архитектурные решения, стиль кода, выбор инструментов и технологий. Разногласия здесь естественны, так как часто нет «единственно правильного» способа выполнения задачи.

3. Эго и авторство. Программисты могут ощущать сильную привязанность к своему коду. Любая критика может восприниматься как личное оскорбление, а не как профессиональное замечание.

4. Разные уровни компетенций. В командах бывают опытные специалисты и новички. Это порождает конфликты, когда более опытные считают, что новичок делает что-то неправильно, а менее опытные ощущают давление и недооценку.

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

6. Scrum и Agile-подходы. Быстрая итеративность, постоянные ретроспективы и регулярная демонстрация результатов могут обострять разногласия, особенно если команда не научилась конструктивно обсуждать проблемы.

Существует ряд публикаций, посвящённых причинам конфликтов в командах разработки. Ниже приведён список тех источников, которые мне кажутся наиболее полезными, с кратким изложением их основных идей:

1) Weinberg, Gerald M (1971). The Psychology of Computer Programming.

Программисты часто идентифицируют себя со своим кодом, а значит, критику кода воспринимают как критику себя, что делает конфликты особенно чувствительными.

2) Brooks, Frederick P (1975). The Mythical Man-Month

Брукс объяснял, что главные трудности в проектах связаны не с технологиями, а с тем, как люди общаются и согласуют работу. Когда роли и ожидания не проговорены, напряжение в команде накапливается. Я бы добавил: именно это часто становится почвой для конфликтов.

3) DeMarco, Tom & Lister, Timothy (1987). Peopleware: Productive Projects and Teams

Авторы показали: продуктивность зависит от атмосферы в команде куда сильнее, чем от инструментов. Токсичная культура, отсутствие доверия и организационные барьеры подтачивают команду изнутри. По сути, это и есть главные усилители конфликтов.

4) Lencioni, Patrick (2002). The Five Dysfunctions of a Team

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

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

Профилактика конфликта

"Высшее искусство войны – побеждать врага, не сражаясь." (Сунь-Цзы, Искусство войны)

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

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

Доверие

Почему руководителю не доверяют

Главную роль в построении доверительных отношений в коллективе играет руководитель. Его стиль управления и отношение к работе во многом формируют атмосферу в команде. На практике я наблюдал следующие поступки и шаблоны поведения руководителей, которые разрушают доверие:

• Попытки узнать, кто что думает, подслушивание сплетен.

• Наличие осведомителей в коллективе.

• Обсуждение проблем в стиле «мы все обсудили, и я решил».

• Поощрение соперничества вместо кооперации.

• Наличие «любимчиков» в команде.

• Давление на подчинённых при прохождении анонимных опросов.

• Публичные обвинения сотрудников при всех, с последующим извинением тет-а-тет.

• Систематические опоздания на все мероприятия – от прихода на работу до собственных митингов.

• Уничижительный тон или высмеивание кого-то за спиной.

• Демонстрация собственной исключительности: отказ включать камеру в онлайн-встречах, игнорирование рукопожатия и другие странные выходки.

• Резкие просьбы замолчать кого-то из подчинённых на митингах.

Приведённые примеры – это только те моменты, которые ярко запомнились. На самом деле при внимательном анализе можно обнаружить множество других ситуаций и деталей, где поведение руководителей влияло на доверие в команде.

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

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

Токсичные руководители

Я бы не назвал руководителей, о которых шла речь выше, самыми плохими. При всех их недостатках у них хотя бы была заинтересованность в результате и стремление защитить своё место, что в определённой степени мотивировало их действовать. Гораздо сложнее работать с другим типом руководителей – теми, кто просто «отрабатывает своё время».

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

Работая с такими руководителями, я никогда не был уверен, что они говорят правду. Всегда оставалось ощущение недосказанности, словно часть информации сознательно скрывалась или подавалась в искажённом виде. При этом, несмотря на все усилия, которые мы прикладывали для того, чтобы проект был успешным, часто всё заканчивалось плачевно.

Наблюдая за этим типом руководителей, я выделил пять характерных поведенческих моделей, которые особенно чётко проявляются в их работе:

1. Формальные исполнители.

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

2. Лояльные системе, но не делу.

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