Как сделать график в project

Как сделать
Содержание
  1. Создание сетевого графика на рабочем столе Project
  2. Добавление легенды
  3. Автоматическое изменение способа расположения рамок
  4. Изменение способа расположения полей вручную
  5. Изменение стиля линии между полями
  6. Выбор типа отображаемых сведений о задаче
  7. Работа с представлением «Диаграмма Ганта»
  8. В этой статье
  9. Использование списка задач
  10. Использование диаграммы
  11. Увеличивать и уменьшать масштаб
  12. Изменение цветов и добавление текста
  13. Почему отрезки диаграммы Ганта не перемещаются?
  14. Как построить диаграмму Ганта в MS Project
  15. Что такое диаграмма Ганта
  16. Как построить диаграмму Ганта в MS Project
  17. Для кого эта статья
  18. Планирование проекта
  19. 1. Принять решения о способе планирования
  20. 1.1. Планирование от начала
  21. 1.2. Планирование от конца
  22. 2. Избавиться от лишнего и упростить план
  23. 2.1. Примеры задач, от которых можно избавиться
  24. 2.2. Пример излишней детализации
  25. 3. Установить взаимосвязи между задачами
  26. 3.1. Используйте минимум видов связей
  27. 3.2. Не используйте связи с суммарными задачами
  28. 3.3. Используйте Сетевую диаграмму
  29. 4. Оценить длительность задач
  30. 5. Избавиться от распараллеливания задач
  31. 6. Выровнять ресурсы
  32. 7. Исключить жесткую привязку задач к датам
  33. 8. Выявить критический путь
  34. 9. Добавить временные буферы в график
  35. 10. Проанализировать график
  36. 10.1. Сокращение сроков
  37. 10.2. Риски, связанные с графиком
  38. Заключение

Создание сетевого графика на рабочем столе Project

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

Чтобы найти представление «сетевой график», нажмите кнопку просмотр > Сетевая схема.

Добавление легенды

Выберите файл > Печать > Параметры страницы.

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

Автоматическое изменение способа расположения рамок

Выберите вид > Сетевая схема.

Выберите формат > Макет.

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

Изменение способа расположения полей вручную

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

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

Изменение стиля линии между полями

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

Выберите вид > Сетевая схема.

Выберите формат > Макет.

В разделе стиль ссылкивыберите ректилинеар или Прямая. Ректилинеар ссылки выглядят так, как это , и прямые ссылки выглядят так, как это .

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

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

Выберите вид > Сетевая схема.

Выберите формат > стили полей.

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

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

Источник

Работа с представлением «Диаграмма Ганта»

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

представление диаграммы Ганта является наиболее часто используемым представлением в Project. В нем с помощью отрезков диаграммы Ганта представлен список задач проекта, связи между ними и расписание. Представление «Диаграмма Ганта» используется по умолчанию для новых проектов.

Примечание: Чтобы перейти в него, в меню Вид выберите пункт Диаграмма Ганта.

В этой статье

Использование списка задач

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

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

Использование диаграммы

Кроме сетки, в представлении «Диаграмма Ганта» также есть наглядная версия списка задач с отрезками диаграммы Ганта, которые демонстрируют длительность задач проекта на временной шкале. Эта часть представления называется диаграммой. Отрезок диаграммы Ганта начинается с даты начала задачи и заканчивается датой ее окончания. Если задачи связаны друг с другом, отрезки диаграммы Ганта также соединены.

Увеличивать и уменьшать масштаб

Единицы временной шкалы для правой части диаграммы Ганта отображаются в ее верхней части. По умолчанию в Project отображаются две единицы времени. Вы можете отобразить до трех единиц времени и изменить их. Например, чтобы получить общее представление о проекте, можно вывести годы и месяцы, а чтобы узнать точные даты начала и окончания задач, вы можете изменить временную шкалу на недели и дни. Дополнительные сведения о настройке шкалы времени в представлении «Диаграмма Ганта» можно найти в разделе Изменение шкалы времени в представлении проекта.

Изменение цветов и добавление текста

Project предоставляет множество гибкости в том, как отрезки диаграммы Ганта отображаются в представлении диаграммы Ганта.

менять цвет, форму и узор отрезков диаграммы Ганта;

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

добавлять текст к отрезкам диаграммы Ганта;

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

изменять высоту отрезков диаграммы Ганта;

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

Почему отрезки диаграммы Ганта не перемещаются?

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

Щелкните правой кнопкой мыши в области диаграммы Ганта, а затем выберите пункт Сетка.

В поле Изменяемая линия выберите Текущая дата.

В области Обычный измените вид линии сетки с помощью полей Тип и Цвет.

Источник

Как построить диаграмму Ганта в MS Project

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

Что такое диаграмма Ганта

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

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

Читайте также:  Как сделать сухарики в домашних условиях

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

Как построить диаграмму Ганта в MS Project

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

Перед тем как построить диаграмму Ганта в MS Project, добавьте мастера в ленту программы. Откройте меню «Файл», а затем раздел «Параметры». В нем выберите пункт «Настроить ленту». В правой части перед вами откроется список вкладок MS Project, на которые можно добавлять мастера диаграмм. Выберите подходящую и нажмите кнопку «Создать группу».

В левом столбце откройте раздел «Команды не на ленте» и найдите команду «Мастер диаграмм Ганта», она расположена внизу списка. Выделите созданную уже группу и нажмите кнопку «Добавить».

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

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

Источник

Для кого эта статья

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

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

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

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

Если говорить об управлении сроками, то можно сформулировать следующие требования. Хороший график проекта:

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

1. Принять решения о способе планирования

1.1. Планирование от начала

Более привычный для большинства способ. Удобен, если вы знаете начало проекта, но только приблизительно представляете, когда он закончится.

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

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

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

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

Чтобы избежать раннего начала задач и распределить задачи во времени, можно использовать ограничения на задачи типа «Не ранее чем», «Фиксированная дата начала».

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

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

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

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

1.2. Планирование от конца

Если конечная дата проекта жестко определена, то правильнее планировать «от конца». Устанавливается дата окончания проекта, и во всех новых задачах автоматически устанавливается тип ограничения «Как можно позже».

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

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

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

2. Избавиться от лишнего и упростить план

Лишним считается все, что не помогает планировать сроки проекта.

2.1. Примеры задач, от которых можно избавиться

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

Задача «Поддержка». Как правило, это задача, которая начинается после запуска в эксплуатацию и имеет, как правило, фиксированную длительность (по договору), либо привязана к некоторым контрольным точкам. Можно включить ее в план проекта, но минимизировать ее детализацию. Эта задача может быть спокойно заменена в плане на две контрольные точки: Начало эксплуатации и Окончание поддержки.

План, в конечном итоге, нужен чтобы ставить задачи и проверять факт и качество исполнения. Это очень хороший критерий, чтобы определить, с какой степенью детализации его делать. В план должны попадать только те задачи, которые РП собирается ставить и проверять их исполнения. Более мелкие задачи переносятся за пределы плана — в Excel, в JIRA или в связанный план рабочей группы в MS Project.

Читайте также:  Как сделать длинный скриншот андроид

2.2. Пример излишней детализации

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

3. Установить взаимосвязи между задачами

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

Можем дать следующие рекомендации для выстраивания графика.

3.1. Используйте минимум видов связей

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

3.2. Не используйте связи с суммарными задачами

Рассмотрим упрощенный пример проекта, состоящего из двух этапов. Иногда план выглядит так:

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

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

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

3.3. Используйте Сетевую диаграмму

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

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

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

4. Оценить длительность задач

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

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

Задачи не должны включать запас «на всякий случай». Добавление запаса в каждую задачу с целью повысить вероятность выполнения в срок каждой задачи, скажем до 90%, делает график длинным, и при этом вы все равно не уложитесь в срок. Реальность такова, что все опоздания накапливаются, а опережения съедаются. Почему так? Причины могут быть следующие:

Поэтому придерживайтесь следующих правил при планировании работ:

5. Избавиться от распараллеливания задач

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

Очевидно, РП отдает управление последовательностью и приоритетом задач консультантам. Тогда, с точки зрения планирования, достаточно было бы одной задачи «Функциональный блок Контроль», назначенной на Емельянову и Тену. Наличие пяти параллельных задач не имеет смысла. Все ресурсы перегружены, трудоемкость и длительность задачи не оценена, приоритеты не понятны.

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

6. Выровнять ресурсы

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

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

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

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

Например, модифицируем предыдущий пример:

В данном примере считается, что А.Тен участвует в доработке всех документов, и два документа пишет самостоятельно. Мы точно не знаем, как будет построена их совместная работа, но предполагаем в среднем он будет на 30% отвлечен на документы А.Емельянова. Поэтому собственные задачи, где он занят на 70% больше по длительности, и оцениваются в 5 рабочих дней. Кроме того, мы добавили буфер, предполагая, что часть задач могут занять больше времени, чем мы предполагаем.

Было бы более правильно вообще разделить задачи между двумя участниками и избавиться от параллельного выполнения задач А.Теном, но в данном случае это сделать сложно. Поэтому приходится идти на нарушение правил, которые мы сами для себя установили выше. Тем не менее, такой план лучше, т.к. помогает контролировать выполнение задач не в конце 14 рабочих дней, которые мы отвели на проектирования функционального блока «Контроль», а уже через 3 дня после начала работы. Кроме того, это дисциплинирует исполнителя с первого дня, у которого нет 14 дней в запасе, а есть целевой срок 3 дня, когда нужно закончить первый документ.

7. Исключить жесткую привязку задач к датам

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

Читайте также:  Как сделать индигофера алхимия классик

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

8. Выявить критический путь

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

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

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

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

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

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

Такой способ планирования хорошо сочетается с методикой планирования «от конца проекта».

9. Добавить временные буферы в график

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

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

В результате, опоздания всегда накапливаются, а опережения — практически никогда.

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

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

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

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

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

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

10. Проанализировать график

Далее мы переходим к тому, для чего, собственно мы проделывали все предыдущие шаги, непосредственно к работе с графиком.

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

10.1. Сокращение сроков

Посмотрим, нельзя ли сократить этот график. Самые длинные задачи — номер 17 и 21. 18 и 15 дней — слишком длинные задачи для того, чтобы их можно было эффективно контролировать.

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

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

10.2. Риски, связанные с графиком

Интересно посмотреть на график проекта с точки зрения управления рисками. Какие риски может обнаружить график проекта?

Заключение

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

График проекта становится реальным инструментом управления в руках руководителя проекта, если график составлен с умом и следуя определенным стандартам. Владение инструментом и методами позволяет управлять сроками проекта гораздо эффективнее, с меньшими трудозатратами времени.

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

Источник

Adblock
detector