Самоучитель по Microsoft Project - часть 26

 

  Главная      Учебники - Разные     Самоучитель по Microsoft Project

 

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

 

 

 

 

 

 

 

 

содержание   ..  24  25  26  27   ..

 

 

Самоучитель по Microsoft Project - часть 26

 

 

 

Рис. 15.7. Результат выполнения анализа по методике PERT

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

воспользоваться тремя кнопками на панели анализа по методу PERT (см. рис. 

15.3). Первой слева расположена кнопка Optimistic Gantt (Диаграмма Ганта — 

оптимистическая оценка), затем Expected Gantt (Диаграмма Ганта — ожидаемая 

оценка) и третьей — Pessimistic Gantt (Диаграмма Ганта — пессимистическая 

оценка).

ПРИМЕЧАНИЕ 

Если вы еще в начале планирования проекта знаете, что будете пользоваться 

анализом PERT для расчета длительностей задач, то стоит применить его уже 

на этапе, составления плана работ.

На рис. 15.8 (файл S.mpp) мы воспользовались этими кнопками и открыли два 

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

проекта, а в нижнее — с пессимистичным. В таком режиме удобно 

просматривать различия между вариантами плана проекта. Как видно в нижнем 

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

сроки.

ВНИМАНИЕ  

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

результате анализа PERT. Следует иметь это в виду при анализе 

оптимистического и пессимистического плана.

Уточнив длительности задач, вернемся к диаграмме Ганта и посмотрим, 

успеваем ли мы выполнить весь объем работы в установленные сроки. Если 

окажется, что в результате уточнения длительностей задач длительность 

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

уложиться в срок.

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

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

индикаторов крайних сроков, которые мы ввели, когда создавали план работ 

(см. раздел

 «Крайние сроки»

). На рис. 15.9 (файл 5.mpp) видно, что задача 

Вывод пленок заканчивается позже крайнего срока, а значит, проект не 

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

сроки или завершающие задачи, оценить длительность проекта можно по 

значению столбца Duration (Длительность) в строке суммарной задачи проекта 

(см. раздел 

«Суммарная задача проекта»

).

Если план не укладывается в срок, длительность проекта нужно уменьшить. 

Для этого нужно сократить длительность его задач или удалить некоторые из 

них.

Но длительность каких именно задач нужно сокращать? Чтобы ответить на этот 

вопрос, нужно определить, от каких задач зависит длительность проекта. А для 

этого можно воспользоваться анализом плана проекта методом критического 

пути (СРМ).

Рис. 15.8. Сравнение оптимистичного и пессимистичного сценариев

Рис. 15.9. После изменения длительноотей задач нарушаются крайние сроки 

проекта

Анализ критического пути проекта

Critical Path (Критический путь) — это задача или последовательность задач, 

определяющая дату окончания проекта. Если увеличить длительность задачи, 

лежащей на критическом пути, то длительность проекта тоже увеличится, а 

если уменьшить ее длительность, то длительность проекта тоже уменьшится.

ПРИМЕЧАНИЕ  

MS Project «умеет» определять время, на которое можно задержать исполнение 

задачи без увеличения длительности проекта. Эта длительность хранится в 

поле Total Slack (Общий временной резерв), и если она меньше или равна нулю 

дней, то задача считается критической. Но в некоторых проектах критическими 

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

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

задач, нужно с помощью команды меню Tools > Options (Сервис > Параметры) 

открыть диалоговое окно настройки параметров MS Project, перейти на вкладку 

Calculation (Расчеты) и указать нужное значение параметра Tasks are criticalis 

slack is less or equal to ... days (Считать критическими задачи, имеющие резерв 

не более ... дней).

MS Project также относит к критическим задачи, имеющие ограничения типа 

Must Start On (Фиксированное начало), Must Finish On (Фиксированное 

окончание), As Late As Possible (Как можно позже) в планируемых от даты 

начала проектах и As Soon As Possible (Как можно раньше) в проектах, 

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

дата окончания которых превышает дату крайнего срока или совпадает с ней.

Для отображения критического пути проекта на диаграмме Ганта нужно 

воспользоваться мастером Gantt Chart Wizard (Мастер диаграмм Ганта), 

вызываемым одноименной командой в меню Format (Формат) или контекстном 

меню диаграммы Гаита. На втором шаге мастера (рис. 15.10) нужно выбрать 

переключатель Critical Path (Критический путь) и нажать кнопку Finish (Готово).

 

Рис. 15.10. Отображаем критический путь на диаграмме Ганта

После этого диаграмма Ганта перестроится, а задачи, лежащие на критическом 

пути (критические задачи), и связи между ними будут выделены красным 

цветом (рис. 15.11, файл б.mрр). Теперь можно переходить к уменьшению 

длительностей задач, причем начать стоит с тех, что лежат на критическом 

пути. При этом следует помнить, что сокращение длительности задач может не 

только убрать их с критического пути, но и сделать критическими другие 

задачи.

СОВЕТ 

Чтобы оставить на диаграмме Ганта только критические задачи, нужно 

воспользоваться фильтром Critical (Критические).

Рис. 15.11. Так выглядит наш план после форматирования диаграммы с 

помощью мастера и применения фильтра для отбора только критических задач

Для сокращения длительности задачи можно применить несколько методов: во-

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

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

сохранении ее объема. Наконец, можно разбить задачу на подзадачи, 

выполняемые одновременно разными сотрудниками.

В нашем случае мы сократили длительность двух задач: Подготовка 

редакционных заданий и Утверждение заданий авторами. Длительность первой 

задачи мы сократили незначительно, а второй — в два раза (с 4 до 2 дней), 

поскольку .на скорость ее выполнения можно повлиять административными 

мерами.

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

сроки. И тогда мы разбили задачу Редактирование материалов на 3 подзадачи: 

Редактирование раздела 1, 2 и 3 и спланировали их одновременное 

исполнение. Это возможно потому, что журнал состоит из трех разделов, и 

каждый из редакторов разделов отвечает за свой раздел и осуществляет 

редактирование материалов в нем независимо от других. Длительность каждой 

задачи была установлена равной 10 дням, а загрузка ресурсов определена в 

70% с ранним пиком в профиле загрузки. В результате бывшая задача и 

нынешняя фаза Редактирование материалов перестала быть критической (рис. 

15.12, файл 7.mрр).

 

Рис. 15.12. Критический путь проекта после редактирования

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

Но прежде чем переходить к анализу и оптимизации стоимости проекта, нужно 

проверить, не возникло ли перегрузок ресурсов после изменений в плане. Это 

возможно, например, у задач с фиксированным объемом работ, поскольку 

уменьшение длительности таких задач приводит к увеличению объема работы, 

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

В нашем случае превышение доступности снова возникло у Иванова, Петрова, 

Сидорова и Галкиной (7.mрр) — наиболее активно задействованных в проекте 

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

учитывать трудозатраты и сверхурочную работу. Приемы выравнивания 

ресурсов вам уже известны, а в нашем случае мы использовали только 

перераспределение загрузки (файл 8.mpp). Теперь, когда план работ и 

загрузка ресурсов нас устраивают, можно переходить к анализу и оптимизации 

стоимости проекта.

Анализ и оптимизация стоимости проекта

При анализе стоимости проекта обычно оценивается его бюджет (суммарные 

затраты на проект) и соотношение составляющих бюджета. Если общая 

стоимость проекта превышает ожидания или затраты на какую-то из 

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

бюджет не сбалансирован), то стоимость оптимизируется.

Анализ стоимости проекта

Чтобы оценить общую стоимость проекта, достаточно перейти в таблицу Cost 

(Затраты) в любом из представлений со списком задач и просмотреть данные в 

столбце Total Cost (Общие затраты) у суммарной задачи проекта. На рис. 15.13 

отображен фрагмент этой таблицы из нашего проекта (файл 9.mрр), и его 

общая стоимость равняется $1543.

Рис. 15.13. Определение общей стоимости проекта

Помимо выяснения общей стоимости часто требуется проанализировать 

пропорциональное соотношение затрат внутри бюджета. Как правило, в каждой 

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

распределены затраты. Например, может существовать требование, чтобы 

стоимость сверхурочной работы не превышала 5% от общей стоимости проекта 

или чтобы затраты на тестирование программного продукта не превышали 10% 

от общей стоимости проекта и т. д.

В общем случае при анализе структуры затрат рассматриваются:

●     

распределение затрат по фазам проекта (например, проектирование, 

разработка, тестирование);

●     

распределение затрат по типам работ (например, соотношение затрат на 

управление с общей стоимостью проекта);

●     

соотношение между затратами на сверхурочные трудозатраты и обычные;

●     

распределение затрат на ресурсы разных типов (например, какая часть 

бюджета проекта уйдет в один отдел организации, а какая — в другой).

При анализе стоимости могут учитываться как все соотношения, так и лишь 

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

проекта с помощью MS Project.

Распределение затрат по фазам проекта

Для определения соотношения затрат между фазами проекта воспользуемся 

настраиваемыми полями и формулами. Нам понадобится два поля, первое из 

которых, Cost2 (Затраты2), мы переименуем в Общая стоимость, а второе, 

Numberl (Число!), переименуем в % от общей стоимости. Во все строки первого 

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

второе поместим формулу [Cost]/[Cost2] ([Затраты]/[3атраты2]), причем в 

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

нужно использовать ту же формулу. После добавления созданных столбцов в 

таблицу она будет выглядеть, как показано на рис. 15.14 (файл 9.mрр). (Чтобы 

быстро заполнить весь столбец данными, нужно вставить стоимость проекта в 

первую ячейку и затем потянуть вниз за квадрат в углу ячейки (аналогично 

тому, как это делается в Excel)). 

 

Рис. 15.14. Анализируем распределение затрат по фазам проекта

На рис. 15.14 видно, как распределены затраты на подготовку номера: на 

планирование и верстку уходит по 10% бюджета, на подготовку материалов 

28% и на предпечатную подготовку 52%.

Распределение затрат по типам работ

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

Например, в нашем проекте на фазе Верстка журнала некоторые задачи 

относятся к корректированию текстов, а не к верстке. Такие ситуации довольно 

часты, и поэтому анализ распределения затрат по фазам обычно дополняют 

анализом распределения затрат по типам работ.

Чтобы провести такой анализ, нужно создать поле, в которое будет заноситься 

информация о типе работы, и определить его значение для каждой из задач 

проекта. В нашем случае (файл 10.mрр) мы переименовали настраиваемый код 

структуры Outline Code! (Код структуры!) в Код работ и создали таблицу 

подстановки к нему (о том, как работать с настраиваемыми кодами структур, 

см. раздел 

«Настраиваемые коды структуры»

). Мы использовали 

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

возможность в дальнейшем более детально описать типы работ.

Мы добавили это поле в таблицу Cost (Затраты) и заполнили его данными для 

всех задач, кроме завершающих (рис. 15.15), поскольку их стоимость равна 

нулю (файл 10.mрр). Теперь перейдем к настройкам поля Number! (Число!) и в 

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

переключатель Rollup (Сведение), а в раскрывающемся списке выберем 

значение Sum (Сумма). Теперь сгруппируем данные (о группировке см. раздел 

«Группировка»

по полю Outline Codel (Код структуры!) и уберем ненужные 

столбцы (рис. 15.16, файл 11.mpp). Первыми идут задачи, у которых не 

определен код, и их стоимость равна SO (кодом не отмечены завершающие 

задачи). Затем в списке представлены другие типы задач и затраты на них, 

причем в таком виде структура затрат представлена более детально, чем в 

предыдущем примере с фазами. 

Как вы видите, стоимость задач типа Написание статей авторами равна нулю, 

хотя затраты на это должны быть учтены в плане проекта. Очевидно, при 

составлении плана стоимость задач не была внесена в план. Поэтому обновим 

план: откроем новое окно и в нем введем информацию о стоимости 

соответствующих задач и 

обновим настраиваемое поле Cost2 (Затраты2). Когда мы вернемся к нашему 

отчету, то увидим, что он изменился (рис. 15.17, файл 12.mрр).

Рис. 15.15. Заполняем настраиваемый код структуры для задач проекта

Рис. 15.16. Затраты на выполнение задач разных типов

Рис. 15.17. После ввода информации о стоимости некоторых задач соотношение 

затрат изменилось

Как видно из этого примера, анализ плана проекта нужен еще и для поиска 

возможных ошибок и несоответствий. Поскольку анализ является 

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

рассмотрено, тем выше вероятность выявить ошибку.

Затраты на обычные и сверхурочные трудозатраты

Для определения стоимости сверхурочных работ добавим в таблицу колонку 

Overtime Cost (Затраты на сверхурочные) и просмотрим ее значения в строке 

суммарной задачи проекта. В файле IS.mpp это значение будет равно нулю, 

хотя мы вводили в план данные о сверхурочных трудозатратах (см. раздел 

«Перенос трудозатрат в сверхурочные» урока 14). Чтобы проверить, что 

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

Overtime Work (Сверхурочные трудозатраты). Как видно на рис. 15.18 (файл IS.

mpp), сверхурочные трудозатраты в плане проекта присутствуют, но их 

стоимость при этом равна нулю. 

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

том, что у ресурса не определена ставка за сверхурочные трудозатраты. И 

действительно, у Буркова эта ставка не определена. Но мало того, в 

представлении Resource Sheet (Лист ресурсов) обнаруживается, что у 

значительной части ресурсов в процессе составления плана проекта была 

утрачена информация о стоимости! Как видите, от анализа план проекта 

существенно выигрывает, ведь благодаря ему мы нашли уже несколько 

серьезных ошибок.

Восстановим информацию о стоимости, скопировав данные одного из 

предыдущих файлов в уроке 14, и снова проанализируем суммарные затраты 

проекта и Их структуру (рис. 15.19, файл 14.mрр).

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

ресурсов

После ввода информации о стоимости ресурсов стоимость проекта существенно 

возросла. Кроме того, изменилось соотношение по стоимости между фазами 

(для удобства восприятия мы добавили в формулу умножение результата на 

100, чтобы в столбце отображалось число процентов).

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

суммарной информации о проекте. В нашем случае они составляют 

незначительную часть от общих затрат на проект, поскольку в качестве ставок 

мы указываем месячную зарплату ресурсов. Однако часто затраты на 

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

случаях требуется определить точно, какой процент от бюджета они 

составляют.

Для этого нужно отредактировать формулу в поле Numberl (Число!), причем эта 

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

поля Cost (Затраты) не равно нулю, поскольку деление на 0 приведет к 

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

выполнение операций по условию.

Формат этого оператора таков: lif (условие; если истина; если ложь)

В скобках сначала указывается условие, затем через точку с запятой 

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

выполнения условия и если условие не выполняется. 

Наша формула представлена на рис. 15.20. Условием оператора является [Cost]

<>0 ([Затраты]<>0), причем условие взято в скобки. Если это соблюдено и 

стоимость задачи не нулевая, то программа заполнит поле, разделив затраты 

на сверхурочные на стоимость задачи и умножив полученный результат на 100. 

Это действие выражено формулой ([Overtime Cost]/[Cost])*100 (([Затраты на 

сверхурочные]/[3атраты])*100). Если же стоимость задачи нулевая, то в поле 

будет помещен 0. Для того чтобы поместить в ячейку 0 или любое другое 

 

 

 

 

 

 

 

содержание   ..  24  25  26  27   ..