Comments 6
Очень много внимания на "право на ошибку".
Что для вас это значит? "Ну завалила проект, ну ничего, будут и другие, есть же право на ошибку". Если это аутсорс - возможно, вы выжмите последние деньги из клиента, а его мечта жизни провалится из-за вашей ошибки, но нестрашно, правда, вы же Junior PM? Будут же другие клиенты. Если продукт, то ещё сложнее.
В нормальных компаниях оно не так работает. Не должно быть Junior PM, а должен быть Associate PM.
А если вам выпало вести свой маленький проект, то готовьте себя к мысли, что у вас нет права на ошибку, а всё, что вы не знаете вы должны компенсировать вопросами старшему PM, старшему разработчику, да кому угодно лишь бы разобраться в ситуации и сделать максимально правильно. И никакой ментор за вами бегать не будет.
Права на ошибку у вас нет.
>>Права на ошибку у вас нет.
К неправильно поставленному вопросу дан не корректный ответ. Постулировать, что права на ошибку нет - прямой путь к каком-нибудь жёсткому неврозу.
Мы же говорим о проекте - проект всегда связан с неопределённостью и созданием чего-то уникального. Поэтому трудности неизбежны. Задача PM - организовать работу с рисками, запланировать резервы и т.д. так, чтобы минимизировать влияние отрицательных неопределённостей на проект и увеличить влияние положительных неопределённостей. Фантазировать на тему того, что вот сейчас мы наймём действительно профессионального PM и это обеспечит нам отсутствие ошибок - не надо.
Вы всё правильно написали. Ошибаться могут все, нужно минимизировать эфект, исправлять ситуацию и т.п.
Я больше про то, что "лицензии на убийство проекта", потому что вы Junior PM - нет.
Очень возможно вы завалите какой-то проект, и вам действительно нужно жить дальше, но это не значит, что это нормально и легализовывать это не нужно.
Более того, бывает так, что чем выше ваша должность тем меньше вы можете принимать неправильных решений. У нас, например, VP of Product несколько раз в год менялся пока не нашли того, кто пустил компанию в правильном направлении. Та же история и про Director of Engineering. Не только Junior PM-ов могут менять, если они не справляются.
И если вы изначально не технический специалист, и не идёте по нормальному пути через Associate PM, то все пункты про "оставание в зоне комфорта" - можно вычеркнуть, и подготовиться к тяжёлому пути.
Важно найти компанию, где руководство должно быть заинтересовано в участии в процессе работы над проектом. Да, ты только начинаешь работать на данной должности, поэтому стоит выбирать компанию, где есть качественное менторство над проектом и есть к кому обратиться в случае проблем, которые могут возникать.
Как говорил поэт: "мечты, мечты, где ваша сладость". По разным причинам много где такого нет. Или есть, но работает не так, как хотелось бы. И если заглянуть в PMBoK, то там последняя глава посвящена работе со стейкхолдерами проекта - их выявлению, вовлечению и контролю вовлеченности. Вас, пи-эмов, много, а начальств - не так много. Поэтому задача PM кроме прочего заключается в том, чтобы найти для проекта ментора, а лучше всего спонсора (где-то это называют куратором) - менеджера старшего уровня, способного напоминать компании о проекте, одобрять и сопровождать существенные изменения, решать проблемы проекта с другими топами и т.д. Ну а дальше PM-у стоит поддерживать интерес спонсора к проекту. Рассчитывать на изначальный мягкий и всеобъемлющий онбординг я бы не стал.
Просто немного цитат для подумать:
Руководитель проекта также ведет работу со спонсором проекта с целью решения внутренних политических и стратегических проблем, которые могут влиять на работу команды, жизнеспособность или качество проекта.
По мере изменения условий руководитель проекта должен постоянно вести работу со спонсором проекта, чтобы добиться согласованности бизнеса и стратегических задач проекта.
Руководители проектов играют ключевую роль в работе со спонсором, чтобы понять стратегические цели и обеспечить согласование задач и результатов проекта с задачами и результатами портфеля, программы и сферами бизнеса. Именно так руководители проектов вносят вклад в интеграцию и реализацию стратегии.
В адаптивном или гибком жизненном цикле представители спонсора и заказчика должны быть постоянно вовлечены в проект для предоставления обратной связи о поставляемых результатах по мере их создания и обеспечения того, что бэклог (план незавершенных работ) отражает их текущие потребности.
и т.д.
Видите какие формулировки? Спонсор - кто-то из топов, у него не будет времени возиться с отдельным проектом/PM если это не какой-то уж совсем важный проект. Тут PM должен сам подсуетиться, а если надо - вовремя поднять "красный флаг".
К вышесказанному добавлю еще, пожалуй, один достаточно очевидный момент:
в управлении проектом для управленца значимыми должны быть не только и не столько сроки и "удовлетворение команды" (которое - совершенно отдельный вопрос, они работают, а не тешат собственное ЧСВ), сколько "выдать требуемый результат", и вот в этом, как обычно, "есть нюансы" - результат для работодателя (Исполнителя, а не Заказчика), тот который ожидается, а не тот, который вам кажется, что нужен
А вот понимания этой частности в Манифесте я как-то не заметил совсем
Набор слов ребенка о том в чем не правы и какими должны быть его родители, давай скорее сама стань мамой и ты поймешь как же твои родители были правы.
Манифест Junior PM