Александр Демура — человек, который посвятил сфере айти более 10 лет. Под его эгидой уже более 5 лет развивается одесский офис одной из ведущих IT-компаний Украины — DataArt. Сам Александр не понаслышке знает трудности и прелести работы проектным менеджером, так как сам, в своё время, был в этой роли. А еще он был в команде многих проектных менеджеров и сейчас сам управляет PM-ами. Теперь он готов поделиться своим мнением с теми, кому ещё только предстоит эта дорога. Александр ответил на вопросы интервью, которое провел наш студент — Всеволод Франко.
После прочтения статей о PM-ах, складывается впечатление, что разработчики эту профессию недолюбливают. Так ли это и почему?
Это хороший вопрос. Я думаю, неприязнь у разработчиков формируется, когда они не видят пользы от менеджеров проектов. Сидит такой разработчик и думает: «Вот я за неделю завершил три задачи, сделал такой-то функционал, а какую пользу проекту принес менеджер? Дергает всех созвонами, мучает отчетами, двигает задачи туда-сюда, болтает по телефону. Если бы не отвлекал постоянно, может, я закрыл бы за неделю четыре задачи, а не три. Пользы от него никакой, а получает, наверное, побольше моего». И это — достаточно глубокая тема, которую двумя предложениями не покрыть.
Отчасти так происходит, потому что нынче в моде Agile-подход, где процесс достаточно простой и хорошо описанный. В его центре — самодостаточная команда, которая сама решает все возникающие вопросы, коммуницирует с представителем заказчика, оценивает объем работ, отчитывается и отгружает продукт. Даже роль Scrum-мастера, который, вроде как, должен отвечать за процесс, на самом деле – переходящая, и совершенно не завязана на PM-е. Неопытные PM-ы в этой ситуации периодически теряются, не понимают, что им делать, и уходят в разные крайности: кто-то перестает работать вовсе (ведь процесс-то самодостаточный), кто-то, наоборот, из кожи вон лезет, пытаясь доказать всем вокруг свою руководящую значимость… Оба варианта, естественно, совершенно деструктивные. Плюс сюда добавляется большое количество разнообразных PM-«болезней»…
Помню, когда меня впервые поставили руководить проектом (до этого я был разработчиком), я это воспринял как сигнал, что я самый важный, главный и мое мнение — единственно правильное. В итоге я ходил за каждым разработчиком, лез ко всем в код с замечаниями, совал свой нос в каждую щель, и вообще не давал никому вздохнуть спокойно. Сам при этом, естественно, ничего толком не успевал — ведь все время уходило на «важные руководящие дела»…
Помню, что был крайне возмущен, когда команда на меня пожаловалась вышестоящему начальству. Со временем это, конечно, удалось перерасти, но похожие симптомы я периодически наблюдаю тут и там. Мне в голову приходит еще множество подобных ситуаций и историй — я, пожалуй, из этого даже доклад сделаю на Odessa Innovation Week этой осенью, спасибо за идею.
А нужна ли тогда вообще эта профессия?
Ну конечно же! Тут достаточно только вспомнить, что тот же Scrum — вообще-то не методология управления проектами, и очень много вопросов (инициация проекта, управление рисками, поставщиками, зависимостями, завершение проекта, и т. д, и т. п.) остается за кадром. Кто-то же должен всем этим заниматься!
Например, к нам приходит заказчик с новой идеей и спрашивает, за сколько времени и денег мы сможем ее реализовать — как ответить на этот вопрос? Для долгосрочного планирования Scrum обычно использует данные по прошлым итерациям, а что делать, когда ничего нет? Сколько человек должно быть в команде? Какие навыки им понадобятся? Когда проект будет готов? Как найти правильных людей со стороны заказчика, кто смог бы сформулировать бэклог проекта? Кто в итоге будет нести ответственность за результат? Классическая теория менеджмента прекрасно отвечает на эти вопросы, и на многие другие тоже.
К тому же, Agile заточен на использование внутри компании для разработки собственных продуктов, где все в одной лодке и объединены общей целью. Как только начинаются отношения вида «заказчик — исполнитель», особенно разделенные несколькими часовыми поясами, появляется целый новый пласт задач и рисков.
Оказывается, что у заказчика есть какие-то ожидания, которыми необходимо управлять. Если он недоволен нашей работой, он может не заплатить, а в крайних случаях — подать на нас в суд. То, что в классическом Agile решается разговором у доски — здесь превращается в комплекс регулярных упражнений, с документами и отчетами, а ведь еще нужно пытаться не потерять пресловутую гибкость.
Еще может оказаться, что команда зависит от результатов работы сторонней дизайн-студии, которую нанял тот же заказчик, и которая нам неподконтрольна, или нужно интегрироваться с каким-то левым кодом, который параллельно пишется непонятно кем и как… И совсем классика жанра — когда заказчик не может толком сформулировать требования, но зато очень хочет, чтобы все было готово к конкретной дате.
Кроме управления собственно проектом и взаимодействия с заказчиком, нужно не забывать и про команду — даже если все хорошо с процессами, всегда остаются вопросы развития и мотивации людей. В общем, хороший РМ на любом проекте найдет способ себя проявить.
Часто PM — следующая ступень карьерного роста аналитиков, разработчиков или тестировщиков. Выходит, для этой должности обязателен опыт работы в одной из этих областей? Можно ли сразу стать РМ-ом?
Я изо всех сил борюсь с расхожим мнением, что PM — следующий шаг развития аналитиков, разработчиков или тестировщиков. Начнем с того, что это, как минимум, шаг не вперед/вверх, а вбок, и это нужно четко понимать.
Весь накопленный разработчиком опыт ему практически никак не помогает в роли РМ-а — РМ работает не с кодом, а с людьми.
Глубокое понимание технической части, конечно, помогает разговаривать с разработчиками на одном языке, но таит множество потенциальных рисков и проблем. Страсть к микро-менеджменту и убежденность, что знаешь как лучше — одна из них. Другая проблема — без постоянной практики знания начинают безнадежно устаревать, РМ со временем перестает ловить мышей и начинает продавливать давно уже устаревшие подходы времен своей молодости. Вообще, РМ — скорее роль, нежели титул, и, в принципе, эту роль может при желании играть любой член команды. Расширение зоны ответственности и набора выполняемых задач, и правда, часто приводят к каким-то повышениям, но, тем не менее, я бы не стал рассматривать РМство именно как следующую ступень карьеры.
Бытует мнение, что РМ — это вход в IT для гуманитариев. Так ли это?
Тут сложно. У нас в компании большинство менеджеров вырастает-таки из технарей, хотя я видел случаи, когда не программисты становились успешными менеджерами. Без определенной технической базы, разумеется, не обойтись: как минимум, нужно в общих чертах понимать, что такое веб-сервис и что делает база данных, но супер глубины может не быть.
Так же тут есть риск развития других патологий. Я иногда вижу, как менеджер в проекте выполняет исключительно коммуникационную роль. Клиент что-то спросил? Переспросили команду. Команда что-то ответила? Переформулировали ответ в более понятный и выдали обратно заказчику.
По сути, такие PM-ы играют роль прозрачных прокси-сервисов, просто передавая информацию от одной стороны к другой, не совершая при этом практически никакой полезной работы. Команда такого менеджера зачастую практически не замечает, и, соответственно, любит далеко не всегда. Впрочем, если менеджер хочет разбираться, что он делает, болеет за проект, заказчика и команду — гуманитарное прошлое не проблема. Работа менеджера проектов достаточно многогранна, чтобы была возможность проявить самые разнообразные навыки и сильные стороны.
В разных компаниях предъявляют разные требования к этой профессии. Можно ли обобщить, какими навыками, знаниями и в каких областях должен обладать сферический РМ в вакууме?
Сферический РМ в вакууме должен понимать, какие в его распоряжении есть инструменты и уметь рассказать, как эти инструменты применять. В базе нужно уверенно владеть всякой аджальной методологией и общей теорией, например, уметь объяснить и на примере показать, что такое критический путь в проекте. Еще было бы неплохо продемонстрировать какие-нибудь техники управления людьми, и опыт решения конфликтных ситуаций.
На что в первую очередь обратит внимание работодатель при найме PM-а? Что станет весомым преимуществом в его пользу?
Я не могу говорить за абстрактного работодателя — только за себя. Для меня важнейший фактор — способность кандидата доказать причинно-следственную связь между своими действиями и какими-то положительными изменениями в проекте, который он вел. Когда проект классный, заказчик адекватный, технологии свежие, объем требований нормальный и команда справляется, легко быть хорошим РМ-ом и ходить, выпятив грудь. А что делать, если в проекте проблемы?
Легко быть хорошим PM-ом на простом проекте
Очень часто я наблюдаю ситуацию, когда РМ смотрит на такое с позиции пассивного наблюдателя. Если во всем виноват плохой заказчик, или руководство, или команда слабая, или еще что-нибудь, а РМ — просто несчастная жертва обстоятельств — для меня это серьезнейший сигнал задуматься.
Еще я люблю, когда РМ не забывает в любой ситуации держать мозг включенным, а не просто применять по списку набор практик, которым его научили на двухдневных курсах. Стартап на три человека управляется совершенно не так, как энтерпрайз на 300, но некоторые про это забывают, и везде ходят в футболке “Оne size fits all”.
Предположим, студент хочет устроиться работать по этой специальности. Возможно ли это и, если да, какие особые требования будут к нему? Что бы вы посоветовали такому студенту?
Студенту такому будет у нас сложно. У нас много клиентов, много проектов, разные технологии, разные процессы, у РМ-а — огромное число степеней свободы, и нужно обладать достаточно обширным опытом, чтобы правильно этой свободой пользоваться. Разумеется, в компании есть и курсы, и прописаны best-practices, и есть более опытные коллеги, готовые поделиться опытом, но неопытный РМ — в любом случае, риск для компании.
Я бы на начальном этапе рекомендовал компанию, которая занимается чем-то одним, где процесс расписан по шагам и стандартизован, и каких-то особых потрясений не происходит. Это позволит человеку набраться опыта, научиться пользоваться правильными инструментами и оттуда уже переходить к более сложным задачам. Спрос на джуновых РМ-ов у нас, в DataArt, конечно, бывает, но он очень уж периодический и неравномерный, попасть к нам без опыта сложно, хоть и не невозможно.
Пару слов от интервьюера — Всеволода Франко: интервью с Александром дало мне понять, что, если уж я решил стать PM-ом, то стоит не просто учиться практикам управления проектами, но и нужно серьезно вникать в саму IT сферу. Более того, работа PM-а подразумевает постоянный рост и развитие. Теперь — я вечный студент и буду вынужден все время впитывать новые знания и использовать новые практики (что, впрочем, меня ни капли не расстраивает — учиться я люблю). А еще — спасибо Александру: не смотря на то, что его компания редко нанимает проектных менеджеров без опыта, он четко дал понять с чего мне стоит начать и в каких компаниях искать работу.