5 незаменимых качеств топ-менеджеров проектов

Послушайте аудиоверсию этой статьи.

Если вы топ-менеджер, вы выделяетесь, и если вас признают топ-менеджером, вы будете пользоваться большим спросом. Заинтересованные стороны будут больше доверять вам, захотят работать с вами и будут больше прислушиваться к вашим советам. Что бы вы ни помогали создавать, лучшие продакт-менеджеры всегда востребованы в организациях по всему миру. Это список некоторых ключевых качеств топ-менеджеров проектов. Надеюсь, они помогут вам стать таковым или проверить, есть ли у вас уже эти привычки.

1. Укрепление доверия в вашей команде

Доверие — важный аспект каждой команды. Об этом часто говорят и пишут, но редко можно увидеть в действии, когда дело доходит до запуска проекта. Важность доверия в процессе управления проектами была признана даже различными организациями по управлению проектами.

Международная ассоциация управления проектами только что добавила разделы о доверии к своей сертификации ICB4, которая является глобальным стандартом для индивидуальных компетенций в управлении проектами, программами и портфелями.

Точно так же три столпа эмпиризма Scrum долгое время основывались на идее, что доверие является одним из трех наиболее важных факторов, поддерживающих эмпирический контроль над проектом. Та же тенденция построения доверия присутствует в LEAN и других традиционных методологиях управления проектами. Если это была такая актуальная тема так долго, то какие основные блокираторы мешают PM установить настоящее доверие в своих командах?

Один из наиболее частых ответов на этот вопрос — «обвинять культуру». Ключом к достижению культуры доверия является отход от этой культуры и превращение каждой ошибки в возможность обучения.

Чтобы воплотить это в жизнь, продакт-менеджеры должны создать в своих командах правильную среду прозрачности и комфорта, поскольку большинство людей работают намного лучше в среде, где члены команды могут выражать свои мысли и совершать ошибки.

Ведущий PM учит свою команду этим принципам на собственном примере, живя рядом с ними, побуждая делиться своими ошибками и превращая их в примеры для обучения. Лучшие продакт-менеджеры понимают, что проявление смирения и уязвимости — это признак силы. Особенно, когда дело доходит до признания собственных ошибок, часто бывает так, что люди склонны защищаться или перекладывать вину. Объяснение того, что вы совершили ошибку и почему , может заставить вас чувствовать себя уязвимым, но если вы открыто признаете и проанализируете эти ошибки, эта привычка поможет другим избежать их в будущем и поможет каждому укрепить доверие и открыться о своих оплошностях. . Например, если вы слишком много обещаете ключевой заинтересованной стороне завершить этап раньше, чем это возможно, из-за отсутствия у вас технических знаний по этому вопросу, будьте готовы признать свою ошибку перед командой и дать им понять, что вы недооценили вещи, а не обвинять их. их за то, что они не предоставили технологию так быстро, как вы хотели. Это может вдохновить других открыться и укрепить связи с вами и их товарищами по команде.

Поймите членов вашей команды: их способности, страхи, разочарования, что им нравится или не нравится и как они взаимодействуют с другими людьми. Когда члены команды чувствуют, что их ценят, им легче приносить пользу. Найдите способы мотивировать свою команду поставленной задачей вместо того, чтобы насильно подталкивать ее к достижению ваших целей. Для этого четко обозначьте, как выглядит успех для проекта и проектной команды, роли и обязанности, но затем позвольте им быть экспертами в своих областях. Ожидайте, что члены вашей команды скажут вам, что нужно сделать. Прислушивайтесь к ним, децентрализуйте принятие решений, чтобы расширить возможности своей команды, но будьте готовы к принятию трудных решений, когда это необходимо.

В конце концов, ваша команда готова вам помочь. Слишком многие продакт-менеджеры совершают ошибки, сразу бросаясь к написанию задач и беря на себя слишком большую часть этой ответственности. Иногда это происходит из-за отсутствия доверия и понимания внутри этих команд. Когда ваша команда пользуется доверием, убедитесь, что они участвуют в определении объема работы, написании пользовательских историй и вообще дают вам советы по вопросам, которые они считают важными.

Лучшие продакт-менеджеры осознают, что их команда — их лучший актив, и будут использовать любую возможность, чтобы построить с ними прочные отношения. Будьте переговорщиком и посредником, но прежде всего будьте едины с командой. Им нужно чувствовать, что вы работаете с ними, а не для кого-то выше. Это предшествует некоторым более техническим советам в этой статье, так как без этого доверия ваш проект, скорее всего, столкнется с рядом проблем.

Ключевой вывод: «Это нормально — показать, что все делают ошибки. Делитесь своими ошибками, когда вы их совершаете, покажите своей команде, что вы на их стороне, и сделайте доверие внутри своей команды приоритетом».

2. Привлекайте заинтересованные стороны, чтобы дать им то, что им действительно нужно

Как продакт-менеджер, вы, вероятно, хорошо осведомлены о том, что многие программные проекты в конечном итоге дают нечто иное, чем то, что хотели или в чем нуждались заинтересованные стороны. Эта проблема связана со многими различными факторами, и она породила целый набор новых методологий, пытающихся решить эту проблему.

Однако даже в эпоху Agile-разработки мы все еще иногда попадаем в ловушку создания неправильных вещей. Анализ заинтересованных сторон важен, но часто начинается с неправильного вопроса. Не задаваясь вопросом «Зачем мы это делаем?», многие проекты инициируются и неправильно определяются, попадая в ловушку построения решения, которое никогда не отвечало реальным потребностям бизнеса.

В сочетании с вопросом «почему» топ-менеджеры должны задать вопрос «кому?» Какие заинтересованные стороны мы поддерживаем, чтобы предоставить решение, чтобы объяснить их «почему?»

Вот где топ-менеджер признает важное различие. Решение может быть определено как результат или результат, но топ-менеджер понимает, что любое решение само по себе не обязательно будет соответствовать первоначальным бизнес-потребностям. Например, если заинтересованные лица считают, что их бизнес-потребность заключается во внедрении ERP-системы, тогда менеджер по проектам должен помочь им раскрыть реальную потребность бизнеса, стоящую за использованием такого решения, как ERP. ERP сама по себе является решением, а не потребностью бизнеса.

Признание истинной потребности бизнеса требует глубокого понимания контекста и заинтересованных сторон, их отношения, уровня власти или влияния, уровня заинтересованности, их влияния на проект, влияния проекта на них, их проблем и, конечно же, того, что они примут в качестве успех проекта.

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

Менеджеры по проектам всегда должны помнить, что реальные преимущества реализации проекта на протяжении всего процесса должны быть согласованы с реальными потребностями, целями и задачами бизнеса.

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

Топ-менеджеры также осознают свою роль в руководстве проектом и, таким образом, не ожидают, что заинтересованные стороны сообщат обо всех требованиях в самом начале проекта. Они понимают, что некоторые заинтересованные стороны не всегда знают, как сформулировать свои потребности, и их роль заключается в том, чтобы помочь заинтересованным сторонам сформулировать свои потребности, от выявления требований до реализации проекта. Также важно помнить, что в процессе выявления требований мы должны выяснить не только требования от заинтересованных сторон, но и их опасения.

Например, в менее зрелых организациях в начале новых проектов часто случается интересный парадокс. На этапе инициализации проекта команда разработчиков ожидает, что заинтересованные стороны четко определят все требования и потребности в решении, для которого они будут разрабатываться. В то же время заинтересованные стороны ожидают, что группа доставки предоставит точную оценку как времени, так и стоимости.

Однако в самом начале определения масштабов проекта слишком много неопределенности, чтобы точно определить эти оценки, и при этом существует опасность создания нереалистичных оценок. Иногда заинтересованные стороны включают как можно больше требований, чтобы учесть неопределенность менее осязаемого решения. Между тем, команда доставки дает очень приблизительную оценку неизвестному.

Результатом этого, скорее всего, станет решение, в котором заинтересованные стороны будут использовать только 20% своих полных требований. Остальное будет разрабатываться без четкой цели, в результате чего проект выйдет за рамки бюджета и графика.

К счастью, лучшие продакт-менеджеры точно знают, как привлечь заинтересованные стороны и провести их через каждый этап VUCA (волатильность, неопределенность, сложность и двусмысленность) своего проекта. Руководители проектов могут разбивать проект на более ощутимые этапы и привлекать заинтересованные стороны, активно создавая и анализируя полученные знания.

Ключевой вывод здесь таков: «Решения создаются для удовлетворения потребностей бизнеса, менеджеры проектов должны следить за тем, чтобы эта цель не была упущена при создании проекта. Убедитесь, что ваши заинтересованные стороны хотят создавать правильные вещи, взаимодействуя с ними для решения их основных потребностей и проблем».

3. Сделать управление рисками проекта органичным упражнением

Большинство проектов имеют набор общих рисков, которые возникают в начале инициализации проекта.

Почти каждый проект начинается с этих общих рисков, включая сопротивление пользователей изменениям, нехватку ресурсов и незрелость технологий, и это лишь некоторые из них. Ведущие продакт-менеджеры привлекают свои команды для выявления не только общих рисков, но и наиболее насущных и уникальных рисков, так что идентификация рисков является рефлексом на протяжении всего жизненного цикла проекта, а не рутинной задачей в начале проекта.

При распознавании рисков топ-менеджеры также обращают внимание на свое сотрудничество с ключевыми заинтересованными сторонами, которые часто прямо или косвенно определяют риск в своих требованиях и проблемах. Хорошие продакт-менеджеры понимают, что этот процесс происходит от этапа выявления требований до всего жизненного цикла проекта, и рассматривают это как преимущество для определения рисков на протяжении всего процесса.

Экспертные продакт-менеджеры также доверяют своим командам и признают свои экспертные знания источником снижения рисков. Чтобы дать членам команды возможность активно выявлять риски, PM дает возможность своей команде взять на себя ответственность за проект и активно участвовать в выявлении рисков и управлении ими.

С практической точки зрения, третий вопрос во время ежедневного стендапа: «Что вам мешает?» отражает более осмотрительные ответы, поскольку команда имеет возможность внести свой вклад в успех проекта. Конечно, некоторые блокираторы могут быть временными или удаляться сразу после схватки, однако некоторые из них являются потенциальными кандидатами, что может привести к значительным рискам. Членов команды необходимо поощрять к выявлению этих потенциальных рисков, и их включение следует приветствовать, а не смотреть на них свысока даже в конце жизненного цикла проекта.

Признание риска также не так просто, как определение риска и дальнейшие действия. Признание риска следует регулярно оценивать с точки зрения вероятности, серьезности и показателя, о котором иногда забывают: близости. Последняя метрика позволяет команде определить правильные действия, будь то «ничего не делать до следующего шага по выявлению риска» или что-то более ощутимое, если риск будет более непосредственным. Здесь важно признать, что топ-менеджеры понимают, как сделать риски действенными, поскольку любой риск бесполезен, если им не управлять. Кроме того, список действий должен быть не только реактивным, но и упреждающим по своему характеру, в конечном счете, отражая бэклог продукта с поправкой на риск.

Короче говоря, топ-менеджер признает, что независимо от опыта или полномочий он не является и не должен быть единственным источником для выявления и управления рисками. Заинтересованные стороны, их команда и другие важные участники проекта должны участвовать в распознавании рисков и управлении ими не только на ранних стадиях, но и регулярно на протяжении всего жизненного цикла проекта. Это важно, потому что очень мало используются риски, которые были выявлены в начале проекта, но с тех пор не управлялись.

Ключевой вывод здесь таков: «Для успешного управления проектом вся команда должна нести ответственность за выявление рисков. Выявление рисков должно быть непрерывным процессом, который происходит на протяжении всего жизненного цикла проекта».

4. Понимание окружающей среды

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

В то время как любой PM понимает, что проекты, за которые он берется, окажут влияние на организацию, ведущие PM признают, что организация также оказывает влияние на их проекты.

Вместо ошибочного менталитета «все под одну гребенку» лучшие продакт-менеджеры адаптируют свой подход, понимая свое окружение. При этом они могут лучше распознавать самые насущные потребности бизнеса, то, как организации будут адаптировать или принимать решение, внедрение и какие изменения будут внесены в решение для достижения правильного соответствия поставленным целям.

При разработке эффективного подхода к управлению проектами ведущие менеджеры по проектам должны обладать глубоким пониманием различных методологий, не только различных подходов к управлению проектами, но и методологий бизнес-анализа, структур управления изменениями, структур архитектуры предприятия и других полезных методов анализа. Это дает PM возможность найти наиболее подходящее решение для компании, чтобы реализовать проект, за который они берутся.

Например, если вы начинаете проект в чрезвычайно жесткой иерархической организации, где существует множество различных уровней утверждения, лучшим подходом может быть смешанный или гибридный подход к управлению проектами. Вы можете выполнить структурированный этап выявления требований, предварительно утвердив требования, а затем разделив проект на этапы с формальными этапами. Параллельно с этим PM может настроить итеративное выполнение, подобное Agile, в командах разработчиков, чтобы использовать лучшие практики итеративной разработки, несмотря на то, что он работает с более традиционным проектом.

Таким образом, топ-менеджеры будут уважать культуру компании, уважительно предлагая новые подходы и обучая организации улучшать свои методы управления проектами. Они признают, что многие организации находятся на разной стадии зрелости и готовности к изменениям, и видят в этом возможность, а не угрозу, положительно повлиять на способность каждой компании внедрять передовые методы управления проектами.

Ключевой вывод здесь таков: «Менеджеры проектов не должны слепо продвигать свою собственную повестку дня, а должны адаптироваться к методам работы организаций и медленно вносить изменения, если это необходимо».

5. Применение принципов LEAN

Лучшие продакт-менеджеры знают, что путь важен так же, как и цель. Иногда путешествие по проекту становится особенно громоздким из-за процесса, который определяет, как все должно быть сделано. Это может проявляться в излишне громоздких шаблонах, бессмысленных встречах или отвлекающих периферийных устройствах, которые мешают путешествию, но ваша ответственность как менеджера по проектированию — сделать так, чтобы эти препятствия как можно меньше влияли на вашу команду.

Руководители высшего звена должны определить более эффективные и действенные процессы для команды, опираясь на принципы гибкого управления проектами, четко определенные в методологии LEAN.

Популярным заблуждением является то, что LEAN подходит только для производства, что просто не соответствует действительности. Методы управления проектами LEAN могут улучшить каждый проект и каждый процесс. Это не просто программа снижения затрат, а способ мышления и действия для вашей команды.

Преимущества применения принципов LEAN хорошо резюмирует цитата генерального директора Toyota Кацуаки Ватанабэ: «Наша стратегия — блестящее управление процессами. Мы получаем блестящие результаты от обычных людей, управляющих блестящими процессами. Мы наблюдаем, что наши конкуренты часто получают средние (или даже худшие) результаты от блестящих людей, управляющих неправильными процессами».

Топ-менеджер, стремящийся устранить ненужный проектный шум и работу, естественным образом приведет процесс к принципам бережливого производства. Топ-менеджер должен тесно сотрудничать с владельцем продукта, его командой и соответствующими заинтересованными сторонами, чтобы помочь им оптимизировать и конкретизировать свои потребности и ожидаемую ценность в ответ на эти потребности.

Также полезно выйти за рамки LEAN, чтобы позаимствовать лучшие практики управления проектами для вашего проекта. Например, только методология PRINCE2 имеет обязательную задачу по учету уроков, извлеченных на начальной стадии проекта . Это фиксирует все уроки, извлеченные из предыдущих проектов, вместо того, чтобы писать документ в конце проекта, который редко будет использоваться другими при запуске нового. Важно не бояться изменить процесс, чтобы исключить ненужные шаги и сосредоточиться на тех, которые приносят реальную пользу.

Это хорошая возможность помочь и изменить процессы или помочь команде выбрать правильные с самого начала. Эти четкие показатели эффективности должны быть прозрачными для всех участников, чтобы определить четкий ориентир успеха проекта.

Ключевой вывод здесь таков: «Поиск правильных решений так же важен, как и правильный оптимизированный процесс предоставления этих решений».