Blog

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

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

План управления проектом – что включает и как его разработать

Определяется стоимость проекта (во сколько же обойдется этот конечный результат). Это наш будущий базовый план стоимости проекта. План управления требованиями – описание того, как вы будете собирать, приоритезировать и управлять требованиями заказчика и стейкхолдеров. Эту часть, почему-то, часто оставляют за бортом, если проект не связан с ИТ (как-то сложилось, что требования – это про ИТ проекты), но это ошибка. Например, если вы строите луноход – то к луноходу тоже будут требования, и ими тоже нужно будет управлять. В Agile-проектах этот план, по большому счету, заменен ретроспективой, но смысл тот же самый.

Что включает план управления проектом

Будете вы в нем вообще системно заниматься вопросом, например, вовлечения стейкхолдеров? Или у вас внутренний проект без денег и вопросы управления стоимостью тут неприменимы? Это делается для того, чтобы ограничить круг задач, которые должен интегрировать РМ. По большому счету, опытный РМ тем и отличается от неопытного, что может легко сказать, какие именно инструменты управления проектами и в какой степени он будет использовать в конкретном проекте. Разрабатывается календарный план проекта (если на предыдущих шагах все сделано верно – то достаточно будет задать начальную или конечную дату и получить результат). Это наш будущий базовый календарный план проекта.

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

Информация полезна? Поддержи развитие проекта!

Действительно, важность формирования ПУП на ранних стадиях проекта критично недооценена. Если вы уверены в том, что вашего понимания того, как вы будете управлять изменениями “в голове” будет достаточно – значит, не нужно тратить время и писать этот план. Посмотрев на все это и поняв, что ничего ни с чем не сходится – возвращаемся в самое начало и пытаемся последовательно достичь баланса, учитывая ограничения проекта.

Потребуется множество уточнений других планов, состыковок и компромиссов прежде чем у вас будет результат, который можно и нужно использовать. Если план управления проектом удалось завершить в 2-3 итерации – это уже успех, но в жизни у меня так ни разу не получилось. Несмотря на то, что план управления проектом кажется сложным процесс планирования проекта для проджект менеджера – нужно попробовать, чтобы понять, что он не содержит ничего лишнего, и что один раз сделав эту работу, вы значительно облегчаете дальнейший ход проекта. В плане прописывается, кто и в каком порядке предлагает, учитывает и авторизует изменения. Какие именно процессы управления проектом будут именно в вашем проекте?

Как разработать план управления проектом

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

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

Принимаются решения о том, что именно будет приобретаться (в том числе какие работы “как сервис”), а что – делаться силами команды 1. Создается WBS (ИСР) проекта, декомпозирующая результат проекта на управляемые куски. Это наш будущий базовый план содержания проекта. Все грамотно объяснено. Видно, что план действительно нужен.