Курс управления проектом. Курс управления. Задача выходит за ваши привычные обязанности, ограничена по времени, и вы создаёте чтото новое скорее, всего это проект
 Скачать 0.65 Mb.
|
Пример: методыИспользование методологии или фреймворка для запуска проекта - еще один пример использования воспроизводимых элементов. Это может быть уже существующая система, такая как PRINCE2®, P3.express, DSDM® или Scrum, или система, которую вы настроили или создали самостоятельно. Однако, как правило, лучше начать с одного из существующих методов и адаптировать его к своим потребностям, чем создавать свой с нуля. Любой повторяемый элемент является абстрактным и нуждается в настройке, чтобы адаптировать его к реальному миру. Тем не менее, существуют разные степени и абстракции и потребности в адаптации: небольшие, относительно конкретные чек-листы качества находятся на одном конце спектра с наименьшим уровнем абстракции и потребностью в адаптации, в то время как методологии находятся на другом конце, с самой высокой потребностью в адаптации. Вы должны всегда учитывать необходимость адаптации, в противном случае воспроизводимый элемент не будет соответствовать вашим потребностям. Waterfall (водопадный или предиктивный подход) Вы собираете требования заказчика, планируете и стараетесь не отклоняться от плана. Этот подход отлично работает, когда вы уже делали похожие проекты и хорошо понимаете, что делать. К примеру, этот подход отлично сработает, если вы уже построили десять дачных домов и приступаете к постройке одиннадцатого в том же поселке. Если вы делаете что-то принципиально новое, этот подход может не сработать: К примеру, ваша команда занималась разработкой сайтов, но поступил новый заказ на разработку мобильного приложения. Заказчик может не знать, чего он хочет на выходе, а команда может не учесть все подводные камни и приложение не будет отвечать запросам заказчика. В таком случае лучше использовать другой подход. Agile (адаптивный или гибкий подход) Вы понимаете, что в проекте много неопределённости и делаете продукт небольшими отрезками (итерациями). В конце каждой создаёте продукт (инкремент). Например, вы можете сначала отрисовать прототип мобильного приложения, потом сделать базовую версию, потом добавлять новые функции, а когда все будет работать на одной платформе, перенести на другие. Но и у этого подхода есть ограничения. Строить таким образом одинаковые дачные дома тоже можно, но получится дольше и дороже из-за постоянных изменений. Проще использовать первый подход: собрать требования, сделать план и следовать ему. Hybrid (гибридный подход)Данный подход сочетает черты предиктивного и гибкого подходов. Из примеров – PRINCE2 Agile и p3express. Agile Suitability ModelИнструмент, который поможет определить, насколько гибкие подходы подойдут вашему проекту и где будут узкие места в применении подхода. Подробнее о применении в дополнительных материалах. Каждый проект уникален, но есть роли, о которых никогда не надо забывать. Спонсор проекта — тот человек, который заинтересован в проекте и готов выделять на него ресурсы. Например, если Директор по продажам решил внедрить CRM, из него получится отличный спонсор: он хочет CRM и может дать на неё бюджет. Но у него не хватит времени вести этот проект самому. Для этого есть менеджер проекта. Менеджер проекта — тот человек, который драйвит проект каждый день. Он помогает команде и отвечает за результат. Менеджер проекта как дирижер оркестра: он может не уметь играть на тромбоне, зато знает произведение, может организовать репетицию и владеет волшебной палочкой. Менеджер проекта не должен программировать лучше разработчика, но он должен организовать процесс так, чтобы разработчик мог хорошо делать свою работу. Консультант — эксперт в своей области, который не участвует в проекте на 100%, но своей экспертизой помогает найти лучшие решения и избежать ошибок. Даже лучшие менеджеры и исполнители не могут знать всего на свете.Профессионалы не стесняются привлекать на свои проекты консультантов. Тимлид — тот человек, который будет работать непосредственно с командой, если проект большой. Как правило, тимлиды обладают техническими компетенциями, но следите, чтобы тимлид помогал команде сделать работу, а не делал её за других. Поддержка ПМ — тот человек, который возьмет на себя множество мелких функций: напоминать про встречи и вести на них заметки, решать мелкие проблемы команды. Если вы хотите, чтобы ПМ мог концентрироваться на главном, дайте ему Поддержку. Члены команды — прекрасные люди, которые создают продукт. Старайтесь, чтобы члены команды могли друг друга заменять. Старайтесь собирать команду заранее, лучше до запуска проекта. Иначе есть риск, что все нужные люди будут уже заняты на других проектах. Работать с командой всегда непросто, но особенно сложно работать с удалённой командой, когда все сидят в разных местах и нельзя подойти к каждому лично. Для тех, кто хочет научиться профессионально работать с удалённой командой, мы подготовили онлайн-курс «Школа удалёнки». В этом курсе Антон Шаяхов, основатель диджитал-агентства Out.Agency и создатель мобильного приложения Практика, делится своими секретами и приёмами, которые позволяют ему вести бизнес из дома и управлять командой, работающей в разных странах. Основные выводы: Спонсор — человек, который: заинтересован в проекте готов выделять ресурсы (деньги, компетенции, связи) для того, чтобы проект успешно реализовался помогает руководителю проекта в вопросах, которые тот не может решить самостоятельно Ключевые задачи спонсора проекта: 1. Приведение проекта в соответствие с целями организации – убедиться, что проект нужен организации и подправить направление, где требуется. 2. Назначение руководителя проекта (ПМ) – необходимо убедиться, что ПМ понимает свою роль, задачи и полномочия. 3. Утверждение базовых планов – в первую очередь, сроки, стоимость, содержание, качество, риски и выгоды. 4. Поддержка руководителя проекта – быть доступным для встреч и консультаций. 5. Обеспечение проекта ресурсами – финансирование, люди и всё, что ещё может потребоваться. 6. Активное продвижение проекта – активно продвигать проект внутри организации, демонстрируя его значимость и будущие выгоды. 7. Наставничество менеджера проекта – делиться своим опытом. 8. Согласование ключевых изменений, влияющих на результаты проекта. 9. Мониторинг и анализ прогресса на регулярной основе. 10. Празднование успеха проекта – награждение команды и менеджера. Советы менеджерам проектов для лучшего сотрудничества со спонсором: Обсудите ожидания от проекта с самого начала. Убедитесь, что вы четко понимаете цели и особенности проекта. Возьмите на себя ответственность за качество отношений – задайте тон для отношений и тип общения, который вы будете использовать. Узнайте, что знает спонсор – определите, какой информацией он уже владеет, и будьте готовы предоставить недостающую. Согласуйте роль и обязанности спонсора. Например, обсудите следующие вопросы: Как спонсор хочет, чтобы руководитель проекта сообщал о прогрессе? Кто будет сообщать о прогрессе руководству компании? В каких вопросах спонсор хочет участвовать? Какие результаты будут утверждены спонсором? Как спонсор будет участвовать в запрашиваемых изменениях? Какое лучшее время и средство общения? Представьте спонсора команде проекта – дайте спонсору возможность представить на уровне руководства взгляд на проект и его ожидаемые результаты. Регулярно встречайтесь и общайтесь открыто – проводите постоянные дискуссии по важным вопросам и продолжайте строить отношения. Уважайте время спонсора – тщательно готовьтесь к встречам и максимально обобщайте информацию. Сделайте так, чтобы спонсору было как можно проще получить необходимую информацию. Будьте открыты и честны со спонсором – своевременно устраняйте проблемы и задержки и дайте спонсору достаточно времени для решения проблем, которые требуют его участия. Содержание проекта важно не только для определения того, что будет сделано в проекте, но и для того, что НЕ войдёт в проект. Для определения содержания проекта: 1. Уточните проблему, которую решает проект. 2. Соберите требования к продукту и проекту. Для этого комбинируйте разные приемы: изучите аналоги, которые есть у вас или конкурентов проверьте, есть ли обязательные требования спросите коллег, которые имеют схожий опыт больше общайтесь с пользователями и заказчиком привлекайте к планированию команду 3. Декомпозируйте проект – разложите проект по «кирпичикам». Допустим, вы хотите сделать конференцию. Это сложная задача. Но она станет гораздо проще, если вы разобьёте её на части. Например: площадка, где будет проходить мероприятие программа, которую вы предлагаете участники, которых вы пригласите спонсоры, которых нужно привлечь Разбить полученные «кирпичики» на конкретные задачи уже гораздо проще. Как и определить сроки и стоимость для таких блоков. Каждый проект требует ресурсов. Даже если проект делается силами своей команды, это время, которое можно было потратить на что-то другое. Нам необходимо понимать, сколько времени займёт проект и сколько это будет стоить. Несколько методов, которые менеджеры проектов применяют для оценки сроков и стоимости:Оценка по аналогам: берём похожий проект и отталкиваемся от его оценок Оценка «снизу-вверх»: разбиваем проект на кирпичики, оцениваем их и суммируем оценки «Сверху-вниз»: отталкиваемся от стоящих перед нами ограничений Предложения исполнителей: спрашиваем оценки у тех, кто будет делать работу Экспертная оценка: спрашиваем тех, у кого большой опыт в решение аналогичных задач Не бойтесь допустить ошибку в оценках – они неизбежны. Но будьте проактивны и работайте над уточнением своих оценок непрерывно. В нашем курсе «Как оценивать проекты и задачи?» мы подробно разбираем все эти и другие приёмы, которые помогают давать точные оценки и делать это быстро. Кроме проверенных техник, мы даём шаблоны и чек-листы, которые можно адаптировать под свой проект, сэкономив много времени и сил на разработку. Это продвинутый уровень для тех, кто готов брать ответственность за свои оценки перед командой и заказчиком. Риск — это неопределенное событие или условие, при наступлении которого могут возникнуть последствия, влияющие на цели проекты. Например, уход из команды единственного дизайнера — это риск. Вы можете сорвать из-за этого сроки проекта или сделать продукт нелучшего качества. Стратегии реагирования на риски Для тех, кто уже обжигался на рисках, мы сделали специальный курс «Как работать с рисками проекта?». В курсе мы подробно разбираем, где искать риски, как их оценивать, что делать дальше. Но главное, как организовать весь процесс работы с рисками и вовлечь в него команду. В бонусной части ПМ101, которую получат все, кто успешно сдаст тесты, мы расскажем об основных источниках рисков. Чтобы управлять рисками, сначала их нужно найти. Чтобы сделать это было проще, используйте все доступные источники информации: Обратитесь к собственному опыту и опыту коллегДаже если вы не делали аналогичный проект, кто-то мог уже работать с этим заказчиком или решать схожие задачи. Изучите корпоративную базу знанийАдаптируйте готовые шаблоны и чек-листы. Обязательно делаете такие шаблоны и чек-листы сами — это упростит работу в дальнейшем. Иерархическая структура рисков (Risk Breakdown Structure, RBS) – это организованное представление идентифицированных рисков плана, которые разделены по уровням и подуровням угроз. Они указывают на разные источники и сферы вероятных рисков. Иерархическая структура в основном приспособлена под конкретные виды планов. При управлении проектами в риски входят внезапные события, сказывающиеся отрицательно на самом плане, а именно стоимости, сроках и качестве выполнения. Поэтому проектный менеджер должен результативно влиять на риски, направляя проект в необходимое русло. Именно для этого применяются декомпозиции угроз срывов либо иерархическая структура рисков. Конструкция представления угроз проекту начинается с первого уровня и заканчивается детализацией рисков. К примеру, на главном уровне возможно разместить: планирование рисков; управление риском; технические риски; внешние риски. Детализированные уровни: конструирование рисков; финансирование рисков и т. д. Этот шаблон применяют для плана в целом, поскольку он дает возможность понять, что приняты к сведению все необходимые вопросы. Иерархическая структура рисков – это контрольный список, в котором на начальном этапе каждый составляющий элемент соизмеряет применимость. Ее прорабатывает руководитель этого проекта. После идентифицирования угроз составляется список их приоритетности. Для того чтобы правильно нейтрализовать риски, им необходимо присвоить баллы. Так, институт управления проектами предлагает использовать P-I балльный метод. При его применении нужно умножить вероятность появления любого риска (P) с его последствиями (I). Построение приоритетности угроз сможет помочь проектному менеджеру понять разделы проекта, которым необходимо уделить больше внимания. При решении вопросов, связанных с техническим риском, руководитель проекта должен убедиться в наличии необходимого профессионального персонала и требуемого оборудования для снятия риска в минимальные сроки. Иерархия рисков помогает определить сосредоточенность рисков в определенном уровне, а также выявить связи между рисками. Проектный менеджер ведет контроль процесса снижения рисков. Иерархическая структура рисков оказывает весомую помощь во время сравнения поступающих от поставщиков различных предложений либо по ведению проекта. Привлекайте к идентификации рисков командуИсполнитель как правило лучше видит подводные камни и мог с ними уже сталкиваться. Следите за профессиональным сообществом и обращайтесь к экспертамПосещайте больше мероприятий и читайте больше статей. Не стесняйтесь обращаться с вопросами к интересным вам экспертам Не игнорируйте корпоративные слухи и сплетниИногда можно услышать что-то полезное. Например, о переезде офиса, сокращении штата или перехода на новый сервис. Резюме проекта — одностраничный документ, описывающий проекте и задающий его границы. Руководители проектов не начинают проект, не имея резюме. В противном случае по ходу проекта возникнет путаница и проявятся разногласия: кто-то не так понял цель проекта, а кто-то считает, что сроки были назначены другие. Резюме проекта отвечает на простые вопросы: |