Составление плана работы по проекту. Технология создания плана проекта. Планирование проекта по временным параметрам

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

Существуют более простые варианты, такие как сделать Landing Page с помощью сервиса LP Generator или подобного ему. Можно не ограничиваться одностраничником и сделать полноценный сайт на конструкторе сайтов. Это рабочие варианты, я никого не отговариваю от них. Все зависит от целей, которые вы ставите перед сайтом и, соответственно, от ваших требований. Я предлагаю план проекта многостраничного сайта с ориентацией на SEO продвижение без использования конструктора сайтов.

Определение основных блоков работ

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

1. Классический маркетинг: знакомство с продуктом, конкурентами, разработка УТП
2. Подбор семантики
3. Разработка структуры сайта
4. Прототипирование
5. Дизайн
6. Верстка
7. Программирование
8. Тестирование
9. Запуск

Картинка становится более четкой, но не хватает деталей, поэтому дроблю крупные задачи на более мелкие.

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

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

Детализация списка задач

Для расчета трудозатрат я стараюсь поделить задачи так, чтобы на каждую задачу можно было назначить одного ответственного специалиста. Сразу к списку задач добавляю колонку «Исполнитель» и расчетное количество часов на выполнение задачи.

Расчет сроков проекта

Большая часть работы сделана, дальше расписываем полученные часы по дням. Некоторые этапы будут идти параллельно. Я привожу для примера расчет, когда над проектом работает 1 специалист каждого направления, соответственно, максимальное количество рабочих часов в день – 8 часов на специалиста.

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

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

Также добавляю общую таблицу по срокам проекта.

Я понимаю, что 62 дня не равняется 760 часам. Разница обусловлена за счет одновременного выполнения части задач разными специалистами.

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

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

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

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

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

Таким образом, очевидно, что процесс планирования оказывает влияние на все ключевые .
В связи с этим, рассмотрим некоторые аспекты планирования более подробно.

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

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

Итак, – это официально утвержденный документ для исполнения проекта (базовый план).

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

Базовый план изменяется только в крайних случаях и не может быть изменен руководителем проекта. Его изменяет Комитет по или заменяющее его лицо (Спонсор, Заказчик). Только в том случае, если изменение утверждено.

Создание плана проекта – это итеративный и интеграционный процесс. То есть при разработке плана проекта используются результаты других процессов планирования (например, стратегического).

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

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

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

Понятие и цель планирования

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

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

Планирование предметной области

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

• На основе анализа целей уточняется текущее состояние управляющей системы.
• Уточнение ключевых параметров проектного решения.
• Детальное формулирование критериев успеха и провала.
• Анализ и корректировка допущений по ограничениям.
• Определение параметров оценки промежуточных и конечных результатов проекта.

Состав процессов планирования

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

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

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

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

Этапы создания календарного плана

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

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

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

Методы разработки планов

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

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

Особенности ресурсного планирования

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

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

Планирование этапов реализации проекта

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

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

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

Уже говорилось о важности предварительного создания модели реагирования на риски. Конкретная модель их обработки может строиться на следующих ответных механизмах:

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

Распространенные ошибки планирования

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

• Применение неправильных целей. Как правило, ошибки в этой части выражаются в неточном или вовсе некорректном формулировании.
• Использование неполных данных. Ошибочность планирования управления проектами особенно характерна для отраслей инжиниринга, где велика вероятность получения неполных или неверных данных из-за нарушений в сложных процессах тестирования.
• Подключение узкой группы специалистов. Зачастую в работу включаются только плановики, которые решают смежные задачи через контрагентов, что само по себе снижает качество результата.
• Формализация планирования. Распространенная проблема, когда отдельные процессы выполняются не ради ясных конкретных целей, а для завершения определенной части работ без акцента на дальнейший эффект.

Заключение

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

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

Цели, сущность и определение

Осуществление проекта буквально на всех стадиях потребует четких действий, скоординированного и последовательного плана. Система планирования управления проектами на первых этапах разрабатывается (в концептуальном смысле) руководителем, владельцем компании/бизнеса. На этапе разработки концепции развития проект-менеджером (или отделом по планам развития) во внимание берутся основные понятия и цели направления:

• продолжительность всего плана реализации проекта;
• протяженность каждого элемента;
• объем необходимых ресурсов для достижения целей: финансовые возможности, трудовые резервы, запас времени;
• объемы привлекаемых строительных или проектных организаций;
• сроки поставки материалов, комплектующих, оборудования;
• ликвидность проводимых мероприятий.

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

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

Основные стадии реализации планирования проектной деятельности

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

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

Однако весь процесс осуществления плана можно для удобства разделить на несколько стадий:

• построение концепции, его целей;
• определяется последовательность работ;
• определяются ресурсы, которые необходимо будет задействовать;
• описание проекта, его состава;
• определение последовательности работ;
• составляется основа проектного бюджета (смета);
• компоновка всех результатов в один документ (бизнес/план);
• реализация, воплощение плана;
• просчет прибыльности по итогам реализуемого плана.

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

7 принципов планирования проектной деятельности

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

Принцип №1: Целенаправленность

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

Принцип №2: Системность

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

Принцип №3: Комплексность

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

Принцип №4: Обеспеченность

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

Принцип №5: Приоритетность

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

Принцип №6: Безопасность

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

Принцип №7: Время

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

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

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

• формирование поэтапности реализуемых работ (график);
• показывать результаты внедряемых этапов (эффективно, неэффективно);
• установление контрольных точек развития и реализации проекта;
• обеспечение всем сотрудникам и руководству проекта объективного понимания того, что нужно делать именно сейчас;
• распределение зон ответственности;
• составление понимания всех используемых ресурсов: трудовых, материальных, финансовых.

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

Краткий словарь понятий, характеризующих процесс планирования проекта:

• ССО – структурная схема организации;
• СРР – структура разбиения (распределения) работ;
• СДР – структурная декомпозиция работ.

Структура в стандартном формате проекта планируемых работ:

• целеполагание;
• планирование;
• создание;
• контроль и возможная коррекция действия на разных этапах;
• презентация;
• рефлексия.

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

Виды планирования проектной деятельности

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

• микропроекты (узкая форма реализации проекта индивидуальной инициативы, объёмы которого могут меняться);
• малые проекты (инструменты реализации с малым трудовым и денежным ресурсом, не нуждаются в крупном финансировании);
• мегапроекты (целевые программы, которые в основе несут взаимосвязь с несколькими малыми или средними проектами).

Виды проектной деятельности по срокам реализации:

• краткосрочные;
• среднесрочные;
• долгосрочные.

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

Виды проектного планирования по типу финансирования (бюджетированной основы):

• спонсорские;
• кредитные или инвестируемые;
• бюджетные;
• благотворительные.

Выводы

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

Планирование представляет собой процесс распределения и назначения ресурсов (материальных и людских) с учетом стоимости и времени выполнения проекта. Планирование относится к наиболее важным процессам для проекта, так как результатом его реализации обычно является уникальный объект, товар или услуга.

Основные функции планирования приведены далее.

Преобразование потребностей в управляемые задачи. Изначально проект выступает в виде требований, разработанных и согласованных с заказчиком. Цель планирования - представить эти требования в виде совокупности отдельных задач, выполнение которых можно контролировать.

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

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

Оценка потенциальных рисков. Хотя некоторые риски могут быть выявлены во время формулировки требований, гораздо больше их обнаруживается после осуществления детального планирования. Знание о существовании этих рисков позволит раньше их заметить (если они осуществились) и приготовиться к их адресации.

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

Группа процессов планирования представлена на рис. 3.10. Эти процессы могут повторяться и входить в состав итерационной процедуры, выполняемой до достижения определенного результата. Например, если первоначальная дата завершения проекта неприемлема, то требуемые ресурсы, стоимость, а иногда и содержание про-( Группы процессов ^управления проектом

Группа процессов планирования

Управление человеческими ресурсами проекта

Планирование

Разработка плана управления челове-ческими ресурсами

Определение

Управление сроками проекта

Определение

операций

Управление

целостностью

Планирование закупок

Управление стоимостью проект^

Оценка стоимости

Управление качеством проекта

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

Определение

последовательности

операций

ресурсов операций

Планирование

качества

длительности

операций

Разработка

расписания

Управление рисками проекта

Определение

Планирование

управления

риском

Проведение качественнного анализа рисков

Проведение количественного анализа рисков

Планирование ответов на риски

Рис. ЗЛО. Процессы планирования

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

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

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

Планирование заключается в составлении следующих планов :

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

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

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

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

Сетевой план с несколькими проектами (для высшего руководства)

Уровень 1

Уровень 3

Уровень 2

Сетевой план с ключевыми этапами (вехами)

Детальный сетевой план

Рис. 3.11. Многоуровневые сетевые планы

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

Стратегическое планирование представляет собой процесс разработки стратегических, укрупненных, долгосрочных планов.

Детальное (оперативное , тактическое) планирование связано с разработкой тактических, детальных планов (графиков) на основе иерархической структуры работ (ИСР) для оперативного управления

на уровне ответственных исполнителей.

Планирование управления содержанием. Одна из распространенных «болезней» программных проектов называется «ползучий фиче-ризм», когда к изначально спроектированной будке для любимой собаки сначала пристраивают сарайчик для хранения садового инвентаря, а потом и домик в несколько этажей для ее хозяина. И все это пытаются построить на одном и том же фундаменте и из тех же самых материалов. Такой подход стал причиной летального исхода многих проектов разработки ПО. Поэтому сразу, как только удалось стабилизировать и согласовать ИСР - иерархическую структуру работ, необходимо разработать план управления содержанием проекта , для чего следует:

• определить источники запросов на изменение;
• установить порядок анализа, оценки и утверждения/отклонения изменения содержания;
• определить порядок документирования изменений содержания;
• определить порядок информирования об изменении содержания. Первая задача, которую необходимо решить при анализе запроса

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

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

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

Следует помнить, что организационная структура проекта является «живым» организмом. Она начинает складываться на стадии планирования и должна меняться по ходу проекта. Нестабильность организационной структуры (частая смена исполнителей) может стать серьезной проблемой в управлении проектом, поскольку существует цена замены, которая определяется временем вхождения нового участника в контекст проекта.

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

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

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

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

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

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

План управления качеством должен включать в себя следующие работы:

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

Уточнение содержания и состава работ. Уточнение содержания (декомпозиция) проекта - одна из важнейших составных частей дисциплины управления проектами. Детализация позволяет оценить, например, общую стоимость проекта через совокупность стоимости отдельных его работ. Результат детализации содержания проекта есть структура декомпозиции работ (Work Breakdown Structure - WBS). В большинстве случаев такая структура является иерархической. При этом сам процесс детализации - это структурная декомпозиция работ , т.е. деятельность по созданию детализированной структуры работ или задач проекта.

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

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

• 1) техническое задание;
• 2) эскизный проект;
• 3) технический проект;
• 4) рабочий проект;
• 5) внедрение.

Если следовать этому стандарту, то на первом уровне ИСР должны находиться именно эти проектные продукты. Если бы пришлось разрабатывать АСУ для управления ядерным реактором или пилотируемым космическим аппаратом, то именно так и следовало поступать. Однако в коммерческой разработке ПО такой подход неэффективен.

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

Выделение компонентов, составляющих программный продукт, - это элемент высокоуровневого проектирования, которое должно выполняться на фазе планирования проекта, не дожидаясь проработки всех функциональных требований к разрабатываемому ПО. Компонентами могут быть как прикладные подсистемы, так и инфраструктурные или ядерные, например подсистема аутентификации, безопасности, библиотека визуальных компонентов графического интерфейса (GUI). При составлении базового плана работ не стоит стремиться максимально детализировать все работы ИСР, достаточно 3-5 уровней.

В контексте детализации часто используются термины «задачи» и «работы» как взаимозаменяемые. Все же корректнее говорить, что задача определяет достижение промежуточного результата, а работы являются комплексами действий для достижения этих результатов. Так как любая задача требует проведения определенных работ при заданных ограничениях, безусловно, можно говорить о несомненном «отображении» (mapping) задач на работы и наоборот. Это и есть причина взаимозаменяемости терминов в повседневной жизни. В то же время понимание отличий между этими понятиями позволяет почувствовать нюансы процессного взгляда на создание продукта, а следовательно, и на жизненный цикл проектов, в том числе и проектов программных систем.

В общем случае можно говорить о детализации : «программа - проект - задача - операция». На рис. 3.12 представлен пример такой детализации (показаны только операции Задачи А).

Рис. 3.12. Пример применения терминов: программа, проект, задача, операция

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

За все части проекта (субпроекты и пакеты работ) должна быть установлена персональная ответственность. Для каждого пакета работ должен быть четко определен результат на выходе. Работы и оценки проекта должны быть согласованы с ключевыми участниками команды, руководством компании-исполнителя и, при необходимости, с заказчиком. В результате согласования члены команды принимают на себя обязательства по реализации проекта, а руководство берет на себя ответственность за обеспечение проекта необходимыми ресурсами.

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

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

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

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

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

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

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

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

Существуют различные эмпирические подходы к оценке стоимости проекта, например стоимость проекта предлагается определять по формуле

СТОИМОСТЬ = {а + Ь?)т(Х),

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

Более упрощенная оценка, полученная экспериментальным путем, выражается в следующем виде:

СТОИМОСТЬ = 5,255 0,91 .

Эти оценки были получены на основе анализа проектов, где программы имели размер от 4000 до 467 000 строк кода и были написаны на 28 различных языках программирования для 66 компьютеров. На разработку было затрачено от 12 до 11 758 чел.-мес. Известны и другие техники эмпирического моделирования.

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

Базовой моделью экспериментальной оценки стоимости проекта на сегодняшний день служит следующее уравнение:

СТОИМОСТЬ = bS c m(X),

где bS c - первичная оценка, которая корректируется с помощью вектора стоимости т(Х) и учета числа старых и новых объектов; с - параметр, который изменяется от нуля до единицы для первой стадии ведения проекта и от 1,01 до 1,26 - для остальных стадий.

При формализованном подходе выполнение оценки проекта основывается на использовании LOC- и FP-метрик.

Конструктивная модель стоимости (СОСОМО - Constructive cost model), предложенная Б. Боэмом, объединила в себе наиболее известные формализованные техники оценки проекта - LOC-оценки (LOC - Lines of Code), которые базируются на числе строк программного кода. В процессе применения этой модели формируются предварительные оценки, позволяющие предъявить заказчику корректные требования по стоимости и затратам на разработку ПП, а также обеспечивается возможность составления плана ПП.

Функционально-ориентированные FP-метрики вместо подсчета LOC-оценки косвенно измеряют программный продукт. Рассматривается не размер, а функциональность или полезность продукта. Автором этой метрики является А. Албрехт. Определение функционального размера состоит из нескольких шагов и начинается с идентификации функций, которые должно иметь приложение. Международная группа пользователей функционального измерения (IFPUG - International Function Point Users Group) опубликовала критерии, по которым определяются функции приложения. При расчете FP-метрики используются пять информационных характеристик: количество внешних вводов; количество внешних выводов (выводы означают отчеты, экраны, распечатки, сообщения об ошибках); количество внешних запросов; количество внутренних логических файлов; количество внешних интерфейсных файлов.

После сбора всей необходимой информации приступают к расчету метрики - определяют количество функциональных указателей FP (Function Points) по некой формуле, где значения входящих коэффициентов регулировки сложности (каждый коэффициент может принимать значения: 0 - нет влияния; 1 - случайное; 2 - небольшое; 3 - среднее; 4 - важное; 5 - основное) выбираются эмпирически в результате ответов на 14 вопросов, которые характеризуют системные параметры приложения.

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

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

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

С помощью стандартных таблиц FP-оценки можно легко пересчитать в LOC-оценки, т.е. по функциональному размеру вычислить количество строк кода. Однако результаты пересчета зависят от языка программирования, используемого для реализации ПО (например, на Java одна единица функционального размера равна 53 строкам исходного кода). В свою очередь, количество строк кода позволяет определить общую трудоемкость, выраженную в чел.-мес., и сроки проекта.

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

Пример 3.1. Рассмотрим порядок выполнения процедуры оценки работ на основе ШС-метрики.

Этап 1. Область назначения проектируемого продукта разбивается на ряд функций/i,/ 2 ,/ 3 , каждую из которых можно

оценить индивидуально

Этап 2. Для каждой функции/ планировщик формирует лучшую LOC n , худшую ЮС Х и вероятную ЮС В оценки. В процессе формирования оценок используются опытные данные из метрического базиса или интуитивные представления планировщика. Диапазон возможных значений оценок соответствует степени предусмотренной неопределенности.

Этап 3. Для каждой функцииf t определяется ожидаемое значение оценки:

ЮС Я + ЮС Х + 4 ЬОС^ ож = 6 "

юс.

Этап 4. Вычисляется значение ШС-производительности разработки функции в соответствии с одним из трех правил.

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

ПР, = ПР ср; / = 1, 2, ..., п.

Правило Б. Для /-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:

ыс ср

МС ож ’

где ЮС ср - средняя ЬОС-оценка, взятая из метрического базиса (соответствует средней производительности).

Правило В. Для /-й функции настраиваемая величина производительности вычисляется по выбранному аналогу (взятому из метрического базиса):

ЬОСднІ

мс ожі

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

Этап 5. Вычисляется общая оценка затрат (чел.-мес.) на проект, если используется правило А:

если используется правило Б или В:

Ь1У ^ож/

Этап 6. Вычисляется общая оценка стоимости проекта, если используется правило А или Б:

СТОИМОСТЬ = УДСТ ср?юС 0Ж/ ;

если используется правило В:

СТОИМОСТЬ = УДСТ ан/ ^ЮС 0Ж/ ,

где УДСТ ср - метрика средней стоимости одной строки программного кода; УДСТ ан, - метрика стоимости одной строки аналога (обе метрики берутся из метрического базиса).

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

Базовое расписание в большинстве случаев является элементом контракта с заказчиком. Контрольные точки {вехи) служат точками анализа состояния проекта и принятия решения в формате «§о или по1 §о», поэтому они должны зримо демонстрировать статус проекта. Предъявляются определенные требования к выбору и формированию контрольных точек, например контрольная точка «Проектирование завершено» является малоинформативной, более эффективным подходом считается метод последовательных поставок: вышеназванная контрольная точка формулируется в форме «Завершено тестирование требований 1, 3, 5, и 7».

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

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

В методе критического пути проекта (Critical path) используется самая длинная цепочка работ в проекте. Увеличение длительности любой работы в этой цепочке приводит к увеличению длительности всего проекта. В проекте всегда существует хотя бы один критический путь, но их может быть и несколько. Критический путь может меняться во время исполнения проекта.

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

Требования График

к проекту

Рис. 3.13. Шаги составления графика работ на проекте

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

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

На этапе планирования могут использоваться также сетевая разбивка работ и диаграмма Ганта.

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

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

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

План работ в виде графа СРР содержит фазы (этапы), шаги и деятельность, включая начальную и конечную деятельность на процессе (рис. 3.14).

Фаза и

Шаг 1 Шаг 2

Рис. 3.14. Пошаговый граф плана проекта

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

Рис. 3.15.

вершины и входящей в заключительную вершину, соответствует временная отметка «ноль».

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

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

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

Рис. 3.16. Диаграмма Ганта

Группа процессов исполнения

Группы процессов правления проектом

Управление качеством проекта

Обеспечение

качества

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