В командах, особенно быстро растущих, конфликты — не редкость. И часто они возникают вовсе не из-за личных антипатий, а из-за размытой структуры полномочий.
Кажется, вот появился новый человек, чтобы помочь… но почему-то вместо облегчения становится только сложнее. Один руководитель — это порядок. Два — это борьба. Особенно если старый — «свой», а новый — новичок с инициативой.
Эта история — именно о таком конфликте. О том, как даже при лучших намерениях можно оказаться в ловушке амбиций, иерархий и негласных правил игры.
Конфликт полномочий
В одной компании решили расширить команду, так как появилось дополнительное финансирование и новые задачи. На момент расширения в ней были разработчики, тестеры и один руководитель проекта, но не было руководителя команды разработки. Его взяли, и между ним и руководителем проекта возник конфликт, так как новый человек стал ставить и распределять задачи и оценивать сроки, что не понравилось руководителю проекта.
Тогда руководитель команды решил просто писать код, фактически превратившись в старшего разработчика, но это тоже вызвало недовольство, только уже со стороны заказчика и руководства более высокого ранга.
Ситуация очень непростая, так как тут с одной стороны компания хочет что-то изменить в проекте, с другой — руководитель проекта, который не хочет терять свою власть и влияние.
Здесь главное понять, что, чаще всего, пока в команде есть лидер, он просто так своими полномочиями не поделится и, скорее всего, даже начальство, которое стоит над ним, не сможет на него повлиять, либо не захочет. У руководителя проектов изначально сильная позиция, он старожила и возможно “свой человек”, а вот у руководителя команды разработки позиция слабая, он – новичок.
Понятно, что раз взяли ещё одного руководителя, значит с текущим проектом ситуация непростая и надо что-то менять. Но с другой стороны — рисковать и “делать ставку” на новичка навряд ли будут.
Если вы оказались в такой ситуации, когда с одной стороны есть полномочия, а с другой — отсутствие влияния и внутреннее сопротивление, я бы предложил действовать следующим образом.
В моей практике было несколько подобных случаев, и было перепробовано множество подходов и вариантов. В итоге, я остановился на таком алгоритме:
1) Обсудить ситуацию один на один с руководителем проекта.
Для этой ситуации очень хорошо подходит фраза: “Great managers are servants, not bosses” из книги Robert K. Greenleaf (1970). The Servant as Leader. Так как его не убрали, значит ваша задача ему помочь. Вам надо закрыть “дыры”, а не взять на себя часть полномочий.
Тут надо учитывать ещё один момент из теории систем. Любая система противится изменениям, она скорее подстроится под них, но не поменяется. Поэтому двигать и менять руководителя проекта или его полномочия скорее всего никто не будет.
2) По возможности, работать через руководителя проекта.
Вы предлагаете ему решения, а он уже озвучивает их команде. Он может начать саботировать ваши предложения, и чтобы за этот саботаж вам не прилетело, документируйте всё, что вы говорите. После каждого разговора с ним надо писать ему письмо с итогами обсуждения, в котором чётко прописывать то, о чём вы договорились.
Если будете работать напрямую с командой, то рискуете усложнить ситуацию, особенно если у вас будут хорошие результаты. Это может обострить конфликт с руководителем проектов. К сожалению, вам надо вытаскивать его, а не команду.
3) Не поддавайтесь давлению "сделай сам".
Может так случиться, что руководитель проекта будет во всём винить команду и её слабые технические знания. Он попросит вас написать код самому и сделать из него “конфетку”, а уж с руководством в проекте он сам отлично справится. Не спешите этого делать.
С командой надо работать так же, как и с руководителем. Если вы всё перепишете и сделаете лучше, у вас начнутся проблемы с коллегами, которые писали этот код до вас. Их ведь тоже никто не снимал с проекта, когда вас брали.
В итоге, вы рискуете писать весь код проекта один, а все остальные будут очень тщательно всё проверять и ждать, когда вы споткнётесь.
Также в моей практике была ситуация, когда неформальные лидеры проекта не давали возможности изменить свой код. Например, руководитель группы разработки хотел переписать очень кривой модуль, но его попросили сначала написать интеграционные тесты к этому модулю, чтобы гарантированно сохранить его текущий функционал.
А написание этих тестов было очень трудоёмкой задачей, и он на пару месяцев “потерялся” в своей работе. Когда он, наконец, их написал, выяснилось, что процентов 80% текущего функционала этого модуля давно устарело и не используется. Причем те, кто просил написать ему эти тесты, знали об этом заранее. На мой взгляд, это был такой скрытый саботаж с целью избавиться от такого активного новичка.
Надо понимать, что никто не хочет терять свою власть и свою позицию. В команде присутствует скрытая иерархия, каждый сидит на своём месте. Есть теневые лидеры, есть те, кто хочет их подвинуть. Одни начнут использовать вас в своих целях, другие попытаются устранить.
4) Взаимодействовать с руководителями высшего звена тоже надо осторожно.
Среди них будут те, кто хочет избавиться от руководителя проекта, и те, кто наоборот желает его сохранить. Для тех, кто хочет избавиться — нужен компромат и конфликт, а для противоположной стороны — наоборот, надо показать, что он отлично справляется, а остальные только мешают ему работать.
Ваша задача — не играть в их игры. Помните, что вы новичок, и скорее “сольют” вас, чем его. Просто у кого-то будет больше компромата, либо у кого-то усилится позиция, но в этой игре навряд ли вы будете ключевой фигурой.
5) Постепенно формируйте своё поле влияния.
Не надо спешить. В коде начните с ревью, займитесь улучшением качества кода. Ищите те зоны, которые не входят в чью-то сферу ответственности. С точки зрения руководства, можно создать метрики, взять на себя контроль за документированием проекта.
Старайтесь работать через других, чтобы они росли, а вы уже повышали свой авторитет через них.
6) Установите контакты с другими отделами.
Помогите команде обновить устаревшее оборудование, договоритесь с отделом DevOps о каких-то улучшениях, разберитесь с доступами, организуйте обучение. Вам нужно стать с одной стороны лицом команды в компании, а с другой — человеком, который решает проблемы команды при взаимодействии с другими отделами.
Обычно за эту сферу деятельности нет сильной конкуренции, но это очень важно — наладить мосты между отделами.
7) Следите за своим выгоранием и эмоциональным состоянием.
Такие ситуации сильно выматывают. Ваша задача — сохранить жизнеспособность вашей роли в компании. Многие захотят от вас избавиться или минимизировать ваше влияние, и с этим надо будет постоянно бороться.
Может так получиться, что вам не удастся занять то место в компании, на которое вас брали. В такой ситуации надо понимать, что лучше уйти, чем сломаться.
8) Думайте о долгосрочной стратегии.
Помните, что вы “новичок”, но это временно, и этот статус рано или поздно изменится. К этому моменту надо заработать достаточный авторитет, чтобы стать частью системы и уже иметь возможность влиять на неё изнутри.
Для успешного решения этой ситуации так же надо стараться не играть по чужим правилам. Если у вас в голове идет подсчет выигрышных и проигрышных партий, то вы уже играете по ним. Ещё надо отказаться от установки, что до вашего прихода была лишь тьма, а вы несете только свет.
Помимо этого, не стоит спешить с какими-то действиями, лучше с начала хорошо все обдумать. В этой ситуации надо быть готовым к тому, что придётся менять свои же решения на ходу, так как чаша весов постоянно колеблется и то, что выглядело разумным вчера, сегодня может измениться.
Теория: как это видят эксперты
То, что я описал выше — это мой личный, практический подход, который я выработал на основе реальных ситуаций и наблюдений. Он не претендует на универсальность — кому-то он может подойти, кому-то показаться слишком мягким или, наоборот, жестким.
Если вам ближе системный взгляд или вы хотите рассмотреть ситуацию с точки зрения признанных теорий, можно обратиться к подходам, описанным в работах разных авторов. Возможно, они подскажут вам другие решения или дадут язык, на котором проще будет обсуждать происходящее с коллегами или руководством.
Подходы в литературе:
1) Адизес описывает четыре управленческих роли: Производитель, Администратор, Предприниматель, Интегратор.
Конфликт может возникнуть, если два управленца действуют из разных ролей:
Руководитель проектов, скорее всего, играет роль Администратора (контроль, сроки, структура)
Руководитель команды разработки может действовать как Производитель и Предприниматель (новые решения, техническое лидерство, планирование)
Решение: провести совмещение ролей или их чёткое распределение: кто за что отвечает в плане ролей Адизеса.
Adizes, I. (1988). Corporate Lifecycles
2) Вудкок и Фрэнсис поднимают тему неопределённости ролей как одной из главных причин конфликтов в команде.
Команда растёт → роли меняются → если они не оговорены, происходит конфликт.
Решение:
Провести сессию по ролевой ясности: кто за что отвечает, кто с кем взаимодействует.
Можно использовать матрицу RACI (Responsible, Accountable, Consulted, Informed).
Woodcock, M., & Francis, D. (1981). Team Development Manual
3) Никитин указывает, что в российских организациях часто силен фактор неформальной иерархии и ожиданий "старшинства".
Руководитель проекта мог воспринять приход руководителя команды разработки как угрозу его позиции (особенно, если раньше он был главным координатором).
Решение:
Обратиться к высшему руководству с просьбой разъяснить и формализовать зоны ответственности.
При этом важно сохранить лицо обеим сторонам, чтобы избежать эскалации.
Никитин В.Ю. (2004). Управление организационными конфликтами
Заключение
На мой взгляд, это достаточно напряжённая ситуация, требующая серьёзных усилий и терпения. Думаю, что мой подход будет полезен и поможет вам справиться с таким видом конфликта.
Но главное, что стоит запомнить: как бы ни складывались роли, формальные и неформальные иерархии — важно сохранить себя. Свои границы, спокойствие и способность мыслить стратегически. Не влезать в чужие игры, не поддаваться провокациям и не думать, что вы должны немедленно “побеждать”.
В таких конфликтах выигрывает не тот, кто громче, а тот, кто остался целым, не сгорел и сделал свою работу так, чтобы завтра было с чем выйти к людям — и к себе самому.
P.S.
Понравилось? Поддержите лайком!