Центральный процессор фирмы производители. Производство современных процессоров. Технологический экскурс. Сокеты процессоров Intel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Группа процессов планирования представлена на рис. 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. Это дает возможность разработчику или менеджеру проекта видеть, как выполняются различные виды деятельности - последовательно или параллельно, находятся ли они на критическом пути.

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

Описанное выше – незначительный пример. Но он отлично объясняет суть – у всего есть начало.

Управление проектами – не исключение. Будучи сложной цепочкой задач и процессов, оно также с чего-то начинается. Этим первым шагом является план проекта .

В этой статье мы поговорим о плане и процессе планирования, а также разъясним моменты, связанные с вопросом «Как создать такой план». Мы выделили 7 шагов.

Что же такое план проекта?

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

Планирование – это процесс, обсуждение. Во время него выясняется объем работ, цели и пути, необходимые для их достижения.

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

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

Цели плана проекта

Хорошо подготовленный план должен отвечать на следующие вопросы.

Почему?

Должны быть выяснены причины, почему на проект выделяются средства; какая проблема должна быть решена.

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

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

Когда?

Здесь речь идет о графике/продолжительности проекта.

Как составить план проекта?

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

1. Общайтесь

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

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

2. Определите участников и цели

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

Кто может быть участником проекта:

• Заказчик – человек, непосредственно финансирующий и утверждающий работу;
• Менеджер проекта – человек, занимающийся планированием с последующим созданием, исполнением и контролем над проектом;
• Команда проекта , которая создает конечный продукт. Члены команды участвуют во многих важных процессах, среди которых разработка, обеспечение качества, работа над дизайном и т.д. Как правило, они не утверждают проект;
• Конечный пользователь ;
• Другие . В этот список могут входить самые разнообразные люди: риск-аналитики, специалисты по снабжению и т.д.

Что можно сделать на этой стадии? Проведите интервью с ключевыми участниками. Так вы поймете, какие требования ставятся, и какие цели стоит достигнуть. Наиболее эффективным способом достижения целей является SMART методика постановки целей.

Проведение интервью также позволяет менеджеру осознать, какую проблему решает проект, и почему вообще он финансируется.

Это наш почему вопрос.

3. Определите весь объем работ

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

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

Это наш что вопрос.

4. Определите роли и ответственности

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

Это наш кто вопрос.

5. Составьте график проекта

Этот пункт – непосредственное продолжение предыдущего. Как только роли и ответственность будут распределены, следующим шагом будет установление продолжительности работы для каждого ресурса с датами начала/окончания.

Это наш когда вопрос.

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

Какой же инструмент для работы с проектом выбрать?

6. Визуализируйте план проекта при помощи диаграммы Ганта

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

Воспользуйтесь GanttPRO – онлайн инструментом для . С его помощью менеджер может:

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

С диаграммами Ганта GanttPRO легко управлять процессами планирования и составлять проект.

7. Управляйте рисками

Все стадии проекта могут подвергаться рискам. Поэтому управление ими – один из важнейших моментов в планировании.

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

Какие риски могут возникнуть?

• Оптимистичные ожидания о времени и затратах;
• Плохо обозначенные требования и пожелания;
• Плохо обозначенные роли и ответственности;
• Перемены в требованиях;
• Новые требования;
• Сокращение бюджета;
• Плохое взаимодействие.

Подытожим

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

А у вас есть опыт планирования проектов?

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

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

Общее планирование проекта

Процедура составления плана называется планированием. Планирование выполняет следующие функции:

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

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

Рис. 10.1.

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

Выделение отдельных работ проекта выполняет следующие функции:

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

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

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

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

Пакет работ должен содержать следующую информацию:

• 1) ожидаемые после завершения работ результаты;
• 2) ответственные за выполнение отдельных работ пакета;
• 3) точки пересечения с другими рабочими пакетами или проектами;
• 4) конкретные действия, задания и сроки;
• 5) затрата времени (в часах или днях) для выполнения отдельных работ пакета и заданий;
• 6) расходы на персонал, оборудование, материалы, необходимые для выполнения работ;
• 7) кодовый номер для идентификации пакета работ;
• 8) подпись и данные руководителя, ответственного за выполнение работ пакета и подпись менеджера проекта.

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

• сроки или временные рамки проекта;
• объем выполняемых работ;
• согласованное с заказчиком проекта качество выполнения работ.

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

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

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

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

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

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

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

На основании плана делается несколько документов разного предназначения. Для старших менеджеров организации и внешних стейкхолдеров - инвесторов, кредиторов, заказчиков, поставщиков и др. необходимо сделать выдержки из плана на одной-двух страницах - резюме, которое должно быть привязано к ключевым процессам жизненного цикла проекта. Если информации слишком много для размещения на одной-двух страницах, следует придумать способы ее группирования. Например, определить, что "группа работ № 1" - это первоначальное техзадание на разработку проекта; "группа работ № 2" - строительство нового здания; "группа работ № 4" - монтаж и наладка производственного оборудования; "группа работ № 5" - подготовка персонала; "группа работ № 6" - сдача объекта в эксплуатацию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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