В продолжение постов про базовые вещи в управлении проектами – сегодня пост про такую популярную концепцию как критический путь проекта.
Как и все в управлении проектами, критический путь – это простая в своей гениальности вещь. Если представить проект как набор взаимосвязанных задач, то критический путь – это самая длинная цепочка последовательно выполняемых задач от начала до конца проекта. Соответственно, если время какой-то задачи НЕ из этой цепочки увеличится – то на общий срок проекта это не повлияет. Но если время любой задачи на критическом пути вырастет хотя бы на день – соответственно сдвинется срок всего проекта. Поэтому-то эта цепочка и называется критическим путем.
Как видите, все просто – руководитель проекта должен знать, какие задачи в его проекте лежат на критическом пути и обеспечить их выполнение вовремя, иначе сроки проекта поедут. Вот и все. Конечно, есть нюансы, но о них ниже.
Как построить критический путь проекта
Определить критический путь проекта очень просто:
- Составить список всех работ в проекте и их длительности (тут, как вы помните, пригодится WBS). В моем любимом примере с ремонтом в списке работ будет: снос межкомнатных старых стен, возведение новых, штукатурка, поклейка обоев, устройство электрики, разводка воды, укладка ламината и т.д. На этом этапе наша цель – получить исчерпывающий список работ и понимание того, сколько займет каждая из них – на штукатурку нам надо 3 дня, на электрику – 10, на ламинат – 4 и так далее.
- Определить, как работы связаны друг с другом. Ну, например, какое условие начала работ по электрике? Наверное, как минимум, возведенные стены? Стены есть – можно начинать. А условий поклейки обоев уже больше – к этому можно будет приступить в самом конце, когда и ламинат уже уложен, и электрика смонтирована, и, конечно, стены оштукатурены и прошпаклеваны. К слову, есть разные типы связей (одна работа может начаться только после окончания другой, только одновременно с другой и т.д.), но на этом этапе не будем усложнять. Выписать это можно в Excel или в MS Project, пронумеровав работы и проставив рядом с каждой их них номера тех работ, завершение которых необходимо для ее старта.
- Дальше методология говорит нам, что нужно разработать сетевой график – от руки на листочке в кружочках написать номера работ, соединить их стрелочками в зависимости от того, какая работа за какой идет, и на входящих в работу стрелочках написать длительность этой работы. Ну или не от руки, а в любом программном обеспечении (не закрывайте пост, это для понимания, в жизни никто в здравом уме это вручную не делает, конечно!). Выглядит готовый сетевой график примерно так (картинки, как всегда из яндекса):
Теперь мы можем подсчитать, какая цепочка самая длинная и выделить это цветом. На графике ниже это работы 1-4-5.
Ну все, поздравляю, вы определили критический путь проекта. Теперь вы знаете, что срок проекта зависит от задач 1, 4 и 5, “поедут” они – “поедет” весь проект. Значит, им все внимание.
При построении сетевого графика есть много нюансов (например, на график можно наносить сразу несколько оценок длительности – оптимистичную, реалистичную и пессимистичную, можно использовать разные типы связей и проч.), но если вы читаете этот пост – скорее всего, вы недавно в профессии руководителя проекта. Поэтому не будем перегружать пост деталями, которые понадобятся вам только через некоторое время (и то не факт, что вообще понадобятся). В любом случае, если захочется романтических подробностей – их всегда можно найти в том же PMBOK.
В жизни сетевые графики, конечно, никто не рисует, тем более – от руки. В лучшем случае задачи с зависимостями вносят в MS Project, а он строит все автоматически, в худшем – используют Excel и делают это от руки с риском допустить ошибку. Для тех, кто знает толк – в сети можно найти даже макросы, которые построят все в Excel за вас, но я не могу понять, зачем нужно это садо-мазо.
Более того, в 90% случаев даже опытный руководитель проекта посмотрит на сетевой график, автоматически построенный в MS Project, и спросит “что это за хрень?”, так как отраслевым стандартом представления критического пути давно стала диаграмма Ганта.
Вот так выглядит сетевой график в MS Project. Не очень, правда?
Ниже будут примеры того, как построенный критический путь выглядит в MS Project в форме диаграммы Ганта. Если доступа к MS Project у вас нет – то же самое умеют многие бесплатные и платные планировщики проекта, подробнее можно посмотреть в посте про диаграмму Ганта.
Примеры критического пути
Поискала в яндексе, там, как всегда, много некорректных примеров, но все-таки отобрала несколько вменяемых в форме диаграмм Ганта, построенных с помощью MS Project. Мне эта визуализации кажется наиболее простой для восприятия. Как уже говорилось выше, технически в MS Project можно построить и полноценные сетевые графики, но это точно не нужно начинающим (да и продолжающие, будем честными, очень редко их используют).
Красным цветом MS Project автоматически подсвечивает задачи на критическом пути, если открыть нужное представление, это очень удобно.
Пример 1:
Пример 2:
Пример 3:
Ну классно же, сразу понятно, на чем концентрировать усилия!
Еще по этой теме в блоге есть ссылка на отличное видео про управление проектами в СССР, рекомендую посмотреть, чтобы разобраться лучше, так как с тех пор ничего особо не поменялось.
Использование критического пути на практике
Как обычно – несколько мыслей из практики о типовых ошибках при использовании критического пути в проектах:
- Не стоит забывать про вторичный критический путь. Я выше написала, что руководитель проекта должен в первую очередь концентрироваться на задачах критического пути, так говорит нам любая методология управления проектами. Практика с этим не спорит, конечно, но дополнительно считает, что обязательно надо работать с задачами, которые при планировании проекта вроде бы лежат вне критического пути, но могут оказаться на нем при относительно небольшой задержке их выполнения. Возвращаемся к ремонту – например, на критическом пути у нас разводка труб в санузле -> укладка плитки -> установка ванны и унитаза. Вне критического пути лежит задача “закупка плитки” и вроде бы ремонт только начался, времени еще полно, плитку же можно купить впритык к моменту ее укладки (если строго следовать методологии). Но хороший прораб (и хороший руководитель проекта) при оценке рисков сразу видят, что если что-то пойдет не так и закупка или доставка задержится – все сроки ремонта санузла сдвинутся. Поэтому стоит начать закупку пораньше, чтобы эта задача не превратилась в задачу на критическом пути. Это пример именно про конкретную задачу, но при оценке может оказаться, что у вас формируется несколько практически независимых цепочек (например, на общий срок ремонта всей квартиры влияет как срок ремонта в санузле, так и срок разводки электрики). На форумах или в чатах можно встретить неофициальные термины “вторичный критический путь”, речь как раз об этом.
- Не стоит высчитывать критический путь вплоть до дня. Этот пункт связан с пунктом выше, бывает, что при определении критического пути разница между несколькими его вариантами составляет буквально несколько дней, и за критический путь принимается цепочка, которая буквально на день-два (или неделю-две) больше альтернативной (опять же, в строгом соответствии с методологией). Но проект – живой организм, “точно как запланировано” все проходит очень-очень редко, поэтому при небольшой разнице лучше сразу честно признать, что обе цепочки – это и есть ваш критический путь, и уделять им обеим повышенное внимание. Иначе с вероятностью, близкой с 100%, эта бомба рванет в самый неподходящий момент.
- Не стоит думать, что критический путь интересен только руководителю проекта. В любой более-менее опытной проектной команде все исполнители знают, что такое критический путь, и что когда руководитель проекта говорит “эта задача на критическом пути” – это значит, что у нее приоритет номер один. Если вы не уверены, что ваша команда это знает – потратьте 5 минут, расскажите о концепции критического пути, покажите, как выглядит критический путь именно в вашем проекте, какие задачи туда попали, и чего вы ждете от тех, кто будет их выполнять. Честное слово, оно того стоит, ну и людям будет приятно узнать что-то новое.
- Не стоит считать, что критический путь “вырублен в камне”. В мире с правильной методологией вы, конечно, должны были максимально оптимизировать критический путь еще до старта проекта, но если с вас никто не требовал уменьшить спланированные сроки, то, скорее всего, вы же не напрягались, правда? Часто можно видеть, что и сам руководитель проекта стрессует и команду доводит, если на критическом пути что-то идет не так, но почему-то не делает никаких попыток этот самый критический путь как-то сократить, чтобы “вытащить” ранее согласованные сроки. Почти всегда при желании возможность для оптимизации найти можно, если глаз уже замылен – посоветуйтесь с соседом-РМом, руководителем, командой, решение точно найдется.
- Не стоит оставлять в проекте “плавающие задачи”. В любом проекте есть задачи, вроде бы сильно не связанные с другими, и чаще всего они остаются просто в списке задач, жестко не привязанные к другим (это, кстати, тот случай, когда методология на 100% права, когда говорит, что ВСЕ задачи должны иметь вход и выход, просто ей в этом вопросе большинство не следует). В итоге про них забывают и в конце проекта они стреляют как то ружье, которое стояло в углу. Например, в ремонте такой задачей может быть “опломбировать счетчики”. Ну а что, сделать можно в любой момент проекта, точно не на критическом пути, до конца ремонта точно дойдем. Но при метаниях между выбором плитки и заливкой пола все как-то не до этого, и вроде бы ремонт уже закончен, а мы счетчики так и не опломбировали, кучу денег за это время потратили зря, оплачивая воду по нормативам, да еще и оказалось, что в управляющей компании очередь на опломбировку на 3 месяца. В итоге проект закрыть не можем, деньги в прямом смысле слова “капают”, в голове нужно все это продолжать держать и т.д. А всего лишь надо следовать простому правилу – любая задача должна быть связана с другими. Это прямо в камне проектного управления надо высечь.
Ну вот, наверное, и вся программа-минимум про критический путь. Хотела запихнуть в этот же пост информацию по способам оптимизации критического пути, но поняла, что это тянет на отдельный пост, так что как-нибудь в другой раз.
Используете метод критического пути в своих проектах? Расскажите в комментариях здесь или в телеграме!
Добавить комментарий