Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

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.

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

Итоги

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

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

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

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

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

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


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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn

Схожі статті




26 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

С самого начала статтьи меня вывела из равновесия вот эта фраза

продуктивные взаимоотношения возможны

Они не то что возможны, а просто маст-хев если вы хотите хоть куда-то продвинуть проект и себя. Сами примеры почему-то слишком упрощенные, с одной/двумя переменными, и сквозят недомолвками. Например в № 1 непонятно как вы выстраивали доверительные отношения с командой (тем более распределенной!) прежде чем начать их всех пропускать через 1:1. Это ведь не факт что вам бы говорили правду, а что загруженный сотрудник и вправду был перегружен и ему нужен был +1, а не какое-то другое решение.

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

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

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

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

Но если показать человеку, что он разговаривает с потенциальным помощником, то общение приобретает более открытый характер.

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

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

Хороший ПМ это который не вмешивается в работу команды , и занимается только своими административными функциями — например заказывает пиццу на команду 😂

я тут намедни кажется весной говорил с пиэмом отечественным мол «ну бывало тоже пиэмил ну работа как работа бомажки перекладывать её тоже кому-то надо делать...» так к.м.к. он таки обиделся потому как как-то так с каким-то «акцентом» переспросил «бомажки перекладывать!?»

Ну может человек совершил мегаачивмент и перевел бумажки в ту же джиру, а тут такое. Обидно

и не смог абстрагиваться «бомажки это бомажки»? вот щас не знаю кто его больше обидел ты или я особенно если ты сказал фактическую правду ))

таски в джире двигать и отчеты по таймшитам составлять — те же бумажки, только электронные :-)

ну «Менеджер борди» це часто дуже потрібна роль.
Просто розробники і навіть тімліди часто не мають часу і бажання розрулювати сотні тасків які зависли в «блокед» або «резолвед», а клієнт хоче красиві метрики і графіки. При чому часто задоволеність і вірогідність продовження контракту залежить від цих графіків.
Для багатьох це і є «перекладування бумажок», але досить мало усвідомлює необхідність і значущість цього.

Хороших ПМ’ов мало. Хотелось бы работать в команде с таким.

но как отличить хорошего ПМ-а от плохого?

Но нужно было продолжать работать над проектом, в котором не видишь смысла.

Так в чем же был смысл проекта? Если его потрудиться объяснить, то мож и мотивация улучшилась бы

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

Вы простите конечно, написано красиво и убедительно, но поверить очень сложно.
Вот к примеру в первом случае Вы сразу, с ходу, нанимаете +1 человека. Причем там было не 100 человек. Обычно не в правилах менеджеров расширять расходные статьи аж никак. Ну только есть совсем прижмет. И то не факт.
Сразу вопрос: как Вы мотивировали перед Вашим руководством или/и клиентом такой шаг как серьезной расширение расходов в условиях, когда Вы только пришли ? Ведь они могли задать вопрос: а раньше достаточно было того, что есть сейчас и т.д.

Ну, кажется посыл был в том, что если ты — новый ПМ в команде, то иди и общайся с каждым членом команды и слушай о его проблемах. А то, что удалось пропушить +1 в команду — это всего лишь один из примеров, где автор нашла проблему и решила её. Собственно, почему нет, поверить в это очень даже можно :)

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

Здесь есть одна неувязочка. Добавление +1 человека не уменьшает сроки (закон Брукса), по крайней мере в короткой и средней перспективе.

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

которого из них кикнули?

На проекте остался основной разработчик, а для второго как раз был подготовлен к старту следующий проект.

По сути, вывод — проводить 1:1 и 1:много с фокусом на сотрудниках, а не на проекте. На моем предыдущем месте работы эти митинги часто откладывались или переносились, что привело к тому что мотивация была очень низкая, а ПМ понятия не имел в чем проблема.

Не только. Это всего лишь один из инструментов. Но даже если вы начнете пользоваться 1:1 — это еще не значит что а) вам действительно будут говорить правду; б) это решит все проблемы в команде и проекте.

Підписатись на коментарі