Не соглашусь. В гибких есть 2 наиболее распространенных подхода: 1. Наличие ПМ в роли лидер-слуга, разгоебающий препятствия. В таком варианте ПМ с техдидом никак не совместим. 2. Скрам, девопс и подобные - роль ПМ отсутствует. Ответственность командная, лидерская роль ситуативная.

2 - форма почти не жизнеспособная 🙂

ну его хотя бы будут слушаться)

Это точно! В реальной жизни не встречал.

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

Конфликт простой - PM сам себе заказчик, разработчик и приёмщик.

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

Ага, плавали, знаем.

В большинстве случаев - нет

Истина - в деталях. Часто TL просят убрать от них "манагера", чтобы не мешал. Особенно, когда кодеры сидят в своей Jira+Conf и считают, что мир производства ПО сосредоточен иммено в этой связке.

коллеги, доброго вечера! Есть у кого опыт релокации в Германию?

В таких случаях можно оставить манагера на внешний контроль проекта. Мы так делали. И манагеру не накладно и руководство знает, что происходит и команде никто не "мешает". Все только выигрывают.

И такой опыт был 🙂

Если команда ответственная, то самый отличный вариант

всем привет. Управление проектами в нко. Ищу наставника из бизнеса.

Для этого TL нужно выучить на PM, а на это требуется тоже не мало лет, пока наберёт опыт использования инструментов управления проектами. При этом, при совмещении обеих этих ролей какая-то из компетенций, либо техническая, либо управленческая,  неизбежно будет страдать.

А как же тогда справляется ScrumMaster? :)))

В этом нет конфликта, если кодеры и TL действительно выполняют свои обязательства в заданный срок, с заданным содержанием, с заданным качеством и не выходят за плановые трудозатраты (бюджет) и ещё если у них получается координировать свои действия с прочими структурными подразделениями компании и заказчиками. Но... так бывает не всегда. Я бы сказал, что это редкость.

А кто сказал, что он справляется? Тут нужно внимательно смотреть в детали, с чем действительно справились, а про что замазали очки стейкхолдерам. Но при этом, скрам мастер, это роль выделенного координатора работ. Меня как менеджера вполне устраивает команда способная организоваться в спринте. И я готов отдать в гибкие методологии, то есть в руки скрам мастера производство минорной версии разрабатываемого продукта, но получение мажорной версии, уже рискованно, а рисками гибкие методики или фрэймворки как то не управляют.

А если еще учесть, что в классическом скраме скрам мастер не координатор работ, а что-то вроде коуча - фасилитатора, то область применимости именно скраммастера становится очень четко очерченной: небольшие достаточно автономные продукты. Если говорить о гибких подходах в проектном управлении более широко, не ограничиваясь скрамом, то мне подход  PMI Agile Guide вполне близок. Пм выполняет ролькоординатора-помощника и интерфейса с внешним миром, разгружая команду для выполнения конкретных работ. Пресловутый лидер-слуга, но облеченный и ответственностью, и полномочиями. Так работает.