Лекция 4. Принципы построения системы деятельностей программного проекта

Обсуждаются понятия теории деятельности, полезные для изучения ме­неджмента разработки программных изделий. На этой базе определяется ме­сто менеджмента в системе деятельностей программного проекта и задача соблюдения баланса между временем выполнения, объемом работ и расходом ресурсов при соблюдении требований к качеству.

Ключевые слова: деятельность, производственная функция, испол­нитель производственной функции, разбиение производственной функции, проектная деятельность, субъект деятельности, цель дея­тельности, материалы и ресурсы деятельности, средства и инстру­менты деятельности, методы деятельности, результат деятельности, система деятельностей, проектная деятельность, автоматизирован­ная деятельность, автоматическая деятельность, стандарт РМВОК, процесс, группа процессов, процессы инициирования, процессы планирования, процессы контроля, процессы исполнения, процес­сы завершения, деятельность менеджера, треугольник менеджмента проектов, методический шаблон работы менеджера, операционный маршрут, траектория, привязка маршрута к роли, обстановка дея­тельности, окружение деятельности.

Обычно в публикациях по вопросам управления программными проектами описывается набор методик, применяемых в тех или иных слу­чаях. Эти методики связываются с одной из общепринятых или с автор­ской концепцией возможных вариантов процесса разработки программ­ного изделия, именуемой методологией. Претендующие на объективность книги содержат также оценки, когда применение излагаемых методик оп­равданно, а когда оно неприемлемо (см., например, [27]). Иногда изложе­ние иллюстрируют условными или даже реальными разработками, чтобы продемонстрировать использование методик в комплексе (см. [11] и [27]). А нередко авторы просто рекламируют свою линию организации управ­ления, не заботясь о границах ее применимости (из этических соображе­ний мы не станем приводить соответствующие примеры, хотя это и легко сделать). Но во всех случаях у читателя чаще всего остается неудовлетво­ренность: он не в состоянии определить, выполнены ли условия примене­ния какой-либо методологии или методики, или понять, что делать, когда такие условия не выполнены. Между тем последнее весьма типично, осо­бенно для проектов, замысел которых не сформулирован в виде четко по­ставленной задачи. Положение усугубляется тем, что любая программная разработка уникальна по своей сути, по условиям выполнения проекта, а потому применение методологии и методик требует их адаптации.

Преодолению трудностей понимания и внедрения методик может помочь общая понятийная база рассмотрения производства программно­го обеспечения, которая не будет привязана к конкретным методологиям, а позволит выделить процессы в разработке программ, в той или иной ва­риации выполняемые при любом подходе, в любой методологии. После­дующее изложение посвящено построению такой базы. Основой для по­строения служит теория деятельности и ее приложение к проектировоч­ной деятельности, разработанные Г.П. Щедровицким [29]. Положения теории деятельности адаптированы к предметной области управления программными проектами.

Производственные функции и исполнители

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

• Можно структурировать выполнение функции, разбивая ее на со­ставляющие, определяя назначение каждой из составляющих и связи между ними так, чтобы результат совместного выполнения совпадал с требуемым результатом разбиваемой функции.

• Можно структурировать обобщенного исполнителя, иными слова­ми, конкретизировать исполнителей, отвечающих за разные аспек­ты выполнения функции.

Оба вида разбиения производственных функций допускают продол­жение в глубину: для исполнителей — до уровня групп исполнителей и конкретных индивидуумов, для функций — до таких фрагментов, кото­рые рассматриваются как неделимые единицы действий. Оба они сущест­вуют одновременно и взаимосвязано.

Разбиение проекта на составляющие двух видов не является незави­симым и однозначным хотя бы потому, что к исполнителям различных функций предъявляются разные квалификационные требования. Есть и другие причины, из-за которых приходится говорить о вариативности структурирования проектов. Так, поскольку целью любой программной разработки является удовлетворение потребностей пользователей, а сами эти потребности со временем меняются (об этом речь впереди), то испол­нителям приходится постоянно адаптировать проект к новым потребно­стям. Меняются и условия, в которых производится разработка, и эти из­менения также нужно учитывать при управлении проектом.

Процесс выполнения проекта представляется как целенаправлен­ная динамическая система деятельностей, реализующих производствен­ные функции посредством их реализации исполнителями, которая раз­вивается во времени. Целенаправленность здесь означает определен­ность задач, для решения которых выполняется каждая из функций на всех уровнях разбиения, а динамичность — изменчивость структуры (разбиения) в ходе развития в соответствии с потребностями решать те или иные задачи.

Системы и элементы проектных деятельностей

Динамика — одна из основных характеристик процесса развития проекта, которая наряду с разбиением функций позволяет рассматривать проект как систему взаимосвязанных целенаправленных видов деятель­ности субъектов-исполнителей, выполняющих функции. С точки зрения теории деятельности каждая работа этой системы характеризуется следу­ющими элементами.

• Субъект — исполнитель деятельности, обладающий определенны­ ми качествами и возможностями, позволяющими заниматься ее выполнением. Субъекты, исполнители программных проектов, могут быть индивидуумами либо группами индивидуумов. Для де­ятельности, рассматриваемой в некотором ракурсе как неделимой, структура субъекта-исполнителя также не рассматривается. Если же деятельность структурируется, то возможны варианты. В жест­ких подходах к проектированию планирование часто распространяют до индивидуальных заданий, гибкие методологии не требуют рассмотрения структуры субъекта-исполнителя (пример — рабочая группа MSF).

(Кратко: субъект — это тот, кто в состоянии выполнять данную де­ятельность.

• Цель — назначение деятельности, явно выделяющее направление ее развития. Цель деятельности всегда соотносится с другими состав­ляющими системы деятельностей: какое место данная деятельность занимает в системе, как и в каком качестве используются результа­ты деятельности в других проектных и внешних деятельностях.

|| Кратко: цель — это то, для чего данная деятельность выполняется.

• Материалы и ресурсы — то, что используется и перерабатывается при выполнении деятельности. Термин «материалы» чаще исполь­зуется, когда аспект расходования не представляет интереса для рассмотрения или отсутствует вовсе. Пример — спецификации программного изделия используются, но, естественно, не расходу­ются в разных видах деятельности по производству программ: как задание на разработку, как эталон для проверки готовой програм­мы, как основа составления документации и т.д. Ресурсы можно определить как расходуемые материалы.

В ходе выполнения деятельности используются средства связи, элек­троэнергия, другие универсальные ресурсы. Кроме того, в деятельно­сти используется оборудование, программы, без которых данное производство невозможно. Это специальные ресурсы, характеризую­щие определенные виды деятельности. Наконец, необходимыми для осмысленной деятельности являются материалы. Применительно к информационным видам деятельности это сведения о предметной области, о потребителях результатов и их нуждах. Все подобное отно­сится к специфичным материалам и ресурсам, выделяющим данную деятельность как ориентированную на продуцирование конкретных результатов. Важным и определяющим для программистcкой дея­тельности видом специфичных материалов являются требования к программному изделию. Они в большей степени, чем что-либо иное, указывают на назначение конкретной деятельности. Кратко: материалы и ресурсы —- это то, из чего в данной деятельно­сти продуцируются результаты.

Одни ресурсы выделяются под проект или под данную деятель­ность, другие разделяются, т.е. используются совместно в несколь­ких деятельностях. Есть расходуемые ресурсы, потребление кото­рых не ограничено. В принципе, ресурсы проекта могут быть сведе­ны к финансовому обеспечению. Но это не всегда удобно, в частно­сти, по той причине, что вполне реальны ситуации, когда ресурсы некоторых проектных деятельностей готовятся в рамках выполне­ния других деятельностей.

В ряде аспектов планирования время можно рассматривать как рас­ходуемый и ограниченный ресурс. Так мы поступали, описывая за­дачи менеджмента в целом (см. лекцию 1). Эта позиция теряет силу, когда надо представлять деятельность как развивающийся процесс, взаимодействующий с другими процессами. В этих случаях следует говорить о событиях, о синхронизации, об обмене данными и т.д. В некоторых аспектах планирования в качестве ресурса продуктив­но рассматривать субъекты, а точнее — их потенциальные возмож­ности, квалификацию, опыт и прочее. Эта точка зрения отражена в данном курсе при обсуждении основных задач менеджера (см. лек­цию 1). Такое рассмотрение удобно при анализе проекта в целом, но для текущих задач оно неприемлемо, так как индивидуализиро­ванное их представление противоречит понятию ресурса. Распределение ограниченных ресурсов — одна из основных задач управления проектом.

• Средства и инструменты. Обычная деятельность предполагает при­менение вспомогательных средств, которые поддерживают ее вы­полнение либо являются необходимыми для получения осмыслен­ных результатов. Средства — общее понятие, отражающее возмож­ность применения объекта в различных деятельностях. Инстру­менты, как правило, специализируются для конкретных видов деятельности. Однако и микроскоп пригоден для забивания гвоз­дей! Данный пример показывает условность разграничения между средствами и инструментами, хотя это и удобно с определенной точки зрения.

Средства и инструменты могут быть внешними по отношению к системе деятельностей проекта или могут разрабатываться в рамках проекта (он предусматривает включение в систему деятельности с соответствующими результатами). В последнем случае нужно раз­личать ситуации, когда разработка ведется с расчетом на независи­мое использование вне проекта и когда внешнее применение созда­ваемых средств и инструментов не предполагается. Кратко: средства и инструменты — это то, с помощью чего в данной деятельности продуцируются результаты.

Методы — совокупность приемов для деятельности данного типа, которые целесообразно применять при ее выполнении, предписа­ний, соглашений и рекомендаций, принимаемых для проекта, ор­ганизации и т.д., регламентов, запрещающих или ограничивающих возможность применения средств, инструментов, других методов, а также задающих ограничения доступа к общим ресурсам. Проект­ные решения, касающиеся методов, при следовании разным мето­дологиям программирования могут быть прямо противоположны­ми. Так, для традиционных методологий обычными являются рег­ламенты разграничения доступа файлам, содержащим интегриро­ванный код разрабатываемой системы, тогда как в рамках методологии экстремального программирования принципиально, что для этих файлов устанавливается общий доступ для всех разра­ботчиков проекта.

Кратко: методы — это то, что указывает на способ выполнения дан­ной деятельности.

В теории деятельности средства, инструменты и методы часто объ­единяют в общее понятие. При таком взгляде метод в том смысле, как мы это определили, представляет собой средство организации деятельности в целом, и применение метода оказывается не чем иным, как специальной деятельностью, являющейся элементом-средством данной деятельности. С учетом методологической на­правленности настоящего курса выделение методов мотивируется тем, что для нас методы являются предметом исследования. ► Результат. При выполнении деятельности субъект-исполнитель со­здает различные продукты, обусловленные и не обусловленные це­лями. Продукты можно рассматривать как материализованные сле­ды деятельности, которые появляются в ходе ее выполнения, в том числе те или иные артефакты. Совокупность всех продуктов, полу­ченных в ходе выполнения деятельности, называется ее результа­том. Результат может содержать продукты, полезные с точки зрения целей проекта и целей деятельности, и бесполезные продукты, не способствующие продвижению проекта к его глобальным целям. Полезность или бесполезность продукта определяется проектными соглашениями. Общий критерий полезности — включение продук­та в другие деятельности системы проекта в качестве атрибута (здесь слово «включение» понимается достаточно широко, например, вли­яние знания, продуцированного при выполнении некоторой дея­тельности, на цели другой деятельности рассматривается как вклю­чение продукта-знания в целевой элемент деятельности). Кратко: результат — это то, что фактически продуцируется в дан­ной деятельности. Любая деятельность есть вполне определенная часть некоторой об­щей системы деятельностей, охватывающей группу субъектов-исполни­телей. Деятельности, субъекты которых не попадают в выделенную груп­пу, являются окружением данной системы. Окружение связано с выделен­ной системой следующими способами:

• из окружения поставляются элементы деятельностей системы;

• деятельностям окружения передаются результаты деятельностей системы;

• система в целом или ее отдельные деятельности являются элемен­тами деятельностей окружения.

Рассмотрение деятельности и системы деятельностей обособленно от других деятельностей — абстрактный прием, позволяющий увидеть структуру деятельности или системы, описать элементы и связи. Предста­вленный список элементов отражает структуру любой осмысленной дея­тельности, а способы связи задают все многообразие систем деятельно­стей. Это представление достаточно содержательно даже на таком абстрактном уровне. Так, с его помощью мы в состоянии дать понятия автома­тической и автоматизированной деятельностей.

Деятельность называется автоматизированной, если она приводит к результатам, которые продуцируются другой, неавтоматизированной де­ятельностью (реальной или, возможно, умозрительной), но с меньшими затратами времени и/или с сокращением расхода ресурсов. Данное опре­деление может показаться излишне общим, охватывающим и случаи, ко­торые интуитивно не представляются как автоматизированная деятель­ность. Можно дать другое определение, которое говорит о сокращении времени и/или расхода ресурсов при выполнении воздействий субъек­том. Нетрудно заметить, что это приводит к необходимости рассматри­вать субъект в качестве (абстрактной) деятельности, выполнение кото­рой приводит к выполнению исходной деятельности. И эта точка зрения вполне правомерна.

Деятельность называется автоматической или, точнее, автоматиче­ски выполняемой, если она имеет неодушевленный субъект, действующий с другими элементами по заданной внешним образом программе. Это то же самое, что вырожденная деятельность, не имеющая субъекта, акт вы­полнения которой осуществляется путем внешней активизации ее един­ственного средства. Третья эквивалентная точка зрения — определение автоматической деятельности как такой, у которой (одушевленный) субъ­ект выполняет единственное воздействие-активизацию. Какое из этих определений использовать, зависит от конкретной ситуации.

Введенные понятия сами по себе почти не связаны со спецификой разработки программного обеспечения. Эта специфика может проявиться при интерпретации системы деятельностей на данной предметной области. Что, собственно говоря, и является предметом обсуждения в данном курсе.

На абстрактном уровне деятельность выполнения любого программ­ного проекта можно изобразить в виде схемы, представленной на рис. 4.1.

Соединения блоков и выделение блока-субъекта означает активность этого блока и пассивность всех остальных, т.е. невозможность выполне­ния деятельности без воздействий субъекта. Здесь все требует конкрети­зации, которая неизбежно приведет к появлению новых деятельностей, связанных с данной. Например, указывая на требования, мы должны по­заботиться о том, какие деятельности их пополняют и обрабатывают, ка­кие средства применяются для продуцирования из этого материала ре­зультата проекта. Использование результата — это встраивание его во внешнюю деятельность пользователя таким образом, чтобы достигалась цель проекта. Подобные, но более содержательные утверждения нужно сделать по каждому из элементов проектной деятельности. В результате такой конкретизации становится явной система деятельностей, в кото­рую погружается проект. Эта система весьма обширна, но для реального управления проектом и эффективного руководства коллективом требует­ся выделить в ней круг деятельностей, на которые можно влиять, дости­гая желаемых результатов. Именно они являются сферой деятельности менеджера (ее материалом). Кроме того, требуется выявить деятельности, которые влияют на проект, задавая его внешние условия и ограничения.

Цель программирования как деятельности можно определить как построение автоматических и автоматизированных деятельностей, а цель методологий программирования — как построение автоматических и ав­томатизированных деятельностей, заменяющих собой неавтоматизиро­ванные аналоги в системе деятельностей программирования.

Для понимания назначения и условий применения различных мето­дик нужно прежде всего распознать место методики в системе проектных деятельностей, рассматривая эту систему максимально широко. В част­ности, не следует забывать и о деятельности тех, кто имеет лишь косвен­ное отношение к проекту (их мы называли в числе инициаторов работ, см. лекцию 2), поскольку по большому счету программистские проекты раз­рабатываются для того, чтобы их использовали, и именно автоматизиру­емая пользовательская деятельность находится в основании того, что на­зывают качеством программного продукта.

В публикациях, посвященных менеджменту проектов, часто говорят не о системе деятельностей, а о процессах, определяя их довольно свободно и неформально. Так, стандарт РМВОК (Project Management Body of Knowledge) института менеджмента проектов РМ1, который фактически является общепризнанным на мировом уровне (достаточно указать на поддержку его со стороны ISO), фиксирует, что «процесс — это серия дей­ствий, приводящая к результату» [48, 49], совсем не заботясь о том, что та­кое «действие» и «результат». ISO 9000 говорит определеннее: «Процесс — любая деятельность, в которой используются ресурсы для преобразова­ния входов в выходы» [39]. Последнее, по-видимому, следует считать об­щепризнанным определением процесса, формализация которого для описания систем процессов представлена в так называемой IDEF-технологии [38]. Отметим, что наше понимание деятельности шире процесса. Оно включает и другие элементы, обычно рассматриваемые неформаль­но, а значит, недостаточно регламентирование Тем не менее с точностью до этого различия в терминологии базовые положения из того, что обсу­ждается и стандартизируется в области менеджмента проектов, можно без особого труда перенести и на понятие системы проектных деятельностей. Так, РМВОК предлагает оперировать понятием группы процессов, опреде­ляя для проектов следующие группы.

• Процессы инициации — начинают проект, определяют для него ис­ходные ресурсы и материалы, цели и все остальные элементы дея­тельности. По существу, это является началом предпроектной дея­тельности.

• Процессы планирования — определяют, какими способами (метода­ ми) предполагается организовать проектную деятельность, на какие сроки и ресурсы рассчитывается проект, на какие вложенные процессы и этапы он разбивается и как предполагается проверять их результаты.

• Процессы исполнения — поэтапное выполнение запланированных процессов в конкретных условиях.

• Процессы контроля — проверка хода процессов и результатов, соот­ветствующая запланированной методике контроля.

• Процессы завершения — то, что должно быть сделано, когда проект завершается.

Схема взаимодействия процессов согласно РМВОК показана на рис. 4.2. В соответствии с этой схемой утверждается взаимосвязь выпол­нения процессов планирования, исполнения и контроля как основного цикла разработки любого проекта. С точностью до того, что мы говорим о деятельностях, а не о процессах, которые абстрагируются от некоторых элементов деятельностей, вводя там, где это необходимо, дополнитель­ные процессы, представленная схема достаточно точно выделяет связи существенных деятельностей системы проектировочных деятельностей, хотя и не охватывает окружение этой системы (о трудностях определения системы и ее окружения мы немного поговорим в следующем разделе). Схема иллюстрирует сущность менеджмента проекта на самом абстракт­ном уровне как деятельность, направленную на организацию и поддерж­ку целенаправленного развития обозначенных на ней групп процессов.

Менеджмент в системе деятельностей проекта

Если сделать интерпретацию системы деятельностей по разработке программных проектов более конкретной, чем простое указание элемен­тов деятельностей, то в системе среди прочих деятельностей должны по­явиться, к примеру, анализ предварительных требований, конструирова­ние архитектуры, составление программного кода, его проверка. Станет понятным, что эти деятельности не могут выполняться в произвольном порядке, поскольку они поставляют друг другу свои результаты и, следо­вательно, зависят друг от друга. Дальнейшая конкретизация проектиро­вочных видов деятельности должна следовать выбранной для проекта ме­тодической установке.

Формирование системы на основе структурирования обобщенного исполнителя приводит к появлению ролей для выполнения производст­венных функций и соответствующих им деятельностей. Соотношение между производственными функциями и системой деятельностью не столь однозначно, как может показаться при поверхностном рассмотре­нии. Причиной тому — трудность определения деятельности как произ­водственной функции, характерная для любых производств, и в частности для производства программных продуктов. Например, с узкопрофес­сиональной точки зрения не является проектной производственной функцией деятельность по обеспечению сотрудников обедами, практи­куемая в некоторых организациях. Но в системе деятельностей, которая охватывает проектные работы, она явно представлена. Сытые работни­ки, сэкономленное ими время — это ее результаты, влияющие на ход вы­полнения проектных заданий. Естественно, что в управленческом аспе­кте менеджмента абстрагируются от подобных функций, однако в плане руководства коллективом она занимает существенное место. Для некото­рых методологий такие виды деятельности считаются принципиальными как способ организации работ. Например, Бек рассматривает стратегию организации рабочего места команды исполнителей проекта по экстре­мальной методологии в качестве одного из решающих факторов успеш­ности этого подхода [3].

Отделение существенного от несущественного — важный аспект формирования системы как объекта управления. Во многом это искусство менеджера, поскольку четких критериев для него не существует. В качест­ве универсальной рекомендации здесь стоит указать ориентацию на цели самого общего процесса и на использование ролевого состава требуемых исполнителей, который определяется содержанием проектных работ, с по­следующим построением проекции реальных сотрудников на роли.

В рамках предмета нашей лекции целесообразно охарактеризовать деятельность менеджера и возможные его действия как составляющие проектировочной системы деятельностей. Ее целью является направле­ние выполнения всех других видов проектных деятельностей таким обра­зом, чтобы они в совокупности продвигали проект к выполнению задава­емых вне системы работ в условиях ограничений по времени, финансам и качеству. Словом, деятельность менеджера состоит в достижении целей деятельности, задающей проект в целом. Эта деятельность сочетается с внешней по отношению к работам проекта деятельностью менеджера, ко­торая заключается в согласовании параметров проекта: объем работ, сро­ки, запрашиваемые финансы.

Таким образом, менеджмент проекта рассматривается как обеспече­ние поставок продукта, разработка которого требует выполнения опреде­ленного объема работ (область действия) с привлечением затрат, не вы­ходящих за определенные пределы, укладывающаяся в заданные рамки времени и удовлетворяющая приемлемому уровню качества. Это широко известный «треугольник менеджмента проектов» (см. [27]), представлен­ный на рис. 4.3. Он интерпретируется как задача менеджера, формулируе­мая следующим образом. Нужно уравновешивать производительность ра­бот проекта (область действия), время (план-график поставок) и расход ресурсов (затраты), удовлетворяя требованиям качества.

По разным причинам соблюдать баланс по всем параметрам чаше всего не удается, а по­тому менеджер вынужден выбирать в качестве первичной цели только один или два параметра, ставя остальные в зависимость от них. Это дейст­вие приводит к такой интерпретации рисунка: «треугольник хорошо-бы­стро-дешево — выбери два из них*.

Представим смысл элементов, составляющих треугольник менедж­мента. Пределы затрат (x_mj_n, x^max) ограничивают возможное значение переменной X, указывающей на выбранный для проекта уровень расхо­дов. Если это значение выходит за интервал (х-, х⁺), то добиться требуе­мого уровня качества не удастся, так как для этого либо мало ресурсов (когда значение попадает в (x_mj_n, х-)), либо их дополнительное потребле­ние не дает роста качества (значение в (х*, х^тах)). В точках интервала (х*, х⁺) падение уровня качества объясняется другими факторами (значения­ми переменных Y и Z и ограничениями на них). Восстановив перпенди­куляр из выбранного значения переменной X, мы получаем множество точек в треугольнике, каждая из которых определяет пару значений двух других переменных, Y и Z. Свойства значений этих переменных анало­гичны затратным значениям. Выбирая конкретное значение одной из них, мы фиксируем другую и в качестве результата получаем точку в про­странстве возможных решений.

Приведенная схема — типичный пример иллюстративного предста­вления процессов. Образно говоря, она не дает и намеков на то, как стро­ить перпендикуляры, т.е. как вычислять зависимые переменные. Схема неявно отсылает к другим методикам и оставляет впечатление понятно­сти того, что нужно делать для планирования проекта.

В литературе можно найти множество вариаций на тему треугольни­ка менеджмента проектов, или, как его еще называют, «железного треу­гольника» [53]. Все они обусловлены стремлением к тому, чтобы учиты­вать в моделях различные аспекты процесса, и в первую очередь перемен­ные, которыми можно оперировать, взаимозависимости переменных и ограничения на их значения. Отсюда появляются варианты переменных, связываемых треугольником, и различные интерпретации диаграмм.

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

В традиционном треугольнике менеджмента качество продуктов и процесса выполнения программного проекта либо не отображается во­все, либо задается при помощи определения некоторой внутренней обла­сти треугольника, например как в представленной выше модели. Это вло­женный треугольник (как на рис. 4.3), круг (как предлагается в компании Microsoft [56]) и др.

М. Видеман предлагает рассматривать качество (QUALITY) как еще одну равноправную переменную [53]. В результате вместо треугольника получается звезда с четырьмя лучами (см. рис. 4.4). Такое представление не позволяет строить перпендикуляры и затрудняет выбор инварианта. Тем не менее в стандарте PMDOK в 1987 году оно было принято [54]. В 1991 году Видеман в работе [55], выполненной в рамках PMI, приводит более строгую интерпретацию четырехугольной звезды, но и она не так понятна, как традиционные для исходного треугольника трактовки. Как оказалось, простоты интерпретации можно добиться, если воспользо­ваться третьим измерением (см. рис. 4.5). В результате сохраняется воз­можность и построения перпендикуляров, и трактовки площади — теперь объема — в качестве инварианта [53].

Идея третьего измерения довольно плодотворна. В частности, сов­сем недавно (статья [57] опубликована 12 апреля 2004 года) ею воспользо­вался Дж. Мараско для отражения в модели еще одной переменной: веро­ятности успеха проекта (см. рис. 4.6).

Автор выстраивает "проектную пи­рамиду" (см. рис. 4.6), в основании которой лежит четырехугольник со сторонами Скорость (Speed), Экономичность (Frugality), Качество (Quality) и Область действий (Scope), а высотой является вероятность ус­пеха (Probability of Success — фактически используется не вероятность, а некоторая величина, с нею связанная, которая позволяет применить про­стой инвариант). Эти пять характеристик проекта рассматриваются как переменные, значения которых связаны инвариантом для имеющихся ус­ловий развития проекта силами данной команды. В качестве инварианта выбирается объем пирамиды.

Эта модель позволяет более реалистично отслеживать деятельность менеджера при выборе стратегии развития проекта, а также при ее кор­ректировке. Так, поскольку вероятность успеха проекта есть величина, изменяющаяся во времени, а объем пирамиды для данного проекта по­стоянен, изменение этой величины неизбежно влечет за собой изменение значений переменных в основании пирамиды. Иными словами, когда в результате тех или иных событий меняется вероятность успеха, это неиз­бежно влечет за собой изменение остальных параметров проекта. Обрат­ное утверждение — о том, что вероятность успеха зависит от «площади» основания, — очевидно.

В результате появляется возможность более оптимистично оцени­вать эффективность ведения проекта, не опираясь на известное суждение о том, что из пяти программных проектов лишь один завершается успеш­но. В соответствии с пирамидой менеджмента это означает, что в ряде случаев не выполняются только первоначальные планы, для которых бы­ла низкой вероятность успеха, но которые затем приобрели более реалис­тичные очертания (например, за счет формирования у исполнителей чет­кого представления о предметной области и о потребностях пользовате­лей). На уровне модели ситуация отображается как уменьшение площади основания пирамиды при соответствующем увеличении ее высоты, по­скольку действует предположение о сохранении объема. Мараско предла­гает рассматривать подобные проекты как умеренно успешные.

Проиллюстрированное выше развитие треугольника менеджмента полезно. Новые модели позволяют глубже понимать процессы, которыми приходится управлять при выполнении программных проектов. Однако не стоит ожидать от них того, для чего они не предназначены. Все подоб­ные модели остаются иллюстративными. И опять следует предостеречь, что впечатление очевидности того, что нужно делать при планировании проекта, складывающееся при работе с новыми схемами, не должно за­слонять необходимость обращения к другим методикам.

Менеджер распределяет имеющиеся в его распоряжении ресурсы по различным деятельностям проекта. Его средства и инструменты предназначены как для решения задач распределения ресурсов, так и для осуществления непосредственного влияния на ход работы (для на­блюдения и контроля, воздействий и т.п.). Методы менеджмента вклю­чают в себя различные методики, в том числе и организационные сред­ства (мероприятия, поручения и т.п.). Общий методический шаблон ра­боты менеджера заключается в том, что сначала определяется проектная деятельность, подвергаемая воздействию, затем выясняется, что требу­ется откорректировать и какие для этого имеются средства; далее выби­рается и осуществляется воздействие. Результаты деятельности менед­жера весьма разнообразны, но все они так или иначе укладываются в ре­шение задач соблюдения баланса при достижении целей, иллюстрируе­мого треугольником менеджмента проектов или иной подобной моделью, например пирамидой менеджмента. Чтобы описать, какие ва­рианты подходов к решению в деятельности менеджера возможны, не­обходимы понятия, отражающие динамику выполнения проектных за­даний. Этот аспект системы проектных деятельностей обсуждается в следующем разделе.