В IT переходят много специалистов из других сфер. Часто у них нет технического образования и опыта работы.
Итак, вопрос: какой технический уровень должен быть у Менеджера проектов в IT?
Для простоты предлагаю взять именно проектного менеджера, не касаясь продуктового.
Второе допущение — он работает в сфере IT аутсорсинга, т.е. заказной разработки софта для стороннего заказчика.
Третье допущение — он обладает необходимой подготовкой в проектном управлении, софт-скиллами, такими как лидерство, коммуникация, клиентоориентированность. Также у него есть некоторые навыки проектирования пользовательского интерфейса и бизнес-аналитики. Здесь предлагаю обсудить лишь уровень технических знаний в области разработки ПО.
Прошу также учитывать фактическое наличие специалистов с выбранным набором навыков на рынке труда — проще говоря реально ли найти такого человека, за адекватные деньги, и захочет ли он идти в усредненную аутсорс компанию.
Варианты:
Никакого. Он лишь управляет проектом, не вдаваясь вообще в технические нюансы. Отдает это на откуп команде разработке, техлиду, СТО, или другим профильным специалистам.
Общая техническая грамотность. Менеджер понимает суть и цикл разработки софта, обладает базовыми знаниями в сетях, тестировании, базах данных, архитектуре. Знает суть Back End и Front End разработки, абстрактно разбирается в языках программирования. Активно интересуется развитием отрасли. Не является в этом всём глубоким специалистом, но вполне понимает суть явлений, процессов, закономерностей.
Глубокие знания. Профильное образование и опыт. ПМ пришел на эту позицию с технической должности, имеет солидный опыт разработки, тестирования или системного администрирования.
Комментарии с аргументами горячо приветствуются.
alan008
Смотря что за проект. В каких-то можно менеджерить и без глубоких технических знаний, а к каким-то без этих знаний нет смысла и близко подходить.
Уровень менеджера должен быть как минимум не ниже уровня участников его команды, иначе его не будут уважать и слишком часто будут ставить на место более опытные разработчики.
VitStep Автор
Согласен.
Берем усредненную историю заказной разработки. Это, как правило, сайты, веб и мобильные приложения низкой и средней сложности, возможно CRM, и другие корпоративные штуки.
VitStep Автор
А в чем смысл? Он ведь не программирует, он управляет.
Насчет ставить на место — зависит от ситуации, от личных качеств ПМ-а и разработчиков. В целом по моему опыту это миф. Разные позиции — разработчики опытны в разработке, менеджеры опытны в управлении гораздо больше вышеуказанных разработчиков. С чего кому-то кого-то ставить на место.
alan008
В чем суть управления, по-вашему? Это же не только задачи раздавать и сроки оценивать, а еще и просчитывать риски, понимать сложные места (где технический долг может стать слишком большим), понимать причины проблем, предугадывать хорошие архитектурные решения, которые потом не выльются в месяцы переделок. Для всего этого нужна неплохая техническая экспертиза, которая может и возможна без знаний деталей технологий, но обычно наоборот накапливается путём набития шишек на множестве этих самых деталей.
VitStep Автор
Вы абсолютно правы про управление — это все есть.
Но я склонен считать что сложные места, причины технических проблем, архитектура — это работа техлида, архитектора, и выше по уровню — СТО. Проектный менеджер в этих вопросах имеет совещательный голос, так как не эксперт зачастую.
Про совмещение этих двух ролей — отдельная тема.
onegreyonewhite
А в чём тогда смысл ПМ'а? Бегать к более опытным, слушать что они скажут и раздавать задачи от них?
Может тогда хорошему техлиду или архитектору нанять секретаря — дешевле, а эффект тот же?
powerman
Не дешевле, и эффект не тот же. Несмотря на то, что часть деятельности ПМ-а действительно напоминает круг обязанностей секретаря, он им далеко не ограничивается.
По сути, основная задача ПМ — успешно довести проект до финиша (или ближайшего milestone). И чтобы это сделать необходимо учесть нужды всех stakeholder-ов (в случае аутсорса — внешнего заказчика/продакт-менеджера, интересы своей компании, архитектора, тимлида(ов) и QA текущего проекта) учитывая доступные этому проекту ресурсы (время, финансирование и команду). Чтобы эти нужды выяснить сначала ПМ-у действительно нужно "бегать к более опытным", но дальше он должен принять решение в каком объёме и очереди эти нужды удовлетворять и контролировать процесс выполнения работ — а это уже вовсе не уровень секретаря, и тем более секретаря одного конкретного stakeholder-а (тимлида/архитектора).
ogr
Тут всё же надо понимать, что у вас за заказчик.
Если это «коммерция», то там, чаще всего, заказчику важно иметь «одно окно» для решения всех вопросов. В этом случае хорошо, если ПМ будет верхнеуровневые технические проблемы решать на месте, не уходя на подумать и посовещаться с командой. Также будет быстрее работа вестись, если ПМ сможет понимать то, что ему пытается донести команда.
Если же это гос. заказчик, то у ПМа там очень специфичная роль: там лизни, тут наори и смотри, не перепутай. Но в таких проектах и ожидания заказчика от ПМ соответствующие.
Camill
Если какой-то проект нельзя менеджерить «без глубоких технических знаний», то значит, на этом проекте есть незакрытые задачи, для которых нужен тимлид/архитектор/CTO, а не менеджер. Потому что менеджмент — это про управление, а не про разработку. Даже если ты супер-крутой спец, через три года без кодинга ты отстал от индустрии навсегда и твои знания уже вовсе не глубоки. А через шесть лет они и вовсе могут начать мешать. Выбрасывать старых менеджеров на помойку и нанимать новых раз в три года — это так себе подход.
И это только если мы говорим про сферическую, относительно монолитную по компетенциям команду из одних разработчиков. А представьте, у вас небольшая команда, которая делает мобильное приложение — например, по распознаванию кошечек. Чтобы управлять ей, менеджер должен уметь в Джаву и базы данных не хуже, чем бэкендщик(и), машинное зрение — не хуже, чем спец по Computer Vision/Machine Learning, Свифт и Котлин знать не хуже, чем мобильщики, тестировать не хуже, чем тестер, и вдобавок, проектировать интерфейсы не хуже, чем дизайнер? Какой-то супермен получается.
Опытные разработчики физически не могут поставить менеджера на место, если менеджер не будет лезть в их область компетенции. Если менеджер сморозил фигню, и разработчики его натыкали носом — это не значит, что менеджеру нужно прокачиваться в менеджменте, а не в разработке.
alan008
Если основная область деятельности компании — разработка какого-л. программного продукта, то получается, что управляем мы чем? Этой разработкой. Вы противопоставляете понятия управление и разработки, но чем же тогда занимается менеджер, чем именно он управляет и каковы его обязанности?
Camill
Обязанности менеджера могут включать планирование и контроль сроков, бюджета, скоупа, ресурсов, переговоры со всеми стейкхолдерами, управление их ожиданиями, введение и настройка процессов. приоритизация задач, формирование команды, People Management, разрешение конфликтов вплоть до введения кризисного управления etc., etc.
Обязанности менеджера не включают написание кода или переламывание команды через колено по поводу конкретных технических решений — только по поводу последствий этих решений.
Чтобы принимать решения, менеджер не должен быть лучшим кодером, чем разработчики.