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