5 историй о том, как строить продуктивные отношения между PM’ом и разработчиками

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

Немного о себе. Я 12 лет в IT-сфере, 9 из них работаю менеджером проектов. На моем счету более 25 успешно завершенных проектов (web, mobile, IoT) для клиентов из США, Европы, Австралии, Бразилии и Украины. Выступаю на конференциях (в этом году была спикером PMConf2019 и Women Techmakers Dnipro), провожу вебинары. Строю и развиваю инженерные команды.

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

• кому сложнее — новому менеджеру или команде, в которую он пришел;
• когда проявлять инициативу, чтобы никому не навредить;
• мотивация команды на нуле, а проект доделать нужно — есть ли выход?

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

Истории

1. «Что-то я мало знаком с этой новой ПМ, попробую меньше общаться, вдруг не заметит, что у нас тут проблемы»

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

Выпало мне такое счастье. Команда сложившаяся, проект старый, я новая. Бинго! Да еще и команда распределенная, а в моем офисе только один человек из пятнадцати. Дабл бинго :)

Моей первоочередной задачей стало запомнить имена (ни с кем из новой команды я не была знакома), кто какие роли выполняет и почему. Потом нужно было выяснить текущие проблемы/задачи и то, как я могу помочь ребятам выйти на более комфортный уровень работы.

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

Когда с именами и ролями в команде немного разобрались, я заметила, что некоторые коллеги все еще отвечают односложно на мои вопросы и информацию нужно вытягивать, как рыбу из пруда. В той ситуации я не могла позволить себе роскошь раскачки знакомства с новыми людьми в течение нескольких недель, потому пошли в ход митинги 1:1 (у менеджера проекта всегда найдется о чем поговорить с ребятами из команды, особенно если проект старый, а ПМ — нет).

Поговорить удалось не со всеми, но полученной информации было достаточно. Оказалось, что один из разработчиков очень сильно перегружен, а об этом мало кто знает. Сказать об этом мне не представлялось возможным: я же новая и потенциально могу отреагировать непредсказуемо, а других «решателей вопросов» не было. Узнать об этом удалось благодаря упомянутым митингам 1:1. Решено было добавить второго разработчика на этой же технологии, которого уже ранее привлекали к текущему проекту.

Как результат, разработчика разгрузили, проектное колесо немного выровняли. Profit.

К чему это я? К тому, что сложно быть новым человеком для сложившейся команды. Но команде ничуть не легче, чем менеджеру. И в таком случае со стороны менеджера должна быть инициатива, чтобы проявить себя, делами подкрепить слова. К новому человеку всегда есть недоверие, но людям в команде нужно не бояться прощупывать почву и пытаться доносить свои идеи. Особенно проблемы, так как даже самый «страшный» ПМ не откажется выслушать и хоть попытается помочь, ведь он часто заинтересован в успехе проекта даже больше, чем вся команда.

Если у вас в команде новый менеджер, то не бойтесь проявить инициативу и поговорить с менеджером на благо себе и/или команды в самом начале. Это поможет наладить отношения. Говорить с менеджером совсем не страшно, а очень даже полезно.

2. «Ну-у-у нет, я так не хочу. Дайте другую задачу, такую я уже делал»

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

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

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

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

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

3. «Я меняю компании каждый год. Не думаю, что ваша станет исключением»

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

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

Мне как менеджеру проекта выпала задача не только ввести нового коллегу в курс предстоящих дел, но и детальнее рассказать о культуре и устоях компании. Для меня задача оказалась интересной: как в нескольких предложениях рассказать о глобальных ценностях и при этом не забыть о локальных неписаных правилах (например, вытереть рассыпанный сахар со стола, если причина его появления на столе — ты).

В конце ознакомительной части я предложила обращаться ко мне с вопросами по работе или происходящему в офисе, сделав акцент на том, что предложение озвучено не просто из вежливости, а действительно можно и нужно так делать.

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

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

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

4. «Странный какой-то разработчик: троллит и пытается забрать мою работу»

На одном из проектов мне посчастливилось работать с очень опытным тимлидом. Ранее мы пересекались на кухне за чашкой кофе, но в одну команду не попадали.

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

Затягивать и умалчивать недоразумения/недовольства считаю неверным подходом, потому позвала тимлида на митинг 1:1. Коллега поведал мне причины своего поведения: с его стороны это был жест помощи, попытка облегчить мою работу. Неожиданно было для обоих, так как помощь в таком объеме мне не требовалась.

В результате мы перераспределили некоторые обязанности и очень четко проговорили подходящий для обоих формат дальнейшей работы. Profit.

А троллинг оказался просто стилем общения со всеми коллегами. Я к нему быстро привыкла :)

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

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

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

5. «Зачем мы делаем этот проект, он же никому не нужен, это *** какое-то»

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

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

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

На одной из ретроспектив ребята признались, что «лошадь дохлая»: мотивация команды практически иссякла. До сих пор благодарна им за честность.

Нужно было срочно принимать меры. Мы коллективно попытались решить, что же нас может мотивировать на этом проекте, найти плюсы и на чем можно сфокусироваться. Пришли к выводу, что наше хорошее — это клиент. Он у нас замечательный (да-да, знаю, в это слабо верится, но факт). Всегда вовремя приходил на звонки, зная о разнице во времени (клиент из США). Отвечал на письма почти в срок (ну нет идеальных людей). Мозг не выносил :)

В итоге договорились, что тестируем вариант работы в режиме смещения фокуса с «все плохо, проект ***» на «что мы можем сделать, чтоб обрадовать клиента». Под договором подписалась вся команда. И с того момента работать стало чуточку проще. Не идеально, но мотивация оторвалась от дна и стала с интересом поглядывать вверх. Profit.

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

Итоги

Для меня началом решения любого вопроса является конструктивный диалог. Открытый, честный, спокойный. Запланированный в удобное для обеих сторон время. В результате получается список прописанных дальнейших шагов, с которыми согласны участники процесса.

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

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

Если же новый человек в команде — это вы, то оглянитесь вокруг, посмотрите, к кому можно обратиться за советом, кто мог бы ввести вас в курс дела и отвечать на вопросы первое время. Возможно, таким человеком станет менеджер (если это не вы :) или ваш коллега на смежной позиции. За вопросы бить точно никто не будет, особенно если вы заранее договоритесь об удобном времени.

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

В моей практике разговоры помогают решить уйму вопросов, а инициатива сотрудников приносит полезные идеи, которые улучшают взаимопонимание и полируют рабочий процесс. Я не устаю повторять свою любимую фразу всем коллегам по проектам: «Каждый из вас может обратиться ко мне с любым вопросом или предложением по работе». И говорю это искренне.

Иллюстрации: Дарина Скульская