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

Выравнивающие задрежки

0

В Microsoft Project 2010 есть инструмент выравнивающих задержек. С помощью него мы указываем особые виды задержек между задачами – задержку между задачами и задержку назначения ресурса на задачу с целью выравнивания загрузки ресурсов. Многие руководители проектов не знают про этот инструмент и применяют вместо него лаги между задачами. Однако с точки зрения логики проекта – это разные задержки и говорят они о разной природе задержек.

Давайте посмотрим какое определение задержкам дается на сайте Microsoft:

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

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

Пример:

Временной резерв проекта

0

В самом начале проекта тщательно контролируйте наличие буферов и свободный временной резерв (free slack) по задачам и проекту в целом. Вы его всегда сможете проверить на виде Использование задач.

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

Надо понимать алгоритм расчета свободного временного резерва:

  • Свободный временной резерв рассчитывается как количество времени на которое может задержаться задача пока не станет задерживать проект.
  • Общий  временной резерв – это минимальная сумма резервов от данной задачи до конца проекта.
  • При наличии жестких ограничений (Must start on) и при наличии нескольких предшественников с разным лагом по задачам на некритическом пути появляется временной резерв.  В случае если конец задач по времени перекрыл начало следующей задачи то свободный временной резерв будет отрицательным.
  • Для задач критического пути он равен нулю. Даже если вы поставите туда специальные буферные задачи или поставите лаг между задачами. Поэтому следует модифицировать алгоритм расчета временного резерва чтобы делать расчет который соответствует вашей модели.

Пример:

Путь особого внимания

0

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

Common sense подсказывает что мы должны наилучшим образом планировать критический путь проекта. На что следует обратить внимание:

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

Пример схемы SCRUM доски

0

Мне очень нравится схема организации доски для рабочей итерации по SCRUM которая приведена в книге

Сколько реально нужно базовых планов?

0

В Microsoft Project есть возможность сохранить десяток базовых планов. А сколько нужно на практике?

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

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

Применение горизонта планирования в Microsoft Project

0

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

В таком случае мы говорим о Горизонте планирования.

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

При использовании Microsoft Project вы можете несколькими способами определить в плане проекта горизонт планирования:

  • Использовать стандартную колонку (атрибут задачи) Publish (Публиковать)
  • Добавить колонку с указанием входит задача в горизонт планирования или нет

При использовании атрибута Publish (Публиковать) вы получаете возможность определять какие задачи будут опубликованы для исполнителей на проектном сервере а какие нет. Таким образом достигается автоматическое определение какая задача готова для передачи к сведению исполнителям – а какие еще не готовы.

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

Go to Top