Проектный менеджер многим кажется супергероем: лучший друг команды, верный советник заказчика, знает английский с рождения, умеет доносить информацию жестами, мгновенно добавлять задачи в таск-трекер и тушить пожары на проекте голыми руками. Но должен ли он, в придачу, иметь опыт разработки?
Дьявол в деталях
Задачи проектного менеджера далеки от написания кода, но для того, чтобы заслужить уважение команды и довести проект до логического завершения, PM обязан не просто выступать в роли почтового голубя, донося сообщения заказчика команде, а полностью взять в свои руки управление разработкой.
Проблема в том, что для этого нужно вникать. Я знаю несколько ситуаций, где проектный менеджер совершил ошибку именно из-за пробелов в матчасти, а наказание понесла вся команда.
Кейс первый. Не отстоял интересы команды
PM выбрал неправильную систему контроля версий. Точнее, не помог выбрать правильную.
Что вообще такое система контроля версий? Если проводить аналогию с компьютерными играми, то это возможность в любой момент сохраниться, и, если что-то не получилось, пройти уровень с контрольной точки заново.
Наш заказчик в прошлом имел опыт разработки (как потом оказалось, ему было где-то за 50) и, исходя из своего опыта, из двух вариантов систем контроля версий (консервативной SVN и современной GIT) он выбрал SVN, аргументируя тем, что будет, порой, заходить и проверять, как идет работа. Это сильно тормозило разработку и портило настроение всей команде, так как более навороченный GIT в десятки раз удобней, да и привычней. Надо ли говорить, что мы просили PM-а повлиять на мнение заказчика?
Когда стадия планирования закончилась и мы начали активную работу, оказалось, что вопрос и не поднимался. Думаю, если бы проектный менеджер понимал всю важность правильной системы контроля версий, он бы не проигнорировал нашу просьбу.
Кейс второй. Влетели в копеечку
Не менее интересным случаем стала ситуация, когда PM принял в работу ряд задач, связанных с аудио-плеером на сайте. Одним из критериев приемки было то, что на сайте все время (не останавливаясь) должна была играть музыка, а сайт изначально был спроектирован так, что данный функционал без костылей и шишек создать было невозможно.
Стоил ли этот плеер затраченных на него времени и сил так и осталось загадкой. Возможно, объясни проектный менеджер заказчику все изначально, тот бы передумал и выбрал более простой вариант реализации, но этого не случилось и разработка влетела клиенту в копеечку.
Кейс третий. Нет доступов — нет работы
Постоянному клиенту команды понадобился маленький хот фикс на сервере в выходные дни. Отношения с заказчиком были настолько хорошие, что разработчик был не против в свой выходной день потратить пару часиков на работу. Все, вроде, договорились, после чего менеджер проектов должен был достать доступы к серверу и передать программисту.
Однако, не понимая всей серьезности поставленной задачи PM просто забыл это сделать. Не получив данные, программист решил, что задача отпала и хорошо провел выходные.
Утро понедельника получилось неловким, ведь, когда менеджер пришел за результатом, повисла длинная пауза. Какой, собственно, может быть результат, если нужные доступы специалист так и не получил?
Так что должен знать проектный менеджер?
На самом деле PM — это человек, который умеет всего по чуть-чуть, но, в первую очередь, он должен быть эффективным коммуникатором.
Что нужно, чтобы быть хорошим PM-ом:
- умение быстро и эффективно разбираться в предметной области проекта;
- понимание жизненного цикла создания ПО;
- знание методологий построения процесса создания ПО;
- умение анализировать потребности заказчика и его бизнеса;
- умение планировать свое и чужое время;
- умение стоять на своем и продвигать интересы заказчика или команды;
- умение мотивировать сотрудников;
- навыки тайм-менеджмента;
- навыки управления финансами в проекте;
- навыки управления командой;
- навыки управление внешними и внутренними коммуникациями.
На этом список только начинается, ведь чтобы построить эффективные коммуникации нужно понимать тех, кто пишет «расширяемый и поддерживаемый код» и понимать основные термины.
Что, по мнению программистов, должен знать и уметь хороший PM:
- знать как хранятся данные на проекте;
- чем отличаться frontend от backend;
- чем языки программирования отличаются друг от друга;
- как происходит деплой проекта (хотя бы куда);
- понимать, что такое HTTP и JSON формат;
- знать основные этапы разработки приложений в зависимости от сферы;
- уметь гуглить.
Данные навыки помогут менеджеру быть ближе к команде и сведут к минимуму ситуации отсутствия доступов к серверу и репозиториям, обещания исправить неполадки за час (если по факту работы на всю неделю), сократят количество неверных оценок, а также дадут понять команде, что их PM не просто почтальон, а такой же IT-шник, как и они сами.
Как подтянуть матчасть?
В подведение итогов хочу сказать, что технические знания для проектных менеджеров важны. Однако отсутствие опыта в разработке — не приговор. Выходцы из других сфер, проявляя любознательность и рвение, могут становиться прекрасными управленцами в IT сфере.
Чтобы заговорить на одном языке с программистами, нужно проявить желание разобраться в их деле. Хорошей практикой является прохождение курсов (можно изучить основы какого-то языка программирования, или сразу пройти курс по техническим знаниям для нетехнарей). Будет полезным чтение книг по архитектурным подходам, посещение тематических мероприятий и хакатонов.
Не стесняйтесь задавать вопросы своей команде, ведь лучше три раза спросить, чем один раз ошибиться со сроками и оплатой. Помните, ваша главная задача — работать со своей командой бок о бок и достигать максимального понимания в любой ситуации!