«Как можно больше контролируйте и отвлекайте»: 5 вредных советов для проджект-менеджера

Меня зовут Александра Стеценко и я занимаю должность операционного директора Wezom Академии. По роду деятельности мне приходится постоянно взаимодействовать с разработчиками практически на всех уровнях. В частности, сейчас у меня тесное сотрудничество с девелоперами, работающими над модернизацией «Личного кабинета» наших студентов.

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

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

Собственный опыт: о менеджерах и их взаимодействии со всей командой

Для начала очень коротко расскажу собственную историю.

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

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

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

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

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

Важный нюанс в понимании работы проджект-менеджера

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

Нет, нет и еще раз нет!

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

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

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

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

Работа с девелоперами: распространенные ошибки и как их не допустить

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

В чем причина?

Менеджмент и разработка — это кардинально разные направления деятельности. Причем не только в техническом плане, но и в софт-скиллах.

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

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

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

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

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

Вредные советы

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

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

1 Как можно чаще отвлекайте разработчика по делу и без, контролируйте его

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

Секрет в том, что у каждого есть свои задачи и дедлайн их выполнения. Главное, чтобы сотрудник выполнил весь объем работы. А сколько времени он при этом проводит на рабочем месте и чем еще занимается — дело второстепенное.

Мы, конечно, не Google. Но какой смысл каждый час мониторить деятельность разработчика и заставлять отчитываться по каждому этапу работы? Поверьте, гораздо правильнее дать специалисту спокойно работать и самостоятельно планировать этапы решения поставленных задач. Я не говорю, что контроль не требуется в принципе. Но он не должен быть фанатичным и абсолютным. Это лишнее.

2 Не беспокойтесь о подготовке качественного ТЗ. Опытный разработчик самостоятельно сориентируется

Запомните одну очень важную вещь! То, как вы сформировали задачу в своей голове, и то, как ее видит разработчик, может быть совершенно разными формулировками. Если вы взялись за подготовку технического задания, то позаботьтесь, чтобы оно было максимально детализированным и понятным.

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

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

3 Не вносите все правки сразу. Разбейте их на части и прорабатывайте каждую отдельно

Когда проджект-менеджер не может собрать все правки и комментарии в единый список, он априори сомнительный специалист.

Если у вас будут правки по проекту (а они правда могут быть):

• соберите их все;
• дайте пояснения;
• проверьте список и структурируйте его.

И только после этого передавайте разработчику.

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

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

4 Не учитывайте пожелания девелопера по дедлайну и его идеи вне задачи

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

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

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

5 Не нужно хвалить подчиненных — это их работа. И не забывайте «подсыпать» срочные задачи

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

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

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

Вместо итогов

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

Например:

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

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

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

1. Слушать и слышать. Не спорить, а находить компромисс в сложных ситуациях.
2. Не перегружать разработчика, а помогать найти баланс между работой и досугом.
3. Четко объяснять каждую задачу и в то же время оставлять простор для новых идей и путей решения задач.
4. Научиться понимать личные проблемы сотрудника и при необходимости делать паузу для перезагрузки и отдыха.

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

Но вы, конечно, можете не согласиться с некоторыми моими мыслями и утверждениями. Потому приглашаю своих коллег проджект-менеджеров к обсуждению темы в комментариях. Как вы взаимодействуете с девелоперами и раскрываете их потенциал? Давайте поговорим!