Схема проекта – План проекта — как составить, этапы и примеры

7 шагов к успешной реализации

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

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

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

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

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

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

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

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

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

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

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

Почему?

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

Что?

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

Кто?

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

Когда?

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

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

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

1. Общайтесь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подытожим

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

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

spark.ru

Как составить план проекта за восемь простых шагов

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

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

Процесс составления плана проекта может быть непростым, особенно если речь идет о сложных проектах. По данным Forbes, 25% технологических проектов оканчиваются провалом. Но есть и хорошая новость — вам вовсе не обязательно быть крутым специалистом в управлении проектами или жертвовать своими выходными, чтобы спланировать успешный запуск проекта за минимальное время. Чтобы составить план проекта, достаточно восьми простых шагов.

Как составить план проекта за восемь простых шагов…

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

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

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

Вопросы, которые нужно согласовать с ключевыми участниками:

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

Шаг 2. Составьте список целей, согласуйте OKR и наметьте план

По мнению руководителей высшего звена, отсутствие четко поставленных целей становится причиной срыва 37% проектов. Если у вас нет четкой цели, не будет и связи между требованиями, задачами и сроками, указанными в плане проекта. Но на данный момент у вас уже есть список потребностей основных участников, вы заручились их поддержкой, и пора назначать им цели и ключевые результаты (OKR). OKR — это методика планирования и постановки целей, которая стала известной благодаря таким компаниям, как Intel и Google. Ваш проект должен быть согласован с корпоративными OKR и с OKR вашей команды.

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

Шаг 3. Создайте документ с описанием объема работ по проекту

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

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

Хотя подготовка документации об объеме работ по проекту должна быть стандартной процедурой, каждый четвертый менеджер проекта, принявший участие в опросе об управления проектами Wellingstone State, признался, что «никогда» не занимался подготовкой таких документов или составлял их «изредка». Создание такой документации даст вам преимущество и поможет всем участникам проекта быть в курсе событий.

Шаг 4. Составьте подробный календарный план проекта

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

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

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

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

Шаг 5. Определите роли, обязанности и ресурсы

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

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

Когда начнете назначать задачи, обязательно учитывайте возможности сотрудников. Четко определите круг обязанностей и ожидания, которые возлагаете на каждого из них. Не забывайте, что 95% сотрудников работают с более чем одной командой или над несколькими проектами. Если эти проекты не согласованы, рабочая загрузка становится для них чрезмерной. Стресс — именно та причина, по которой 50% сотрудников начинают искать другую работу, а 25% увольняются, как показал наш недавний отчет «Эпидемия стресса».

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

Шаг 6. Определите процессы взаимодействия и проверки

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

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

Шаг 7. Составьте план на случай, если что-то пойдет не по плану

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

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

Шаг 8. А вот теперь можно праздновать запуск проекта!

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

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

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

Прямиком к счастливому финалу

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

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

www.wrike.com

Схема управления проектами — Project

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

Управление проектами — задача не из легких. Кроме того, это руководство поможет вам понять управление проектами при использовании Project. Ниже приведены ссылки на статьи и краткие руководства по соответствующим аспектам управления проектами.

Открытие плана проекта

Чем сложнее проект, тем больше нужно будет спланировать, прежде чем приступить к работе с Project. На начальном этапе проектирования используйте приложения, такие как Word, Excel и SharePoint, чтобы сформулировать свой замысел.

Цель проекта	ОПИСАНИЕ
Создание плана проекта	Без надлежащего предварительного обдумывания на начальном этапе проекты нередко оказываются несостоятельными. При составлении уставных документов, предварительных спецификаций и, возможно, бюджета следует учитывать заинтересованные лица и спонсоров. В случае небольших проектов значительную часть этой работы можно выполнить в Microsoft Project. Для более крупных проектов используйте приложения Word, Excel, SharePoint или даже мобильный телефон, чтобы фиксировать свой ход мысли.
Согласование планов с заинтересованными лицами	Поддерживать коммуникационные каналы с заинтересованными лицами не всегда просто. Но это важно для успеха проекта.
Создание и отправка отчетов по проекту	Для облегчения трудоемкого обмена данными в Project предусмотрен целый ряд отчетов, которые создаются одним щелчком мыши. Записывайте свои первоначальные планы, главные этапы проекта, требования к бюджету, потребности в персонале и т. д.

К началу страницы

Создание календарного плана проекта

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

1. добавление задач;

2. упорядочение задач;

3. добавление людей;

4. обмен данными с рабочей группой.

Цель проекта	ОПИСАНИЕ
Создание календарного плана проекта	Продумав первые этапы проекта, самое время перейти к созданию календарного плана в Project. Вы можете начать с пустого проекта или воспользоваться шаблонами, созданными другими руководителями проектов — специалистами в области управления проектами или деловой сфере, в которой вы работаете.
Добавление задач	Задачи — это действия, которые выполняются в рамках проекта. Узнайте, как добавлять задачи, изменять их свойства и оценивать их длительность.
Упорядочение задач	Добавляемые задачи не всегда с первого раза располагаются в порядке, удобном для управления. Узнайте, как их упорядочить при помощи суммарных задач и подзадач, а также связывания.
Добавление людей и назначение им задач	После добавления задач в проект продумайте, кого вы хотите задействовать для их выполнения. Учтите, что добавление людей и назначение задач в Project — это два разных действия.
Обмен ресурсами с помощью пулов ресурсов и главных проектов	Чтобы облегчить управление человеческими ресурсами в рамках нескольких проектов, разместите их участников в одном файле проекта. Этот файл будет служить пулом ресурсов. С его помощью вы сможете распределять ресурсы среди нескольких проектов (без помощи Project Server).
Определение затрат проекта	Управление затратами по проекту может быть интимидатинг для любого руководителя проекта. В Project вы можете обнаружить, что эта работа не так сложна. Полезные советы, которые помогут вам оставаться на связи с бюджетом.

К началу страницы

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

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

ЦЕЛЬ	ОПИСАНИЕ
Выбор подходящего представления календарного плана	Чтобы лучше ориентироваться в сложном календарном плане, выберите подходящее представление. Диаграмма Ганта — лишь один из вариантов представления хода вашего проекта. Кроме него вы можете воспользоваться представлением календаря, сетевым графиком или шкалой времени, чтобы просмотреть необходимые подробности.
Отслеживание хода выполнения работы	После того как вы создадите первоначальное расписание, пора начать наблюдать за его пределами. Создание базового плана и использование подходящего представления поможет вам отслеживать ход выполнения проекта.
Отслеживание процента завершения задач	Отслеживание хода выполнения может показаться сложным, но вот как быстро отобразить процент завершения с помощью индикатора выполнения на диаграмме Ганта.
Устранение проблем с выделением ресурсов	Чтобы добиться оптимальной производительности и результатов из ресурсы, необходимо управлять рабочими нагрузками ресурсов, чтобы избежать превышения доступности и неполной перегрузки.
Определение даты завершения проекта	Для руководителей проектов нет ничего хуже, чем смещение даты завершения проекта после внесения изменений в календарный план. Ознакомьтесь со стратегиями управления датой завершения проекта.
Отчет о состоянии проекта	Нередко обмен данными становится непростой задачей (особенно когда речь идет о неприятных новостях). Чтобы справиться с ней, вы можете использовать наглядные профессиональные отчеты Project, которые можно создавать и отправлять заинтересованным лицам и исполнителям с помощью нескольких простых действий.
Управление затратами по проекту	Вы вышли за рамки бюджета? Нужно откорректировать затраты? Узнайте, как решать проблемы с затратами в календарном плане.
Просмотр отчетов об анализе освоенного объема	Освоенный объем — это усовершенствованный способ отслеживания. Но он рассчитан не только на профессионалов. Вы также можете использовать его для отслеживания своего проекта.
Управление рисками	В проекте риски встречаются на каждом шагу. Определяйте слабые места заблаговременно и принимайте соответствующие меры, чтобы не дать им превратиться в крупные неприятности.
Работа с несколькими проектами	Project предоставляет инструменты, помогающие управлять межпроектными зависимостями, даже задачами в одном проекте, которые зависят от завершения другого проекта.

К началу страницы

support.office.com

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

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

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

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

На стадии планирования устанавливаются основные параметры осуществления проекта. К ним относятся:

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

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

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

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

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

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

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

Основные процессы (присутствуют всегда):

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

Вспомогательные процессы (присутствуют по мере необходимости):

• Планирование и установление стандартов качества, и определение путей их достижения
• Организационное планирование, включающее в себя определение и распределение функционала, ответственности и норм субординации
• Подбор людей, необходимых для реализации проекта, и формирование команды
• Установление коммуникационных и информационных потребностей членов проекта
• Идентификация, оценка и документирование рисков проекта (установление факторов неопределенности и степени их влияния на проект, определение благоприятных и неблагоприятных сценариев реализации проекта)
• Логистическое планирование (что, когда, где и как закупать и поставлять)

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

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

Принимаемые решения и предпринимаемые действия в сфере проектного планирования основываются на нескольких важных принципах:

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

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

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

Структура разбиения работ, матрица ответственности, статьи затрат

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

Для руководителя проекта СРР не менее важна, т.к. позволяет:

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

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

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

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

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

Составление СРР может выстраиваться на следующих основаниях:

• Этапы жизненного цикла проекта
• Особенности организационной структуры
• Компоненты результата (товара, услуги и т.п.), получаемого после реализации проекта
• Функциональные или процессные элементы деятельности организации, которая реализует проект
• Географическое расположение (если проекты распределены пространственно)

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

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

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

Не менее важно избегать ряда ошибок при структуризации проекта, а именно нельзя:

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

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

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

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

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

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

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

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

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

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

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

• Трудовые ресурсы
• Финансовые средства
• Оборудование
• Техническое оснащение
• Технологии и информация
• Поставщики и материалы

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

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

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

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

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

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

• Ответственные лица
• Структура счетов
• Сроки выполнения
• Содержание работ

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

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

Сетевое планирование проектов

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

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

Есть также тип сетевой диаграммы, называемый сетью типа «вершина-событие», но в практической работе его применяют не так часто. В этом случае работа имеет вид линии, соединяющей два события (узлы графа), отображающие начало и конец определенной работы. Хорошим примером такой диаграммы является PERT-диаграмма – вот она:

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

Методами сетевого планирования называют методы, нацеленные на максимальное сокращение продолжительности проекта. Их основой служат метод критического пути (МКП или CPM (от англ. Critical Path Method)) и метод оценки и пересмотра планов (PERT (от англ. Program Evaluation Review Technique)).

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

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

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

Горизонтальная линейная диаграмма, где проектные задачи представлены временными отрезками с конкретными временными параметрами (началом, окончанием, задержками и т.д.) называется диаграммой Гантта, и она тоже является неотъемлемой частью сетевого планирования. Вот ее пример:

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

Сетевая модель разрабатывается поэтапно:

• Определяются списки проектных работ
• Оцениваются параметры работ
• Устанавливаются зависимости между работами

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

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

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

Чтоб отдельные этапы проекта и весь проект в целом были реализованы своевременно, необходимо также планировать проект по временным параметрам. Рассмотрим этот вопрос подробнее.

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

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

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

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

• Концепция управления проектом по временным параметрам
• Календарное планирование проекта
• Контроль хода проектных работ
• Анализ и урегулирование хода работ
• Закрытие управления проектом

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

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

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

Если говорить о причинах временных потерь в проекте, то к ним можно отнести:

• Ненадлежащее управление качеством и составлением смет
• Отсутствие резервного плана при непредвиденных затратах
• Некачественное распределение рисков среди участников проекта
• Отсутствие структуры в системе коммуникаций
• Трудновыполнимая система проектной отчетности

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

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

или так:

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

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

И последнее, на чем мы заострим внимание в первом уроке, – это некоторые организационные моменты.

Организация работ по проектному планированию

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

Проектное планирование включает в себя несколько этапов:

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

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

• Постановка ошибочных целей
• Использование неполной информации
• Игнорирование прошлого опыта
• Игнорирование вопроса доступности ресурсов
• Недостаток внимания координации участников проекта
• Игнорирование мотивации исполнителей
• Чрезмерное внимание детализации плана
• Составление плана ради плана и игнорирование контроля следования плану

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

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

Проверьте свои знания

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

Кирилл НогалесСергей Крутько

4brain.ru

Блок-схема выбора оптимальной методологии разработки ПО / Habr

Вступление

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

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

Во-вторых, выбрав методологию, не нужно слепо следовать ей. Часто ее необходимо «допилить», адаптировав под свой проект. Что-то можно выкинуть, что-то добавить из других методологий, внести что-то своё. Например, вам никто не мешает использовать такую практику как парное программирование в водопадной модели, если это принесёт вам пользу. На Хабре есть прекрасная статья по адаптации Скрама и Канбана к конкретному проекту, которая хорошо иллюстрирует данный принцип.

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

1. Краткое описание

Модель жизненного цикла – общее описание того, как происходит процесс разработки.

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

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

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

V-Model — придумана в Германии и США, как способ улучшить каскадную модель для применения в государственных проектах. V-Model имеет специфику проектов для гос органов: фиксированные требования, стоимость и время. Отличие в том, что этап анализа и проектирования связан с этапом тестирования. Например, во время анализа требований одновременно изучаются подходы к тестированию, во время проектирования архитектуры системы разрабатываются высокоуровневые планы и сценарии тестирования, во время проектирования компонентов системы изучаются способы тестирования компонентов и их взаимодействия, создаются сценарии тестирования, пишутся утилиты, помогающие в тестировании, инструкции, скрипты и т.д. Всё это помогает лучше понять требования и спроектировать систему. Однако тут, также как и в каскадной модели, нежелательно, чтобы требования менялись во время разработки.

Спиральная модель (Spiral) – ориентирована на проекты, в которых имеются серьёзные риски. Разработка представляется в виде спирали. Каждый виток спирали – итерация. Виток спирали состоит из четырёх этапов: планирование, анализ рисков, разработка, оценивание заказчиком. В конце каждой итерации решается, стоит ли продолжать проект. Характерной чертой является то, что на этапе анализа рисков создаются прототипы, концепты, модели которые призваны разрешить риск на ранней стадии. Чем дальше движение по спирали, тем больше разработки продукта и меньше прототипов и концептов. Типичное применение такой модели – исследовательские проекты. Является очень дорогой моделью, и не оправдана в системах, где риски незначительны.

Итеративная модель – ориентирована на проекты, где требования могут меняться по ходу разработки. Проект состоит из итераций (от 1-2 до 6 недель). Каждая итерация может включать в себя этап анализа, проектирования, реализации, тестирования. Имеет большие накладные расходы на организацию процесса, чем каскадная модель, однако стоимость исправления ошибки в зависимости от длительности проекта не так высока. Следующие методологии реализуют итеративную модель: Scrum, XP, отчасти Kanban.

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

Методология экстремального программирования (XP) – состоит из 12 практик: парное программирование, разработка через тестирование, рефакторинг, простая архитектура, коллективное владение кодом, непрерывная интеграция, заказчик в команде, частые релизы, игра в планирование, 40-часовая рабочая неделя, стандарты кодирования, метафора системы. Обязательно использование всех 12 практик.

Методология Канбан (Kanban) – конвейер задач. Имеет всего 3 правила: визуализация процесса разработки с помощью канбан-доски, ограничение на количество задач на каждом этапе, постоянное измерение производительности команды и улучшения.

Методология RAD (Rapid Application Development) – ориентирована на быструю разработку приложения, итеративно, с максимально простой архитектурой, минимальными издержками на процесс, максимально используя готовые компоненты и мощные инструменты. Имеет ограничение на длительность проекта — 60-90 дней. Мне нравится аналогия с пирожками из полуфабрикатов. Так вот, RAD – когда нужно быстро слепить пирожок из готовых компонентов.

2. Разбор блок-схемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если же вам нужна максимальная продуктивность, то также есть варианты. Скрам ориентирован на постоянное усовершенствование процесса. Для этого у него есть митинг ретроспективы, которые проводятся в конце спринта. Также во время обзора спринта обсуждается, что было сделано хорошо, что плохо и что улучшить. Если у вас опытная команда, хорошо отлаженный процесс и вам в принципе не нужны совершенствования, то следование методологии Скрам будет отнимать у вас слишком много времени, которое вы могли бы потратить с большей пользой. Например, по Скраму, если спринт длится 1 месяц, то обзор спринта должен занимать 4 часа и ретроспектива спринта – 3 часа. Плюс к этому есть планирование спринта, длящееся 8 часов и ежедневные Скрам митинги по 15 минут.

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

Если совершенствования не нужны и всё, что нужно, это сконцентрироваться на выполнении задач, то хорошо подойдёт RAD или Kanban. RAD имеет много общего с agile методологиями, но в нём есть существенное ограничение на длительность проекта. Желательно не более 60-90 дней. Канбан похож на некий беспрерывный конвейер, который может длиться бесконечно. Он хорошо работает на проектах поддержки, но плохо там, где требуется разработать сложную архитектуру, т.к. ориентирован на быстрое добавление фич в приложение. Под фичами имеется в виду кусок функциональности, который виден пользователю и непосредственно решает какую-либо его задачу. Например, логирование, оптимизация и масштабируемость пользователю не видны, это не фичи в терминологии Канбан. А вот новая страница, отчёт, дополнительные фильтры в поиске— это то, что видно пользователю и является фичей.

Источники:

1. Dr. Winston, W. Royce. Managing development of large software systems. 1970. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
2. W Boehm, A spiral model of software development and enhancement. 1986. http://csse.usc.edu//TECHRPTS/1988/usccse88-500/usccse88-500.pdf
3. W Boehm. Spiral Development: Experience, Principles, and Refinements. 2000. http://www.sei.cmu.edu/reports/00sr008.pdf
4. С. Белоусова, И. Бессонова, Руджеро Гиляревский. Введение в программные системы и их разработку. НИУ ВШЭ. http://www.intuit.ru/studies/courses/3632/874/info
5. К. Швабер, Д. Сазерленд.Скрам Гайд. Исчерпывающее руководство по Скраму: Правила игры.
http://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-RUS.pdf#zoom=100
6. Rational Unified Process. Best Practices for Software. Development Teams. http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
Introduction to OpenUP. http://epf.eclipse.org/wikis/openup/
7. Х. Книберг, М. Скарин. Scrum и Kanban: Выжимаем максимум. InfoQ. 2010
8. К. Ауэр, Р. Миллер. Экстремальное программирование. Постановка процессов. – СПб.: Питер: 2004
9. Экстремальное программирование – реальность и мифы. skipy.ru/philosophy/xp.html
10. M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. APress, USA, 2003
11. James Christie. The seductive and dangerous V Model.
http://www.clarotesting.com/page11.htm
12. Adel Alshamrani. A Comparison Between Three SDLC Models Waterfall Model, Spiral Model, and Incremental/Iterative Model. http://www.academia.edu/10793943/A_Comparison_Between_Three_SDLC_Models_Waterfall_Model_Spiral_Model_and_Incremental_Iterative_Model

habr.com

Идеальный план управления проектами от пяти экспертов

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

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

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

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

• Концепция: ответы на все «что?» и «почему?», краткая информация о замысле, целях и конечных результатах проекта. 

• Стратегия реализации: ответы на все «как?», касающиеся проекта. Какую методику вы будете использовать? Результат будет выдан за один раз или в несколько этапов? 

• Объем работ: что входит (и не входит) в ваш проект? Опишите здесь иерархическую структуру работ и основные результаты. 

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

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

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

Источник изображения: racichart.org

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

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

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

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

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

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

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

Как отмечает Харрин, «Чересчур подробный план не сделает вас более умным или организованным. Чем он длиннее, тем больше шансов, что никто, кроме вас, не сможет дочитать его до конца». Простой план проекта, которому удобно следовать, — это наилучший вариант. 

Начните с ТЗ

Как говорит Брэд Игленд, опытный руководитель ИТ-проектов, автор и консультант, основа успешного плана проекта — это техническое задание (ТЗ). Почему? Потому что оно помогает прийти к согласию в начале работы. Позже, когда возникнут новые требования и объемы проекта начнут расширяться, можно будет вернуться к ТЗ и проверить, для чего изначально задумывался этот проект. 

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

Установите таймер

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

 

 

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

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

• Этап 3: цели и результаты. Запишите цель проекта, затем определите, какими должны быть его результаты. Проверьте, все ли правильно, задав вопрос: «Если мы проделаем все, что указано на этапе 2, достигнем ли мы наших целей?»

• Этап 4: возможные альтернативы. Какие есть альтернативные пути, которые приведут вас к тем же результатам? Есть ли более эффективный способ достичь своих целей? 

• Этап 5: экономика и препятствия. Какова стратегия финансирования проекта? Насколько он важен в сравнении с другими проектами? Какие ресурсы вам потребуются? С какими препятствиями вы столкнетесь? 

• Этап 6: план наступления. Изучите список единиц работы и определите, что следует сделать сначала. Поставьте у этого пункта букву A. Таким же образом расставьте Б, В и т. д. Затем выясните, что можно сделать одновременно с пунктами A, Б и т. д. Так вы составите график работ по проекту. 

• Этап 7: допущения и риски. Какие трудности могут встретиться при выполнении каждой задачи? Как можно сократить риски или найти обходные пути? 

• Этап 8: основные показатели успеха. Определите 3-4 самых главных заинтересованных участника и спросите: «Какой результат скорее всего их удовлетворит?» Это и будут показатели успешности проекта. Решите, как измерить каждый из них по завершении проекта. 

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

Не увлекайтесь планированием

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

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

Варгас использует обобщенную версию руководства по планированию из PMBoK. Узнать больше о каждом аспекте его процесса планирования вы можете в его блоге. 

Не усложняйте

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

• Зачем? Каковы основные преимущества реализации этого проекта для бизнеса? 

• Что? Что входит в объем работ по проекту? 

• Кто? Каковы основные роли, требующиеся для выполнения пункта «Что»?

• Когда? Когда необходимо выполнить пункт «Что», чтобы получить «Зачем»?

• Где? Где лучше всего выполнять работу? Где «Что» может быть использовано клиентами и конечными пользователями? 

Только после того, как вы закончите отвечать на эти вопросы, можно переходить к ответам на вопрос «Как?».

Лучшие методики планирования управления проектами

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

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

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

Wrike — система планирования управления проектами, которой пользуются 14000 компаний во всем мире. Попробуйте, чтобы улучшить планирование!

www.wrike.com

Презентация на тему: Структура проекта

1.5. Структуры проекта

Структура проекта (Project Structure) – состав элементов проекта и связи между ними.

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

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

1. Совокупность элементов каждого уровня иерархии
декомпозиции проекта должна представлять весь проект.
Уровни декомпозиции различаются между собой степенью
детализации;
2. Исходя из первого правила суммарное значение характеристик
проекта (объемы работ, стоимость, потребляемые ресурсы,
количество исполнителей и др.) на каждом уровне структуры
проекта должны совпадать;
3. Нижний уровень декомпозиции проекта должен содержать
такие элементы работ, на основе которых могут быть
определены количественные значения характеристик работ,
необходимые и достаточные для оперативного управления
проектом.
На основе детальных данных проекта могут быть получены
агрегированные данные для любого уровня структуры
проекта.	2

Структура проекта

Структура — это прежде всего связи, а потом уже состав проекта

Количество уровней структурной модели проекта составляет не более 8

Общая схема структуры проекта

Нижний уровень детализации в иерархии проекта назвается Work Breakdown Structure (WBS)

Тема 1. Управление проектами

4 4

Типы структурных моделей проекта

Тема 1. Управление проектами

5 5

Типы структурных моделей проекта

1.Модель, удовлетворяющая условиям иерархичности, ранжированию и ресурсам, называется деревом целей

2.Структурная схема организации проекта называется

организационное дерево

3.На основе структурной модели проекта и «организационного дерева» строится матрица распределения ответственности

4.На основе структурной модели проекта, дерева целей, организационного дерева и матрицы распределения ответственности строится сетевая модель проекта

5.На основании структуры проекта и данных о стоимости элементов проекта строится дерево стоимости

6.Структурная схема материально-технического обеспечения проекта называется деревом ресурсов

проекта

7.Совокупность вероятностей наступления негативных

событий при реализации проекта описывается деревом		6 6
рисков	Тема 1. Управление проектами

Дерево целей

1.Иерархическая структура, отвечающая следующим требованиям:

Организационное дерево

2. Структурная схема организации проекта называется организационное дерево

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

3.На основе структурной модели проекта и «организационного дерева» строится матрица распределения ответственности

Я — единоличное решение; ! – персональная ответственность; Р – участие в коллегиальном решении без права подписи; П – планирование; О – организация; К – контроль; Т – исполнительство.

Сетевая модель проекта

4.На основе структурной модели проекта, дерева целей, организационного дерева и матрицы распределения ответственности строится сетевая модель проекта

studfiles.net