Привет! Я Саша Ворожищев, руководитель направления Flutter/iOS в AGIMA. Сейчас у нас в компании мир и покой, но мы еще помним времена, когда проджекты и тимлиды постоянно ссорились. Ссорились, само собой, из-за работы: каждый хотел доминировать на проекте и по-своему понимал задачи. Иногда к решению конфликтов подключались буквально все — вплоть до топ-руководителей. В итоге мы придумали, как не допускать таких стычек. И я расскажу об этом подробно.
Кто эти люди и что им делить
Вы точно знаете, чем занимаются проджект и тимлид, но давайте синхронизируемся. Это важно, потому что в разных компаниях эти роли понимают по-разному. Вот как их видим мы.
Проджект-менеджер (Project Manager). Отвечает за планирование и организацию процесса. Его цель — реализовать проект за определенный срок и уложиться в определенный бюджет. Он управляет ресурсами, ставит задачи и приоритеты, работает с заказчиком. ПМ владеет навыками управления рисками и конфликтами.
Тимлид разработки (Team Lead). Он отвечает за разработчиков, направляет общие усилия в нужное русло. Тимлид отвечает за развитие команды, за стандарты разработки и архитектурную целостность продукта. Должен обладать высокими техническими навыками и помогать разработчикам решать задачи.
Главное сходство между ними: тот и другой управляют проектом. Главная разница: ПМ сосредоточен на проекте в целом, тимлид — на технической части. Обычно они работают в тандеме: вместе планируют сроки, вместе нанимают специалистов. И именно здесь плодородная почва для конфликта.
Чтобы не быть голословными, мы провели небольшое исследование. Это были опросы среди подписчиков наших телеграм-каналов для разработчиков и проджектов. Оказалось, что конфликты бывают примерно на трети проектов.
Разберем, почему они возникают, на конкретных примерах.
Кейс №1. Тимлид и проджект по-разному видят цели проекта
Срок сдачи проекта уже подходит. Заказчик давить на менеджера: хочет выкатить проект к определенной дате. Менеджер торопит команду, чтобы не нарушить обязательства. За неделю до релиза тимлид говорит: «У нас код так себе, нужен рефакторинг». Менеджер с ним спорит, времени нет. Но тимлид стоит на своем: отдавать проект со слабым кодом — плохая идея.
Как работать с проблемой:
✔️ Найти компромисс. Например, оба могут признать, что есть важная часть кода, которую нужно обернуть в Unit-тесты, а есть типовые блоки, которые не требуют тщательной проработки.
✔️ Разделить обязанности. Каждый сосредоточится на своих обязанностях и не будет мешать другому. Например, проджект займется планированием и контролем основных задач, а тимлид — качеством работы.
✔️ Перераспределить ресурсы. Ресурсы можно изначально распределить так, чтобы удовлетворить всех. Например, если качество кода — главный приоритет для тимлида, то лучше сразу выделить больше ресурсов на тестирование.
Тут важно, чтобы оба человека слышали друг друга и были настроены на диалог. Если один спокойно и с аргументами объяснит свою позицию другому, они точно найдут компромисс. А чтобы избежать подобных конфликтов в будущем, проджект и тимлид могут работать над коммуникацией с самого начала: проговорить цели каждого, обязанности и место в команде.
Кейс №2. Тимлид и проджект не могут решить, кто главнее
Был у меня в практике случай, когда на одном из проектов проджект пытался руководить тимлидом. Причем это было новое направление в компании, у которого не было бэкграунда. Сначала это привело к конфликтам, тимлид пытался отвоевать пальму первенства. Потом он понял, что проджект ничего не понимает в разработке и начал вешать ему лапшу на уши: растягивал сроки и писал некачественный код.
Многое на проекте зависит от стиля лидерства. В этом случае проблема была как раз в том, что ребята пытались управлять по-разному. Наш CTO Андрей Непряхин недавно написал о стилях лидерства подробную статью. Пересказывать ее не буду. Напомню только, что стилей 4: диктатор, формалист, либерал, демократ.
Если отношения руководителей не складываются из-за разных стилей лидерства, можно попробовать такие способы.
✔️ Обсудить различия в стиле лидерства. Руководители могут выбрать тот стиль, который соответствует интересам проекта. Можно использовать методы анализа конфликтов, такие как техника «Взвешенного среднего» или метод «Четыре столпа».
✔️ Найти компромисс. Если руководители не могут найти общий язык, можно попытаться найти компромисс, который бы учитывал интересы обоих руководителей.
✔️ Назначить нейтрального посредника. Посредник поможет решить разногласия и наладить работу. Это может быть внешний консультант или управленец, у которого достаточно опыта, чтобы помочь руководителям найти общий язык.
✔️ Разделить роли и обязанности. Разделить обязанности имеет смысл таким образом, чтобы каждый из руководителей занимался задачами, которые соответствуют его стилю лидерства и компетенциям.
Кейс №3. У проджекта и тимлида разное отношение к планированию
На моей памяти бывали разные случаи. Вот один из них. Менеджер был готов писать тимлиду и разработчикам каждый день. Спрашивал, как дела с задачами и прочее. Если что-то шло не по плану, сразу эскалировал. При этом тимлид взял задачу, оценил на 12 часов и пропал, не отвечал менеджеру. Задачу сделал в срок, но пока делал, ситуация разрослась. В итоге получился конфликт.
К счастью, такие конфликты легко предотвратить. Важно изначально договориться, как часто разработчики будут давать рассказывать о статусе задачи. Например, каждый день на дейли.
Кейс №4. Проджект и тимлид по-разному оценивают риски
Проджект-менеджер может считать, что время на риски можно закладывать небольшое, так как проект не сложный. В то же время тимлид может считать, что время на риски нужно увеличить, так как есть сложные нюансы в архитектуре. Это может привести к разногласиям о том, какие сроки установить и какими методами управления рисками.
Такой конфликт может привести к неправильному определению приоритетов и управлению ресурсами. Тогда это затронет весь проект и может вызвать недовольство в команде. Ошибка в оценке рисков может привести к увеличению сроков, перерасходам или даже к сбою в работе проекта.
Для решения конфликта нужно детально проанализировать риски и оценить их с командой. После этого нужно всем вместе обсудить, какие методы управления рисками использовать и какие из них должны быть управляемыми.
Кейс №5. Изначально проблемный проект
Есть безнадежный проект, на котором сроки уже почти сорваны. За пару недель до дедлайна топ-менеджмент решает привлечь нового руководителя проекта или тимлида, чтобы он «разрулил» ситуацию. Этот человек понимает, что в этой кризисной ситуации «волшебной таблетки» не существует. Причина может быть любая: плохо выстроенный процесс, изначально неверная оценка, нехватка рабочих рук. Вариантов очень много.
Тут нужно понимать, что к новому руководителю приковано внимание руководства. Значит, и ожидания высокие. Чувствуя такую ответственности, проджект/тимлид начинает давить на вторую сторону. Конфликты неизбежны, как минимум поначалу.
В этом случае проджект/тимлид должен сосредоточиться на следующих моментах:
✔️ Понять ситуацию. Разобраться в причинах, понять, какие меры помогут эти причины устранить. Проджект/тимлид должен провести анализ проекта и выявить проблемные области, чтобы разработать стратегию работы.
✔️ Установить приоритеты. Лучше сосредоточиться на задачах, которые имеют наибольшую значимость для проекта.
✔️ Общаться. Проджект должен строить открытую коммуникацию с командой проекта и заказчиком. Процесс должен быть прозрачным, чтобы все видели прогресс проекта и его проблемы.
✔️ Руководить командой. Тимлид должен убедиться, что каждый член команды понимает свою роль в проекте и знает, что от него требуется. Он должен мотивировать и поддерживать команду, чтобы достичь целей.
✔️ Проявлять гибкость. Проджект/тимлид должен быть гибким и готовым менять стратегию, если текущая не работает.
✔️ Управлять рисками. Проджект/тимлид должны определить риски, каждый со своей стороны, и разработать стратегию для управления ими. Нужно сразу наметить план действий, если ситуация пойдет по негативному сценарию.
✔️ Установить реалистичные ожидания. Проджект/тимлид должны определить, чего реально достичь в оставшееся время. Заказчик должен понимать, что проект можно завершить только в определенных параметрах и с учетом рисков.
Итого: основные причины конфликтов
- Человеческий фактор.
Разные характеры, неумение уступать или искать компромиссы, сложности со софт-скиллами и прочее. Как правило, со временем, благодаря тимбилдингам и ретро, отношения устаканиваются. Здесь же перегруженность тимлида или проджекта — это нужно решать с руководством. - Разные подходы и методики работы.
Тимлид и проджект тянут одеяло на себя. Проджект пытается контролировать разработку, а тимлид — взять на себя больше организационной ответственности. Сюда же отнесем и сложности с согласованием сроков, понимания рабочих процессов и т. п.
Что помогает решать конфликты
Во-первых, нужно развивать взаимопонимание. В этом помогут хард- и софт-скиллы. Причем зачастую тимлиду нужно развивать софты, а проджекту — харды. О тимлиде, его качествах и умениях мы рассказывали в этой статье.
Очевидно, что проджект должен понимать базовую логику работы продукта. Иначе он просто не сможет выстраивать процесс разработки и объяснять технические нюансы заказчику. Но и проверять кодовую базу он, конечно, тоже не должен.
Тимлиду пригодится умение общаться: с командой и с заказчиком. Еще один важный навык — тайм-менеджмент. Ему приходится распределить задачи по уровню срочности и иногда не на одном проекте.
Что на эту тему почитать проджекту:
- Deadline. Роман об управлении проектами. Том ДеМарко.
- Цель. Процесс непрерывного улучшения. Элияху М. Голдратт.
- Искусство управления IT-проектами. Скотт Беркун.
Что на эту тему почитать тимлиду:
- Как пасти котов. Наставление для программистов, руководящих другими программистами. Рейнвотер Дж. Ханк.
- Семь навыков высокоэффективных людей. Стивен Кови.
- Практика лидерства. Питер Ф. Друкер.
Какой конфликт считать здоровым
Разберемся, что такое «адекватный конфликт» — это конфликт, при котором проект не страдает ни в финансовой части, ни в части качества кода. Что-то вроде конфликта интересов.
Рассмотрим самый распространенный случай. Что важно проджекту на проекте? Сделать его качественно и быстро. Он хочет, чтобы заказчик был доволен, и это правильно. В этом его основополагающая цель. Тимлиду важно правильно распределить ресурсы, оптимизировать их работу и нагрузку, сделать качественные решения. Иногда ему нужно отвлечь сотрудника от рабочего процесса, чтобы тот не выгорал. Нужно подумать, в какой релиз попадет задача.
Всё это можно решить с помощью старого доброго общения. Если они вместе обсудят проблемы, сделают оценку задач, распределят их, то найдут компромисс. Суть такого конфликта — в системе, которую можно сравнить с системой сдержек и противовесов.
Когда эскалировать конфликт руководству
- Когда конфликт влияет на бюджет или сроки проекта. Например, если тимлид отказывается работать с менеджером — это явно серьезная проблема.
- Когда конфликт влияет на качество работы. Например, если менеджер не согласен с решениями тимлида и это приводит к переработкам и выгоранию команды.
- Когда конфликт между менеджером и тимлидом влияет на команду. Например, если из-за конфликта члены команды не знают, какие задачи им брать и кто за них отвечает.
- Когда конфликт невозможно решить на уровне команды. Например, если все разговоры на ретро и других встречах ни к чему не привели.
Если даже после эскалации решить вопрос не удается, лучше развести ребят по разным проектам. Ситуации бывают разные.
Подводим итоги: как не допустить конфликтов между тимлидом и проджект-менеджером
- Установить ясные роли и обязанности. Проджект и тимлид должны понимать, какие задачи им предстоит выполнять и как их работа взаимосвязана друг с другом.
- Определить ясные цели и ожидания. При определении целей проекта и ролей проджекту и тимлиду необходимо ясно определить ожидания руководства и заказчика, а также предупредить об опасностях и рисках, связанных с проектом.
- Создать коммуникационный план. Необходимо разработать план коммуникации, который определит частоту и формат взаимодействия между менеджером и тимлидом. Этот план должен учитывать разные каналы связи и быть связанным с целями проекта.
- Определить и настроить процессы управления проектом. Нужно определить единый процесс управления проектом, который поможет понять, как они должны работать вместе, чтобы достичь общих целей.
- Создать сплоченную команду. Создайте атмосферу доверия и взаимопонимания в команде, чтобы каждый участник мог высказывать свои мысли и мнение, и был готов помочь друг другу при возникновении проблем.
- Регулярно обновлять статус текущих планов и этапов. Конфликты могут возникать, когда что-то в проекте неожиданно меняется. Регулярно срезайтесь и актуализируйте данные.
Расскажите, как обстоят дела у вас. Тимлид и проджект ругаются? Или в основном они лучшие друзья? И если есть проблемы, как вы их решаете?
А еще подписывайтесь на телеграм-канал AGIMA Dev. Вообще мы там рассказывает о разработке, но иногда и об управлении разработкой. И вообще давайте больше общаться — так что жду вас в тг.
