Всё верно. На очень больших проектах появляется необходимость разделять нагрузку с ПМ, так и появляется продукт-менеджер.
Грубо: продукт занимается генерацией идей, проджект — их исполнением.
Да, я согласен, очень точная аналогия. Именно поэтому я вообще мечтаю работать в области машиностроения (:
В общем то да, продукт-менеджер должен уметь очень многое, чуть ли не всё сразу, но в его роль не входит руководить всем. Ровно как и главный инженер отвечает за модель в целом, за её потребительские свойства и качества, но на деле производством руководят менеджеры проектов, так что я склонен считать, что за развитие продукта отвечает ПМ, а продукт-менеджер лишь помогает развиваться продукту в нужном русле, без углубления и принятия на себя функций управления конкретными этапами производства.
Отсюда и моё поддержание столь общей схемы: «Всё обо всём, но в общем».
Простите за масло масляное, с утра тяжело формировать мысли. И спасибо за хорошую наводку на литературу, обязательно прочитаю.
Так, стоп. Цель статьи — донести, кто такой менеджер продукта. И, как ни странно, к управлению продуктом, он имеет очень общее и несколько далёкое отношение. Это мой опыт и живой пример текущего проекта.
Скажите, пожалуйста, Вы как Вы описываете эту роль студентам? Как человека, который в итоге отвечает за продукт и его жизнь, то есть глава всех глав?
Простите, бизнес воздействует на государство?
Для меня категория бизнес — это всё, что не относится к разработке продукта и его поддержанию с технической точки зрения, а именно продажи, маркетинг, финансовое обеспечение организации, и да, правовая поддержка тут. Это так называемые подразделения обеспечения, они ничего не производят, а занимаются бизнесом, если угодно.
Может быть потому что в Tech, Business и UX можно вписать все указанные разделы Вашей иллюстрации? Это общепринятые общие разделы, простите за некоторую тавтологию. А так же потому, что продукт-менеджер не внедряется в рабочие процессы большинства из перечисленных разделов?
Именно по этому я стараюсь максимально разделять группировку задач на листах, чтобы была возможность по завершению группы (смежной) просто выкинуть лист. Об это «лёгкости» я и говорил в статье.
Ниже привели несколько интересных систем учёта, возможно, они будут Вам полезны. Я пока не вижу смысла уходить от бумаги, ручки/карандаша.
Я прочитал несколько популярных книг по управлению рабочим временем и практически ничего не усвоил для себя, так как живого опыта там мало. В их относительной пользе я с Вами согласен.
Я веду разные списки: свой личный на бумажном листе, и дашборды в таск-трекере, которые формируются автоматически. Без последних, естественно, не прожить, ибо актуализировать ситуацию и следить за ней нужно постоянно. Но дашборды не отражают личных задач. Заводить на каждую таск я пробовал, но это дублирование личных записей. Кажется, что просто лишняя работа.
Флипборды и обычные доски — отличная идея. Я пока не задумывался над их использованием в личных целях, применял только тогда, когда над задачей работает кто-то кроме меня. Поэкспериментирую, возможно, добавится наглядности в моей деятельности.
А без встреч никак. Я, к счастью, не использую Agile и прочие разновидности, но встречаться приходится по ряду причин. Для себя правила, конечно же есть. Есть и внештатная этика — не держать сотрудника на встрече, если от него ничего не нужно. Кажется, это стандартная практика, ибо пользы сотрудник принесёт больше, если будет работать, а не скучать на встрече.
Спасибо за развёрнутый отзыв, добавил в свою копилку.
Грубо: продукт занимается генерацией идей, проджект — их исполнением.
В общем то да, продукт-менеджер должен уметь очень многое, чуть ли не всё сразу, но в его роль не входит руководить всем. Ровно как и главный инженер отвечает за модель в целом, за её потребительские свойства и качества, но на деле производством руководят менеджеры проектов, так что я склонен считать, что за развитие продукта отвечает ПМ, а продукт-менеджер лишь помогает развиваться продукту в нужном русле, без углубления и принятия на себя функций управления конкретными этапами производства.
Отсюда и моё поддержание столь общей схемы: «Всё обо всём, но в общем».
Простите за масло масляное, с утра тяжело формировать мысли. И спасибо за хорошую наводку на литературу, обязательно прочитаю.
Скажите, пожалуйста, Вы как Вы описываете эту роль студентам? Как человека, который в итоге отвечает за продукт и его жизнь, то есть глава всех глав?
Для меня категория бизнес — это всё, что не относится к разработке продукта и его поддержанию с технической точки зрения, а именно продажи, маркетинг, финансовое обеспечение организации, и да, правовая поддержка тут. Это так называемые подразделения обеспечения, они ничего не производят, а занимаются бизнесом, если угодно.
Ниже привели несколько интересных систем учёта, возможно, они будут Вам полезны. Я пока не вижу смысла уходить от бумаги, ручки/карандаша.
Я веду разные списки: свой личный на бумажном листе, и дашборды в таск-трекере, которые формируются автоматически. Без последних, естественно, не прожить, ибо актуализировать ситуацию и следить за ней нужно постоянно. Но дашборды не отражают личных задач. Заводить на каждую таск я пробовал, но это дублирование личных записей. Кажется, что просто лишняя работа.
Флипборды и обычные доски — отличная идея. Я пока не задумывался над их использованием в личных целях, применял только тогда, когда над задачей работает кто-то кроме меня. Поэкспериментирую, возможно, добавится наглядности в моей деятельности.
А без встреч никак. Я, к счастью, не использую Agile и прочие разновидности, но встречаться приходится по ряду причин. Для себя правила, конечно же есть. Есть и внештатная этика — не держать сотрудника на встрече, если от него ничего не нужно. Кажется, это стандартная практика, ибо пользы сотрудник принесёт больше, если будет работать, а не скучать на встрече.
Спасибо за развёрнутый отзыв, добавил в свою копилку.