Привет! Я Саша Ворожищев, руководитель направления Flutter/iOS в AGIMA. Сейчас у нас в компании мир и покой, но мы еще помним времена, когда проджекты и тимлиды постоянно ссорились. Ссорились, само собой, из-за работы: каждый хотел доминировать на проекте и по-своему понимал задачи. Иногда к решению конфликтов подключались буквально все — вплоть до топ-руководителей. В итоге мы придумали, как не допускать таких стычек. И я расскажу об этом подробно.

Кто эти люди и что им делить

Вы точно знаете, чем занимаются проджект и тимлид, но давайте синхронизируемся. Это важно, потому что в разных компаниях эти роли понимают по-разному. Вот как их видим мы.

Проджект-менеджер (Project Manager). Отвечает за планирование и организацию процесса. Его цель — реализовать проект за определенный срок и уложиться в определенный бюджет. Он управляет ресурсами, ставит задачи и приоритеты, работает с заказчиком. ПМ владеет навыками управления рисками и конфликтами.

Тимлид разработки (Team Lead). Он отвечает за разработчиков, направляет общие усилия в нужное русло. Тимлид отвечает за развитие команды, за стандарты разработки и архитектурную целостность продукта. Должен обладать высокими техническими навыками и помогать разработчикам решать задачи.

Главное сходство между ними: тот и другой управляют проектом. Главная разница: ПМ сосредоточен на проекте в целом, тимлид — на технической части. Обычно они работают в тандеме: вместе планируют сроки, вместе нанимают специалистов. И именно здесь плодородная почва для конфликта.

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

Разберем, почему они возникают, на конкретных примерах.

Кейс №1. Тимлид и проджект по-разному видят цели проекта

Срок сдачи проекта уже подходит. Заказчик давить на менеджера: хочет выкатить проект к определенной дате. Менеджер торопит команду, чтобы не нарушить обязательства. За неделю до релиза тимлид говорит: «У нас код так себе, нужен рефакторинг». Менеджер с ним спорит, времени нет. Но тимлид стоит на своем: отдавать проект со слабым кодом — плохая идея.

Как работать с проблемой:

✔️ Найти компромисс. Например, оба могут признать, что есть важная часть кода, которую нужно обернуть в Unit-тесты, а есть типовые блоки, которые не требуют тщательной проработки.

✔️ Разделить обязанности. Каждый сосредоточится на своих обязанностях и не будет мешать другому. Например, проджект займется планированием и контролем основных задач, а тимлид — качеством работы.

​​✔️ Перераспределить ресурсы. Ресурсы можно изначально  распределить так, чтобы удовлетворить всех. Например, если качество кода — главный приоритет для тимлида, то лучше сразу выделить больше ресурсов на тестирование.

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

Кейс №2. Тимлид и проджект не могут решить, кто главнее

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

Многое на проекте зависит от стиля лидерства. В этом случае проблема была как раз в том, что ребята пытались управлять по-разному. Наш CTO Андрей Непряхин недавно написал о стилях лидерства подробную статью. Пересказывать ее не буду. Напомню только, что стилей 4: диктатор, формалист, либерал, демократ.

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

✔️ Обсудить различия в стиле лидерства. Руководители могут выбрать тот стиль, который соответствует интересам проекта. Можно использовать методы анализа конфликтов, такие как техника «Взвешенного среднего» или метод «Четыре столпа».

✔️ Найти компромисс. Если руководители не могут найти общий язык, можно попытаться найти компромисс, который бы учитывал интересы обоих руководителей. 

✔️ Назначить нейтрального посредника. Посредник поможет решить разногласия и наладить работу. Это может быть внешний консультант или управленец, у которого достаточно опыта, чтобы помочь руководителям найти общий язык.

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

Кейс №3. У проджекта и тимлида разное отношение к планированию

На моей памяти бывали разные случаи. Вот один из них. Менеджер был готов писать тимлиду и разработчикам каждый день. Спрашивал, как дела с задачами и прочее. Если что-то шло не по плану, сразу эскалировал. При этом тимлид взял задачу, оценил на 12 часов и пропал, не отвечал менеджеру. Задачу сделал в срок, но пока делал, ситуация разрослась. В итоге получился конфликт.

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

Кейс №4. Проджект и тимлид по-разному оценивают риски

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

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

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

Кейс №5. Изначально проблемный проект

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

Тут нужно понимать, что к новому руководителю приковано внимание руководства. Значит, и ожидания высокие. Чувствуя такую ответственности, проджект/тимлид начинает давить на вторую сторону. Конфликты неизбежны, как минимум поначалу.

В этом случае проджект/тимлид должен сосредоточиться на следующих моментах:

✔️ Понять ситуацию. Разобраться в причинах, понять, какие меры помогут эти причины устранить. Проджект/тимлид должен провести анализ проекта и выявить проблемные области, чтобы разработать стратегию работы.

✔️ Установить приоритеты. Лучше сосредоточиться на задачах, которые имеют наибольшую значимость для проекта.

✔️ Общаться. Проджект должен строить открытую коммуникацию с командой проекта и заказчиком. Процесс должен быть прозрачным, чтобы все видели прогресс проекта и его проблемы.

✔️ Руководить командой. Тимлид должен убедиться, что каждый член команды понимает свою роль в проекте и знает, что от него требуется. Он должен мотивировать и поддерживать команду, чтобы достичь целей.

✔️ Проявлять гибкость. Проджект/тимлид должен быть гибким и готовым менять стратегию, если текущая не работает.

✔️ Управлять рисками. Проджект/тимлид должны определить риски, каждый со своей стороны, и разработать стратегию для управления ими. Нужно сразу наметить план действий, если ситуация пойдет по негативному сценарию.

✔️ Установить реалистичные ожидания. Проджект/тимлид должны определить, чего реально достичь в оставшееся время. Заказчик должен понимать, что проект можно завершить только в определенных параметрах и с учетом рисков.

Итого: основные причины конфликтов

1. Человеческий фактор.
   
   Разные характеры, неумение уступать или искать компромиссы, сложности со софт-скиллами и прочее. Как правило, со временем, благодаря тимбилдингам и ретро, отношения устаканиваются. Здесь же перегруженность тимлида или проджекта — это нужно решать с руководством.

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

Что помогает решать конфликты

Во-первых, нужно развивать взаимопонимание. В этом помогут хард- и софт-скиллы. Причем зачастую тимлиду нужно развивать софты, а проджекту — харды. О тимлиде, его качествах и умениях мы рассказывали в этой статье.

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

Тимлиду пригодится умение общаться: с командой и с заказчиком. Еще один важный навык — тайм-менеджмент. Ему приходится распределить задачи по уровню срочности и иногда не на одном проекте.

Что на эту тему почитать проджекту:

• Deadline. Роман об управлении проектами. Том ДеМарко.

• Цель. Процесс непрерывного улучшения. Элияху М. Голдратт.

• Искусство управления IT-проектами. Скотт Беркун.

Что на эту тему почитать тимлиду:

• Как пасти котов. Наставление для программистов, руководящих другими программистами. Рейнвотер Дж. Ханк.

• Семь навыков высокоэффективных людей. Стивен Кови.

• Практика лидерства. Питер Ф. Друкер.

Какой конфликт считать здоровым

Разберемся, что такое «адекватный конфликт» — это конфликт, при котором проект не страдает ни в финансовой части, ни в части качества кода. Что-то вроде конфликта интересов.

Рассмотрим самый распространенный случай. Что важно проджекту на проекте? Сделать его качественно и быстро. Он хочет, чтобы заказчик был доволен, и это правильно. В этом его основополагающая цель. Тимлиду важно правильно распределить ресурсы, оптимизировать их работу и нагрузку, сделать качественные решения. Иногда ему нужно отвлечь сотрудника от рабочего процесса, чтобы тот не выгорал. Нужно подумать, в какой релиз попадет задача.

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

Когда эскалировать конфликт руководству

1. Когда конфликт влияет на бюджет или сроки проекта. Например, если тимлид отказывается работать с менеджером — это явно серьезная проблема.

2. Когда конфликт влияет на качество работы. Например, если менеджер не согласен с решениями тимлида и это приводит к переработкам и выгоранию команды.

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

4. Когда конфликт невозможно решить на уровне команды. Например, если все разговоры на ретро и других встречах ни к чему не привели.

Если даже после эскалации решить вопрос не удается, лучше развести ребят по разным проектам. Ситуации бывают разные.

Подводим итоги: как не допустить конфликтов между тимлидом и проджект-менеджером

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

2. Определить ясные цели и ожидания. При определении целей проекта и ролей проджекту и тимлиду необходимо ясно определить ожидания руководства и заказчика, а также предупредить об опасностях и рисках, связанных с проектом.

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

4. Определить и настроить процессы управления проектом. Нужно определить единый процесс управления проектом, который поможет понять, как они должны работать вместе, чтобы достичь общих целей.

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

6. Регулярно обновлять статус текущих планов и этапов. Конфликты могут возникать, когда что-то в проекте неожиданно меняется. Регулярно срезайтесь и актуализируйте данные.

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

А еще подписывайтесь на телеграм-канал AGIMA Dev. Вообще мы там рассказывает о разработке, но иногда и об управлении разработкой. И вообще давайте больше общаться — так что жду вас в тг.

Что еще почитать про управление разработкой:

• Как управлять конфликтами в команде разработки.

• Как мотивировать команду: основные правила и принципы.

• Как мы делаем тестирование прозрачным. Всё об инфраструктуре QA.

• Матрица компетенций: важный инструмент для мотивации команды.