Из всех ваших описаний ясно, что вы видите РМ только в аутсорсной разработке (клиент в продуктовой это конечный потребитель, заказчик в продуктовой больше ставит цель верхнеуровнево и не ходит к кодерам). РМ в аутсорсе отвественнен за «проект», в том чтобы он не провалился, но часто полномочий у него мало — влиять напрямую на кол-во людей в команде он не может (бюджет определяет клиент), увольнять людей может только в рамках проекта. «Просто по моему опыту, мало кто заморачивается всей нетехнической стороной, маркетингом там, бизнесом клиента и профилем юзера.» — этого РМ-у в аутсорсной и вовсе не будут давать, так как никто не поверит что он что-то может. Чаще всего РМ ответственен за коммуникацию, за мотивирование, координацию. Но если команда небольшая, то это всё прекрасно закрывает ВА, если команда большая, то он просто следит за организацией процесса, и пытается закрывать проблемы по мере возможностей. Плюс общение с заказчиком на старте, но тут и составление договора, и проработка первоначальной документации. Ну и быть ответственным, что заказчик «рад» заплатить по счёту.
В продуктовой компании РМ больше имеет полномочий, за счёт того что команду можно набирать и увольнять, и чаще нужно вести людей в плане их развития (курсы, ревью знаний, рост по позициям). Опять же в продуктовой компании это может совмещать продакт в себе. Отдельный продакт и РМ возможны, но это означает что РМ номинальный и чаще всего он слишком похож на тимлида (Яндекс в пример, всё именно так).
Нужен ли для координации и организации небольших команд разработки до 15-ти человек (большие всегда будут дробить на небольшие) МВА? С моей точки зрения — он не бесполезен, но не нужен в полной мере.
К самой статье есть ряд замечаний, но в целом она слишком «общая». Изучение компании лучше начинать с человека который уходит с вашей позиции или работает на аналогичной, так же не стесняться задавать эти вопросы при собеседовании — «Почему ушёл предыдущий? Чем занимается другой РМ сейчас? Могу ли я с ним пообщаться, чтобы лучше понять организацию работы?».
Много вставок "я", словно человеку нужно везде показать что он самый нужный и важный. После того как прочитал, что как будут выглядеть календари для маркетологов (вроде это фича для пользователей, и решать лучше им) будет решать продакт — перестал читать и проматывал по диагонали. Там хорошо видны все "я". По нужности скиллов у вас статья про project manager.
В продуктовой компании РМ больше имеет полномочий, за счёт того что команду можно набирать и увольнять, и чаще нужно вести людей в плане их развития (курсы, ревью знаний, рост по позициям). Опять же в продуктовой компании это может совмещать продакт в себе. Отдельный продакт и РМ возможны, но это означает что РМ номинальный и чаще всего он слишком похож на тимлида (Яндекс в пример, всё именно так).
Нужен ли для координации и организации небольших команд разработки до 15-ти человек (большие всегда будут дробить на небольшие) МВА? С моей точки зрения — он не бесполезен, но не нужен в полной мере.
К самой статье есть ряд замечаний, но в целом она слишком «общая». Изучение компании лучше начинать с человека который уходит с вашей позиции или работает на аналогичной, так же не стесняться задавать эти вопросы при собеседовании — «Почему ушёл предыдущий? Чем занимается другой РМ сейчас? Могу ли я с ним пообщаться, чтобы лучше понять организацию работы?».
Много вставок "я", словно человеку нужно везде показать что он самый нужный и важный. После того как прочитал, что как будут выглядеть календари для маркетологов (вроде это фича для пользователей, и решать лучше им) будет решать продакт — перестал читать и проматывал по диагонали. Там хорошо видны все "я". По нужности скиллов у вас статья про project manager.