В этой статье вы найдете примеры решения управленческих задач с помощью Microsoft Project 2010 и более старшей версии. Будем идти от простого к сложному.
/update поправил картинки/
Наша компания регулярно проводит курсы и тренинги по управлению проектами. Следите за нашим .
1. Как учесть отпуск сотрудника в проекте?
Летний период регулярно подбрасывает руководителю проекта ситуацию, когда сотрудник внезапно выбывает из проекта. Как правильно это отразить в расписании проекта?
Отличное решение – использовать Календарь сотрудника .
1. Перейдите в Лист ресурсов
2. Откройте свойства ресурса и перейдите в раздел “Изменить рабочее время
”
3. Теперь вы можете указать, в какой период времени ваш сотрудник будет недоступен и почему.
Аналогично можно отразить командировки, болезни или другие причины отсутствия.
Должен вас предупредить, что сроки и работы однозначно “поедут” и вам придется вносить коррективы в оставшиеся работы.
PS. Если вы используете “взрослую версию”, то функция “Изменить рабочее время ” вам будет недоступна. Поэтому откройте Календарь сотрудника непосредственно из сервера проектов.
2. Как быстро заменить работы “выбывшего” сотрудника на другого члена команды?
Пусть сотрудник заболел (с кем не бывает), но что же делать с оставшимися работами в проекте? Как правильно заменить все назначения данного ресурса на другого?
В решении этого вопроса вам поможет форма “Назначение ресурсов “, “горячее” сочетание клавиш Alt+F10 .
1. Перейдите в представление “Диаграмму Ганта
”
2. Любым удобным для вас способом отфильтруете все задачи, в которых назначен заболевший сотрудник
3. Выделите все задачи и вызовите форму “Назначение ресурсов
” или нажмите Alt+F10
.
4. Выберите сотрудника к замене. Нажмите “заменить” и укажите на кого именно.
2.1 Фильтр нужного сотрудника
Форма “Назначение ресурсов ” – лучший способ массовой замены назначений в расписании. Также несомненное преимущество данного метода в возможности заменить ресурс в уже исполняющейся задаче.
2.2 Форма Назначение ресурсов
Замена сотрудника в проекте MS Project
3.Трюки в Microsoft Project. Как быстро найти отстающие задачи?
Руководитель проекта редко просматривает все задачи своего проекта. Чаще всего внимание менеджера вызывают только опаздывающие задачи. Какой способ вывести только запаздывающие задачи подойдет лучше?
Способов много, но мне на первое место я поставлю использование фильтра “Задачи с задержкой” . Этот фильтр выводит задачи, которые отстают от графика (либо их состояние не актуализировано).
3.1 Задачи с задержкой
Способ другой. Гурманы MS Project используют более сложное действие: выводят поле “Отклонение окончания ” и фильтруют отстающие задачи по нему.
Также в дополнение к способу 2 я использую фильтр “Диапазон дат “, который показывает только нужное мне “временное окно” (как правило от текущей пятницы плюс 2 недели).
Должен предупредить: использование всех предложенных методов требует сохраненного “базового плана” . Не знаете что такое “базовый план ” или не совсем понимаете как он работает? Дочитайте статью до конца.
4. Как правильно выровнять ресурсы в Microsoft Project?
Выравнивание ресурсов
– сложный управленческий алгоритм из 5 шагов, в котором только 4 и 5 шаги выполняются в Microsoft Project. Процедуру выравнивания ресурсов я подробно объясняю в ходе онлайн . Или получите на вашем предприятии.
Порядок действий в Microsoft Project:
1. Добавьте в представление “Диаграмма Ганта
“: поля “Приоритет
” и “” (на скриншоте название поля сокращено для удобства).
2. Заполните поле “Приоритет
“.
3. Для задач с приоритетом 100 установите признак “Допускается прерывание при выравнивании “.
Вот такая у вас должна быть “картинка”:
4.1 Выравнивание ресурсов (исходное положение)
Теперь можете приступить к выравниванию задач с помощью автоматического алгоритма.
Не получилось? Очень вероятно. Повторю: выравнивание ресурсов – алгоритм из 5 шагов, в котором только 4 и 5 шаги требуют использования MS Project. Как узнать “полный алгоритм”? Дочитайте статью до конца.
4.2 Выравнивание ресурсов (положение после выравнивания)
4.3 Выравнивание ресурсов (Планировщик работы группы после выравнивания)
5. Трюки в Microsoft Project. Как определить сотрудников, пожирающих общий резерв трудозатрат? Метод для продвинутых менеджеров.
Данный метод предназначен для опытных и продвинутых менеджеров, которые хотят оптимизировать рабочее время своих сотрудников на проекте, найти источники потерь.
Представьте, что в вашем проекте есть утвержденная сумма трудозатрат, например 1400 человеко-часов. Команда знает, что оценка каждой операции всегда есть сумма двух слогаемых: время на выполнение задачи и резерв на неизвестное (т.н. “сержантский запас”).
Команда договорилась, что весь график работ будет составлен по оптимистическому сценарию, т.е. без учета резервов на неизвестное. “А где же сержантский запас?”, – спросите вы. Все резервы команда объединяет в общий резерв и вставляет его на критический путь проекта, подпитывая контрольную веху. Смотрите скриншот.
5.1 Использование общего резерва
Команда приступает к операциям и начинает измерять фактически затраченное время. Если задача занимает времени больше, чем предполагал оптимистический сценарий, то дефицит пополняется за счет общего резерва. В ситуации, когда задача заняла меньше времени, чем было спланировано, то излишек пополняет общий резерв.
С помощью цветовых индикаторов в Microsoft Project можно выделить сотрудников, чья работа ведет к “пожиранию” резерва. Пристальное внимание, обучение, необходимость двойного контроля – возможные способы устранения потерь.
Преимущества метода:
- команда дает оценки в двух составляющих (оптимистический сценарий и резерв)
- контрольная веха проекта максимально защищена от сдвига
- можно оценить степень риска проекта на дату (посчитать остаток резерва и разделить его на плановую сумму резерва).
Желаю вам удачи!
В этой статье я рассказал о том, какие трюки в MS Project вы можете самостоятельно использовать.
Компания “ ” – профессиональное вашими , интересное , на вашем предприятии.
5.1. Общие понятия
Под ресурсами в проекте понимают рабочую силу, технику (Компьютеры, и другое оборудование), материалы и деньги. Это разновидные товары, необходимые для исполнения работ, что есть обязательным условием исполнения какого-либо проекта.
Очень важным является составление и оценка потребностей в ресурсах, сроков их получения и обеспечения полного и эффективного использования. Необходимо, прежде всего, решить проблему исполнения работ по проекту с необходимым уровнем качества, используя минимально возможное время, ресурсы и деньги.
5.2. Виды ресурсов, допустимых для планирования в MS Project
После того как определен состав задач проекта, нужно определить, кто эти задачи будет исполнять и какое оборудование будет использоваться . Для этого нужно ввести в план проекта список ресурсов и информацию о них, а затем распределить эти ресурсы между задачами.
Как же добавлять ресурсы в проект, планировать и определять степень их возможного участия в проекте?
Планирование ресурсов начинается с определения состава ресурсов, то есть составления списка людей и оборудования, необходимого для выполнения проектных работ. Работа со списком ресурсов осуществляется в представлении Resource Sheet (Лист ресурсов), и наиболее удобной для ввода данных является таблица Entry (Ввод).
Например:
Для добавления нового ресурса в список нужно установить курсор в поле Resource Name (Название ресурса) и ввести его название. Затем в поле Туре (Тип) нужно выбрать один из двух пунктов раскрывающегося списка: Work (Трудовой) или Material (Материальный). Первый вариант нужно выбрать, если ресурс -- сотрудник, а второй -- если оборудование. До тех пор пока не установлено значение этого поля, другие поля таблицы редактировать не удастся, а после того как значение выбрано, многие поля заполняются стандартными значениями. В моем случае это будет трудовой ресурс.
Чтобы определить равномерность загрузки ресурсов, нужно открыть представление Resource Sheet (Лист ресурсов). В нем все ресурсы, загрузка которых превышает их доступность, выделены красным цветом, а в колонке Indicators (Индикаторы) рядом с их названиями отображается специальный значок.
Обычно, необходимые проекту ресурсы известны заранее, только если в организации накоплен большой опыт выполнения аналогичных проектов. Если же такого опыта нет, то определить ресурсы можно в процессе создания назначений.
После того как назначения определены и на каждую задачу назначены исполнители и выделены материалы, перейдя в представление Resource Sheet (Лист ресурсов), мы видим список всех требуемых проекту сотрудников.
5.3. Использование MS Project для выравнивания загрузки ресурсов
Превышение доступности ресурса заключается в том , что для выполнения назначенной работы ресурсу требуется больше времени, чем у него есть. Существует несколько причин, способных привести к этому. Самой распространенной среди них является назначение ресурса на задачи, исполнение которых полностью или частично осуществляется одновременно. Другим вариантом может быть увеличение объема работ задачи, приведшее к превышению допустимого уровня загрузки ресурса. Наконец, назначение ресурса из-за изменений в плане может приходиться на дни, когда ресурс недоступен.
Выровнять загрузку ресурсов можно несколькими способами. Во-первых, уменьшив объем работы перегруженных ресурсов, сократив некоторые задачи или назначив других сотрудников на их выполнение. Во-вторых, избавившись от пересечения задач, вставив в расписание перерывы в задачах или назначениях либо изменив даты их начала и окончания. Наконец, учтя работу, выполняемую ресурсом сверх нормы, как сверхурочную.
Для выравнивания загрузки ресурсов в Microsoft Project можно воспользоваться автоматизированными средствами, а можно перераспределить загрузку вручную. Как правило, используются оба способа, поскольку команда автоматизированного выравнивания использует только второй из перечисленных методов выравнивания и поэтому обычно не может выровнять загрузку всех ресурсов.
5.4. Обоснование, назначение ресурсов задач из WBS;
WBS декомпозируется до уровня, необходимого для планирования и контроля. В общем случае это будет детализация до уровня, по крайней мере, на один уровень ниже, требуемого для отчетности - позволяющего осуществлять эффективное планирование, контроль, и измерение выполнения отдельных работ с однозначно определяемыми ресурсами.
Хотя полное определение ресурсов будет возможно на стадии детального планирования, нужно в целом понимать, как это будет выполняться, и что данный уровень детализации WBS поддерживает необходимый объем работ.
Чтобы соответствующим образом подготовиться к планированию ресурсов в соответствии с WBS, необходимо рассмотреть следующие вопросы при определении уровня детализации WBS:
· Все ли работы запланированы с достаточной степенью детализации, необходимой для формирования и соблюдения обязательств?
· Существует ли возможность установления и контроля индивидуальных назначений ресурсов на работы со структурой отчетности, определенной данной WBS?
· Можно ли определить назначения на работы при постепенном расширении WBS? Будут ли они обоснованы как при разворачивании WBS сверху-вниз, так и при сборе данных снизу-вверх?
· Как обычно производится назначение ресурсов на работы и их контроль?
· Будут ли назначения ресурсов на работы согласованы с формальной системой расчета расписания?
· Как будут распределяться бюджеты?
· Можно ли будет связать бюджет с предполагаемым увеличением работы?
· Можно ли измерить увеличение объема работы на приемлемом уровне (т.е. соответствует ли уровень детализации WBS эффективному планированию и контролю)?
· Можно ли логически собрать данные по индивидуальным рабочим заданиям (т.е. можно ли работы, определенные в WBS, сгруппировать логически)?
· Вовлечено ли в проект более одной организации (в противном случае перед детальным планированием ресурсов необходимо утверждение WBS у других участников проекта)?
· Как будет определяться состояние работ в процессе выполнения проекта?
Как я уже обозначил в моем проекте (т.е. на стадии организации проекта) будут использованы лишь трудовые ресурсы. Т.е., сотрудники проекта - это прежде всего директор фирмы, который будет решать все наиболее важные для фирмы вопросы, начиная от идеи, (также в нашем случае и составления бизнес-плана), и заканчивая выбором помещения.
Конечно, степень участия директора предприятия в организационном процессе, может иметь разный процент. Поэтому, вопросы на более низшем уровне, либо помощь в решении главных вопросов, может лечь на плечи менеджера организации. В его обязанности может входить как выбор необходимых материалов и оборудования, так и подготовка в оформлении регистрационных документов. Менеджер может помочь в выборе помещения, а также в проработке маркетинговой концепции.
Пользуясь руководством дизайнера-проектанта, также участника данного процесса, можно быстро и качественно произвести необходимый ремонт помещения, подготовить рекламную кампанию фирмы, помочь в обучении сотрудников. .
- Tutorial
Небольшое введение
Вся методология - это просто набор простых методов и рекомендаций по использованию MS Project для решения прикладных задач руководителя проекта. Сразу оговорюсь, что методология не претендует на универсальность, и применима только при некоторых ограничениях, которые я буду упоминать по ходу повествования.Для начала, давайте вспомним, что обычно требуется от руководителя проекта. Для опытных руководителей это очевидно, а начинающим (или только собирающимся стать руководителями) будет полезно лишний раз вспомнить. Итак, проект по разработке программного обеспечения - это создание некоторое уникального продукта. На разных этапах жизненного цикла проекта от РП требуется решать различные задачи.
Перед началом проекта
Перед началом проекта от руководителя проекта обычно требуется ответить на два вопроса:- сколько проект займет времени
- сколько проект будет стоить
Примечание . Мне никогда не приходилось иметь дела с явными денежными оценками проекта, и, как я сейчас понимаю, это серьезное упущение. Все проекты, которыми я руководил, исполнялись сотрудниками компании. Команда проекта формировалась на всё время проекта, некоторые специалисты привлекались на определенное время. Фактически, от меня требуется оценка количества требуемых исполнителей, а также сроки их привлечения. Как мне кажется, это достаточно типичная ситуация для компаний, занимающихся разработкой ПО. В итоге все сводится к оценке трудозатрат, которая, с использованием эмпирических формул, превращается в оценку стоимости проекта. Как видим, присутствует прямая зависимость стоимости проекта от его сроков.
В процессе выполнения проекта
В условиях упомянутых ограничений, основной задачей руководителя проекта является обеспечить выполнение проекта в заявленный срок, а это непосредственновлияет на его стоимость. Непредвиденные обстоятельства, которые обязательно сопутствуют любому проекту, могут привести к срыву сроков. Строго говоря, сроки проекта могут неожиданно и сократиться, но, честно говоря, я такого никогда не видел. От руководителя требуется своевременно реагировать на такие события, чтобы уменьшить негативные последствия. Единственный известный мне способ решения этой задачи - это аккуратное планирование, регулярное отслеживание надвигающихся проблем и корректирование планов.
При завершении проекта
При завершении проекта руководитель обычно оглядывается назад и подводит итоги проекта. Чаще всего требуется оценить насколько проект выбился из плановых графиков и почему это произошло.Что умеет MS Project
Несмотря на внешнюю сложность, MS Project очень прост в идейном плане. Он оперирует тремя сущностями - задачи, ресурсы, календарь и связи между ними. По сути - это база данных, пользовательский интерфейс для создания и редактирования сущностей и минимальная, довольно простая автоматизация (то, что Project делает сам, в ответ на введенные данные).Разберем вкратце свойства сущностей.
Задача имеет длительность, объем, назначенный ресурс и еще чертову уйму различных свойств. Если встроенных свойств не хватает, можно добавить свои - этим мы потом воспользуемся. Задачи могут быть связаны между собой различными отношениями (предшественники, последователи и т.п.).
Ресурс
имеет много описательных свойств, но самое главное - для него можно
задать доступность во времени, для этого используется календарь. Ресурс может быть
назначен на задачу.
На основе этих данных Project умеет делать различные представления с использованием
фильтров, группировок, сортировок и т.п. Кроме этого он умеет по некоторому алгоритму
вычислять сроки начала и окончания задач с учетом доступности назначенных ресурсов
и связей между задачами. Вот, собственно, и почти все что он умеет.
Давайте посмотрим, какую пользу можно из этого извлечь
Как это использовать
Примечание Чтобы было понятнее, я уточню некоторые общие свойства проектов,
с которыми я работал. Итак, речь идет о проектах по разработке программного обеспечения,
которые состоят из нескольких этапов. В конце каждого этапа мы должны получить некоторый
осязаемый результат, который будет предъявлен заказчику, поэтому для нас важно оценить
срок не только проекта в целом, но и каждого этапа. Повторяю, единственный вид ресурсов
который требуется - это люди, причем мы не нанимаем специалистов со стороны, а используем
возможности уже работающих сотрудников.
Подготовка плана
Итак, перед нами лежит техническое задание, и требуется дать ответ на три вопроса:- Сколько времени займет этот проект?
- Сколько (и каких) специалистов для этого потребуется?
- Какие примерно трудозатраты ожидаются по этому проекту?
Подготовка плана выполняется в несколько этапов:
- Готовим список задач
- Выставляем зависимости между задачами
(результат какой задачи необходим для перехода к следующей?). - Назначаем исполнителей задач
- Выравниваем загрузку ресурсов
- Балансируем то, что получилось
- Не используем суммарные задачи для декомпозиции.
Все задачи помещаем в один линейный список. Сначала это может показаться неудобным,
но зато избавляет от многих проблем в дальнейшем. Для управления структурой задач
используем настраиваемые поля (см.ниже). - Очень часто для управления зависимостями задач используют Drag&Drop. Когда задач много это быстро становится неудобно. Я рекомендую в этом случае не использовать перетаскивание, а явное указывать номера задач-предшественников. для этого можно добавить в таблицу столбец «предшественники» и вписывать номера задач вручную.
- Срок каждой задачи не должен превышать двух недель.
Если срок задачи превышает неделю - это уже повод задуматься о её декомпозиции. Я придерживался очень простой методики оценки: примитивная задача - 2 дня, средней
сложности - 1 неделя, сложная задача - 2 недели. При этом сложных задач не должно быть много. Такой подход дает возможность подготовить оценочный план довольно быстро.
С одной стороны, полученная оценка, конечно, не будет точной, но, с другой стороны - а какая из них точная? По опытку практического применения могу сказать, что на
больших проектах погрешности оценок отдельных задач обычно нивелируются, а на малых часто можно (и нужно!) использовать и более точные оценки. - Всеми силами избегаем задач, у которых несколько исполнителей. Для каждой задачи должен быть назначен только один исполнитель. Двух исполнителей имеет смысл назначать
только если они действительно работают вдвоем (например, вы практикуете парное программирование). В прочих случаях лучше декомпозировать задачу. - При назначении исполнителей руководствуемся их профессией и квалификацией, пока не беспокоясь о равномерности загрузки.
- Используем суммарные задачи для разделения задач на этапы. Ставим зависимости между этапами, чтобы они шли последовательно. Разделение на этапы пока достаточно приблизительное.
Балансировка проекта
Самым главным в методике является именно балансировка. Цель этого процесса - подготовить план, в котором работы достаточно равномерно разделены между исполнителями на всем протяжении.После первичной подготовки плана обычно получается полное безобразие, а не проект. Поэтому начинаем приводить его в порядок. Приведение в порядок заключается в ручной балансировке назначений исполнителей и разделений на этапы. Для этого используем группировку задач по исполнителям , чтобы увидеть как разложились задачи. Для удобства просмотра рекомендую сортировать задачи по дате начала.
Примечание.
Теоретически, для оценки загрузки полагается использовать графики
загрузки пользователей. Эти графики хороши (наверное) для начальства, когда они
оценивают готовый проект. Но они непригодны на этапе создания плана, так как показывают
что все плохо, но совершенно не дают информации почему это так и что можно сделать.
Дальше начинается магия балансировки. Требуется минимизировать сроки выполнения каждого этапа путем обеспечения более-менее равномерной нагрузки на всех участников проекта. Для этого мы выполняем следующие действия:
- Сменить исполнителя задачи.
Это имеет смысл сделать, если мы видим, что у одного исполнителя большой хвост задач,
а у другого есть явные «дыры», причем он может взять на себя некоторые работы у
первого. - Перенести задачу в другой этап.
Задача, которая приводит у удлинению срока этапа, но при этом не является необходимой
для получения результата этапа может быть перенесена на этап позже. И наоборот,
если в этапе присутствуют «дыры» в загрузке исполнителей, а изменить исполнителей
не получается, то можно попробовать взять задачи из следующего этапа.
Теперь еще раз внимательно смотрим на проект, убеждаемся, что связи между задачами расставлены правильно, что ничего не забыто, а назначения исполнителей соответствуют их специальностям и квалификации.
Учет рисков
Теперь - последний штрих: учет рисков. Честно признаюсь, я не занимался серьезным управлением рисками, но учитываю возможность возникновения определенных форсмажоров (таких как болезни исполнителей, забытые работы и т.п.). Для этого я добавляю в каждый этап фиктивную задачу с минимальным приоритетом, под названием «прочие работы» для каждого ресурса. После выравнивания ресурсов эти задачи оказываются в конце этапа. Длительность этих задач зависит от вероятности возникновения и степени вляния рисков, она зависит от способа определения оценок длительностей задач, здоровья членов команды и степени паранойи руководителя проекта. Обычно я выставлял длительность «прочих работ» примерно от трети до четверти длины этапа.В результате всех перечисленных манипуляций у нас получается план выполнения проекта, с которым можно работать.
С этим планом мы можем:
- Назвать сроки выполнения проекта и его этапов. Аргументированно и с высокой степенью
достоверности. - Оценить примерные трудозатраты по проекту
Работа с планом
Когда проект запускается в работу, исходный план, который использовался для оценки, можно использовать и для отслеживания выполнения проекта. От руководителя проекта требуется регулярно выполнять следующие действия:- Выдавать задания исполнителями
- Отмечать выполненные задания в плане
- Корректировать план в случае значительных отклонений
Для определения проблемного участка удобно использовать различные группировки - по исполнителями, по компонентам и др. Часто может оказаться, что проект в целом идет даже с опережением, но в определенном разрезе наблюдается отставание, например один из разработчиков неожиданно уткнулся в серьезную системную проблему, которая привела к отклонениями. Использование только средней метрики не покажет этой проблемы - она всплывет только в конце этапа, когда что либо делать будет уже поздно.
Примечание. Обычно я не двигаю задачи по календарю, а только отмечаю насколько они выполнены. Отклонение от плана я отслеживаю по отклонению суммарной задачи проекта от текущего момента.
Есть другая стратегия - внесение изменений в сроки задач, «выталкивая» невыполненные задачи вперед. При таком подходе для отслеживания отклонений от плана можно использовать другую полезную функцию MS Project - базовый план. Базовый план - это просто сохраненный снимок состояния задач. Его можно сделать в начале проекта. Для сравнения текущего плана с базовым, открываем «диаграмму Ганта с отслеживанием». Для динамичного плана, когда порядок выполнения задач часто меняется, это может оказаться неудобным, поэтому я вставляю в проект контрольные точки, отражающие некоторые важные результаты проекта, и отслеживать отклонения от базового плана только для них.
Управление структурой задач с помощью пользовательских полей
Я категорически рекомендую не использовать суммарные задачи в MS Project для функциональной декомпозиции или категоризации задач. Дело в том, что иерархия задач в MS Project сильно завязана на их последовательность. А часто хочется посмотреть на задачи в разной последовательности, при этом вся структура «рассыпается». Для управления структурой задач я рекомендую использовать Пользовательские поля . MS Project имеет предопределенный набор полей с неопределенным заранее поведением, которые мы можем использовать так, как нам удобно. Например, для разбивки задач по компонентам нужно на основе текстового поля Текст1 создать поле Компонент и задать для него список значений, соответствующий компонентам системы.
После этого мы получаем возможность указать для каждой задачи компонент, к которому она относится, и, используя группировку задач по компонентам, отслеживать как идут дела.
Пользовательские поля позволяют разделять задачи по нескольким категориям, например, я разделял задачи по типу работ: Разработка, Тестирование, Документирование.
Упомяну для любопытных, что в MS Project также можно задать правила рисования диаграмм на основе свойств задач. При желании, можно сделать так, что задачи по разным компонентам будут иметь разные цвета, причем цвет будет определяться только свойством задачи, его не нужно задавать вручную для каждой задачи. Такие настройки не требуют написания сриптов, а делаются штатными средствами настройки диаграмм.
Использование пользовательских полей, а также встроенные в MS Project функции фильтрации, сортировки и группировки задач позволяют получить самые разные представления, которые позволяют получить ответы на многие вопросы, которые возникают у руководителя проекта.
Завершение проекта
В конце проекта мы получаем план, в котором все задачи выполнены. Обычно я стараюсь сохранять также и исходный план, хотя бы в качестве базового. Честно говоря, на этом этапе от MS Project мало проку, так как интересуют не плановые значения, а фактические. Какие-то решения этой проблемы предлагает MS Project Server, там есть возможность учитывать фактические трудозатраты, но это уже за пределами данной статьи.Заключение
Я попытался обобщить свой опыт использования MS Project для практического решения задач, которые возникали передо мной, когда я руководил проектами по разработке ПО. Описанная методика не претендует не универсальность, но она, как мне кажется, достаточно проста и логична, при этом позволяет решать практические задачи руководителя проекта.Использование этого подхода позволило мне успешно и в срок завершить не один проект.
Правда, случались и сбои. Это происходило, как правило, тогда, когда плохо была проведена подготовительная часть проекта, а именно - постановка задачи. Т.е. в результате проекта получалось не совсем то, что требовалось, а понимание этого приходило слишком поздно.
Наверняка я что-то упустил, не стесняйтесь задавать вопросы.
Один из наиболее важных аспектов работы руководителя проектов - отслеживать назначения всех ресурсов, чтобы эффективно сбалансировать их рабочие нагрузки. У одних ресурсов возможно превышение доступности, а у других - неполная загруженность. Просматривая рабочие нагрузки и доступность в Microsoft Project, вы можете оценить, насколько эффективно ваши ресурсы задействованы в проекте и требуется ли внести корректировки.
На вкладке Задача или Ресурс Вид выберите элемент Использование ресурсов .
Во многих представлениях ресурсов, включая и "Использование ресурсов", ресурсы с превышением доступности отображаются красным цветом. Превышение доступности означает, что превышено максимальное число единиц ресурса в определенный период времени. На листах ресурсов в поле индикатора для ресурсов с превышением доступности также появляется индикатор выравнивания нагрузки ресурса. Посмотрите на индикатор и назначения задач, чтобы оценить, допустимо ли превышение доступности.
Примечание: В представлении "Использование ресурсов" отображаются назначения ресурсов не только для задач текущего проекта, но и суммарные. Суммарные назначения ресурсов показывают общий объем работы, назначенной ресурсу во всех проектах. Для отображения суммарных назначений ресурсов необходимо подключиться к серверу Microsoft Project и открыть корпоративный проект. Если вы не хотите, чтобы строки суммарных назначений учитывались в итогах, показанных в представлении "Использование ресурса", выделите эти строки и нажмите клавишу DELETE.
На вкладке Задача или Ресурс в раскрывающемся меню группы Вид выберите элемент Использование ресурсов .
На вкладке Формат нажмите кнопку Добавить подробности .
В списке Доступные поля выберите Процент загрузки и нажмите кнопку Показать .
.
Совет: Вы можете увеличить масштаб на период, показанный на шкале времени (например, вы можете изменить представление с дней на часы), нажав кнопку увеличить (+) в правом нижнем углу окна. Кроме того, вы можете увеличить масштаб за период времени (например, вы можете изменить представление с дней на недели), нажав кнопку уменьшить (-) .
Трудозатраты по ресурсам .
Оставшееся время .
Использование ресурсов .
В центре проектов Ресурсы .
Ресурсы в группе Переход выберите элемент Планирование загрузки .
На вкладке Доступность в группе Представления
В таблице Подробности
Совет: Доступность выберите элемент Задать диапазон дат , а затем в полях окна Определение диапазона дат выберите новые даты.
На вкладке Ресурс в группе Вид выберите представление График ресурсов .
В левом окне проверьте имя первого ресурса, прокручивая экран влево или вправо.
В группе Вид выберите в раскрывающемся списке элемент Лист ресурсов или Использование ресурсов .
На вкладке Вид в группе Данные откройте раскрывающееся меню Фильтр и выберите элемент .
Чтобы снова увидеть полный список ресурсов, в раскрывающемся меню Фильтр выберите элемент Нет фильтра .
Примечание: Даже без использования фильтра вы легко определите, у каких ресурсов превышена доступность, поскольку их имена выделяются красным цветом в любом представлении ресурсов. Кроме того, в представлениях "Лист ресурсов" и "Использование ресурсов" в поле индикатора для таких ресурсов предлагается выровнять нагрузку.
В любом представлении задач, например "Диаграмма Ганта" или "Сетевой график", на вкладке Ресурс в группе Выравнивание выберите элемент Следующее превышение доступности .
В группе Вид выберите элемент Лист ресурсов или Использование ресурсов .
На вкладке Вид в раскрывающемся меню Группировка выберите элемент Создать группу .
В поле Имя поля выберите вариант Превышение доступности .
В поле Порядок выберите вариант По возрастанию или По убыванию .
Если вы выберете порядок По возрастанию
затем по и выберите значение пик .
Укажите имя группы и нажмите кнопку Применить .
Превышение доступности: Да
Чтобы снова отобразить ресурсы в первоначальном порядке, в раскрывающемся списке Группировка выберите элемент [Нет группы] .
В группе Вид выберите элемент Использование ресурсов .
На вкладке Формат в группе Подробности установите флажок Оставшееся время .
В строке Ост. доступн.
В группе Вид выберите элемент График ресурсов .
На вкладке Формат в раскрывающемся меню Диаграмма выберите элемент Доступность по трудоемкости .
Чтобы перейти к следующему ресурсу, у которого есть доступное время, нажмите клавишу PAGE DOWN или воспользуйтесь полосой прокрутки либо клавишами со стрелками в левой области.
Эти инструкции относятся к Microsoft Project 2007.
В этой статье
Просмотр рабочей нагрузки ресурса в представлении "Использование ресурсов"
В меню Вид выберите элемент Использование ресурсов .
В той части представления "Использование ресурсов", где показана таблица, проверьте имена ресурсов и назначенные им задачи.
В той части представления, где показана шкала времени, посмотрите, как распределена работа в выбранном периоде времени.
Во многих представлениях ресурсов, включая и "Использование ресурсов", ресурсы с превышением доступности отображаются красным цветом. Превышение доступности означает, что превышено максимальное число единиц ресурса в определенный период времени. На листах ресурсов в поле индикатора для ресурсов с превышением доступности также появляется значок , указывающий, что нагрузку ресурса нужно выровнять. Посмотрите на индикатор и назначения задач, чтобы оценить, допустимо ли превышение доступности.
Предположим, две задачи с одинаковой длительностью четыре часа начинаются и заканчиваются одновременно. Если вы назначаете обе задачи Глебу, технически у него получается превышение доступности, поскольку в четырехчасовой интервал ему нужно выполнить две задачи, то есть Глеб загружен на 200 процентов. Но если задано выравнивание по дням, нагрузку Глеба не требуется выравнивать, поскольку в течение всего дня его восьмичасовая трудоспособность не превышается.
Примечание: В представлении "Использование ресурсов" отображаются назначения ресурсов не только для задач текущего проекта, но и суммарные. Суммарные назначения ресурсов показывают общий объем работы, назначенной ресурсу во всех проектах. Для отображения суммарных назначений ресурсов необходимо подключиться к серверу Microsoft Office Project и открыть корпоративный проект. Если вы не хотите, чтобы строки суммарных назначений учитывались в итогах, показанных в представлении "Использование ресурса", выделите эти строки и нажмите клавишу DELETE.
Можно также изменить представление "Использование ресурсов", чтобы в нем на шкале времени отображались все назначения ресурсов и проценты их рабочей загрузки. Таким образом вы увидите все назначения по ресурсам, а также насколько полно они задействованы для работы над назначенными задачами в выбранный период времени.
В меню Вид выберите элемент Использование ресурсов .
В меню Формат выберите элемент Стили подробных данных .
В списке Доступные поля выберите Процент загрузки и нажмите кнопку Показать .
Просмотрите шкала времени часть представления. В поле "выДелено" . добавленной строки можно просмотреть процент общего количества доступных рабочее время ресурса, выделенных для назначений в течение выбранного периода времени. Кроме того, в представлении "Шкала времени" отображаются как трудозатраты ресурса с превышением доступности, так и процент выделения в красном виде, что позволяет точно определить, когда ресурс становится превышением доступности.
Совет: Вы можете увеличить масштаб на период, показанный на шкале времени (например, вы можете изменить представление с дней на часы), щелкнув масштаб в . Кроме того, вы можете увеличить масштаб за период времени (например, вы можете изменить представление с дней на недели), нажав кнопку уменьшить масштаб .
Просмотр сведений о доступности корпоративных ресурсов в Project Online
Чтобы найти ресурсы с превышением доступности или неполной загруженностью во всех или только в одном проекте, вам нужно открыть Project Online и посмотреть на диаграмму и таблицу доступности ресурсов.
Чтобы отобразить назначенные трудозатраты, сгруппированные сначала по ресурсам, а затем по проектам, в которых участвуют ресурсы, выберите Трудозатраты по ресурсам .
Чтобы отобразить назначенные трудозатраты, сгруппированные по проектам, в которых участвуют ресурсы, выберите Использование ресурсов по проектам .
Чтобы отобразить количество времени ресурсов, которое еще доступно для работы в указанный период времени, выберите Оставшееся время .
Чтобы отобразить объем трудозатрат, которые назначены ресурсу, выберите Использование ресурсов .
В центре проектов Project Online в меню слева щелкните Ресурсы .
Установите флажки около тех ресурсов, сведения о доступности которых хотите посмотреть, а затем на вкладке Ресурсы в группе Переход выберите элемент Планирование загрузки .
Чтобы выбрать смежные ресурсы в списке, нажмите клавишу SHIFT и, удерживая ее нажатой, щелкните сначала первый, а затем последний ресурс. Чтобы выбрать несмежные ресурсы, нажмите клавишу CTRL и, удерживая ее нажатой, поочередно щелкните каждый ресурс.
На вкладке Доступность в группе Представления выберите представление ресурсов.
Если на предыдущей странице вы выбрали несколько ресурсов, щелкните легенду на диаграмме и выберите те ресурсы, которые хотите увидеть на диаграмме.
В таблице Подробности под диаграммой отображается шкала времени, на которой показано, сколько работы назначено ресурсу в указанный период времени.
Совет: Чтобы изменить диапазон дат на диаграмме, на вкладке Доступность выберите элемент Задать диапазон дат , а затем в полях окна Определение диапазона дат выберите новые даты.
Просмотр индивидуальных рабочих нагрузок на диаграмме
В представлении "График ресурсов" отображается линейчатое представление диаграмма и доступность отдельных ресурсов. Это представление позволяет быстро определить, является ли выделенный ресурс слишком распределенным или недостаточной в течение определенного периода времени. Кроме того, можно просмотреть процент единицы, выделенных для назначений, а также доступность максимальное число единиц ресурсов.
В меню Вид выберите элемент График ресурсов .
Проверьте имя первого ресурса в представлении "График ресурсов".
Если имя ресурса показано красным цветом, у него превышена доступность. Черным цветом показаны ресурсы, загруженные в соответствии с заданной трудоспособностью (полностью или нет).
Синие полоски (по умолчанию) показывают, что объем выделенных трудозатрат точно соответствует (или не достигает) максимальной доступности ресурса и его рабочему времени в этот период. Красные полоски (по умолчанию) показывают, что назначенная ресурсу нагрузка в этот период превышает его максимальную доступность и рабочее время.
Обратите внимание на наибольшие проценты загрузки в показанный период времени, то есть пиковые единицы для ресурса.
Пиковые единицы указаны в нижней части диаграммы.
Чтобы посмотреть диаграмму для следующего ресурса, нажмите клавишу PAGE DOWN или воспользуйтесь полосой прокрутки либо клавишами со стрелками.
Просмотр списка ресурсов с превышением доступности
У вас есть возможность посмотреть список только тех ресурсов, у которых превышена доступность. Для этого выберите представление "Лист ресурсов" или "Использование ресурсов", а затем отфильтруйте ресурсы с превышением доступности.
В меню Вид выберите элемент Лист ресурсов или Использование ресурсов .
В представлении щелкните Фильтр и выберите вариант Ресурсы с превышением доступности .
Чтобы снова увидеть полный список ресурсов, щелкните Фильтр и выберите вариант Все ресурсы .
Примечание: Даже без использования фильтра вы легко определите, у каких ресурсов превышена доступность, поскольку их имена выделяются красным цветом в любом представлении ресурсов. Кроме того, в представлениях "лист ресурсов" и "использование ресурсов" в поле индикатор появляется индикатор, указывающий на выравнивание ресурсов с превышением доступности.
Превышение доступности отображается также в представлениях задач, но не выделяется красным цветом. В представлении задач вам придется поочередно переходить к каждой задаче, в которой есть превышение доступности ресурса, потому что в этом представлении не показано, у каких ресурсов (и насколько) превышена доступность.
Группирование ресурсов с превышением доступности
В представлении "Лист ресурсов" или "Использование ресурсов" можно группировать ресурсы с превышением доступности. Ресурсы также можно группировать по пиковым единицам, которые показывают максимальный процент загрузки каждого ресурса в назначениях проекта. Просматривая ресурсы по степени превышения их доступности, вы можете в первую очередь обратить внимание на тех, у кого она самая высокая.
В меню Вид выберите элемент Лист ресурсов или Использование ресурсов .
В меню Проект Группировка и выберите пункт Настройка группировки .
В поле Имя поля выберите вариант Превышение доступности .
В поле Порядок выберите вариант По возрастанию или По убыванию .
Если вы выберете порядок По возрастанию , сначала будет показана группа ресурсов без превышения доступности, а уже после нее группа ресурсов с превышением доступности.
Чтобы создать вложенную группировку пиковые единицы, щелкните поле затем по и выберите пункт пиковые единицы .
Чтобы сохранить эту группу, нажмите кнопку сохранить . Укажите имя для группировки, а если вы хотите, чтобы группировка отображалась в меню Группировка, установите флажок Показывать в меню . Нажмите кнопку ОК , чтобы закрыть диалоговое окно " Сохранение группы ".
Элементы представления группируются в соответствии с заданными условиями. Все ресурсы, у которых есть назначение, превышающее 100 процентов пиковых единиц на каком-либо этапе проекта, объединяются в группу Превышение доступности: Да . Если вы создали вложенную группу пиковых единиц, у вас может появиться дополнительная группа под названием , и т. д.
Чтобы снова отобразить ресурсы в первоначальном порядке, в поле Группировка выберите элемент Нет группы .
Поиск ресурсов с доступным временем
Если у вас есть ресурсы с превышением доступности, имеет смысл поискать в проекте ресурсы, у которых есть доступное время, чтобы более равномерно распределить рабочую нагрузку. Эта возможность пригодится также в том случае, если у вас есть дополнительные неназначенные задачи и вам нужно узнать, кто доступен для этой работы.
Доступность ресурсов определяется по следующей формуле:
доступность ресурса = емкость ресурса – (суммарное назначение ресурса + календарные исключения)
Суммарное назначение ресурса - это суммарный объем всей работы, выполняемой ресурсом, а календарные исключения - это любые исключения в основном календаре ресурса.
Чтобы найти ресурсы, которые могут поработать над задачей дополнительное время, измените представление "Использование ресурсов", включив в него данные о том, сколько времени (часов, дней или недель) ресурс доступен для дополнительных назначений. Это представление также можно использовать для перераспределения работы между ресурсами с превышенной доступностью и ресурсами с неполной загруженностью.
В меню Вид выберите элемент Использование ресурсов .
В меню Формат наведите указатель на элемент Подробности и выберите вариант Оставшаяся доступность .
В строке Ост. доступн. (оставшаяся доступность) проверьте объем работы, соответствующий оставшемуся доступному времени (или неполной загруженности) в каждый период.
Кроме того, вы можете отобразить и изменить представление графика ресурсов, чтобы просмотреть линейчатую диаграмму отдельного ресурса, которая поможет вам найти пользователей, которые могут работать с дополнительными часами по задаче. В представлении «График ресурсов» вы можете просматривать сведения о выделенных ресурсах за один раз. Вы можете просматривать количество доступных трудозатрат за определенный период.
В меню Вид выберите элемент График ресурсов .
В меню Формат наведите указатель на элемент Подробности и выберите вариант Доступность по трудоемкости .
Проверьте объем доступной работы для выбранного ресурса, показанный на диаграмме. Чтобы увидеть неполную загруженность в разные периоды времени, прокрутите шкалу времени.
Проверьте количество доступного времени для выбранного ресурса в нижней части диаграммы.
Чтобы перейти к следующему ресурсу, у которого есть доступное время, нажмите клавишу PAGE DOWN или воспользуйтесь полосой прокрутки либо клавишами со стрелками.
Статья предоставлена редакцией информационно-аналитического журнала "Управление Проектами" в рамках совместного проекта с Финансовой академией “Актив”.
Современные методы и средства проектного управления, статьи по развитию навыков и компетенций в области управления проектами, программами и портфелями проектов доступны при приобретении выпуска журнала или при полугодовой и годовой подписке.
Для кого эта статья
Существует масса пособий по работе в MS Project. Почти все они рассказывают о технике: как пользоваться приложением, какие сущности в нем существуют, какие связи между задачами используются и т.д. Однако когда доходит до практики, руководитель проекта сталкивается с необходимостью принимать решения другого характера – какие задачи должны входить в график, как найти золотую середину между детальностью графика и удобством работы с ним, какие приемы лучше использовать, чтобы минимизировать трудозатраты на планирование? Как, в конце концов, обеспечить выполнение сроков проекта?
Данная статья – для тех, кто не нуждается в детальных инструкциях по использованию MS Project. Статья предназначена для практиков, которым будет интересно познакомиться с опытом других руководителей проектов. Ниже изложены некоторые приемы и принципы, которые сформировались в результате многолетнего опыта работы, и которые позволяют сделать практичный график проекта.
Планирование проекта
Хотя график проекта может служить разным целям, здесь мы сосредотачиваемся на задаче управления сроками. Как спланировать и обеспечить выполнение проекта в срок. При этом за скобками остаются задачи расчета полных трудозатрат и стоимости проекта. Решить обе задачи одновременно с помощью одного графика проекта возможно, но сложно, т.к. требования к детальности и полноте графика, в зависимости от поставленных целей, разные.
Если говорить об управлении сроками, то можно сформулировать следующие требования. Хороший график проекта:
- Приспособлен для информирования заказчика и проектной команды. Для этого он должен быть понятным, компактным, логичным, хорошо структурированным.
- Легко модифицируется в случае изменений сроков и состава задач. Его легко поддерживать в актуальном состоянии.
- Позволяет контролировать сроки, обнаруживать проблемы и принимать по этому поводу решения.
Для того, чтобы составить такой график предлагаем следующий план действий:
1. Принять решения о способе планирования
1.1. Планирование от начала
Более привычный для большинства способ. Удобен, если вы знаете начало проекта, но только приблизительно представляете, когда он закончится.
В свойства проекта устанавливаете дату начала. Все новые задачи автоматически сдвигаются в начало, т.к. по умолчанию для них устанавливается тип ограничения «Как можно раньше». После выстраивания последовательности задач с помощью связей, проект растягивается. Путем манипуляций с длительностью и последовательностью задач получаете желаемую дату окончания проекта.
Это более комфортный способ планирования с психологической точки зрения. Легче планировать сначала то, что ближе и понятнее, а затем на основе ближайших результатов, переходить к последующим задачам.
Минус в том, что задачи, которые могли бы быть сделаны позже, становятся в плане слишком близко к началу проекта. Некоторые считают, что это правильно, т.к. лучше делать все как можно быстрее. Наверняка возникнут осложнения, и раннее выполнение задач создает резервы времени. В некоторых случаях это справедливо. Но это также приводит и к негативным последствиям.
В начале проекта, как правило, нужно сосредоточиться на концептуальных и стратегических задачах, отложив все второстепенные, чтобы не распыляться, не терять фокус и не тратить понапрасну ресурсы. Во-вторых, сделанные заранее работы могут оказаться не нужны, или сделаны не так, как требуется из-за недостатка информации. Например, написанные в начале проекта документы придется переписывать, потому что изменились требования заказчика.
Чтобы избежать раннего начала задач и распределить задачи во времени, можно использовать ограничения на задачи типа «Не ранее чем», «Фиксированная дата начала».
Иногда используют задержки и сдвиги между задачами.
Рисунок 1
Однако пользоваться задержками лучше по возможности меньше.
Величина задержки выставляется произвольно, логики их применения и оценки не видна непосредственно из графика. Читать такой график сложнее. Впоследствии, при изменении графика, возможно, потребуется переоценка длительности и необходимости задержек. Вы вынуждены управлять ими вручную, трудоемкость поддержки графика увеличивается, вероятность ошибки возрастает.
Если задержка действительно необходима, то лучше добавить задачу ожидания явно. В приведенном примере, после Опытной эксплуатации, вместо задержки в 5 дней можно добавить задачу «Подготовка приемочных испытаний». Тогда будет понятно, для чего требуется 5 дней, кто должен это делать, и чем грозит изменение сроков по этой задаче.
1.2. Планирование от конца
Если конечная дата проекта жестко определена, то правильнее планировать «от конца». Устанавливается дата окончания проекта, и во всех новых задачах автоматически устанавливается тип ограничения «Как можно позже».
Логика планирования в этом случае другая, но в некотором смысле более правильная. Вы задаете себе вопрос: «что необходимо, чтобы завершить проект?». Затем определяете, что необходимо, чтобы достичь этих промежуточных результатов, добавляете предшествующие задачи, к ним в свою очередь присоединяются предыдущие задачи и т.д. Выстраивается последовательная цепочка работ, которые ведут к результатам проекта.
Такой способ хорош тем, что выстраивается четкая логика цепочки работа-результат-работа. Последовательное выстраивание плана от конца позволяет осознать, для чего нужна каждая задача, и как будет использован ее результат. И задачи не начинаются раньше, чем необходимо.
Многие скажут, что откладывать задачи на потом рискованно. Что если задача займет больше времени, чем запланировано, и результат опоздает? А она обязательно опоздает, и тогда следующая задача сдвинется и неизбежно сдвинется окончание проекта. Чтобы избежать этого, в график добавляются временные буферы. Подробнее об этом ниже.
2. Избавиться от лишнего и упростить план
Лишним считается все, что не помогает планировать сроки проекта.
2.1. Примеры задач, от которых можно избавиться
Рассмотрим группу задач «Управление проектом». Понятно, что задача управления проекта необходима, но она не определяет длительность проекта, а проект определяет ее длительность. Если мы сосредоточены на планировании сроков, можно ее убрать.
Рисунок 2
Задача «Поддержка». Как правило, это задача, которая начинается после запуска в эксплуатацию и имеет, как правило, фиксированную длительность (по договору), либо привязана к некоторым контрольным точкам. Можно включить ее в план проекта, но минимизировать ее детализацию. Эта задача может быть спокойно заменена в плане на две контрольные точки: Начало эксплуатации и Окончание поддержки.
Рисунок 3
План, в конечном итоге, нужен чтобы ставить задачи и проверять факт и качество исполнения. Это очень хороший критерий, чтобы определить, с какой степенью детализации его делать. В план должны попадать только те задачи, которые РП собирается ставить и проверять их исполнения. Более мелкие задачи переносятся за пределы плана — в Excel, в JIRA или в связанный план рабочей группы в MS Project.
2.2. Пример излишней детализации
Расписать задачи до отдельных шагов и действий можно, но что это дает? С точки зрения оценки длительности — ничего. Скорее, приводит к ошибке, т.к. в каждой задаче заложена значительная погрешность.
Рисунок 4
- «Письмо Пятнициной» — «Ответ Пятнициной». Можно спокойно исключить из плана. Если какие-то задачи зависят от получения письма от Пятнициной, и это действительно шоу-стоппер, то вводим веху «Получение списка ключевых пользователей от Пятнициной». То, что для получения списка нам нужно связаться с Пятнициной, может остаться за кадром.
- «Назначение встречи» — 1д. Скорее всего должно занять несколько минут. Вместо этого можно было бы вставить одну задачу по подготовке презентации и веху «Встреча с директорами обществ». Не нужна группировка задач. Вместо четырех строк — две.
- «Выпуск организационно-распорядительной документации» может быть одной задачей. В заметках по задаче, можно перечислить, кому нужно выслать письмо. Длительность задачи определяется суммарным временем подготовки всех документации. И эта информация будет точнее, растягивать эту задач на неделю нет никакой необходимости.
3. Установить взаимосвязи между задачами
Связи между задачам выстраивают логику плана. Связь от конца к началу, означает, что результаты предыдущей задачи, необходимы для начала следующей. По идее, в плане не должно быть задач, у которых нет последователей , кроме последней вехи завершения проекта или этапа. Каждая задача делается в плане для чего-то, ее результат всегда востребован.
3.1. Используйте минимум видов связей
В MS Project вы можете использовать разные виды связей между задачами «Окончание-начало», «Начало-начало» и т.д. По возможности, избегайте разнообразия использования разных типов связей. Читать график с разными видами связей сложно. Его поведение графика при модификации становится трудно предсказуемым. Чем проще, чем однообразнее — тем лучше.
3.2. Не используйте связи с суммарными задачами
Рассмотрим упрощенный пример проекта, состоящего из двух этапов. Иногда план выглядит так:
Рисунок 5
В результате мы имеем неоптимальный план. Иванов и Петров будут простаивать, ожидая завершения работы Сидорова по Этапу 1. Если у нас есть задача максимально сжать график проекта, мы начнем работы по Этапу 2, не дожидаясь завершения всех работ по Этапу 1. И тогда график будет выглядеть следующим образом. Связи между задачами, в данном случае отражают последовательность работ каждого из ресурсов.
Рисунок 6
Если же действительно нужно закончить все работы по Этапу 1 и только после этого начинать Этап 2, то можно организовать план следующим образом, не прибегая к связям между суммарными задачами — вставить вехи завершения этапа 1 и начала этапа 2.
Рисунок 7
Такой способ организации графика имеет еще одно преимущество — он делает план очень легким для чтения. Это важно для выверки логики и наличия всех необходимых связей между задачами.
3.3. Используйте Сетевую диаграмму
Для выверки связей очень удобно пользоваться при этом не привычной диаграммой Гантта, а сетевой диаграммой.
Рисунок 8
Для этого типа диаграммы важно иметь хорошо организованную группировку связей на вехи. В противном случае очень легко запутаться в стрелках, которые идут из задач в одном углу диаграммы в другой.
Очень часто довольно сложный план на сетевой диаграмме выглядит проще и логичнее, что позволяет быстро проверить наличие и корректность связей между задачами. Смотрите пример реального графика проекта:
Рисунок 9
Рисунок 10
4. Оценить длительность задач
В литературе описано много специальных и общих методик (PERT, мозговые штурмы, Дельфи и проч.). В реальности вы либо делаете оценку из собственного опыта, либо запрашиваете у экспертов или непосредственных исполнителей.
При оценке исполнителями нужно делать поправку. Учитывайте следующие факторы:
- О достоверности оценки лучше судить, если известны предположения, их которых исходил оценщик.
- Учитывайте психологические особенность каждого исполнителя
- Сделать поправку длительности. Для некоторых исполнителей, исходя из опыта работы с ними, нужно делить оценку на два, для других — умножать на три.
Задачи не должны включать запас «на всякий случай». Добавление запаса в каждую задачу с целью повысить вероятность выполнения в срок каждой задачи, скажем до 90%, делает график длинным, и при этом вы все равно не уложитесь в срок. Реальность такова, что все опоздания накапливаются, а опережения съедаются. Почему так? Причины могут быть следующие:
- «Студенческий синдром» — выучить курс в ночь перед экзаменом. И в проекте начинаем задачу когда до ее сдачи осталось минимум времени.
- Перфекционизм — если осталось время, надо работу довести до совершенства.
- Отсутствие доверия — «если сегодня я сделал быстрее, то в следующий раз моим оценкам не поверят, и урежут запрашиваемой мной время».
- Возможность работать менее интенсивно — «зачем напрягаться, если есть запас по времени?»
Поэтому придерживайтесь следующих правил при планировании работ:
- Вероятность выполнения в указанный срок установите в 50%. Это сократит оценку длительности по сравнению с 90% оценкой вероятности примерно вдвое. Сокращение времени позволит добавить в график временные буферы, которые вы будете расходовать из-за неизбежного опоздания по задачам. О добавлении буферов смотрите ниже.
- Ресурсы не должны быть перегружены. Люди не должны выполнять несколько задач одновременно. В этом случае их производительность будет максимально возможной.
5. Избавиться от распараллеливания задач
Часто можно увидеть в планах параллельные задачи, назначенные на одних и тех же исполнителей. Например,
Рисунок 11
Очевидно, РП отдает управление последовательностью и приоритетом задач консультантам. Тогда, с точки зрения планирования, достаточно было бы одной задачи «Функциональный блок Контроль», назначенной на Емельянову и Тену. Наличие пяти параллельных задач не имеет смысла. Все ресурсы перегружены, трудоемкость и длительность задачи не оценена, приоритеты не понятны.
Гораздо лучше было бы назначить одного исполнителя на каждую задачу, оценить каждую задачу по чистой трудоемкости с вероятностью выполнения ее в срок с 50% вероятностью, выстроить задачи в цепочку и добавить временно буфер в конце. Тогда это был бы реальный инструмент управления в руках РП.
6. Выровнять ресурсы
Часто руководители проекта не обращают внимание на то, что согласно составленному графику проекта ресурсы перегружены. Они просто не ставят задачу подгонки загрузки ресурсов под определенную планку. Действительно, если в плане ресурсы перегружены, то это не значит, что в реальной жизни они не смогут выполнить поставленные задачи. Проблема в том, что такой план нам об этом ничего не говорит, в нем нет информации о реализуемости плана. Многократная перегрузка ресурсов в плане равносильна отсутствию информации об их реальной загрузке.
Если мы хотим планировать загрузку ресурсов, нужно загрузку выравнивать. Можно это делать не для всех ресурсов, а только критических, которые мы действительно хотим планировать. Например, мы можем планировать своих сотрудников, но не планировать ресурсы заказчика, загрузка и возможности которых находятся за пределами нашего влияния.
В MS Project имеется функция выравнивания ресурсов. Эта функция расставляет задачи с учетом связей между задачами и ограничения по максимальной загрузке каждого ресурса и приоритета (поле «Приоритет»). Не всегда это приводит к нужному результату. План становится слишком длинным, а ресурсы недогружены. Задачи привязываются в плане к конкретным датам, что мешает их перепланировать. Можно добиться более адекватного плана в ходе автоматического выравнивания с помощью пересмотра зависимостей и расстановкой приоритетов, но это очень кропотливый и трудоемкий процесс.
Альтернатива — это ручное выравнивание с помощью установки последовательности задач, выполняемых одним ресурсом. Это возможно, если план не очень сложный.
Например, модифицируем предыдущий пример:
Рисунок 12
В данном примере считается, что А.Тен участвует в доработке всех документов, и два документа пишет самостоятельно. Мы точно не знаем, как будет построена их совместная работа, но предполагаем в среднем он будет на 30% отвлечен на документы А.Емельянова. Поэтому собственные задачи, где он занят на 70% больше по длительности, и оцениваются в 5 рабочих дней. Кроме того, мы добавили буфер, предполагая, что часть задач могут занять больше времени, чем мы предполагаем.
Было бы более правильно вообще разделить задачи между двумя участниками и избавиться от параллельного выполнения задач А.Теном, но в данном случае это сделать сложно. Поэтому приходится идти на нарушение правил, которые мы сами для себя установили выше. Тем не менее, такой план лучше, т.к. помогает контролировать выполнение задач не в конце 14 рабочих дней, которые мы отвели на проектирования функционального блока «Контроль», а уже через 3 дня после начала работы. Кроме того, это дисциплинирует исполнителя с первого дня, у которого нет 14 дней в запасе, а есть целевой срок 3 дня, когда нужно закончить первый документ.
7. Исключить жесткую привязку задач к датам
Следующий шаг – подгонка графика под необходимые даты. Не всегда удается это сделать естественными связями между задачами, возникает множество обстоятельств, диктующих необходимость начала или завершения задач в определенные периоды времени. Приходится привязывать задачи к датам.
Привязка к датам оправдана, если определяется внешними по отношению к плану условиями. Например, зафиксированная дата начала испытаний; контрольная точка, которая определяется внешним проектом; несдвигаемое событие. Во всех остальных случаях нужно избегать ограничений. Если их избежать не удается, то лучше использовать мягкие ограничения: «Начало не позднее», «Начало не ранее» и т.п. Это позволяет автоматически двигать задачи вслед за теми, от которых они зависят.
8. Выявить критический путь
Если задачи выстроены правильно, то MS Project покажет вам критический путь проекта — цепочку задач, которая определяет длительность. Изменение длительности или задержка начала выполнения любой задачи на критическом пути меняет дату окончания проекта.
Соответственно, чтобы уложиться в установленные сроки, нужно обеспечивать своевременное или опережающее выполнение именно задач критического пути. Для этого нужно:
- Уделять задачам критического пути ежедневное внимание, контролировать готовность всех необходимых ресурсов для их выполнения.
- Мотивировать участников на сокращение длительности выполнения задач критического пути, не допускать отвлечения на другие задачи.
- Использовать временные буферы, страхующие отклонение по срокам.
Например, заканчивается разработка функционального блока. Далее заказчик должен протестировать этот блок. Когда до окончания разработки остается 2 дня, необходимо предупредить ключевых пользователей о том, что через 2 дня они должны быть готовы принять разработку в тестирование. И зафиксировать это формально (электронным письмом, решением оперативного совещания, и т.п.). Разрыв между задачами критического пути приводит к увеличению срока проекта, поэтому управлять этим процессом нужно жестко.
При постановке задачи критического пути исполнителю нужно говорить о том, что эта задача является определяющей для проекта. Исполнитель должен полностью сосредоточиться на ней, не отвлекаться на второстепенные задачи. А в случае возникновения проблем и задержек, сразу оповестить об этом РП.
Но от осложнений никто не застрахован. Нет никаких гарантий, что задача будет выполнена в срок. Но это не означает, что нужно стремиться устанавливать такие сроки, которые гарантированно обеспечивают выполнение задачи в срок. Как известно, работа занимает ровно столько времени, сколько на нее отведено, об этом мы говорили ранее. Устанавливайте агрессивные сроки, но имейте запас для компенсации неизбежных опозданий. И лучше этот запас иметь консолидировано, в буфере, который добавляется в конец критического пути.
Рисунок 13
В приведенном примере красным выделены задачи критического пути, синие — другие задачи, зеленые — буферы. Обратите внимание, что некритические задачи тоже застрахованы буфером. Сроки по ним также с большой степенью вероятности будут нарушены. И чтобы не сорвать своевременное начало задачи критического пути, мы добавляем буфер на входе в цепочку.
Такой способ планирования хорошо сочетается с методикой планирования «от конца проекта».
9. Добавить временные буферы в график
Добавление буферов в план позволяет избежать нарушений конечной даты проекта или этапа при неизбежном изменении сроков по задачам.
Как правило, мы добавляем запас в каждую задачу, чтобы нас не наказывали за опоздания. Мы предпочитаем заложить запас на все риски, которые могут случиться — отвлечение на совещания, изменения требований заказчика, длительные согласования, технические проблемы и личные обстоятельства. Стараемся дать оценку необходимых сроков с вероятностью 90% их соблюдения. И несмотря на это, часто их срываем. Выше мы уже говорили о студенческом синдроме и прочих психологических моментах, которые приводят к нарушению сроков несмотря на все резервы, которые мы делаем в каждой задаче
В результате, опоздания всегда накапливаются, а опережения — практически никогда.
Выход следующий – избавиться от резервов в задаче и вынести их в общий буфер проекта. Установить целевую вероятность выполнения задачи в срок в 50% Это значительно сокращает оценку сроков по каждой задаче, согласно статистике – вдвое. В половине случаев он будет нарушен. И это может быт не вина исполнителя, а влияние обстоятельств и неправильной оценки. При таком подходе вы не будете наказывать исполнителей за нарушение сроков, а относиться к этому как к неизбежному.
При этом вы будете иметь запас, чтобы компенсировать отставание. Для этого в график добавляются буферы. Когда задачи опаздывают и сдвигают последующие, вы используете буфер. По скорости расходования буфера можно судить, насколько удачно вы спланировали проект, достаточно ли у вас ресурсов и правильно ли организованы работы. Если буфер расходуется слишком быстро, то необходимо принимать меры.
Рисунок 14
Различаются буферы проекта (этапа) — запас создаваемый в конце критической цепочки. И питающие буферы — временные резервы на входе в критическую цепочку, страхующие поток задач вне критического пути.
Размер буфера определяется длиной цепочки, которую он страхует, а также степенью неопределенности и рисков. Классики рекомендуют отводить на буферы около 50% длительности всей критической цепочки. Руководитель проекта должен исходить из собственной оценки рисков и возможностей графика проекта.
Нужно понимать, что проект с маленьким запасом скорее всего опоздает. Проектов, в которых все идет, как запланировано, не бывает. Невозможность добавить буфер может быть либо в результате явной недооценки сроков проекта, либо из-за явной переоценки длительности проектных задач, что случается, когда мы закладываем запас в каждую задачу. Даже если запас есть, но он заложен в задачи, проект все равно опоздает, по перечисленным выше причинам.
Подробнее об этом методе построения графика проекта можно прочитать в книге Э.Голдратта «Критическая цепь», которая написана в форме бизнес-романа, легко читается и действует крайне вдохновляюще.
10. Проанализировать график
Хороший график показывает, какие потенциальные проблемы есть в проекте; какие есть возможности для сокращения сроков; достаточно ли ресурсов для выполнения проекта.
10.1. Сокращение сроков
Рассмотрим пример:
Рисунок 15
Посмотрим, нельзя ли сократить этот график. Самые длинные задачи — номер 17 и 21. 18 и 15 дней — слишком длинные задачи для того, чтобы их можно было эффективно контролировать.
Нельзя ли детализировать и разделить эти задачи на части? Оказывается, это разработка отчетов, каждый из которых занимает в среднем по 1 дню. Не обязательно, чтобы их разработку вел один человек последовательно. Можно разделить их на порции и распределить между несколькими разработчиками. Добавили одного разработчика, разделили на неравные части и получили следующий график.
Рисунок 16
Таким образом, график наглядно показал, что необходим еще один человек в команду. Стало понятно, как нужно распределить задачи, чтобы сократить сроки и снизить риски зависимости от исполнителей, которые, например, могут в самый неподходящий момент заболеть.
10.2. Риски, связанные с графиком
Интересно посмотреть на график проекта с точки зрения управления рисками. Какие риски может обнаружить график проекта?
- Параллельное выполнение множества блоков работ или функциональных направлений. Необходимо решить, влечет ли опоздание одного из них серьезные последствия для всего проекта? Сложные проекты включают в себя до десятка направлений. Внедряется одновременно финансы, бюджетирование, HR, логистика и т.д. Если не предусмотрены работы по интеграции и координации направлений, не заложены резервы на отклонения по каждому из направлений, нет этапа интеграционного тестирования, велика вероятность неуспеха проекта в целом, а не только срыва сроков.
- Отсутствие периода опытной эксплуатации. Если ОПЭ невозможна, то нужно рассматривать возможность поэтапного запуска, по функциональным областям или организационным единицам.
- Излишне агрессивный график, отсутствие или недостаточный размер резервов. Об этом уже говорили. Такой проект вероятнее всего опоздает.
- Этапы проекта или ключевые работы идут внахлест, с перекрытием. Во многих случаях это увеличивает риск переделки по уже выполненным задачам.
- Если в графике отсутствуют работы и вехи, закрепленные за заказчиком, то возможно, мы плохо контролируем работы со стороны заказчика. Необходимо обратить внимание на то, что некоторые работы могут быть некорректно отнесены к зоне ответственности исполнителя.
- Отсутствие в графике вех, означающих формальную приемку работ, может означать, что мы не до конца понимаем, какие промежуточные результаты и в какой момент должны подтвердить. А это чревато проблемами при сдаче результатов в конце проекта.
Заключение
На практике часто бывает, что график проекта составляется, потому что так принято, так требуется, для галочке. Но реальное управление проектом идет без его использования, потому что это сложно, трудоемко, и жизнь значительно богаче.
График проекта становится реальным инструментом управления в руках руководителя проекта, если график составлен с умом и следуя определенным стандартам. Владение инструментом и методами позволяет управлять сроками проекта гораздо эффективнее, с меньшими трудозатратами времени.
Загрузка...
