Вы абсолютно правы. Все что вы описали — это более высокоуровневые задачи, которые на практике должны отразиться в более конкретных действиях менеджера. И тут начинаются сложности: а как же правильно поступать на каждом конкретном этапе разработки с каждой составляющей (которые вы перечислили)? Практик действительно много, но они помогают как раз на этом самом высоком уровне, но не говорят, как поступить в той или инной ситуации. И адаптация любой методологии под свои нужды требует живого опыта за плечами, а новичок таким похвастаться не может.
Про «Эффективных менеджеров». Приходилось встречать тех, кто имея опыт работы PM никогда не работал простым членом команды («по ту сторону») и в попытках применить общепринятые практики умудрялся адаптировать их в совершенно нерабочие конструкции. Отсюда потом нарекания на менеджеров о бюрократии, странностях, отчетах и прочем. Мне проблема видится в непонимании менеджерами тех самых методологий и нежелании получать действительно полезный опыт путем признания своих ошибок.
В описанной вами ситуации избежать выполнения дополнительных обязанностей не получится.
Я, скорее, имела в виду ситуацию с неким недоверием со стороны PM к команде и желанием все контролировать (позиция «хочешь чтобы все было сделано правильно — сделай сам»). Когда, имея все необходимые ресурсы, менеджер, в меру своих возможностей, берется за чужие задачи и считает такой подход правильным. То есть ему проще выполнить задачи самому, чем научить ребят из команды новым техникам.
Приходилось бывать на вашем месте и закрывать собой некоторые позиции, пока новые люди не были набраны (в частности QA и BA). Старалась для себя расставить приоритеты так, что основным все таки оставались обязанности PM (общий фокус по проекту и синхронизация с другими командами зависимых проектов), а уже вторичными (overtime) дополнительные задачи.
Но такие периоды все-таки должны быть временными, так как постоянно нести подобную нагрузку будет очень и очень не просто (особенно на крупных проектах). Возможно, стоит попробовать поговорить с руководством о необходимости пополнения команды или привлечения на part time нужных специалистов из соседних команд. Постараться донести мысль о том, что ваша задача — максимально помогать команде двигаться в правильном направлении и решать множество сопутствующих внешних/ внутренних проблем. Могу предложить проверенный мною способ: выписывать все свои выполненные задачи с результатом и предъявить список руководству как подтверждение объема вашей работы в роли PM. Ведь большая часть нашей работы вовсе не оформлена в виде задач и иногда не видна. А так можно обосновать собственную загрузку.
Больше речь идет о том, что очень желательно посвящать команду в цели бизнеса. По возможности, подробно рассказать о приоритетах (почему они именно такие), о главном фокусе спринта (на случай «обрезания» функционала, если команда не успевает выполнить полный объем в спринте), особенностях нового функционала (какие именно бизнес задачи он должен решать).
У себя на проекте практиковали следующее: на груминге (или на планировании) Product Owner (или аналитик) начинал собрание как раз с пояснения описанных выше нюансов и уже после переходили к обсуждению конкретных задач. Таким образом, команду вначале погружали в бизнес контекст, а уже после было намного проще брейнштормить по требованиям, хорошо понимая, какие улучшения/изменения можно предложить для достижения цели (полезный для пользователя функционал).
Про «Эффективных менеджеров». Приходилось встречать тех, кто имея опыт работы PM никогда не работал простым членом команды («по ту сторону») и в попытках применить общепринятые практики умудрялся адаптировать их в совершенно нерабочие конструкции. Отсюда потом нарекания на менеджеров о бюрократии, странностях, отчетах и прочем. Мне проблема видится в непонимании менеджерами тех самых методологий и нежелании получать действительно полезный опыт путем признания своих ошибок.
Я, скорее, имела в виду ситуацию с неким недоверием со стороны PM к команде и желанием все контролировать (позиция «хочешь чтобы все было сделано правильно — сделай сам»). Когда, имея все необходимые ресурсы, менеджер, в меру своих возможностей, берется за чужие задачи и считает такой подход правильным. То есть ему проще выполнить задачи самому, чем научить ребят из команды новым техникам.
Приходилось бывать на вашем месте и закрывать собой некоторые позиции, пока новые люди не были набраны (в частности QA и BA). Старалась для себя расставить приоритеты так, что основным все таки оставались обязанности PM (общий фокус по проекту и синхронизация с другими командами зависимых проектов), а уже вторичными (overtime) дополнительные задачи.
Но такие периоды все-таки должны быть временными, так как постоянно нести подобную нагрузку будет очень и очень не просто (особенно на крупных проектах). Возможно, стоит попробовать поговорить с руководством о необходимости пополнения команды или привлечения на part time нужных специалистов из соседних команд. Постараться донести мысль о том, что ваша задача — максимально помогать команде двигаться в правильном направлении и решать множество сопутствующих внешних/ внутренних проблем. Могу предложить проверенный мною способ: выписывать все свои выполненные задачи с результатом и предъявить список руководству как подтверждение объема вашей работы в роли PM. Ведь большая часть нашей работы вовсе не оформлена в виде задач и иногда не видна. А так можно обосновать собственную загрузку.
У себя на проекте практиковали следующее: на груминге (или на планировании) Product Owner (или аналитик) начинал собрание как раз с пояснения описанных выше нюансов и уже после переходили к обсуждению конкретных задач. Таким образом, команду вначале погружали в бизнес контекст, а уже после было намного проще брейнштормить по требованиям, хорошо понимая, какие улучшения/изменения можно предложить для достижения цели (полезный для пользователя функционал).