Новое в управлении проектами (стр. 1 из 2)
М. Якубович
Идея написания этой статьи родилась после размышления о том, какие действительно радикальные и инновационные концепции я встречал в литературе по управлению проектами за последние несколько лет. Мозг мой скрипел, морщины на лбу становились все более отчетливыми, но в итоге мне удалось кое-что вспомнить. И я отважился выпустить в информационный эфир краткий дайджест этих концепций.
Пожалуй, первое, что мне удалось вспомнить - это метод критической цепочки, предложенный Э. Голдраттом. Метод позволяет решить ряд проблем в управлении сроками проекта.
Какие проблемы в управлении сроками нам известны?
1. Необходимость сфокусированности на наиболее важных задачах проекта
В проекте обычно очень много задач и в том случае, если их тысячи, появляется желание узнать, какие задачи оказывают наибольшее влияние на длительность проекта и срыв которых приведет к увеличению сроков проекта. Эту проблему ученые решили примерно полстолетия назад, придумав метод критического пути для расчета параметров сетевого графика и операций, срыв сроков которых приведет к срыву сроков всего проекта. Операции, не лежащие на критическом пути, имеют резерв времени, на который они могут быть задержаны без влияния на сроки всего проекта. Таким образом, внимание руководителя проекта всегда сфокусировано на задачах критического пути. Однако, вскоре после начала применения метода критического пути стало понятно, что он имеет довольно серьезное ограничение – в расчетах параметров сетевого графика не учитывается загрузка ресурсов, необходимых для выполнения задач. Возникают ситуации, когда один и тот же человек должен одновременно работать над несколькими задачами, стоящими в графике параллельно (например, 24 ч в сутки). Для решения этой задачи в некоторых пакетах программного обеспечение для календарного планирования проектов используют алгоритмы выравнивания ресурсов, хотя существуют и пакета ПО, где рассчитывается ресурсный критический путь.
2. Буфер времени в каждой операции
Э. Голдратт в своей книге утверждает, что обычно исполнители, делающие оценку трудозатрат на выполнение работ проекта, перестраховываются и закладывают временной буфер. Из собственного опыта работа в проектах и анализа оценок трудозатрат могу подтвердить, что большинство людей действительно являются перестраховщиками.
3. Не поощряется раннее исполнение работ
В большинстве проектов действительно не поощряется раннее выполнение работ. Почему? Да потому, что даты задач-последователей уже спланированы и люди, назначенные на их исполнение, тоже имеют свои планы на другие дни. Значит, если кто-то закончил задачу ранее, то он, скорее всего, даже не сообщит об этом: зачем подводить своих коллег?
4. Студенческий синдром
Этим синдромом болеют многие из нас, разрешая себе приступать к работе в самый последний момент, когда ее уже надо сдавать.
5. Мультипроектность
В компании обычно идет несколько проектов и один сотрудник может работать одновременно в нескольких проектах. Возникает необходимость координировать планы нескольких проектов, работающих на общих ресурсах.
6. Вариабельность
Оценка трудозатрат имеет вероятностный характер, это значит, что ошибка в оценке накапливается по цепочке работ и вероятность завершения последней работы в срок стремится к нулю.
7. Фактор Мерфи
Если что-то страшное может случиться при выполнении задачи проекта, это обязательно случится.
8. Закон Паркинсона
Работа будет длиться столько времени, сколько на нее отведено руководителем.
Э. Голдратт положил в основу решения проблем со сроками свой известный метод теории ограничений и предложил следующий алгоритм планирования сроков проекта:
1. Построить критический путь проекта
2. Учесть ограничения по ресурсам
3. Убрать временной буфер из каждой операции
Для этого можно просто сократить трудозатраты, заявленные исполнителем на выполнение работы, скажем, на 50%
4. Добавить временной буфер в конец проекта
Суммировать временной буфер всех операций, лежащих на критическом пути, и вставить его последней операцией на критическом пути
5. Добавить временной буфер перед критическими операциями
Для этого надо суммировать временной буфер по «питающей цепи» (цепи, последняя операция которой вливается в критический путь) и вставить его последней операцией перед операцией критического пути
6. Контроль расходования буферов по ходу проекта
Для этого достаточно использовать очень простой показатель: отношение величины временного буфера (в днях) к длине критического пути (в днях). Как только это отношение снижается ниже установленного норматива – надо вносить корректирующие действия.
Второе, о чем мне посчастливилось узнать из статей и приватных бесед – это новый подход к автоматизации бизнеса, основанный на инфороботах. И мне кажется, что этот подход действительно изменит бизнес, как утверждает его автор С. Трушкин.
Инфороботы – некие сущности, появление которых в нашем жизненном пространстве по заявлениям некоторых инноваторов (см. статьи «Третья научная революция», «Инфороботы») резко изменят бизнес. Моя статья как раз направлена на то, чтобы предугадать, как инфороботы повлияют на некоторые методы управления проектами.
Итак, выше я уже привел описание проблемы, с которой сталкивался управляющий проектом при управлении сроками – необходимость сфокусированности на самых приоритетных работах проекта. Как определялись эти самые важные работы среди длинного списка работ, мы уже разобрались – для этого использовался метод критического пути, а позже был предложен метод критической цепочки. С чем была связана необходимость сфокусированности? Одной из причин является ограниченность внимания человека, которая описывается так называемым числом Миллера (средний человек может одновременно держать в памяти 7+- 2 объектов). Но ведь пятьдесят лет назад у человека появился серьезный помощник – компьютер, который должен был решить эту проблему. Не решил. А почему? Потому что все современные программные продукты, связанные с хранением и обработкой данных, основаны на пассивных записях – пока менеджер не обратит внимание на запись, он про нее не вспомнит. А если и вспомнит, то у менеджера есть воля – свобода принятия решения делать что-то по проблемной записи или нет.
Что такое инфороботы и что они изменят в сложившейся ситуации? Проведу параллели с десятью шагами проектирования и создания систем управления, основанных на инфороботах (см. «Как создавать и автоматизировать бизнесы в Inforoad»).
Начнем с метода создания сетевого графика.
Как создавался ранее сетевой график? Разрабатывалась иерархическая структура работ (ИСР, СДР, WBS), далее работы нижнего уровня иерархии ИСР объединялись в цепочки связанных работ отношениями последовательности выполнения работ. После этого, с помощью МКП рассчитывались параметры операций, определялись даты раннего и позднего старта и финиша, резервы времени, критический путь.
Какая может быть альтернатива у этого метода? Да, пожалуйста, начнем с подхода к созданию сетевого графика.
Для выполнения проекта нам надо, чтобы ресурсы проекта проходили стадии последовательной обработки и были приведены в итоге работа к целевому состоянию.
Приведу пример: строительство нового многоэтажного дома.
Для реализации этого проекта нужно огромное количество ресурсов: люди, оборудование, строительные материалы, площадка для застройки и т.д. В итоге мы должны получить дом, соответствующий требованиям к нему (спецификациям).
Итак, шаги по построению сетевого графика:
1. Делаем перечень всех необходимых для реализации проекта ресурсов
2. Для каждого ресурса описываем его жизненный цикл и строим ресурсную (маршрутную) карту
3. Нужный результат будет получен только в том случае, если все ресурсы в нужный момент готовы для преобразования. Поэтому выявляем временную зону, в которую ресурсы должны попадать одновременно (синхронно). Только если в этом временном промежутке все требуемые ресурсы находятся в требуемом состоянии, происходит запланированное преобразование основного продукта проекта из одного состояние в другое.
4. Нормируем время переходов ресурса в каждое состояние в маршрутной карте. Определяем точки пересечения ресурсов, получаем сетевой график.
На рисунке представлен фрагмент сетевого графика, на котором отображена Карта состояний дома, как основного продукта проекта, и маршрут одного из необходимых видов оборудования для строительства дома – опалубки. В какой то запланированный момент времени опалубка должна быть поставлена в нужном количестве и ассортименте на объект строительства, иначе сроки строительства коробки дома будут сорваны.
Хорошо, скажете Вы, а как же быть с определением критического пути, ресурсного критического пути? В случае использования инфороботов это не нужно.
Инфороботы – активные записи в компьютерной памяти, которые создаются с целью отслеживания состояния конкретных ресурсов. Целью жизни Инфоробота является привести ресурс в требуемое владельцу состояние. При этом инфоробот не только контролирует состояние ресурса но и активно воздействует на участников процесса обработки.
Что же происходит дальше при использовании инфороботов при планировании и отслеживании проекта?
5. Записываем все требуемые данные внутрь специальных документов, описывающих будущих роботов. Программируем среду
6. Нанимаем людей для обработки ресурсов в каждой намеченной нами точек обработки. Каждый из нанятых людей отслеживается своим инфороботом, так как это так же ресурсы системы. У каждого сотрудника есть контракт и бюджет времени по компетенциям (ролям). Соотвествующие инфороботы следят и за этим как за любым другим ресурсом компании.