Как стать автором
Обновить

Комментарии 14

А что делать с ничтожными РП? Такими, которые не считают нужным изучить продукт, озаботиться планированием задач, попробовать вникнуть в суть того, кто чем занимается, но имеющий связи в госкомпаниях чтобы договориться о презентации продукта (и только по этой причине находящийся на месте)?
Смотря какая лично у вас цель)
Но тут видно ведь, что у него другая роль. Вовсе не рп. Продавец, владелец продукта, кто угодно, но не рп. Просто нанять на роль рп ещё одного человека. В явном виде или в виде «помощника». Можно даже взять человека «навырост»

Часть проблем от того что руководители забывают что их миссия помогать в выполнении проекта, а не мешать. В случае же бюрократизации организации и конфликтов интересов между отделами и менеджментом, крайними будут подчинённые на проекте. Так как координально ситуацию исправить не может, а требовать качественное выполнение работы от других отделов просто шаров может не хватить) И тогда остаются перестановки кресел на Титанике...

Менеджеры проектов, как правило, стремятся обеспечить предсказуемость сроков путём стандартизации и соблюдения цикличности процессов.
Какая то уж очень теоретизированная статья. PM должен тупо правильно разбить задачу на части. Совсем хорошо познакомится со всеми заинтересованными сторонами и узнать, что они думают о проекте. Связать части вместе. Получить для каждой части исполнителей/команды. Собрать с них сроки и проверить ресурсы в полном объеме. Обеспечить исполнителей работой по графику. И контролировать результат. Все. Иногда затыкать дыры из-за обыденного головотяпства и необязательности.
В данной статье описаны не так «типы личности» ПМов, сколько классификация их по злоупотреблению теми или иными инструментами своей работы. Любой опытный ПМ бывал во многих из этих «личностей» на какую-то долю (не верю в существование абсолютных), в зависимости от ситуации в проекте. Ведь и вправду бывают команды в которых недостаточно коммуникаций, и бывают такие, где из-за несчасности команда просто не выходит на свой показатель velocity.
Так что в целом, это как в тесте «кто ты из игры престолов» или даже «Какая ты любовница» из космо… полезно для самоанализа.
А если вы встретились реально с одним из типов описанных в тексте, абсолютно зацикленным на одном из инструментов, решение проблемы — показать что бывают другие рабочие инструменты, если не осознал — уволить.
НЛО прилетело и опубликовало эту надпись здесь
Разделение понятий Продакт менеджер и Проджект менеджер, ИМХО наносит больший вред чем пользу в большинстве случаев. В больших проектах — да, это может быть обоснованно, из-за огромного количества задач, большой команды и т.д. В маленьких проектах, если Проджект Менеджер и Продакт Менеджер — это одно лицо, то это существенно ускоряет процесс принятия решений, и как следствие, ускоряет разрешение любых проблем.
Однако, такое лицо, единолично принимающее решение, должно быть профи в своем деле, и полагаться на опыт, знания и рассматривать ситуацию с нескольких сторон. А не действовать интуитивно.
НЛО прилетело и опубликовало эту надпись здесь
Разделение ролей зачастую имеет экономический подтекст — разделение труда повышает его эффективность или минимизирует его неэффективность. Увеличение количества участников взаимодействия конечно вносит штраф в коммуникации, но зачастую это лучше, чем негативные экономические и организационные спецэффекты.
Задача проджетка — сделать продукт правильно. Задача продакта — сделать правильный продукт. Это разные задачи, которые решаются разными способами. И это конфликт интересов, из-за которого хорошей практикой является разведение этих ролей по разным людям.
Кроме того, роль продакта нужна в случаях, когда заказчик не персонализирован, когда некому подписаться под требованиями, например, когда какой-то продукт выпускается на рынок. а не по контракту для какой-то конкретной организации.
НЛО прилетело и опубликовало эту надпись здесь
epishman uzverkms Господа, нет смысла спорить. Внесем немного Геймификации в обсуждение, и представим что продукт — персонаж MMORPG.
Так вот, «Важнее следить за процессом» — дает свои бонусные очки к одним характеристикам продукта, но отнимает другие. Также как, например возрастающая «Сила» — уменьшает «Ловкость». Так продукт получается более стабильный (все тщательно оттестировано и выполнено «по стандарту», использованы правильные технологии и т.д. Но при этом имеет более высокую себестоимость разработки: ЗП Проджект менеджера, простои по времени из-за длительных согласований между Продактом и Проджектом, и т.д.
А вывод напрашивается только один: Каждый персонаж ММОRPG имеет свои слабые и сильные стороны, и предназначен для решения определенных задач. Универсального рецепта нет, также как и универсального набора членов команды, и универсального набора знаний у разработчиков.
Вы толлите что ли? Колониально-венчурное. Про масонов тут ещё напишите.
Производство автомобиля — продуктовая, а не проектная деятельность. А вот проектирование автомобиля — вполне себе проект иди даже программа проектов в рамках жизненного цикла продукта.
"зачем «делать продукт правильно», почему процесс так важен, клиентам ведь нужен результат?" — если мы заглянем в термины и определения, то в большинстве случаев под проектом понимается временное предприятие, предназначенное для создания уникального продукта или услуги в заданный бюджет, время, набор работ, с необходимым уровнем качества. Под «уровнем качества» некоторые корпоративные методологии вполне справедливо понимают «клиентам нужен результат».
Делать продукт правильно — стараться удерживать тройственное ограничение проекта (деньги, время, содержание). Иначе проект расползётся по одному или нескольким параметрам и или погибнет, или будет выполнен, только радости от него уже не будет никакой.
На основе этих статей могла бы выйти прекрасная настолка на механике какого-нибудь «Манчкина». :)
Я боюсь представить какие там будут непотребства.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории