Процессы планирования проекта

Лекция №2 Процессы планирования проекта. Иерархическая структура работ. Базовое расписание проекта. Процессы планирования проекта Планирование проекта – непрерывный процесс, направленный на определение и согласование наилучшего способа действий для достижения поставленных целей проекта с учетом всех факторов его реализации. Основным результатом этого этапа является План проекта. Однако, процесс планирования не завершается разработкой и утверждением первоначального плана проекта. В ходе осуществления проекта могут происходить изменения как внутри проекта, так и во внешнем окружении, которые требуют уточнения планов, а часто значительного перепланирования. Поэтому процессы планирования могут осуществляться на протяжении всего жизненного цикла проекта, начиная с предварительного укрупненного плана в составе концепции проекта, и заканчивая детальным планом работ завершающей фазы проекта. Планирование – комплексная, многокритериальная функция, предполагающая рассмотрение, анализ и прогнозирование нескольких функциональных областей проекта. Планирование проекта может включать следующие процедуры (и объекты): • Планирование целей и содержания проекта (предметная область). • Календарное планирование работ проекта (время). • Планирование затрат и финансирования проекта (стоимость, бюджет). • Планирование качества (качество, его показатели). • Организационное планирование (персонал). • Планирование коммуникаций (коммуникации). • Планирование управления рисками (риски). • Планирование контрактов (поставки и контракты). • Планирование изменений (источники изменений). • Разработку сводного плана проекта (интеграционный план). Планирование предметной области проекта Предметная область проекта (Project Scope) – совокупность продуктов и услуг, производство которых должно быть обеспечено в результате завершения осуществляемого проекта. Предметную область проекта определяют цели, результаты и работы проекта. В процессе жизни проекта все составляющие предметной области проекта могут претерпевать изменения. Цели результаты, работы и их характеристики могут изменяться или уточняться как в процессе разработки проекта, так и по мере достижения промежуточных результатов. Планирование предметной области проекта включает следующие задачи и процедуры: • Анализ текущего состояния и уточнение целей и результатов проекта. • Уточнение основных характеристик проекта. • Подтверждение и уточнение критериев успеха и неудач проекта. • Анализ и корректировку ограничений и допущений, принятых на стадии инициации проекта. • Выбор критериев оценки промежуточных и окончательных результатов создания проекта. • Построение структурной декомпозиции предметной области проекта, которая послужит основой для иерархической структуры работ (ИСР). Планирование времени проекта Согласованная работа всех участников проекта организуется на основе календарных планов или расписаний работ проекта, основными параметрами которых являются: сроки выполнения, ключевые даты, продолжительности работ. Календарными планами называют проектно-технологические документы, устанавливающие полный перечень работ проекта, их взаимосвязь, последовательность и сроки выполнения, продолжительности, а также исполнителей и ресурсы, необходимые для выполнения работ проекта. Планирование проекта по временным параметрам заключается в составлении различных календарных планов (расписаний работ), удовлетворяющих всем требованиям и ограничениям проекта и его частей. Календарные планы составляются на весь жизненный цикл проекта и его этапы, для различных уровней управления и участников проекта. Календарное планирование проекта состоит из следующих этапов: 1. Составление иерархической структуры работ. 2. Определение списка работ проекта на основе структурной декомпозиции проекта. 3. Определение последовательности выполнения работ и их взаимосвязей с помощью организационно-технологических моделей. Уточнение временных ограничений. 4. Определение продолжительности работ. 5. Составление сетевой диаграммы проекта. 6. Составление диаграммы Ганта. 7. Оптимизация расписаний работ проекта по временным критериям. 8. Утверждение календарных планов. 9. План управления проектом по временным параметрам. Иерархическая структура работ (ИСР) (Work Breakdown Structure, WBS) Это ориентированная на результат иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходи- мых результатов. С ее помощью структурируется и определяется все содержание проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта. Основой для разработки ИСР служит концепция проекта, которая определяет продукты проекта и их основные характеристики. ИСР обеспечивает выявление всех работ, необходимых для достижения целей проекта. Многие проекты проваливаются не от того, что у них нет плана, а от того что в этом плане забыты важные работы, например тестирование и исправление ошибок, и продукты проекта, например пользовательская документация. Поэтому, если ИСР составлена корректно, то любая работа, которая в нее не вошла не может считаться работой по проекту. ИСР делит проект на подпроекты, пакеты работ, подпакеты. Каждый следующий уровень декомпозиции обеспечивает последовательную детализацию содержания проекта, что позволяет производить оценку сроков и объемов работ. ИСР должна включать все промежуточные и конечные продукты. Выполнять декомпозицию работ проекта можно по-разному. Например, ГОСТ 19.102-77 предусматривает каскадный подход и определяет следующие стадии разработки программной системы: 1. Техническое задание. 2. Эскизный проект. 3. Технический проект. 4. Рабочий проект. 5. Внедрение. Если следовать этому стандарту, то на первом уровне ИСР должны находиться именно эти проектные продукты. Если бы пришлось разрабатывать АСУ для управления ядерным реактором или пилотируемым космическим аппаратом, то именно так и следовало поступать. Однако в коммерческой разработке ПО такой подход чаще всего не эффективен. Процесс разработки коммерческого ПО должен быть инкрементальным. Это означает, что на верхнем уровне декомпозиции нашего проекта должны находиться продукты проекта, а на следующем уровне - компоненты, из которых эти продукты состоят. Компоненты далее могут быть декомпозированы на «фичи» функции, которые они должны реализовывать. Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое мы должны выполнить на фазе планирования проекта, не дожидаясь проработки всех функциональных требований к разрабатываемому ПО. Компонентами могут быть как прикладные подсистемы, так и инфраструктурные или ядерные, например, подсистема ведения логов, безопасности, библиотека визуальных компонентов GUI (Graphic User Interface). При составлении базового плана работ не стоит стремиться максимально детализировать все работы. ИСР не должна содержать слишком много уровней. При этом должна быть установлена персональная ответственность за все части проекта (подпроекты и пакеты работ). Для каждого пакета работ дол- жен быть четко определен результат на выходе. Работы и оценки проекта должны быть согласованы с ключевыми участниками команды, руководством компании-исполнителя и, при необходимости, с заказчиком. В результате согласования члены команды принимают на себя обязательства по реализации проекта, а руководство принимает на себя обязательства по обеспечению проекта необходимыми ресурсами. ИСР является одним из основных инструментов (средств) в механизме управления проектом, с помощью которого измеряется степень достижения результатов проекта. Важнейшая ее функция это обеспечить консистентное представление всех у частников проекта относительно того, как будет делаться проект. В последующем базовый план будет служить ориентиром для сравнения с текущим исполнением проекта и выявления отклонений для целей управления. Базовое расписание проекта После определения трудоемкости работ необходимо определить график их выполнения и общие сроки реализации проекта – составить расписание работ по проекту. Базовое расписание – утвержденный план-график с указанными временными фазами проекта, контрольными точками и элементами иерархической структуры работ. Базовое расписание может быть наиболее наглядно представлено диаграммой Ганта. В этой диаграмме плановые операции или элементы иерархической структуры работ перечислены с левой стороны, даты отображаются сверху, а длительность операций показана горизонтальными полосками от даты начала до даты завершения. Базовое расписание это, как правило, элемент контракта с заказчиком. Контрольные точки (вехи) должны служить точками анализа состояния проекта, поэтому они должны зримо демонстрировать статус проекта. Рисунок 1 – Диаграмма Ганта (пример) Если работы не связаны между собой, то любую из них мы можем начинать и завершать, когда нам удобно. Все работы можно делать параллельно и в этом случае минимальная длительность проекта равна длительности самой долгой работы. Однако, на практике между работами существуют зависимости, которые могут быть «жесткими», например, анализ - проектирование – кодирование – тестирование и документирование конкретной функции; или «нежесткими», которые могут пересматриваться или смягчаться. Например, последовательное выполнение задач конкретным исполнителем (можно перепланировать на другого исполнителя) или разработка базового ПО, которая должна предшествовать разработке прикладного ПО. В этом случае можно создавать «заглушки» эмулирующие работу базового ПО. Для отображения таких связей можно использовать сетевую диаграмму проекта. Сетевая диаграмма (диаграмма предшествования) – графическое отображение работ проекта и зависимостей между ними. Рисунок 2 – Сетевая диаграмма (пример) Если связи между работами в сетевой диаграмме превратить в вершины, а вершины-работы в связи (и добавить две новых вершины — начало и конец проекта), то получится так называемая PERT-диаграмма (PERT — program evaluation and review technique, техника оценки и обзора программ). Рисунок 3 – PERT-диаграмма (пример) Сетевые и PERT-диаграммы используются для планирования продолжительности проекта и выделения критических путей — последовательностей работ от начала до конца проекта, сумма длительностей которых максимальна среди таких последовательностей. Увеличение длительности любой работы в подобной цепочке приводит к увеличению длительности всего проекта. В проекте всегда существует хотя бы один критический путь, но их может быть несколько. Критический путь может меняться во время исполнения проекта. При исполнении проекта руководитель должен обращать внимание на исполнение задач на критическом пути в первую очередь и следить за появлением других критических путей. Практическая рекомендация: на критическом пути должны стоять работы с нежесткими связями, которые всегда можно перепланировать, если возникает угроза срыва сроков. Планирование стоимости проекта Планирование стоимости проекта состоит из следующих этапов: 1. Определение стоимости использования ресурсов. 2. Определение стоимости каждой проектной работы, исходя из объема затрачиваемых на выполнение ресурсов и их стоимости. 3. Определение стоимости проекта. Стоимость проекта – совокупность стоимостей ресурсов проекта и стоимостей выполнения работ. Стоимость проекта определяется ресурсами, необходимыми для выполнения работ, в том числе: • Оборудование (покупка, взятие в аренду, лизинг). • Приспособления, устройства и производственные мощности. • Рабочий труд (штатные сотрудники, нанятые по контракту). • Расходные товары (канцелярские принадлежности и т.д.). • Материалы. • Обучение, семинары, конференции. • Субконтракты. • Перевозки и т.д. 4. Составление сметы проекта. Смета проекта – документ, содержащий обоснование и расчет стоимости проекта, обычно на основе объемов работ проекта, требуемых ресурсов и цен. 5. Согласование и утверждение сметы. 6. Составление бюджета проекта Бюджет – документ, определяющий ресурсные ограничения проекта. 7. Согласование и утверждение бюджета проекта Бюджет может составляться в виде: • Матрицы распределения расходов. • Календарных планов-графиков затрат. • Столбчатых диаграмм затрат. • Столбчатых диаграмм кумулятивных затрат. • Линейных диаграмм распределенных во времени кумулятивных затрат. • Круговых диаграмм структуры расходов и пр. Планирование управления изменениями В ходе достижения цели проекта могут измениться обстоятельства, что повлечёт за собой внесение изменений как в план проекта, так и в те элементы проекта, которые уже реализованы. Каждое из таких изменений, для вынесения вердикта о его реализуемости, должно быть подвергнуто анализу. Поэтому, сразу, как только удалось стабилизировать и согласовать ИСР, необходимо разработать план управления изменениями проекта. Для этого следует: • Определить источники запросов на изменение. • Установить порядок анализа, оценки и утверждения/отклонения изменения содержания. • Определить порядок документирования изменений содержания. • Определить порядок информирования об изменении содержания. Первая задача, которую необходимо решить при анализе запроса на изменения - выявить объекты изменений: требования, архитектура, структуры данных, исходные коды, сценарии тестирования, пользовательская документация, проч. Затем требуется спроектировать и детально описать изменения во всех выявленных объектах. И наконец, следует оценить затраты на внесение изменений, тестирование изменений и регрессионное тестирование продукта и их влияние на сроки проекта. Эта работа, которая потребует затрат рабочего времени и порой значительных разных специалистов: аналитиков, проектировщиков, разработчиков, тестировщиков, наконец, менеджера проекта. Поэтому эта работа должна обязательно быть учтена в плане. Планирование организационной структуры Организационная структура это согласованное и утвержденное распределение ролей, обязанностей и целей деятельности ключевых участников проекта. Она в обязательном порядке должна включать в себя систему рабочих взаимоотношений между рабочими группами проекта, систему отчетности, оценки хода выполнения проекта и систему принятия решений. Следует помнить, что организационная структура проекта – «живой» организм. Она начинает складываться на стадии планирования и должна меняться по ходу проекта. Нестабильность организационной структуры – частая смена исполнителей - может стать серьезной проблемой в управлении проектом, поскольку, существует цена замены, которая определяется временем вхождения нового участника в контекст проекта. Планирование управления конфигурациям Конфигурационное управление один из важных процессов производства программного обеспечения. План проекта должен включать в себя работы по обеспечению единого хранилища всей проектной документации и разрабатываемого программного кода, обеспечению сохранности и восстановление проектной информации после сбоя. Работы по настройке рабочих станций и серверов, используемых участниками проектной команды, тоже должны войти в план. Кроме этого в плане должны содержаться работы, необходимые для организации сборки промежуточных выпусков системы, а также ее конечного варианта. Эти работы, как правило, выполняет один человек – инженер по конфигурациям. Если проект небольшой, то эта роль может быть дополнительной для одного из программистов. «Размазывать» эту работу на всех участников проекта, во-первых, неэффективно. Установка и конфигурирование среды разработки, например, баз данных и серверов приложений, требует определенных компетенций и знаний особенностей конкретных версий продуктов. Если эти навыки придется осваивать всем разработчикам, то на это уйдет слишком много рабочего времени. Во-вторых, «размазывание» работ по управлению конфигурациями может привести к коллективной безответ- ственности, когда никто не знает, от чего не собирается проект и как откатиться к консистентной версии. Управление конфигурациями может многократно усложниться, если проектной команде параллельно с разработкой новой функциональности продукта приходится поддерживать несколько релизов этого продукта, которые были установлены ранее у разных клиентов. Все эти работы должны быть учтены в плане проекта. Планирование управления качеством Обеспечение качества еще одна из базовых областей знаний в программной инженерии. Относительно того, что такое качество ПО и как его эффективно обеспечивать, можно рассуждать очень и очень долго. Здесь мы ограничимся утверждением о том, что обеспечение качества это важная работа, которая должна быть спланирована заранее и выполняться по ходу всего программного проекта, а не только во время приемо-сдаточных испытаний. При планировании этой работы необходимо понимать, что продукт проекта не должен обладать наивысшим возможным качеством, которое недостижимо за конечное время. Необходимое качество продукта определяется требованиями к нему. И еще. Основная задача обеспечения качества это не поиск ошибок в готовом продукте (выходной контроль), а их предупреждение в процессе производства. План управления качеством должен включать в себя следующие работы: • Объективную проверку соответствия программных продуктов и технологических операций применяемым стандартам, процедурам и требованиям. • Определение отклонений по качеству, выявление их причин, применение мер по их устранению, а также контроль исполнения принятых мер и их эффективности. • Представление высшему руководству независимой информации о несоответствиях, не устраняемых на уровне проекта.