Кросс-функциональное взаимодействие в ИТ: когда все правы, но ничего не работает
Введение
Один из ключевых навыков для руководителя команды разработки — умение договариваться с соседними отделами и командами. Без этого навык успешной реализации проекта часто остаётся только в теории.
В моей практике был случай, когда именно провал в кросс-функциональном взаимодействии стал причиной закрытия проекта. Причём это был не отдельный модуль, а часть масштабной системы для крупного заказчика.
Почему проект может развалиться, даже если всё работает
Проблема возникла на этапе автоматического развертывания — процесс шёл через общую среду и постоянно «сыпался» ошибками. Результаты работы были недоступны, и мы не могли продемонстрировать заказчику функционирующий продукт. Ответственность за развертывание лежала на команде DevOps. Однако все обращения к ним заканчивались одинаково: «У нас всё работает. Это у вас что-то не так».
Дошло до того, что DevOps открывали лог сборки и требовали устранить все предупреждения компилятора — несмотря на то, что эти предупреждения не были критичными и никак не влияли на процесс. Разработчики, понимая, что теряют время, сами находили ошибки в скриптах развертывания и предлагали конкретные правки. Но и это встречало сопротивление.
Иногда удавалось договориться с одним из сотрудников DevOps — вносились правки, ситуация вроде бы сдвигалась с мёртвой точки. Но вскоре появлялся другой сотрудник и откатывал изменения назад.
Результат был закономерен: проект стабильно срывал сроки. И не по вине команды разработки — у нас всё прекрасно работало локально. Но интегрироваться в общую систему и показать, как работает наш компонент, мы не могли. Сначала заказчик решил заменить всю команду. Но и новая не смогла наладить взаимодействие. В итоге проект закрыли.
Проблема «Мы и они»
В чём была суть конфликта? На мой взгляд, ключевая проблема — это типичный эффект «мы и они». Сотрудники DevOps воспринимали себя как более квалифицированных, более умных, более значимых для проекта, чем команда разработки. Поэтому любые попытки разобраться в проблеме заканчивались не поиском решения, а защитной реакцией: «Это не на нашей стороне, ищите у себя».
Это не про конкретных людей, а про типичную для организаций искажённую логику взаимодействия. Когда появляется ощущение, что «мы — это настоящие профессионалы», а «они — источник проблем», всё начинает сыпаться.
Эта модель хорошо описана в работах по организационной психологии. Впервые её обозначил Генри Минцберг, анализируя, как устроены внутренние структуры компаний. Позже тема получила развитие у Криса Аргириса, Дональда Шёна, Ричарда Бёрта и Джона Коттера — они изучали внутренние конфликты и барьеры в коммуникации между подразделениями.
Что такое «мы и они» в контексте бизнеса? Это одновременно психологическая и организационная проблема. Она возникает, когда команды внутри одной компании начинают воспринимать друг друга как чужих. Не как коллег с общими целями, а как внешних агентов, мешающих «нормальной» работе. В кросс-функциональном взаимодействии это приводит к недоверию, конфликтам и потере эффективности.
Типичные признаки этой ситуации:
Отделы фокусируются исключительно на своих задачах, игнорируя общую картину.
Другие команды воспринимаются как препятствия, а не партнёры.
Превалирует установка: «Наша работа важнее».
Взаимодействие происходит только по принуждению или в условиях крайней необходимости.
Одним из стандартных решений считается привязка конкретного сотрудника DevOps к проекту. Он становится ответственным за развертывание именно этой системы в общей среде. И если возникают проблемы, ответственность несёт он, а не команда разработки. Формально это логично: появляется конкретный человек, с которым можно говорить по делу.
Но на практике всё сложнее. Особенно когда в игру вступают культурные и организационные барьеры.
В том проекте, о котором я рассказывал, команда DevOps находилась в одной стране, а разработчики — в другой. Разный родной язык, разные ментальные модели, разные контексты. Более того, DevOps — часть компании-заказчика, а мы — подрядчик. И даже если логика требовала выделить отдельного человека и закрепить за проектом, реализовать это было сложно.
В моей практике подобные проблемы возникали неоднократно. История, которую я описал выше, — пожалуй, самая тяжёлая по последствиям. Но далеко не единственная.
Был случай, когда мы пытались подключить сотрудника к проекту, и всё упёрлось в доступы. Казалось бы, задача простая — выдать нужные права. Но этого так и не произошло. Системные администраторы компании утверждали, что «всё работает» и что проблема точно не на их стороне. Сотрудник остался без доступа, а проект — без нужного специалиста.
Была и другая ситуация — не менее абсурдная. Проблема с доступом действительно существовала, но она не решалась официально. Администраторы в упор не видели сбой, уверяя, что всё должно работать. В результате знания о том, как обойти эту ошибку, передавались от одного разработчика к другому как некое сакральное знание. То, что должно было решаться через нормальный рабочий процесс, фактически превратилось в шаманство. Системной коммуникации не было.
Проблема «мы и они» в ИТ — повсеместна. Она возникает не только на стыке ролей, но и на уровне технологий. Одна команда использует один язык программирования, другая — другой. Иногда языки даже технически близки, но отношения между людьми становятся скорее враждебными, чем партнёрскими.
Я наблюдал, как разработчики буквально «держались» за свой язык. Некоторые настолько привязаны к привычному стеку, что предпочли бы уйти из компании, чем переключиться на другую технологию. Причины не всегда эмоциональны. Многие просто боятся потерять профессиональную идентичность — особенно если язык менее популярен на рынке или хуже оплачивается. А зарплатные разрывы между направлениями в ИТ все прекрасно понимают.
Что с этим делать: как чинить разрывы между командами
Всё это — проявления той самой глубокой проблемы, о которой я уже говорил. Избавиться от неё полностью, скорее всего, невозможно. Чтобы работать с такими конфликтами, нужны не просто добрые намерения, а системный подход. Один из самых применимых в моей практике — теория структурных дыр Рональда Бёрта. (Structural Holes Theory, 1992).
Суть теории Бёрта проста и в то же время мощна. Внутри любой организации почти всегда существуют «структурные дыры» — разрывы между отделами, командами или даже отдельными людьми. Эти разрывы мешают обмену знаниями, тормозят процессы и часто становятся причиной конфликтов.
Чтобы преодолеть эти барьеры, Бёрт предложил создавать «мосты» — механизмы и роли, соединяющие разрозненные группы и обеспечивающие стабильную коммуникацию между ними.
Он выделил три ключевых инструмента:
Создание роли «брокеров» — людей, способных действовать на границе двух (или более) подразделений. Это не обязательно формальная должность, но в идеале — тот, кто понимает оба мира и может не просто передавать информацию, а интерпретировать её, преодолевая барьеры «мы и они». Часто именно такие «брокеры» становятся точкой синхронизации команд и несут ответственность за качество взаимодействия.
Развитие «слабых связей» — неформальных каналов между людьми из разных команд. В организациях, где сотрудники общаются не только внутри своих подразделений, но и с представителями других ролей и функций, работа идёт быстрее, а доверие между отделами выше. Такие связи формируют «социальный клей», который невозможно регламентировать, но именно он часто спасает в кризис.
Анализ и визуализация коммуникационных разрывов — то, что сейчас можно делать через внутренний анализ коммуникаций, соцграфов и карт взаимодействий. Кто с кем говорит? Кто остаётся изолированным? Бёрт предлагал использовать эту информацию, чтобы вовлекать изолированные команды в общие процессы, перемещать людей между подразделениями, разрушать стены, пока они не превратились в бетон.
На практике, теория Бёрта действительно помогает. Я сам применял её в работе и видел, как наличие «мостов» позволяет сглаживать конфликты и запускать сложные проекты, которые раньше буксовали.
Но — и это важно — в реальной жизни всё не так гладко, как на схемах.
В описанном выше случае формально у нас был человек со стороны DevOps, ответственный за взаимодействие с проектом. Однако вскоре он ушёл, а на его место пришёл новичок, который слабо понимал, как устроена система и что от него требуется. К тому же не все в команде DevOps были в курсе, что наш проект разрабатывается на другом языке программирования, с особыми нюансами при развертывании. Эти различия требовали внимания, но их попросту игнорировали.
Развить «слабые связи» тоже не удалось. Команда DevOps находилась в другой стране, принадлежала другой компании, и у нас не было ни физической, ни культурной возможности выстраивать живое взаимодействие. Мы находились в положении подрядчика, а DevOps — на стороне заказчика. В условиях неравного влияния руководство, естественно, чаще прислушивалось к ним.
Финал предсказуем: нашу команду заменили, а сам проект вскоре закрыли.
Заключение
Важно понимать: для того чтобы теория структурных дыр действительно работала, одних организационных механизмов недостаточно. Нужны ещё как минимум два условия: непредвзятое отношение со стороны руководства и готовность всех сторон признавать и устранять реальные проблемы, а не просто отмахиваться от них.
Добиться этого трудно. Но если не пытаться — точно ничего не изменится. Поэтому остаётся одно: стремиться строить мосты, даже когда почва под ними нестабильна. Надеяться, что встречный ветер не окажется ураганом. И делать всё, что в наших силах, чтобы проект выжил — даже когда все вокруг говорят: «У нас всё работает».
А вы сталкивались с эффектом «мы и они»? Что сработало у вас?
