Александр Демура: «Вначале я лез к каждому разработчику с замечаниями»

Александр Демура: «Вначале я лез к каждому разработчику с замечаниями»
Глава одесского центра разработки DataArt Александр Демура дал интервью слушателю курсов Iampm Всеволоду Франко. Мы отобрали для вас самые интересные цитаты о минимальном наборе знаний, необходимом опыте и частых ошибках PM. А полностью текст беседы можно прочитать здесь.

О непонимании

Я думаю, неприязнь формируется, когда разработчики не видят пользы от менеджеров проектов. Сидит разработчик и думает: «Вот я за неделю завершил три задачи, сделал такой-то функционал, а какую пользу проекту принес менеджер? Дергает всех созвонами, мучает отчетами, двигает задачи туда-сюда, болтает по телефону. Если бы не отвлекал постоянно, может, я закрыл бы за неделю четыре задачи, а не три. Пользы от него никакой, а получает, наверное, побольше моего».

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

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

О переходе в PM

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

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

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

О знаниях и качествах

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

Для меня важнейший фактор — способность кандидата доказать причинно-следственную связь между своими действиями и какими-то положительными изменениями в проекте, который он вел. Когда проект классный, заказчик адекватный, технологии свежие, объем требований нормальный и команда справляется, легко быть хорошим РМ-ом и ходить, выпятив грудь. А что делать, если в проекте проблемы?