Руководитель ИТ проектов и его команда: как выстраивать отношения правильно?

Тема статьи: коммуникации РП и команды, как это делать правильно, как неправильно, и к чему вас это вас приведет.

Эта статья – часть цикла статей о том, чего не рассказывают на курсах РП, и что в жизни понадобится вам с первого же дня работы: о так называемых софтскиллах РП. Кому это интересно, читайте статьи здесь и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Все нижесказанное основано на моем личном опыте, как РП с опытом 25 лет и РПО с опытом 10 лет. Поехали.

РП – это коммуникатор. Он коммуницирует в две стороны: слева - те, кто ждет от него результат (заказчики), справа - те, с помощью кого он этот результат должен дать (команда). Прошлая статья «Как говорить заказчику нет» была на тему общения с заказчиками. Эта статья на тему того, как правильно общаться с командой.

Формально для новоиспеченного руководителя проектов работа с командой выглядит проще простого: получи оценку, спланируй, поставь задачи, да плюй в потолок, ожидая выполнения. Успех? Как бы ни так.

Обычно, к вам приходит лид и говорит: «в ТЗ написано непойми что», «кто это оценивал» или «оценивал я, я дал кучу вопросов и сделал кучу допущений, но на них забили». И дает неточные примерные сроки раза в три больше, чем вы уже пообещали, с учетом всех допущений.

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

И в этот момент уже бесполезно выяснять, почему вас не предупредили, почему вам не сказали или почему вы сами не отследили. За проект всегда отвечает РП, он всегда крайний. Если вас за такой проект не уволят – вам крупно повезет.

Проблема в том, что выше упущены обе составляющие работы с командой которые я считаю критичными: менеджер должен быть требовательным помощником для своей команды.

Вначале менеджер не спрашивал: все ли ясно, есть ли проблемы? Затем не следил за исполнением, и рисками, помогая своей команде заранее решать подступающие проблемы проекта. А в итоге упустил готовность функционала и не смог спросить за сроки. Это – пример непрофессиональной работы руководителя проектов.

Как-то раз я пришел на проект, который надо было спасать. Я был тертый РП, потому на собеседовании спросил, что стало с предыдущим руководителем, и мне рассказали, что 3 человека уже уволились или были уволены, проект на грани срыва, заказчик уже недоволен и надо спасать.

Я решил вписаться, рассудив, что, в крайнем случае, меня просто также уволят, ну и ничего страшного.

Первым делом я узнал, кто был ключевым сотрудником проекта и поговорил с ним. Выяснилось, что заказчику пообещали сроки вдвое меньше, чем он сам говорил, лишь бы продать. Что его никто не слушает и заставляют подписаться под новые сроки. А он собирается писать «по собственному», потому что ничего подобного он не обещал и дать не может.

Как я сейчас понимаю, я сделал самое правильное: я спросил его самого какой реально план работы он видит? Он подумал и дал план, который отличался от обещанного заказчику на полгода (в большую сторону). Дальше мы этот план немного утрясли и выделили минимум, который можно сделать быстрее + условия для этого.

Дальше я спросил: «что тебе надо, чтобы сделать это в те сроки, что мы с тобой придумали?» И он попросил прикрыть его от заказчика, и обеспечить привлечение нескольких человек, необходимых для выполнения работы в срок. Я пообещал сделать это.

После этого я пошел и согласовал наш план с заказчиком (как я это сделал – можно почитать в статье «Как говорить заказчику нет») и выстроил все коммуникации по объему, срокам и оценкам через себя (я просто разрешил лиду вообще не отвечать на эти вопросы и говорить «поговорите с Петром, это к нему»).

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

Итог превзошел ожидания: мы выполнили наш план на 100%, мы успели именно в те сроки, которые согласовали, заказчик был доволен и даже выпустил пресс релиз об успешном внедрении. Но главное в этой истории то, что отношения с командой были идеальные. Прошло 10 лет, а мы до сих пор общаемся, и тот архитектор до сих пор говорит мне «спасибо тебе, что тогда прикрыл меня от этих истерик и дал спокойно работать».

Фраза из примера выше: «Спасибо, что даешь возможность просто работать, а не участвовать в этих истериках», по-моему, это лучшая похвала менеджеру со стороны команды из всех возможных. К этому должен стремиться менеджер, работающий с людьми.

Разработчик, которого все время дергают, работает медленнее, а ошибается чаще. Разработчик, который работает в режиме ошпаренной кошки, выгорит за полгода и пошлет нафиг Руководителя проектов, который не может ему организовать правильный процесс работы, а затем пошлет всю компанию. Как этого не допустить? Как РП может помочь своей команде?

Всего два пункта:

Плановое выполнение.

Поглядите на соотношение плановых и внеплановых задач вашей команды за период. Если внеплановых задач у вашей команды больше 20% - у вас проблемы с процессами и отношениями с заказчиком. Если вы даже не можете сосчитать % внеплановых задач, очевидно, дела еще хуже. Потребуется сперва наладить этот учет, а затем см предложение 1.

Проблема плохого планирования серьезнее, чем может показаться: из 4х команд, с которыми я работал за последний год, в 3х процент внеплановых задач был больше 50% (!!). И это команды от 30 до 300 человек. Внеплановые задачи ставятся в спринт, внеплановые задачи приходят разработчикам по мессенджерам в формате «друг, помоги, это ОЧЕНЬ важно» и так далее. Добрые ребята разработчики рады помочь всем, а в итоге они не успевают делать плановые задачи, которые переезжают на следующий спринт. И так далее. Разработчика ругают, а косяк-то не его. Просто нет процессов и разработчика не прикрыли от управленческого бардака.

Помните: планирование работы команды – полностью ваша ответственность, как Руководителя проекта, Руководителя продукта или CIO (если вы не набрали себе менеджеров):

Моя практика показывает: если указанные процессы в ИТ команде есть, работают и контролируются руководителями, команды дают предсказуемые результаты. Стоит копнуть там, где бизнес недоволен ИТ разработкой – неизбежно что-то из этого (а, скорее вообще все) не работает. Сроки двигаются, бизнес ругается на ИТ, ИТ видит в бизнесе врагов, которые сами не понимают, чего хотят, разработчики выгорают, и компания тратит деньги на найм новых разработчиков (в текущих условиях – существенные деньги) и все дальше повторяется по кругу. Выход только один – выстраивать планирование.

Итого: команда не должна работать в режиме пожаротушения. Команда должна работать по плану.

Спрашивать, чем он может помочь и делать то, что попросят.

«Все ли устраивает?», «чем я могу тебе помочь?», «что мешает?» - хорошие вопросы команде от менеджера – помощника. Обратите внимание: недостаточно просто спросить и пойти дальше, ничего не делая. Люди запомнят, что вы обещали помочь и, если вы ничего не сделаете - станете балаболом, с которым говорить бесполезно. Записывайте и решайте. Не получается решить - расскажите, что пробовали решить и не получилось.

Команда, которая видит, что менеджер реально старается помочь и прикрыть, всегда поможет и прикроет менеджера в ответ. У вас не будет проблемы иногда попросить выручить и поработать в выходные, помочь что-то сделать быстро. Вам сами все предложат и помогут (поворчат, но помогут). Дополнительный плюс: сотрудники в такой команде часто не переходят на более жирные офферы от других компаний, потому что ценят атмосферу и вас, как руководителя.

Итого: Менеджер должен помогать, а не просто спускать указания и невыполнимые сроки.

Однако, если вы все время делаете все только для команды, будет перекос: вы перестанете учитывать интересы бизнеса – вашего главного заказчика - фокусируясь только на удобстве исполнителя. Тут важно помнить, что команда вам денег за работу не платит и приоритеты и фокус проекта определяете именно вы, как РП, а не ваша команда. Это -100% ваша ответственность.

Делать качественный продукт – хорошо. Но иногда бизнесу не надо сразу качественно, надо быстро. Переносить сроки, потому что «мы увидели, как можно сделать еще лучше» - было бы неплохо, если бы от ваших сроков не зависели реальные деньги, KPI и выплаты зарплат.

Вы, как РП, даете сроки исполнения ваших проектов и стоимость. Сроки и бюджет вы рассчитываете на основании оценки от команды. И если ваша команда начинает переносить сроки – вы вправе спросить за это.

Менеджмент начинается там, где человек дает срок на выполнение задачи и старается этот срок соблюсти. Это управление временем, объемом, изменениями, коммуникациями – только в рамках одного человека и одной задачи. Я ожидаю от миддлов и выше (аналитиков и разработчиков), что они умеют давать оценку и попадать в нее. А если не попадают – они говорят заранее, а не по факту опоздания.

Я иногда замечаю, что тестировщики не хотят ссориться с разработчиками и не переводят задачи в «Переоткрыто», хотя там есть ошибки. Я замечаю, что менеджеры закрывают глаза на перенос сроков разработчиками, чтобы «сохранить хорошие отношения». И я хочу сказать тем, кто так делает: ребята, мы на проекте собрались не для того, чтобы быть хорошими друг для друга. У нас другая цель: сдать проект и заработать денег для своей компании, из которых нам потом заплатят зарплату, а потом (если повезет) и премию. Если разработчик не успевает – должен стараться успевать. Если дал оценку под дедлайн проекта и не успел – значит надо поработать ночью (да, за ошибку в оценке есть ответственность). Если разработчик ошибся, то переоткрыть задачу - нормально, ошибаются все. Тут важно не скрывать это, а быстро и в рамках оценки устранить свои ошибки.

Разумеется, в ответ разработчик потребует от вас понятной постановки и будет 100% прав. Это ответственность РП, обеспечить качественную постановку, см выше про организацию процесса.

Если РП дает непонятную задачу и просит оценить, опытный разработчик никогда ее не оценит просто цифрой. Там будет примерный срок, куча вопросов и допущений. Далее вы, как РП, должны устранить вопросы вашей разработки (уточнить оценку и обеспечить плановость работ) и еще раз подтвердить оценку (чтобы потом было с кого спросить).

Вы даете сроки, как РП, основываясь на оценке команды. На ваше слово ориентируется бизнес. Нельзя просто так взять и молча перенести сроки. И вы, как РП, вправе требовать выполнения работы в срок и понимать все причины задержек и переносов (для того, чтобы далее устранять их, помогая вашей команде) от разработчиков.

Итого: требовать выполнения в обещанные сроки – это ваша обязанность.

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

Если вы не будете следить за двумя полюсами работы с командой (помогать и требовать), вас занесет или в «хорошего парня», которого уволят за неисполнение проектов в срок или в «чайка-менеджера», который не глядя переносит на команду все свои проблемы и не несет никакой добавленной стоимости к своему проекту (и набрать администратора можно в два раза дешевле, чем РП).

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

Мой ТГ канал называется «Морковка спереди, морковка сзади» не просто так: морковка спереди для команды – это премии, это хорошие отношения в команде и предсказуемость. Морковка сзади – это ответственность за сроки. Практика показывает, что обе морковки важны для получения обоюдного удовольствия от выполнения работ на проекте.

Подводя итог статьи: помогайте команде, требуйте обещанные вам сроки. И цените на вес золота тех, кто умеет делать работу в срок – таких людей мало.

Всем успешных проектов!