Канбан – шаблон в Project Online Professional

С ноября 2017 года в облачном Project Professional появились scrum-шаблон и Канбан – шаблон для гибкого управления проектами. За прошедшее с ноября время шаблоны улучшились. В этой статье разберем работу с Канбан-шаблоном.

Файл – Создать — Канбан-проект

Канбан – шаблон в Project Online Professional

В представлении Доска невыполненной работы в первом столбце создаем задачи с помощью кнопки +Новая задача

Канбан – шаблон в Project Online Professional

Канбан – шаблон в Project Online Professional

При этом, все стандартные для Project свойства задач сохраняются.

Канбан – шаблон в Project Online Professional

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

Канбан – шаблон в Project Online Professional

Канбан – шаблон в Project Online Professional

С помощью кнопки Добавить новый столбец можно поместить на доску любые нужные столбцы для задач.

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

Канбан – шаблон в Project Online Professional

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

Канбан – шаблон в Project Online Professional

Канбан – шаблон в Project Online Professional

Какие отчеты можно построить по своему плану?

Отчет – Гибкая разработка – Состояние задачи

Канбан – шаблон в Project Online Professional

Отчет – Гибкая разработка – Состояние работы

Канбан – шаблон в Project Online Professional

 

Метод критического пути

Метод критического пути в MS Project

Когда расписание проекта составлено, зачастую необходимо сократить его сроки выполнения. Например, руководство компании или заказчик настаивает на сокращении сроков. Мы можем применять к расписанию различные способы сэкономить время – например, быстрый проход (fast tracking) или сжатие расписания (crashing). Но для их эффективного использования надо знать, сокращение каких задач (работ) действительно приведет к сокращению сроков проекта.

В этом может помочь определение критического пути проекта.

Раньше, когда компьютерные программы для расчетов по проекту не применялись, руководитель проекта чертил табличку, в которой для каждой задачи определял 4 даты: раннего начала и раннего окончания, позднего начала и позднего окончания. Первые две даты определялись при прямом проходе по проекту, последние 2 – при обратном.

Прямой проход по проекту (forward pass)  означает следующее: сначала самая первая задача проекта ставится на самую раннюю дату, когда ее можно начать.  При прямом проходе все задачи ставятся на самые ранние возможные даты начала. Так, если задача-предшественник (с учетом длительности) может закончиться самое раннее третьего числа, то ее задачи-последователи начинаются немедленно после нее – четвертого. Итак, при прямом проходе все задачи ставятся как можно раньше, с учетом их длительностей и связей.

Далее выполняется обратный проход (backward pass). Самая последняя задача проекта ставится окончанием на самую позднюю дату, когда ее можно закончить. Исходя из длительности, рассчитывается ее поздняя дата начала. К ней вплотную, как можно позже, ставятся задачи-предшественники, конечно, с учетом их связей и длительностей.

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

Задача Раннее начало Раннее окончание Позднее начало Позднее окончание Общий временной резерв
Задача 1 1.4 3.4 1.4 3.4 0
Задача 2 4.4 6.4 4.4 6.4 0
Задача 3 7.4 14.4 7.4 14.4 0
Задача 4 15.4 18.4 15.4 18.4 0
Задача 5 4.4 9.4 9.4 14.4 5

 

Теперь рассчитывается разница между датой позднего начала и раннего начала либо между датой позднего окончания и раннего окончания для каждой задачи. Этот показатель называется общим временным резервом задачи (Total slack, total float).

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

Если общий временной резерв задачи равен нулю, такую задачу называют критической (critical), или лежащей на критическом пути.

Таким образом, критический путь (critical path) – это набор задач, определяющих сроки всего проекта.

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

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

Как в MS Project увидеть критический путь своего проекта?

Когда критический путь проекта может быть не непрерывным?

Какие способы сокращения сроков можно применить?

Как построить ресурсно-зависимый критический путь проекта?

Классификация временных ограничений

 

  ПЛАНИРОВАНИЕ ОТ ДАТЫ НАЧАЛА ПЛАНИРОВАНИЕ ОТ ДАТЫ ОКОНЧАНИЯ
ГИБКИЕ КАК МОЖНО РАНЬШЕ (ASAP)

КАК МОЖНО ПОЗЖЕ (ALAP)

СРЕДНИЕ

МОГУТ ЗАТЯНУТЬ СРОКИ ПРОЕКТА

НАЧАЛО НЕ РАНЕЕ (SNET)

ОКОНЧАНИЕ НЕ РАНЕЕ (FNET)

НАЧАЛО НЕ ПОЗДНЕЕ (SNLT)

ОКОНЧАНИЕ НЕ ПОЗДНЕЕ (FNLT)

ЖЕСТКИЕ

МОГУТ ВЫЗВАТЬ КОНФЛИКТ ПЛАНИРОВАНИЯ

НАЧАЛО НЕ ПОЗДНЕЕ(SNLT),

ОКОНЧАНИЕ НЕ ПОЗДНЕЕ(FNLT),

ФИКСИРОВАННОЕ НАЧАЛО(MSO), ФИКСИРОВАННОЕ ОКОНЧАНИЕ(MFO)

НАЧАЛО НЕ РАНЕЕ(SNET),

ОКОНЧАНИЕ НЕ РАНЕЕ(FNET),

ФИКСИРОВАННОЕ НАЧАЛО (MSO), ФИКСИРОВАННОЕ ОКОНЧАНИЕ (MFO)

Временные ограничения

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

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

По умолчанию, у каждой задачи уже есть временное ограничение –Как можно раньше (As soon as possible) при планировании от начала, или Как можно позже (As late as possible) при планировании от окончания. Эти ограничения считаются гибкими, с их помощью можно построить гибкий динамический график, который будет автоматически пересчитываться при изменении условий проекта.

На самом деле, многие из пользователей программы неосознанно устанавливают временные ограничения, когда вручную заполняют даты начала и окончания каждой задачи (столбцы Начало и Окончание). При ручном заполнении столбца Начало к задаче применяется ограничение Начало не ранее (указанной даты), при заполнении столбца ОкончаниеОкончание не ранее (указанной даты). Эти ограничения могут привести к неоправданному затягиванию сроков проекта. Например, Project рассчитал с учетом длительностей и связей дату начала задачи – 1 июня, а вы установили дату начала – 15 июня. В итоге получаем «дырку в проекте» длиной в две недели. Также средние временные ограничения мешают гибкости календарного графика и его автоматическому пересчету.

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

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

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

См. также статьи Классификация временных ограничений, Как устанавливать временные ограничения