Впахиватель)
верно. Задачи генерит бизнес или рынок (например, ритэйлы сейчас срочно переходят в digital). А вот как решить эту задачу — это уже команда решает во главе с DMом, да
Риск «Jack of all trades....» явный, чего таить.
Советы такие:
1) выбрать какой-то индустриальный домен и достаточно долгое время (ибо менять можно и нужно) «дышать» технологиями этого домена. Фокус-фактор выше, момент — сильнее.
2) или выбрать некую область технологии (мы называем это практикой), например, data solutions — которые деливерить на множество клиентов.
Знание техники морфирует от уровня к уровню: от деталей кода на первых уровнях, до понимания, какие задачи бизнеса решает те или иные системы и какие риски на масштабирование и поддержку они приносят — считайте, Enterprise Architect.
Еще, как вывод, для действительно сложных программ одинаково нужны и супер-процессники, которые будут сводить многочисленные проекты в контролируемый процесс, и деливери менеджеры на платформы и системы, которые, собственно, и призваны решать поставленные задачи. Тогда и нет перегрузки на одну роль и присутствует экспертиза.
Ближе всего DM и Tech PM в середине карьеры. там сходство просто _очень_ сильное (особенно взяв Amazon-style определения TPMов), но...
Три отличия, почему мы не выбрали это имя для EPAM.
0. Начальный уровень DM — это Multi(hybrid)-Skilled Team Leader. Все же это не Tech PM. и нам хотелось сделать разницу.
1. Для Senior DM и далее мы хотели заложить больше продуктового менеджмента (выбирать правильные вещи первыми, делать эффективно) и дать развитие карьеры в направления индустрии или практики как enterprise architect, что чуть различается от «классического» (тоже на-тоненького) определения TPM (Technical Project/Program Manager)
2. Мы IT компания. У нас все в той или иной степени Technical PM :) Различие было в сути вопросов, на который отвечают люди носящие той или иной тайтл. Помимо общих вопросов менеджера «Что?», «Когда?» (и да, технический PM быстрее найдет ответ на первые два), + «Сколько?».DM-а же мы просим ответить на дополнительный вопрос «Как» — т.е. уклон в способности управлять решениями «под ключ» и уметь копать в детали.
+ one more thing, может это и главное
для трансформации культуры нужны сильные изменения. новое имя — это очевидное подспорье.
p.s. опережая вопрос — «а чем отличается это от Product Manager и Solution Architect» :) но тут вроде понятно — Prd.M отвечает за стратегию и успех платформы на рынке но не факт что сам управляет процессом созидания. Архитектор еще менее вероятно, что управляет.
Надеюсь, ответил.