Расписание проекта
При помощи ИСР и оценки проекта мы получили ответы на два самых важных вопроса из трех: что делаем и сколько это будет стоить? Остался последний вопрос: когда будет готово? Именно на этот вопрос отвечает расписание проекта.
Расписание проекта похоже на план поездки: есть контрольные точки, прогноз времени их достижения, конечная точка путешествия. Идем по плану — молодцы. Задерживаемся — разбираемся, почему, и думаем, как нагнать отставание.
Расписание проекта лучше всего позволяет понять, как идут дела: нужно ли поднажать или все хорошо.
Глоссарий расписания проекта
Давайте начнем с терминов, чтобы в дальнейшем говорить на одном языке.
Операция (Activity) — это работа, выполняемая в рамках проекта. Соответствует пакету работ (нижнему уровню ИСР/WBS).
Контрольное событие (Milestone) — достижение или значимое событие проекта. Например, завершение важной операции. Формулируется всегда в прошедшем времени: «Завершена разработка мобильного приложения». Контрольное событие в расписании имеет нулевую длительность, и на него не выделяются ресурсы.
Отношение предшествования (Precedence relationship) — порядок, в котором выполняются операции или операции и контрольные события. По сути, это ответ на вопрос: «Что нужно сделать, прежде чем начать выполнять эту задачу?»
Что же такое расписание проекта?
Расписание — главный инструмент управления проектом. Это план, в котором с привязкой ко времени отражено, кто, что и когда будет делать. Расписание содержит информацию об очередности и длительности операций, запланированных датах начала и окончания, исполнителях и датах достижения контрольных событий.
С его помощью собирают информацию о ходе проекта и отслеживают, соответствует ли фактическая скорость реализации запланированной.
Расписание отвечает на вопрос, кто и когда будет делать работу. Зная стоимость ресурсов и материалов, можно составить бюджет проекта и спрогнозировать, к какому числу сколько денег может понадобиться.
Расписание помогает менеджеру работать с изменениями проекта. Решение, принимать или не принимать изменения, зависит от того, насколько они повлияют на последовательность операций, необходимые ресурсы, контрольные события и сроки. Давайте представим ситуацию: вы опережаете расписание на неделю, но тут к вам обращается заказчик и просит добавить в разрабатываемую систему еще один отчет. Эта работа займет четыре дня. И вторая ситуация: заказчик обращается к вам с аналогичной просьбой, но разница в том, что вы опаздываете на неделю, а команда уже две недели работает без выходных. Очевидно, что в первом случае согласиться включить дополнительную работу в проект проще, чем во втором.
Если расписание показывает, что реализация проекта опаздывает, то менеджеру необходимо принять корректирующие действия, чтобы вернуть проект в нужное русло.
Выше мы уже говорили о том, что расписание позволяет нам понять, кто и когда должен выполнять те или иные работы. Следовательно, лучше подбирать команду исходя из расписания проекта: это намного продуктивнее, нежели сначала набрать команду, а затем под нее составлять расписание проекта. Во втором случае, скорее всего, выяснится, что набраны не те люди, не в том количестве, не с теми компетенциями.
Визуализация расписания работ
Чтобы за всеми работами по проекту и их последовательностью было удобнее следить, используют инструменты визуализации: диаграммы, схемы и графики.
К обычным видам визуализации расписания относятся диаграммы предшествования, диаграмма Ганта и диаграмма контрольных событий.
Диаграмма Ганта — один из любимейших инструментов руководителей проектов (рис. 19). В ней на оси Х отмечается время, а по длине задачи (визуализируется полоской) можно судить о продолжительности ее выполнения. Менеджеры нежно называют эту диаграмму «колбаски Ганта» из-за определенной схожести с мясным продуктом.
Высшему менеджменту нужно быстро, буквально с первого взгляда, понять, как идут дела в проекте. В этом случае можно прибегнуть к помощи диаграммы контрольных событий. Выполненные контрольные события заштриховываются, и можно с одного взгляда понять, опережает проект расписание или опаздывает. На картинке ниже (рис. 20) проект отстает от расписания, поскольку к сегодняшней дате мы планировали закончить строительство крыши, но эта работа еще не выполнена.
В среде менеджеров проектов даже бытует шутка о том, что существует метод управления по контрольным событиям: завершили этап проекта в срок — получили похвалу. Не успели вовремя — по шапке.
Главная задача диаграммы предшествования (PDM) — определить последовательность операций. Диаграммы предшествования помогают понять порядок следования работ и то, какие работы нужно выполнять последовательно, а какие могут осуществляться параллельно для экономии времени (рис. 21).
Так как диаграммы предшествования очень важны, то предлагаю на них остановиться подробнее.
Диаграммы предшествования
Как мы уже знаем, ИСР дает нам список всех работ проекта. Теперь нужно расположить эти работы в той последовательности, в которой они будут выполняться. И здесь нам помогут диаграммы предшествования, которые также называют «операциями на узлах».
Это метод составления сетевых диаграмм, где запланированные операции представляются узлами, а связи между ними — стрелками. Стрелки демонстрируют последовательность выполнения.
Что мы делаем? Берем пакеты работ (нижний уровень ИСР) и строим между ними зависимости (рис. 22).
У нас добавились узлы «Начало» и «Конец». Обратите внимание, что у этих узлов есть стрелки только одного направления: у начала только на выход, у конца только на вход. У всех остальных узлов есть одна или несколько стрелок и на вход, и на выход.
Получилась очень простая диаграмма с типом зависимости «Финиш — Старт», когда для начала операции «Согласование ТЗ» нужно закончить работу над выработкой требований и разработкой дизайна.
Всего существует четыре типа зависимостей (рис. 23).
Давайте подробнее остановимся на каждом из них.
Финиш — Старт (FS). Это самая простая и понятная зависимость: следующая операция начинается только после того, как заканчивается предыдущая. Например, сначала нужно построить фундамент дома, а потом уже возводить стены. Поскольку тип зависимости «Финиш — Старт» наиболее логичен и интуитивно понятен, при планировании проектов в 99% случаев применяют только его. Расписания, в которых используют другие типы зависимостей, гораздо сложнее читать. Каждый из остальных трех типов зависимостей можно преобразовать в «Финиш — Старт» (чуть позже разберемся, как это сделать).
Старт — Старт (SS). Это операции, которые должны начинаться одновременно: старт одной операции означает старт другой. Например, одновременно со стартом новой услуги необходимо запустить службу поддержки потребителей этой услуги.
Финиш — Финиш (FF). Это операции, которые завершаются одновременно. Например, если я продал машину, то прекращаю размещение платного объявления о продаже.
Старт — Финиш (SF). Тип операций, когда выполнение текущей операции завершается в момент начала следующей. Например, компания готовит производственный цех до тех пор, пока не привезут новые станки. Но как только прибывают станки, команда прекращает ремонт помещения, начинает их устанавливать и запускает производство. Еще один хороший пример для людей, знакомых с армией: солдаты драят плац до прихода генерала.
Иногда между операциями требуется определенный временной интервал. Он отображается в виде цифры над стрелкой. Положительная цифра означает, что нужно подождать определенное время, прежде чем начинать следующую операцию. Это называется задержкой (Lag time). Например, после заливки фундамента нужно дать бетону 36 часов, чтобы застыть, а уже потом можно возводить стены (рис. 24).
Если цифра отрицательная, это значит, что можно начинать работать, не дожидаясь завершения предыдущей операции. Это называется опережением (Lead time). Например, нам необходимо оштукатурить и покрасить три комнаты. Штукатур будет работать 12 часов (три комнаты по четыре часа на каждую), а маляр — восемь. Так вот, маляру не нужно ждать, пока штукатур закончит все три комнаты. Он может начинать красить первую через четыре часа после того, как ее закончит штукатур, или через 8 часов после начала работы штукатура. Как будет выглядеть эта зависимость, показано на рисунке 25.
Это пример зависимости «Финиш — Старт».
Пример зависимости «Старт — Старт» изображен на рисунке 26.
Зависимость «Старт — Старт» можно легко переделать в «Финиш — Старт», используя временной лаг, равный длине первой операции (рис. 27).
Таким образом, при помощи задержки и опережения мы можем сделать из любого типа зависимости легко воспринимаемый тип «Финиш — Старт».
Составление диаграмм предшествования — это первый шаг в разработке расписания.
Метод критического пути
После того как мы определили последовательность работ, у нас появилось понимание того, что и за чем следует. Несмотря на это, мы все еще не можем ответить на вопрос о том, когда проект будет завершен. В поиске ответа нам поможет метод критического пути — это второй шаг составления расписания.
Метод критического пути используется для оценки минимальной длительности проекта и определения степени гибкости его расписания.
Критический путь — это самый короткий интервал времени, за который может быть реализован проект. Современное программное обеспечение для управления проектами без проблем рассчитает критический путь любого проекта. Тем не менее, чтобы понять суть этого метода, разберем на очень простом примере, как это делается.
Как построить критический путь
Чтобы определить критический путь проекта, давайте пройдем весь процесс по шагам.
Шаг 1. На базе диаграммы предшествования строится сетевой график. В сетевом графике узел выглядит следующим образом (рис. 28).
- Ранний старт (Early start) — самый ранний момент времени, в который может начаться запланированная операция.
- Ранний финиш (Early finish) — самый ранний момент времени, когда операция может быть завершена.
- Поздний старт (Late start) — самый поздний момент времени, в который может начаться запланированная операция, чтобы не задержать выполнение всего проекта. Обратите внимание, что если операция начинается после этой даты, то весь проект будет задержан.
- Поздний финиш (Late finish) — самый поздний момент времени, когда операция может завершиться, не увеличив длительность всего проекта.
Для примера возьмем маленький проект по созданию веб-сайта. Вот его диаграмма предшествования (рис. 29).
На ее базе рисуем сетевой график (рис. 30).
На схеме появилась информация об узлах. Для каждой операции в центральной ячейке сверху цифрой прописана длительность ее исполнения. Выработка требований займет три дня, разработка дизайна — четыре дня и т.д.
Шаг 2. Выполняем прямой проход.
- Устанавливаем дату начала проекта. Она одновременно является и датой раннего старта первой операции. Ставим 0 у первых операций в ячейке раннего старта (рис. 31).
- Добавляем длительность операции к дате начала, чтобы получить ранний финиш для первой операции. В нашем примере это 0 + 3 = 3 дня (рис. 32).
- В ячейку раннего старта следующей операции вписываем цифру раннего финиша предыдущей операции. Если предшествующих операций много, то в качестве раннего старта последующей операции выбираем самую позднюю дату раннего финиша. Например, операции «Согласование ТЗ» предшествуют сразу две операции: «Выработка требований» и «Разработка дизайна». В дату раннего старта операции «Согласование ТЗ» мы ставим 4, то есть самый поздний вариант (рис. 33).
- Повторяем действия слева направо по всему графику и получаем вот такую картину (рис. 34).
Итак, мы прошлись по верхним ячейкам и заполнили даты раннего старта и раннего финиша для всех операций. Дата раннего финиша последней операции получилась 25. Это означает, что проект по созданию веб-сайта можно выполнить за 25 дней. Теперь делаем обратный проход и заполняем нижние угловые ячейки — это необходимо, чтобы определить гибкость нашего расписания.
Шаг 3. Обратный проход.
- В нижнюю правую ячейку позднего финиша операции «Демонстрация заказчику» вписываем день завершения проекта из ячейки выше (рис. 35).
- Вычитаем длительность операций из позднего финиша, чтобы получить дату позднего старта операции. В нашем примере это 25–1 = 24. Вписываем в левую нижнюю ячейку (рис. 36).
3. Проходим по графику в обратном порядке. Переносим дату позднего старта в ячейку позднего финиша предыдущей операции (рис. 37).
4. Если у предшествующей операции множество других, то выбираем самую раннюю дату позднего старта предшествующей (рис. 38).
5. Вот что у нас получается в итоге (рис. 39).
Теперь осталось заполнить центральную ячейку снизу для каждой операции, чтобы стало понятно, для чего мы это все делаем.
Шаг 4. Считаем временной резерв (Float) для каждой операции. Временной резерв операции — это время, на которое операция может задержаться, но при этом дата завершения проекта не пострадает. Отнимаем от позднего старта ранний старт и получаем временной резерв операции:
Float = LS (поздний старт) — ES (ранний старт).
Или другой вариант:
LF (поздний финиш) — EF (ранний финиш).
Тут все равно, какой вариант, поскольку оба расчета всегда дадут один и тот же результат.
В нашем примере для операции «Выработка требований» это 1 – 0 = 1 (рис. 40).
Рассчитываем временные резервы для всего проекта (рис. 41).
В некоторых местах у нас получились нули — это и есть тот самый критический путь проекта, то есть последовательность операций, задержка на которых приведет к задержке всего проекта. Серой заливкой обозначен критический путь примера (рис. 42).
У всех остальных операций есть резерв. Это значит, что они не лежат на критическом пути и их задержка в рамках временного резерва не повлияет на сроки сдачи всего проекта.
Вот как это выглядит в «колбасках» Ганта. Для упрощения диаграммы мы задействуем для работы выходные дни (рис. 43).
Руководитель проекта должен обращать максимум внимания именно на операции, находящиеся на критическом пути. Ведь задержка в работе над любой из них автоматически сдвигает дату завершения проекта. Риски, связанные с операциями критического пути, нужно прорабатывать в первую очередь.
Кроме того, критический путь помогает нам в выравнивании ресурсов. Выравнивание ресурсов — это работа с расписанием, при которой операции проекта сдвигаются так, чтобы у членов команды не было переработок. Обратите внимание, что на картинке выше программист Вася два дня должен работать по 16 часов одновременно над HTML-версткой и программированием. Видя, что обе операции не лежат на критическом пути, менеджер может корректировать расписание, чтобы Вася не работал сверхурочно, а выполнял операции последовательно. Это изменение не повлияет на дату завершения проекта, а Вася будет рад уходить домой вовремя (рис. 44).
Вот новое расписание проекта, в котором дата завершения осталась прежней, а сотрудник не сгорел на работе.
Что делать, если длительность проекта нужно сократить
После того как расписание построено, у вас есть дата завершения проекта. Если она всех устраивает, то менеджер утверждает расписание и принимается за работу. Очень часто бывает так, что проект не укладывается в желаемые бизнесом сроки, и тогда расписание нужно оптимизировать, чтобы проект был готов к определенной дате.
Какие подходы может использовать руководитель проекта, чтобы сократить расписание? Есть четыре подхода: сломать расписание, «быстрый проход», изменение подхода и переоценка зависимостей.
Сломать расписание (Crashing). Если один человек соберет яблоки в саду за десять дней, то два человека сделают это за пять дней. Таким образом, суть метода состоит в том, чтобы привлечь к проекту больше людей и выполнить его быстрее. Ломая расписание, менеджер смотрит на операции, лежащие на критическом пути проекта, и анализирует, можно ли выполнить их быстрее, если добавить людей в команду, — при условии, что у менеджера есть такая возможность.
«Быстрый проход» (Fast tracking). Эта методика подразумевает сжатие расписания проекта с помощью полного или частичного распараллеливания операций, которые обычно выполняются последовательно. Например, обычно тестирование проводится после завершения разработки, но, вероятно, существует возможность начать тестирование за неделю до завершения разработки и тем самым завершить проект быстрее на неделю.
«Быстрый проход» сокращает сроки проекта, но часто приводит к дополнительным рискам и увеличению стоимости. В нашем примере, если разработчики в последние дни работы над проектом внесут в него серьезные изменения, тестировщикам придется начинать работу с самого начала, а все уже сделанное отправится в мусорку. Это как начать строить дом до того, как работы над фундаментом завершены, а потом понять, что фундамент недостаточно прочен и его нужно доработать. Проще говоря, придется разбирать все, что уже успели построить, переделать фундамент и потом начать строительство стен заново. Все это не добавляет хорошего настроения команде. Вряд ли кому-то понравится переделывать то, над чем он кропотливо работал неделями, особенно если до этого работать приходилось с овертаймами.
Изменение подхода. Нужно посмотреть на проект и найти иной путь реализации. Представим, что в рамках проекта одна из задач — постройка беседки. Закупка стройматериалов и строительство отнимает неделю. Если нужно сократить сроки проекта, то мы можем обратиться в компанию, продающую готовые беседки. Таким образом мы можем получить беседку не за неделю, а за несколько часов. И далеко не всегда такой ход приводит к увеличению бюджета проекта. Самый яркий пример изменения подхода в IT — это отказ от написания собственного решения и покупка готового. Например, не разрабатывать систему управления программой лояльности, а купить готовую и проверенную временем, которая давно стала стандартом в области.
Изменение подхода и покупка готового решения требуют от менеджера опыта и тщательности выбора. В противном случае можно потратить месяцы на интеграцию стороннего решения лишь для того, чтобы понять, что оно не подходит.
Произвести переоценку зависимостей. Допустим, вы можете начать разработку ПО только после того, как купите мощный сервер. Это зависимость «Финиш — Старт». Дело в том, что сервер могут доставить только через три месяца. Может быть, не стоит терять это время и лучше попробовать начать разработку сейчас на том оборудовании, что есть, или арендовать сервер со схожими характеристиками? Вполне вероятно, что уже к моменту доставки сервера все будет готово и можно будет начать тестирование созданного продукта.
Обратите внимание, что все вышеперечисленные методы сокращения расписания нужно применять к задачам, находящимся на критическом пути. Сокращение задач вне его может никак не повлиять на сроки сдачи проекта в целом.
Что делать, если проект опаздывает и не укладывается в расписание
Мы разобрались с тем, что делать, если расписание проекта не укладывается в сроки еще на этапе планирования. А что делать, если уже идущий проект не вписывается в планы? Ответ простой: переделывать изначальное расписание проекта, используя те же методы. Здесь есть нюансы, которые нужно знать.
У слома расписания, особенно на поздних этапах проекта, существуют негативные последствия. В нашей практике был вот какой случай. Для завершения работ проекта по разработке программного обеспечения требовалось два месяца, а остался только один. И неопытный менеджер предложил удвоить размер команды, чтобы успеть в срок. В подобных проектах это большая ошибка: после такого изменения производительность команды резко падает, потому что приходится отвлекаться на обучение новичков. Графически это можно проиллюстрировать следующим образом (рис. 45).
Давайте разберем, что отображено на графике.
Команда работает на своем плато производительности. При добавлении новых людей ребятам приходится тратить время на их обучение, и это ведет к потере производительности. На графике мы заштриховали эту потерю темным. Только через некоторое время новички смогут выполнять первые задачи самостоятельно — производительность команды начинает расти. Прирост производительности мы заштриховали светлым.
Здесь главный вопрос — когда планируется заканчивать проект? Если окончание близко, то добавлением людей можно сделать только хуже. Если до завершения еще далеко, то улучшенная производительность увеличенной команды в какой-то момент перекроет время, потраченное на обучение новичков. То есть площадь прироста производительности (светлый штрих) будет больше площади потери производительности (темный штрих). В такой ситуации уже можно выиграть.
Есть еще один вариант — прибегнуть к овертаймам и попросить команду поработать сверхурочно, но эта мера хороша лишь в качестве временной. В конце концов продуктивность сотрудников, месяц работающих в полторы смены, обязательно упадет. Команда устанет, и ее производительность рухнет. В худшем случае команда просто выгорит и потеряет интерес к проекту.
Овертайм помогает увеличить продуктивность, но его лучше не внедрять дольше, чем на одну-две недели. В крайних случаях можно попросить команду поработать на выходных. Но не забывайте, что команде нужен отдых и энергия на новую рабочую неделю. Вместо рабочих выходных можно оставаться на несколько часов дольше в течение рабочей недели.
Вышеперечисленные методы работают, и часто после адаптации расписания опаздывающий проект удается сдать в срок. Славянским народам в принципе свойственно умение в нужный момент мобилизоваться и очень эффективно справиться с горой накопившейся работы.
Несколько советов по работе с расписанием проекта
Знание критического пути помогает менеджеру понять, на какие операции следует обратить внимание в первую очередь. Необязательно помнить обо всех задачах сразу, но в уме нужно постоянно держать текущую и следующую задачи критического пути — про них нельзя забывать ни при каких обстоятельствах.
Отличное решение — вовлекать команду в формирование расписания проекта. Если команда помогает менеджеру, то у нее впоследствии не будет вопросов, откуда взялись те или иные сроки. Здесь работает тонкий психологический момент: если команда сама назвала сроки, то ей сложно потом спорить с ними. Следовательно, команда сделает все, чтобы выполнить обещанное.
При планировании расписания нельзя использовать такие инструменты, как овертаймы, так как в критический момент не останется пространства для маневра.
