Меня зовут Александра Стеценко и я занимаю должность операционного директора Wezom Академии. По роду деятельности мне приходится постоянно взаимодействовать с разработчиками практически на всех уровнях. В частности, сейчас у меня тесное сотрудничество с девелоперами, работающими над модернизацией «Личного кабинета» наших студентов.
Именно это направление работы и подтолкнуло меня поднять тему взаимодействия менеджеров с разработчиками. А точнее поделиться тем, как из-за ошибок первых вторые теряют собственный потенциал или не используют его по полной.
Здесь будет и личный опыт, и результаты наблюдений, и рассмотрение распространенных ошибок менеджеров, с которыми сталкивалась я лично и можете столкнуться вы. Ну и, конечно, несколько полезных советов для читателей.
Собственный опыт: о менеджерах и их взаимодействии со всей командой
Для начала очень коротко расскажу собственную историю.
Мой путь в проджект-менеджменте пролегал через разные компании и совершенно разные бизнес-процессы, которые необходимо было оптимизировать и внедрять в них новые инструменты управления.
В начале карьеры я занималась чисто менеджментом проектов без подчиненных. Со временем мне удалось перейти на следующий уровень и уже работать с командой, выстраивать рабочий процесс, брать на себя ответственность за других людей, с которыми я работаю.
Собственно, именно с этого момента я поняла, что мне нравится организовывать рабочие процессы и отвечать за их эффективность. И это, по моему мнению, один из главных софт-скиллов, необходимых современному проджект-менеджеру.
Отсюда мой первый совет: если вам нравится работа с людьми и решение операционных проблем, если вы готовы нести ответственность за подчиненных и контролировать их работу, если вы охотно помогаете каждому сотруднику в решении его задач, проджект-менеджмент — это именно ваше направление!
Эта сфера деятельности открывает перед вами чрезвычайные возможности работы с уникальными проектами и не менее уникальными людьми. Это просто никогда не надоедает. И если уж человек стал проджектом, то вряд ли захочет менять профессию. Потому что постоянное движение — это здорово!
Важный нюанс в понимании работы проджект-менеджера
Распространенная ошибка — считать, что главная задача проджекта — контроль за выполнением поставленных задач. Поэтому в понимании некоторых далеких от темы лиц, проджект-менеджер — это некий «начальник», постоянно стоящий за спиной, контролирующий каждое действие и только ждущий вашей ошибки, чтобы рассказать, как же на самом деле нужно было сделать.
Нет, нет и еще раз нет!
Хороший проджект делает все возможное, чтобы его команда работала как можно лучше.
Он оптимизирует рабочие процессы, контролирует нагрузку подчиненных и пытается добиться лучших результатов меньшими усилиями.
Поэтому такой специалист — это в первую очередь надежное и ответственное звено рабочего процесса, но никак не злой контролер.
Казалось бы, это ясно. Но почему тогда я вообще подняла тему взаимодействия проджектов именно с разработчиками? Вот здесь начинается самое интересное!
Работа с девелоперами: распространенные ошибки и как их не допустить
Дело в том, что проджект-менеджер, никогда ранее не работавший с девелоперами, сможет понять их исключительно с опытом. И это правда. Есть случаи, когда действительно опытные и ответственные проджекты приходят в новую компанию и в буквальном смысле разрушают весь рабочий процесс, хотя должны его улучшать.
В чем причина?
Менеджмент и разработка — это кардинально разные направления деятельности. Причем не только в техническом плане, но и в софт-скиллах.
Для проджекта главное — чтобы задача была выполнена. Он может не вдаваться в технические детали и объективно не понимать, насколько эта самая задача сложна и сколько времени реально требует.
Разработчик выполняет работу, объективно оценивает сложность и сроки выполнения. Но ему может быть сложно объяснить проджекту, почему тот или иной этап требует больше времени, чем другие. А какой-либо из этапов вообще невозможно выполнить здесь и сейчас.
Результат — недоразумение в команде, конфликтные ситуации, разочарование и в большинстве случаев… потерянный потенциал разработчика.
Ведь здесь нужно понимать: девелопер в этой ситуации — подчиненный. А проджект — руководитель. Но часто это именно та ситуация, когда руководитель не прав. И именно из-за его ошибок или неготовности воспринимать другую точку зрения команда работает неэффективно, тратит время на лишние действия или даже разваливается.
Главный секрет успешно выстроенного процесса работы между менеджером и разработчиком — это грамотно настроенная коммуникация и искреннее желание проджекта понять девелопера. Как этого добиться? Как минимум — не допускать распространенных ошибок, о которых я расскажу дальше.
Вредные советы
Я попробую построить свои рекомендации для коллег несколько нестандартным образом в виде вредных советов с рекомендациями, как лучше всего строить сотрудничество в команде.
И если вы вдруг почувствуете, что в своей работе случайно или даже намеренно такие вредные советы используете, то самое время тщательно пересмотреть свой подход к взаимодействию с подчиненными.
1 Как можно чаще отвлекайте разработчика по делу и без, контролируйте его
В офисах Google у сотрудников нет привычного графика. Человек может прийти в любое время и так же уйти из офиса, когда считает нужным. А в течение дня может заняться своими делами, поиграть в PlayStation или даже вздремнуть часик в специальной комнате для отдыха.
Секрет в том, что у каждого есть свои задачи и дедлайн их выполнения. Главное, чтобы сотрудник выполнил весь объем работы. А сколько времени он при этом проводит на рабочем месте и чем еще занимается — дело второстепенное.
Мы, конечно, не Google. Но какой смысл каждый час мониторить деятельность разработчика и заставлять отчитываться по каждому этапу работы? Поверьте, гораздо правильнее дать специалисту спокойно работать и самостоятельно планировать этапы решения поставленных задач. Я не говорю, что контроль не требуется в принципе. Но он не должен быть фанатичным и абсолютным. Это лишнее.
2 Не беспокойтесь о подготовке качественного ТЗ. Опытный разработчик самостоятельно сориентируется
Запомните одну очень важную вещь! То, как вы сформировали задачу в своей голове, и то, как ее видит разработчик, может быть совершенно разными формулировками. Если вы взялись за подготовку технического задания, то позаботьтесь, чтобы оно было максимально детализированным и понятным.
Представьте, что создаете его для специалиста, который вообще не знаком с вашим проектом и которому нужно объяснить каждый пустячок.
Да, вы потратите на подготовку ТЗ определенное время. Но это гораздо меньше, чем может потребоваться для повторного выполнения той же задачи из-за того, что вы с разработчиком друг друга не поняли. Поверьте, никто не хочет дважды делать одну и ту же работу.
3 Не вносите все правки сразу. Разбейте их на части и прорабатывайте каждую отдельно
Когда проджект-менеджер не может собрать все правки и комментарии в единый список, он априори сомнительный специалист.
Если у вас будут правки по проекту (а они правда могут быть):
- соберите их все;
- дайте пояснения;
- проверьте список и структурируйте его.
И только после этого передавайте разработчику.
Иначе вы потратите колоссальное количество времени на то, чтобы решить все спорные вопросы. А разработчик просто моментально выгорит, потому что бесконечно будет заниматься исправлением ошибок и доработками вместо того, чтобы сконцентрироваться на главной задаче.
Понятно, что ситуации бывают разные. И не всегда одной итерации достаточно. Но превращать правки в нескончаемый поток точно не стоит.
4 Не учитывайте пожелания девелопера по дедлайну и его идеи вне задачи
Неумение или нежелание прислушиваться к подчиненным — очень отрицательная черта проджекта. У разработчиков должна оставаться возможность выражать свои идеи и имплементировать их в проект. А в некоторых случаях даже влиять на дедлайн задач, над которыми они работают.
Помните, что они как минимум лучше ориентируются в своей теме, чем вы. И это нормально. Но здесь все же следует сохранять предел, чтобы уже сами девелоперы не начали использовать такую свободу для уменьшения собственных объемов работы из-за нежелания работать в привычном ритме.
Вы должны спрашивать и выслушивать предложения разработчиков, советоваться с ними по поводу дедлайнов, обсуждать вопросы, которые вам не решить самостоятельно. Вы на одной стороне, не забывайте об этом.
5 Не нужно хвалить подчиненных — это их работа. И не забывайте «подсыпать» срочные задачи
Похвала — это мощный мотиватор в любой работе. Если специалист действительно хорошо выполнил поставленную задачу, проявил инициативу, внес свой весомый вклад в развитие всей компании, почему бы не похвалить его? Этим вы продемонстрируете его ценность и значимость.
Такой мотиватор часто работает гораздо лучше, чем денежная премия в конце месяца.
Применимо к срочным задачам, важно понимать следующее. Когда у вас постоянно появляются задачи «на вчера», это уже вопрос к вам как проджект-менеджеру. Ваша задача — планировать рабочий процесс так, чтобы подобного вообще не происходило или происходило как можно меньше. Форс-мажорные обстоятельства происходят, но они не должны стать для вас и ваших подчиненных нормой.
Вместо итогов
Важная отличительная черта эффективного взаимодействия проджект-менеджера с разработчиком — это стабильность. Если эта стабильность исчезает, значит, вы что-то делаете не так.
Например:
- Специалист долго отвечает на ваши сообщения, хотя раньше отвечал сразу.
- Девелопер просит обратиться к кому-то другому с этой задачей, потому что не может (или не хочет) ее делать.
- Разработчик просто изменил свое отношение к вам, стал неприветливым и, грубо говоря, холодным.
Если наблюдаете нечто подобное, есть вероятность того, что рабочие отношения уже испорчены. Но даже это еще отнюдь не критическая ситуация. Ее можно исправить. И я обязательно расскажу об этом в следующей публикации на Highload.
Сейчас же хочу подытожить все вышесказанное и подчеркнуть, что главные задачи любого современного проджект-менеджера — это:
- Слушать и слышать. Не спорить, а находить компромисс в сложных ситуациях.
- Не перегружать разработчика, а помогать найти баланс между работой и досугом.
- Четко объяснять каждую задачу и в то же время оставлять простор для новых идей и путей решения задач.
- Научиться понимать личные проблемы сотрудника и при необходимости делать паузу для перезагрузки и отдыха.
Я искренне надеюсь, что мой опыт и советы помогут кому-нибудь из вас лучше построить собственную работу и взаимодействие с разработчиками, не тратить их потенциал, а только наращивать его.
Но вы, конечно, можете не согласиться с некоторыми моими мыслями и утверждениями. Потому приглашаю своих коллег проджект-менеджеров к обсуждению темы в комментариях. Как вы взаимодействуете с девелоперами и раскрываете их потенциал? Давайте поговорим!
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: