Comments 19
Поправьте грамматическую ошибку — адаптировать, а не адоптировать.
У меня вопрос по ошибке номер 3: а как этого избегать, если кроме тебя действительно некому, но ты не вправе добрать себе человека и одновременно не можешь себе позволить спустить вопрос на тормозах?
Больше речь идет о том, что очень желательно посвящать команду в цели бизнеса. По возможности, подробно рассказать о приоритетах (почему они именно такие), о главном фокусе спринта (на случай «обрезания» функционала, если команда не успевает выполнить полный объем в спринте), особенностях нового функционала (какие именно бизнес задачи он должен решать).
У себя на проекте практиковали следующее: на груминге (или на планировании) Product Owner (или аналитик) начинал собрание как раз с пояснения описанных выше нюансов и уже после переходили к обсуждению конкретных задач. Таким образом, команду вначале погружали в бизнес контекст, а уже после было намного проще брейнштормить по требованиям, хорошо понимая, какие улучшения/изменения можно предложить для достижения цели (полезный для пользователя функционал).
У себя на проекте практиковали следующее: на груминге (или на планировании) Product Owner (или аналитик) начинал собрание как раз с пояснения описанных выше нюансов и уже после переходили к обсуждению конкретных задач. Таким образом, команду вначале погружали в бизнес контекст, а уже после было намного проще брейнштормить по требованиям, хорошо понимая, какие улучшения/изменения можно предложить для достижения цели (полезный для пользователя функционал).
Да, я пункт перепутала, я про второй. С третьим прозрачно.
В описанной вами ситуации избежать выполнения дополнительных обязанностей не получится.
Я, скорее, имела в виду ситуацию с неким недоверием со стороны PM к команде и желанием все контролировать (позиция «хочешь чтобы все было сделано правильно — сделай сам»). Когда, имея все необходимые ресурсы, менеджер, в меру своих возможностей, берется за чужие задачи и считает такой подход правильным. То есть ему проще выполнить задачи самому, чем научить ребят из команды новым техникам.
Приходилось бывать на вашем месте и закрывать собой некоторые позиции, пока новые люди не были набраны (в частности QA и BA). Старалась для себя расставить приоритеты так, что основным все таки оставались обязанности PM (общий фокус по проекту и синхронизация с другими командами зависимых проектов), а уже вторичными (overtime) дополнительные задачи.
Но такие периоды все-таки должны быть временными, так как постоянно нести подобную нагрузку будет очень и очень не просто (особенно на крупных проектах). Возможно, стоит попробовать поговорить с руководством о необходимости пополнения команды или привлечения на part time нужных специалистов из соседних команд. Постараться донести мысль о том, что ваша задача — максимально помогать команде двигаться в правильном направлении и решать множество сопутствующих внешних/ внутренних проблем. Могу предложить проверенный мною способ: выписывать все свои выполненные задачи с результатом и предъявить список руководству как подтверждение объема вашей работы в роли PM. Ведь большая часть нашей работы вовсе не оформлена в виде задач и иногда не видна. А так можно обосновать собственную загрузку.
Я, скорее, имела в виду ситуацию с неким недоверием со стороны PM к команде и желанием все контролировать (позиция «хочешь чтобы все было сделано правильно — сделай сам»). Когда, имея все необходимые ресурсы, менеджер, в меру своих возможностей, берется за чужие задачи и считает такой подход правильным. То есть ему проще выполнить задачи самому, чем научить ребят из команды новым техникам.
Приходилось бывать на вашем месте и закрывать собой некоторые позиции, пока новые люди не были набраны (в частности QA и BA). Старалась для себя расставить приоритеты так, что основным все таки оставались обязанности PM (общий фокус по проекту и синхронизация с другими командами зависимых проектов), а уже вторичными (overtime) дополнительные задачи.
Но такие периоды все-таки должны быть временными, так как постоянно нести подобную нагрузку будет очень и очень не просто (особенно на крупных проектах). Возможно, стоит попробовать поговорить с руководством о необходимости пополнения команды или привлечения на part time нужных специалистов из соседних команд. Постараться донести мысль о том, что ваша задача — максимально помогать команде двигаться в правильном направлении и решать множество сопутствующих внешних/ внутренних проблем. Могу предложить проверенный мною способ: выписывать все свои выполненные задачи с результатом и предъявить список руководству как подтверждение объема вашей работы в роли PM. Ведь большая часть нашей работы вовсе не оформлена в виде задач и иногда не видна. А так можно обосновать собственную загрузку.
На мой взгляд, первая ошибка — весьма спорная. Предоставить всю необходимую по задаче информацию можно только для простых задач, когда область постановки задачи совпадает с областью её решения. Но чаще ситуация складывается иным образом — когда даже результаты решения задачи не могут быть определены, не говоря уже о требуемых ресурсах. В таких случаях разбивают процесс решения задачи на этапы. Первый этап — определение того, что собственно является результатом решения задачи, т.е. формулируются критерии того, что задача решена, и эти критерии могут быть проверены внешним наблюдателем, например, сотрудником отдела тестирования. Следующий этап — это формулирование алгоритма решения задачи. Затем — перечень необходимых ресурсов (например, списка литературы, которая должна быть проработана). Наконец — решение самой задачи.
Спасибо за совет номер 3. Частенько этим грешу (хотя сам не занимаю роль PM)
Добавлю указанную книгу в список для чтения.
Добавлю указанную книгу в список для чтения.
Боюсь что беда сегодня именно в том, что в сфере плодятся «Эффективные менеджеры»
Работаю РМ в собственной компании уже на протяжении 5-ти лет и беда всегда одна, разделение желаний собственника и возможностей технической команды. Не проблема собрать высококвалифицированный штат и начать ваять проект, проблема всегда в обещаниях и только в них. Нельзя обещать ничего — можно брать в работу и ожидать результат, но есть множество переменных от которых зависит успех любого проекта.
Вот некоторые из них:
— Статичность желаний собственника
— Финансирование
— Команда
— Сроки
Грамотный РМ может собрать все части проекта, сложить из этого рабочий алгоритм и запустить проект.
Новичку требуется усвоить всего одно правило, никогда ничего не обещать без проработки!
И будет Вам счастье) Вообще есть множество общемировых практик, но система адаптивного управления должна быть своя!
Работаю РМ в собственной компании уже на протяжении 5-ти лет и беда всегда одна, разделение желаний собственника и возможностей технической команды. Не проблема собрать высококвалифицированный штат и начать ваять проект, проблема всегда в обещаниях и только в них. Нельзя обещать ничего — можно брать в работу и ожидать результат, но есть множество переменных от которых зависит успех любого проекта.
Вот некоторые из них:
— Статичность желаний собственника
— Финансирование
— Команда
— Сроки
Грамотный РМ может собрать все части проекта, сложить из этого рабочий алгоритм и запустить проект.
Новичку требуется усвоить всего одно правило, никогда ничего не обещать без проработки!
И будет Вам счастье) Вообще есть множество общемировых практик, но система адаптивного управления должна быть своя!
Вы абсолютно правы. Все что вы описали — это более высокоуровневые задачи, которые на практике должны отразиться в более конкретных действиях менеджера. И тут начинаются сложности: а как же правильно поступать на каждом конкретном этапе разработки с каждой составляющей (которые вы перечислили)? Практик действительно много, но они помогают как раз на этом самом высоком уровне, но не говорят, как поступить в той или инной ситуации. И адаптация любой методологии под свои нужды требует живого опыта за плечами, а новичок таким похвастаться не может.
Про «Эффективных менеджеров». Приходилось встречать тех, кто имея опыт работы PM никогда не работал простым членом команды («по ту сторону») и в попытках применить общепринятые практики умудрялся адаптировать их в совершенно нерабочие конструкции. Отсюда потом нарекания на менеджеров о бюрократии, странностях, отчетах и прочем. Мне проблема видится в непонимании менеджерами тех самых методологий и нежелании получать действительно полезный опыт путем признания своих ошибок.
Про «Эффективных менеджеров». Приходилось встречать тех, кто имея опыт работы PM никогда не работал простым членом команды («по ту сторону») и в попытках применить общепринятые практики умудрялся адаптировать их в совершенно нерабочие конструкции. Отсюда потом нарекания на менеджеров о бюрократии, странностях, отчетах и прочем. Мне проблема видится в непонимании менеджерами тех самых методологий и нежелании получать действительно полезный опыт путем признания своих ошибок.
Очень спорные ошибки, по моему мнению. Особенно утверждение, что пм должен — вместе с командой успешно реализовать проект. У кого то есть инструкция, что бы наверняка?!
Из самых важных проблем юных ПМ по моему мнению:
— Недостаточная согласованность (не убеждаются, что стороны имеют одинаковое понимание в аспектах, вопросах, процессах. Как на уровне исполнитель-заказчик, так и на уровне внутри компании. Типичный ответ джун пма при проблемах — «я думал он все понял» или «это же было очевидно»)
— Недостаточное документирование (мало пишут и много говорят. как следствие, детали размываются либо теряются. постановка задач личная, на пальцах, либо по скайпу в голос. мало пишут в таски, трекер, почту.)
— Не делегируют (пытаются все делать самостоятельно забирая на себя большие полномочия и возможности. как следствие, перегружены и считают, что другие с обязанностями справятся хуже либо не справятся вообще)
Это три основных которые ведут к самым популярным ошибкам и проблемам.
И последняя на закуску — пытаются подружится с клиентом. Это поведение жертвы. Как следствие, не могут клиенту отказать либо оспорить. Потом клиенты катаются на шее и не относятся к исполнителю как к профессионалу.
Из самых важных проблем юных ПМ по моему мнению:
— Недостаточная согласованность (не убеждаются, что стороны имеют одинаковое понимание в аспектах, вопросах, процессах. Как на уровне исполнитель-заказчик, так и на уровне внутри компании. Типичный ответ джун пма при проблемах — «я думал он все понял» или «это же было очевидно»)
— Недостаточное документирование (мало пишут и много говорят. как следствие, детали размываются либо теряются. постановка задач личная, на пальцах, либо по скайпу в голос. мало пишут в таски, трекер, почту.)
— Не делегируют (пытаются все делать самостоятельно забирая на себя большие полномочия и возможности. как следствие, перегружены и считают, что другие с обязанностями справятся хуже либо не справятся вообще)
Это три основных которые ведут к самым популярным ошибкам и проблемам.
И последняя на закуску — пытаются подружится с клиентом. Это поведение жертвы. Как следствие, не могут клиенту отказать либо оспорить. Потом клиенты катаются на шее и не относятся к исполнителю как к профессионалу.
Sign up to leave a comment.
6 ошибок начинающего PM