Вовремя и в рамках бюджета. Управление проектами по методу критической цепи
Шрифт:
Значительной доли внимания удостоились легкие, или гибкие (agile), методы, предлагаемые для решения проблем, характерных для проектов, связанных с информационными технологиями. В Википедии говорится [7]: «Методы Agile возникли в середине 1990-х годов отчасти в противовес чрезвычайно формализованным методам, таким как Rational Unified Process (рациональный унифицированный процесс, RUP), Prince6, ISO 9000. Процессы, порождаемые данными методами, считались бюрократизированными, медленными, противоречащими стилю командной работы, принятой у инженеров, создающих ПО». Сторонники иногда называют этот подход «бережливое управление проектами» по аналогии с «бережливым производством».
1) быструю разработку приложений;
2) параллельную разработку приложений;
3) экстремальное программирование;
4) SCRUM7.
Подробное рассмотрение этих методов не является нашей целью.
Я все же с изрядной долей скептицизма воспринимаю объяснения типа «традиционное управление проектами не подходит для ИТ-проектов» как причину появления облегченных, или гибких, методов. От людей, по-настоящему, профессионально разбирающихся в управлении проектами (имеющих сертификат РМР), я подобных заявлений не слышал. Так, Дэвид Андерсон [8, с. 55] пишет:
«В традиционном подходе при запуске проекта главная задача — четко определиться с содержанием, зафиксировать бюджет (включая людей и ресурсы) и дату окончания работ. На этом основании стоит классическая модель управления проектами PMI, поддерживаемая тяжеловесными методами контроля качества ISO 9000... что создает для менеджеров ИТ-проектов наихудшие условия при разработке софта. Существующая модель управления проектами по PMI/ ISO 9000 устарела» (с. 60).
Несмотря на то, что далее Андерсон демонстрирует искусный подход к внедрению ССРМ в ИТ-проектах, по моим личным наблюдениям за ИТ-компаниями, столкнувшимися с трудностями при реализации проектов, многие из них не понимают традиционной методики, а если и применяют ее, то неправильно. Основные ошибки: неполное исходное определение содержания проекта (например, нет иерархической структуры работ) и использование неэффективного процесса управления изменениями или вообще полное отсутствие такового. Часть методов, которые называют альтернативой тяжеловесным технологиям РМВОК, на самом деле в этом своде знаний описаны. Наиболее яркий пример — подход «ускоренная спиральная разработка прототипов». И хотя гибкие методологии довольно эффективны в работе небольших команд над несложными системами программного обеспечения, я считаю, что в отношении масштабных проектов они играют скорее вспомогательную роль и не заменяют комплексных подходов, описанных в РМВОК и ОРМ3.
Приведу несколько соображений насчет «гибкого» управления в ситуации, когда требования определены не четко. Во-первых, такие стандарты,
как РМВОК и ОРМ3, не требуют досконального соблюдения всех своих предписаний абсолютно во всех проектах в каждой организации. Это некое меню, из которого можно выбирать и которое можно адаптировать к нуждам конкретной компании. Да, люди склонны применять подобные стандарты буквально и целиком, увязая в деталях, но проблема-то при этом не в стандарте, а в его использовании. К счастью, уже в самом начале карьеры я научился легко адаптировать такие стандарты к конкретным проектам, указывая в каждом плане проекта те процедуры, которые применимы в данном случае. Я понял, как использовать проверочные списки, чтобы быстро отбирать самое необходимое для конкретного проекта. В небольших, краткосрочных и малобюджетных проектах особые формальности не нужны и требуются очень простые приемы планирования и коммуникации. Проекты крупные, длительные, дорогие, с вовлечением большого количества подразделений и организаций должны быть более формализованы, тщательнее спланированы и строже контролируемы.
Во-вторых, бывают проекты, задачу которых при запуске невозможно сформулировать целиком и полностью. К ним относятся многие проекты в сфере информационных технологий. Во многих случаях детали того, что предстоит сделать, в самом начале неясны, например при ремонте, техобслуживании или разработке нового лекарства. В таких проектах результаты первых шагов могут изменить последовательность дальнейших действий, и к подобным ситуациям наилучшим образом подходит планирование методом
Для контроля за происходящими переменами, в том числе для уточнения исходных условий во всех проектах должен существовать эффективный процесс управления изменениями . Управление изменениями — ключевая составляющая гибкого управления проектами. Управлению изменениями посвящены особые разделы РМВОК. Менеджеры ИТ-проектов часто жалуются на непрерывные неконтролируемые корректировки проектного задания — на «сдвиг содержания» (scope creep). Я им объясняю, что в моих проектах все корректировки задания контролируются и что, на мой взгляд, потеря контроля — это проблема, которая связана с неопытностью самого менеджера, не использующего эффективные методы управления изменениями. Многие сами признают это, объясняя бесконтрольность сложившейся ситуации тем, что при запуске проекта не были определены должным образом исходные установки и границы содержания или со всеми вовлеченными сторонами не были оговорены соответствующие важные процедуры. В дальнейшем, начав контролировать изменения, менеджеры замечают, что проекты, к их удивлению, становятся более управляемыми и появляется возможность успешно завершать их в срок.
И наконец, выполнение проектов в максимально короткие сроки сокращает общие потери, в частности потери, вызываемые происшедшими изменениями, которые воздействуют не только на планы, но и на ранее достигнутые результаты. ССРМ способствует большей гибкости проектных организаций в их реакции на изменяющиеся потребности и служит дополнением ко всем гибким методологиям.
Существует несколько подходов к управлению качеством.
Концепция шести сигм была разработана в компании Motorola, но приобрела известность благодаря General Electric. Она дополняет принципы всеобщего управления на основе качества TQM.
Премия Малкольма Болдриджа в США8 — признание высочайших достижений в бизнесе. Изначально она базировалась на TQM, но сейчас границы ее расширяются.
ISO 9000 — международный стандарт качества, внедренный многими компаниями. На сайте премии Малкольма Болдриджа [9] приводится сравнение данных подходов:
«Хотя и критерии премии Болдриджа, и сертификация по ISO9001:2000, и шесть сигм являются системами измерения качества, нацеленными на совершенствование работы и увеличение степени удовлетворенности клиентов, но акценты в них расставлены по-разному.
Шесть сигм:
• концентрируются на измерении качества продукции и совершенствовании проектирования самих процессов;
• призывают к улучшению всех процессов и сокращению расходов.
Сертификация по ISO 9001:2000:
• представляет собой модель для объективной оценки соответствия продукции и услуг требованиям рынка;
• концентрируется на исправлении недостатков системы обеспечения качества продукции и услуг.
Критерии премии Болдриджа:
• фокусируются на достижении совершенства в работе всей организации через общие процессы управления;
• устанавливают и отслеживают общезначимые организационные результаты: клиенты, продукция и услуги, финансы, человеческие ресурсы, эффективность организации».
Из литературы может сложиться впечатление, будто TQM — это управленческая причуда, не оправдавшая возлагаемых на нее надежд и к концу столетия не нашедшая широкого применения. В опубликованной недавно книге о шести сигмах [10, с. 43-49] утверждается, будто шесть сигм решают все проблемы, с которыми не справилась концепция TQM. Я тем не менее полагаю, что TQM весьма эффективна, если применять ее правильно, а шесть сигм — часть продолжающегося процесса по совершенствованию TQM.