Microsoft Project -управление проектами

XNXX delivers free sex тут.


Риски в расписании

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

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

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

Задачи с предварительными длительностями

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

Главная проблема в планировании таких задач заключается в том, что их длительность не известна заранее, поскольку нет опыта в их выполнении. Поэтому обычно при планировании длительность этих задач остается предварительной (estimated). Такие задачи можно обнаружить в плане проекта с помощью стандартного фильтра Tasks With Estimated Durations (Задачи с оценкой длительности).

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

Слишком короткие задачи

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

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

Чтобы избежать таких сдучаев, нужно проанализировать все задачи плана проекта длительностью меньше одного дня (кроме вех) и все задачи, у которых при анализе PERT ожидаемая длительность совпадала с оптимистичной. Для этого создадим новый фильтр и настроим его (рис. 16.1, файл 1.mpp). (О том, как создавать и настраивать фильтры см. раздел «Создание фильтра».)

Рис. 16.1. Настраиваем фильтр для отбора коротких задач

Фильтр отбирает задачи, у которых длительность меньше либо равна одному Дню или значение настраиваемого поля Durationl (Длительность!) равно значению настраиваемого поля Duration2 (Длительность2). (Эти настраиваемые поля используются при анализе по методу PERT для хранения информации об оптимистической и ожидаемой длительности.) Среди задач, отобранных по одному из этих критериев, фильтр отбирает те задачи, у которых значение поля Milestone (Веха) равно No (Нет), то есть задачи, не являющиеся вехами. Результат применения фильтра в нашем проекте представлен на рис. 16.2 (файл 1.mpp). Коротких задач оказалось только три, из них две Редколлегии, на которые отведено по 3 часа, и Окончательная сборка журнала, на которую отведено 2 дня. Кроме того, оптимистическая и ожидаемая длительности совпали у (разы Редактирование материалов)

Рис. 16.2. Просматриваем короткие задачи с помощью фильтра

После того как короткие задачи отобраны, определим реалистичность отведенного на них времени. В нашем случае 3 часа на редколлегию — это вполне нормально. Два дня на сборку журнала — срок оптимистичный, но учитывая, что работать будут двое, справиться вполне можно. К тому же, они задействованы на 25% (то есть за 2 дня отработают всего 6 часов), значит, если они не будут укладываться в срок, то будет возможность увеличить загрузку и успеть завершить задачу вовремя.

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

Слишком длинные задачи и задачи с большим числом ресурсов

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

Обнаружить в плане задачи с большой длительностью очень просто. Достаточно воспользоваться автофильтром и отфильтровать задачи по столбцу Duration (Длительность), отобрав задачи с длительностью, превышающей, например, 5 пли 10 дней (об использовании автофильтра см. раздел «Автофильтр» ).

Оптимистическая длительность может совпадать с ожидаемой не точцо, а с определенным допущением, например различаться на 1 или 2 часа. Чтобы такие задачи тоже можно было обнаружить, в этом же файле мы создали фильтр Слишком короткие задачи — 2, в котором можно внести это допущение.

А вот автоматически отобрать задачи с большим числом ресурсов нельзя, поскольку в MS Project нет специального столбца «внутренней» таблицы, в котором было бы указано число ресурсов, назначенных на задачу. Поэтому нам, как обычно, придется воспользоваться настраиваемым полем (файл 2.mрр). Переименуем поле задач Number2 (Число2) в Число ресурсов и поместим в него формулу Len ([Resource Names]) (Len ([Названия ресурсов])) (рис. 16.3).

Рис. 16.3. Настраиваем формулу для определения числа ресурсов

Функция Len определяет длину текстовой строки, переданной ей в качестве параметра. В нашем случае этой строкой является значение поля Resource Names (Названия ресурсов). Чем больше ресурсов назначено на задачу, тем длиннее строка и тем больше будет значение поля Число ресурсов.

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

После завершения настройки поля отсортируем задачи по этому полю. Для этого с помощью команды меню Project к Sort > Sort by (Проект > Сортировка > Сортировать по) откроем диалоговое окно сортировки и выберем созданное поле в качестве критерия. Сортировать задачи будем по убыванию, чтобы задачи с наибольшим числом ресурсов оказались в верхней части списка, и сбросим флажок Keep outline structure (Сохранить структуру), чтобы сортировка осуществлялась в рамках всего проекта, а не в рамках отдельных фаз (рис. 16.4, файл 2.mрр).

На рис. 16.5 (файл 2.mрр) задачи в верхней части представления отсортированы по числу ресурсов. В задачах в начале списка задействовано по 4-5 сотрудников, в задачах чуть ниже — по 2-3 человека. В нижней части представления отображена Форма задач (Task Details Form), в которой можно просмотреть детальную информацию о задаче, выбранной в верхней части представления.

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

Рис. 16.4. Сортируем задачи по созданному полю

Рис. 16.5. План проекта после сортировки задач по числу ресурсов

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

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

Например, на рис. 16.8 (файл 4.mрр) мы применили новый фильтр в представлениях Gantt Chart (Диаграмма Ганта) и Network Diagram (Сетевой график) и совместили окна с этими представлениями в одном окне. В верхнем окне в таблице строки с задачами, подсвеченными фильтром, выделены голубым шрифтом (14, 42, 43), а в нижнем цветом выделены блоки, обозначающие задачи (на рисунке виден только блок 14).

Рис. 16.8. Новый фильтр применен в двух разных представлениях

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

Иногда одна из двух задач начинается намного позже другой, и тогда она создает временной резерв другим. Например, на рис. 16.9 (файл 5.mpp) у задачи Верстка обложки две предшественницы, одна из которых, Фотосъемка модели, завершается за неделю до планируемого начала верстки обложки. В этой ситуации риск задержки верстки из-за фотосъемки минимален, потому что у последней есть очень большой временной резерв.

Рис. 16.9. Анализ зависимостей у задачи Верстка обложки

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

Задачи с внешними зависимостями

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

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

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

Чтобы эти задачи можно было определить на формальной основе, при создании списка задач можно добавить настраиваемое поле типа Flag (Флаг) и изменять его значение для задач с внешними зависимостями.

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

Рис. 16.10. Заносим информацию о риске в план проекта

Назад Начало Вперед