Технические навыки - это навыки и системный подход в области управления проектами:) никаких Java, PHP, C

Хорошо вы живете )) в 70% компаний, где я был, под этим имеют в виду именно стек разработки )

Наверное им нужны не совсем ПМы:) найти человека с системным  мышлением и стратегическим виденьем уже не просто, а тут ещё и стек разработки

от проектов зависит ) если проекты - типовые, в пресейлах участие не нужно, рутины дофига - думаю можно взять и без видения и мышления. если нетиповые, большие, требуют тщательного планирования - да, важно. если же проект (как в большинстве случаев) представляет из себя непонятно что - что-то надо сделать (но неясно что), как можно дешевле и точно в срок - скорее не ПМ нужен, а лидер, кто на себя ответственность возьмет по всем фронтам и будет всех пинать ходить, а так же убеждать руководство что результат есть (особенно, если он правда есть). Таких позиций на рынке и большинство. Ну  + добавим сюда все позиции скрам-мастеров, продукт-менеджеров, руководителей направлений, тимлидов, где пишут проджект менеджер. Увы, слово "проект" в России де факто обозначает очень многое

Коллеги, про тех. навыки имеется в виду вот что

2018-08-14 17:22

клево, но одному мне кажется что domain expertise  - это как раз знания в области, например если это разработка ПО, то это опыт в управлении разработкой? )

Про отраслевые технические знания тут ни чего нет

пару месяцев назад уже обсуждали, насколько глубокие знания нужны ПМу профильные - к общему согласию не пришли.

Стандартный вопрос: должен ли РП по разработке ПО уметь программировать?
Ответ: не обязательно, но очень желательно.

Хм, ну тут в вопросе ошибка. Должен ли РП проекта создания нового автомобиля быть гонщиком или автомехаником в прошлом? ) Как много таких автомобилей вы знаете? Насколько их проекты успешные?

У меня есть реализованные проекты создания корпоративного портала на SharePoint и заказной разработки системы мониторинга ит-инфраструктуры. Программировать не умею.
И есть проекты построения крупных корпоративных сетей хранения данных. Чем iSCSI отличается от FC я вам не расскажу.
Но проекты успешно завершены.

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

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

Михаил спасибо. Оно самое.

В идеале нужно, чтобы человек умел всё. Но если есть выбор - опыт работы с подрядчиками/выбора поставщика или несколько языков программирования. То я, пожалуй, выберу первую опцию.

Я второе. Но это сугубо мой личный опыт после обильной практики по первому сценарию. Второе, как минимум, развязывает руки и всегда будет востребовано. Первое уже и так отмирает, если организовать грамотно работу с порога и заложить правильные схемы работы с подрядчиками (имею ввиду рамочные контракты с предельными суммами на 2-3 года и работа по заказам), когда оттендерился разок, а потом по рельсам катаешься, изредка используя soft skills. Второе привлекательнее тем, что это гарантия трудоустройства где угодно и когда угодно, при желании халтура, при желании - стек знаний, который может очень помочь в ситуации, когда тебе нужно в одиночку спасать мир, как Брюс Уиллис

Какое максимальное количество человек у вас было в проектной команде, сколько стейкхолдеров, сколько ПМов было в прямом подчинении, сколько подрядчиков, как часто приходилось бывать спонсором проекта, сколько процентов своего рабочего времени вы тратите на коммуникации? Не хочу обидеть, но как только в команде планировния на IT проекте появляется Solution Architect, то я вообще не понимаю зачем ПМу технический бекраунд. Сам по себе технический бэкграунд безусловный плюс, если не в ущерб другим навыкам.

Технический бэкграунд нужен когда нет техлида. И нет возможности вытащить. :( Ну спит он сейчас.