Должен ли PM вникать в процесс разработки: разбираемся на примерах

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

Дьявол в деталях

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

Должен ли PM вникать в процесс разработки: разбираемся на примерах 0

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

 

Кейс первый. Не отстоял интересы команды

PM выбрал неправильную систему контроля версий. Точнее, не помог выбрать правильную.

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

Наш заказчик в прошлом имел опыт разработки (как потом оказалось, ему было где-то за 50) и, исходя из своего опыта, из двух вариантов систем контроля версий (консервативной SVN и современной GIT) он выбрал SVN, аргументируя тем, что будет, порой, заходить и проверять, как идет работа. Это сильно тормозило разработку и портило настроение всей команде, так как более навороченный GIT в десятки раз удобней, да и привычней. Надо ли говорить, что мы просили PM-а повлиять на мнение заказчика?

Должен ли PM вникать в процесс разработки: разбираемся на примерах1 1

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

 

Кейс второй. Влетели в копеечку

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

Должен ли PM вникать в процесс разработки: разбираемся на примерах2 2

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

 

Кейс третий. Нет доступов — нет работы

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

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

Должен ли PM вникать в процесс разработки: разбираемся на примерах3 3

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

 

Так что должен знать проектный менеджер?

На самом деле PM — это человек, который умеет всего по чуть-чуть, но, в первую очередь, он должен быть эффективным коммуникатором.

Что нужно, чтобы быть хорошим PM-ом:

  • умение быстро и эффективно разбираться в предметной области проекта;
  • понимание жизненного цикла создания ПО;
  • знание методологий построения процесса создания ПО;
  • умение анализировать потребности заказчика и его бизнеса;
  • умение планировать свое и чужое время;
  • умение стоять на своем и продвигать интересы заказчика или команды;
  • умение мотивировать сотрудников;
  • навыки тайм-менеджмента;
  • навыки управления финансами в проекте;
  • навыки управления командой;
  • навыки управление внешними и внутренними коммуникациями.

На этом список только начинается, ведь чтобы построить эффективные коммуникации нужно понимать тех, кто пишет «расширяемый и поддерживаемый код» и понимать основные термины.

Что, по мнению программистов, должен знать и уметь хороший PM:

  • знать как хранятся данные на проекте;
  • чем отличаться frontend от backend;
  • чем языки программирования отличаются друг от друга;
  • как происходит деплой проекта (хотя бы куда);
  • понимать, что такое HTTP и JSON формат;
  • знать основные этапы разработки приложений в зависимости от сферы;
  • уметь гуглить.

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

Как подтянуть матчасть?

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

Должен ли PM вникать в процесс разработки: разбираемся на примерах4 4

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

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

Автор статьи: Дмитрий Ховрич