учебники, программирование, основы, введение в,

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кратко: методы — это то, что указывает на способ выполнения данной деятельности.
В теории деятельности средства, инструменты и методы часто объединяют в общее понятие. При таком взгляде метод в том смысле, как мы это определили, представляет собой средство организации деятельности в целом, и применение метода оказывается не чем иным, как специальной деятельностью, являющейся элементом-средством данной деятельности. С учетом методологической направленности настоящего курса выделение методов мотивируется тем, что для нас методы являются предметом исследования.

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

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

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

Рассмотрение деятельности и системы деятельностей обособленно от других деятельностей — абстрактный прием, позволяющий увидеть структуру деятельности или системы, описать элементы и связи. Представленный список элементов отражает структуру любой осмысленной деятельности, а способы связи задают все многообразие систем деятельностей. Это представление достаточно содержательно даже на таком абстрактном уровне. Так, с его помощью мы в состоянии дать понятия автоматической и автоматизированной деятельностей.
Деятельность называется автоматизированной, если она приводит к результатам, которые продуцируются другой, неавтоматизированной деятельностью (реальной или, возможно, умозрительной), но с меньшими затратами времени и/или с сокращением расхода ресурсов. Данное определение может показаться излишне общим, охватывающим и случаи, которые интуитивно не представляются как автоматизированная деятельность. Можно дать другое определение, которое говорит о сокращении времени и/или расхода ресурсов при выполнении воздействий субъектом. Нетрудно заметить, что это приводит к необходимости рассматривать субъект в качестве (абстрактной) деятельности, выполнение которой приводит к выполнению исходной деятельности. И эта точка зрения вполне правомерна.
Деятельность называется автоматической или, точнее, автоматически выполняемой, если она имеет неодушевленный субъект, действующий с другими элементами по заданной внешним образом программе. Это то же самое, что вырожденная деятельность, не имеющая субъекта, акт выполнения которой осуществляется путем внешней активизации ее единственного средства. Третья эквивалентная точка зрения — определение автоматической деятельности как такой, у которой (одушевленный) субъект выполняет единственное воздействие-активизацию. Какое из этих определений использовать, зависит от конкретной ситуации.
Введенные понятия сами по себе почти не связаны со спецификой разработки программного обеспечения. Эта специфика может проявиться при интерпретации системы деятельностей на данной предметной области. Что, собственно говоря, и является предметом обсуждения в данном курсе.
На абстрактном уровне деятельность выполнения любого программного проекта можно изобразить в виде схемы, представленной на
Соединения блоков и выделение блока-субъекта означает активность этого блока и пассивность всех остальных, т.е. невозможность выполнения деятельности без воздействий субъекта. Здесь все требует конкретизации, которая неизбежно приведет к появлению новых деятельностей, связанных с данной. Например, указывая на требования, мы должны позаботиться о том, какие деятельности их пополняют и обрабатывают, какие средства применяются для продуцирования из этого материала результата проекта. Использование результата — это встраивание его во внешнюю деятельность пользователя таким образом, чтобы достигалась цель проекта. Подобные, но более содержательные утверждения нужно сделать по каждому из элементов проектной деятельности. В результате такой конкретизации становится явной система деятельностей, в которую погружается проект. Эта система весьма обширна, но для реального управления проектом и эффективного руководства коллективом требуется выделить в ней круг деятельностей, на которые можно влиять, достигая желаемых результатов. Именно они являются сферой деятельности менеджера (ее материалом). Кроме того, требуется выявить деятельности, которые влияют на проект, задавая его внешние условия и ограничения.
Цель программирования как деятельности можно определить как построение автоматических и автоматизированных деятельностей, а цель методологий программирования — как построение автоматических и автоматизированных деятельностей, заменяющих собой неавтоматизированные аналоги в системе деятельностей программирования.
Для понимания назначения и условий применения различных методик нужно прежде всего распознать место методики в системе проектных деятельностей, рассматривая эту систему максимально широко. В частности, не следует забывать и о деятельности тех, кто имеет лишь косвенное отношение к проекту (их мы называли в числе инициаторов работ, см. лекцию 2), поскольку по большому счету программистские проекты разрабатываются для того, чтобы их использовали, и именно автоматизируемая пользовательская деятельность находится в основании того, что называют качеством программного продукта.
В публикациях, посвященных менеджменту проектов, часто говорят не о системе деятельностей, а о процессах, определяя их довольно свободно и неформально. Так, стандарт PMBOK (Project Management Body of Knowledge) института менеджмента проектов PMI, который фактически является общепризнанным на мировом уровне (достаточно указать на поддержку его со стороны ISO), фиксирует, что «процесс — это серия действий, приводящая к результату» , совсем не заботясь о том, что такое «действие» и «результат». ISO 9000 говорит определеннее: «Процесс — любая деятельность, в которой используются ресурсы для преобразования входов в выходы». Последнее, по-видимому, следует считать общепризнанным определением процесса, формализация которого для описания систем процессов представлена в так называемой IDEF-технологии Отметим, что наше понимание деятельности шире процесса. Оно включает и другие элементы, обычно рассматриваемые неформально, а значит, недостаточно регламентированно. Тем не менее с точностью до этого различия в терминологии базовые положения из того, что обсуждается и стандартизируется в области менеджмента проектов, можно без особого труда перенести и на понятие системы проектных деятельностей. Так, PMBOK предлагает оперировать понятием группы процессов, определяя для проектов следующие группы.

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

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


Менеджмент в системе деятельностей проекта
Если сделать интерпретацию системы деятельностей по разработке программных проектов более конкретной, чем простое указание элементов деятельностей, то в системе среди прочих деятельностей должны появиться, к примеру, анализ предварительных требований, конструирование архитектуры, составление программного кода, его проверка. Станет понятным, что эти деятельности не могут выполняться в произвольном порядке, поскольку они поставляют друг другу свои результаты и, следовательно, зависят друг от друга. Дальнейшая конкретизация проектировочных видов деятельности должна следовать выбранной для проекта методической установке.
Формирование системы на основе структурирования обобщенного исполнителя приводит к появлению ролей для выполнения производственных функций и соответствующих им деятельностей. Соотношение между производственными функциями и системой деятельностей не столь однозначно, как может показаться при поверхностном рассмотрении. Причиной тому — трудность определения деятельности как производственной функции, характерная для любых производств, и в частности для производства программных продуктов. Например, с узкопрофессиональной точки зрения не является проектной производственной функцией деятельность по обеспечению сотрудников обедами, практикуемая в некоторых организациях. Но в системе деятельностей, которая охватывает проектные работы, она явно представлена. Сытые работники, сэкономленное ими время — это ее результаты, влияющие на ход выполнения проектных заданий. Естественно, что в управленческом аспекте менеджмента абстрагируются от подобных функций, однако в плане руководства коллективом она занимает существенное место. Для некоторых методологий такие виды деятельности считаются принципиальными как способ организации работ. Например, Бек рассматривает стратегию организации рабочего места команды исполнителей проекта по экстремальной методологии в качестве одного из решающих факторов успешности этого подхода.
Отделение существенного от несущественного — важный аспект формирования системы как объекта управления. Во многом это искусство менеджера, поскольку четких критериев для него не существует. В качестве универсальной рекомендации здесь стоит указать ориентацию на цели самого общего процесса и на использование ролевого состава требуемых исполнителей, который определяется содержанием проектных работ, с последующим построением проекции реальных сотрудников на роли.
В рамках предмета нашей лекции целесообразно охарактеризовать деятельность менеджера и возможные его действия как составляющие проектировочной системы деятельностей. Ее целью является направление выполнения всех других видов проектных деятельностей таким образом, чтобы они в совокупности продвигали проект к выполнению задаваемых вне системы работ в условиях ограничений по времени, финансам и качеству. Словом, деятельность менеджера состоит в достижении целей деятельности, задающей проект в целом. Эта деятельность сочетается с внешней по отношению к работам проекта деятельностью менеджера, которая заключается в согласовании параметров проекта: объем работ, сроки, запрашиваемые финансы.
Таким образом, менеджмент проекта рассматривается как обеспечение поставок продукта, разработка которого требует выполнения определенного объема работ (область действия) с привлечением затрат, не выходящих за определенные пределы, укладывающаяся в заданные рамки времени и удовлетворяющая приемлемому уровню качества. Это широко известный «треугольник менеджмента проектов» , представленный на
Он интерпретируется как задача менеджера, формулируемая следующим образом. Нужно уравновешивать производительность работ проекта (область действия), время (план-график поставок) и расход ресурсов (затраты), удовлетворяя требованиям качества. По разным причинам соблюдать баланс по всем параметрам чаще всего не удается, а потому менеджер вынужден выбирать в качестве первичной цели только один или два параметра, ставя остальные в зависимость от них. Это действие приводит к такой интерпретации рисунка: «треугольник хорошо-быстро-дешево — выбери два из них».
Представим смысл элементов, составляющих треугольник менеджмента. Пределы затрат (xmin, xmax) ограничивают возможное значение переменной X, указывающей на выбранный для проекта уровень расходов. Если это значение выходит за интервал (x-, x+), то добиться требуемого уровня качества не удастся, так как для этого либо мало ресурсов (когда значение попадает в (xmin, x-)), либо их дополнительное потребление не дает роста качества (значение в (x*, xmax)). В точках интервала (x*, x+) падение уровня качества объясняется другими факторами (значениями переменных Y и Z и ограничениями на них). Восстановив перпендикуляр из выбранного значения переменной X, мы получаем множество точек в треугольнике, каждая из которых определяет пару значений двух других переменных, Y и Z. Свойства значений этих переменных аналогичны затратным значениям. Выбирая конкретное значение одной из них, мы фиксируем другую и в качестве результата получаем точку в пространстве возможных решений.
Приведенная схема — типичный пример иллюстративного представления процессов. Образно говоря, она не дает и намеков на то, как строить перпендикуляры, т.е. как вычислять зависимые переменные. Схема неявно отсылает к другим методикам и оставляет впечатление понятности того, что нужно делать для планирования проекта.
В литературе можно найти множество вариаций на тему треугольника менеджмента проектов, или, как его еще называют, «железного треугольника» . Все они обусловлены стремлением к тому, чтобы учитывать в моделях различные аспекты процесса, и в первую очередь переменные, которыми можно оперировать, взаимозависимости переменных и ограничения на их значения. Отсюда появляются варианты переменных, связываемых треугольником, и различные интерпретации диаграмм.
Довольно часто как значения переменных интерпретируются длины сторон треугольника менеджмента, а взаимозависимость задается как инвариант треугольника (например, площадь), который для конкретного проекта и условий его выполнения данной командой остается неизменным. В этом случае выбор значений двух переменных, т.е. длин соответствующих сторон влечет за собой вычисление третьей подобно тому, как это делалось в интерпретации с восстановлением перпендикуляров.
В традиционном треугольнике менеджмента качество продуктов и процесса выполнения программного проекта либо не отображается вовсе, либо задается при помощи определения некоторой внутренней области треугольника, например как в представленной выше модели. Это вложенный треугольник , круг (как предлагается в компании Microsoft) и др.
М. Видеман предлагает рассматривать качество (QUALITY) как еще одну равноправную переменную . В результате вместо треугольника получается звезда с четырьмя лучами ). Такое представление не позволяет строить перпендикуляры и затрудняет выбор инварианта. Тем не менее в стандарте PMDOK в 1987 году оно было принято . В 1991 году Видеман в работе, выполненной в рамках PMI, приводит более строгую интерпретацию четырехугольной звезды, но и она не так понятна, как традиционные для исходного треугольника трактовки. Как оказалось, простоты интерпретации можно добиться, если воспользоваться третьим измерением . В результате сохраняется возможность и построения перпендикуляров, и трактовки площади – теперь объема — в качестве инварианта.
Идея третьего измерения довольно плодотворна. В частности, совсем недавно ею воспользовался Дж. Мараско для отражения в модели еще одной переменной: вероятности успеха проекта . Автор выстраивает "проектную пирамиду" , в основании которой лежит четырехугольник со сторонами Скорость (Speed), Экономичность (Frugality), Качество (Quality) и Область действий (Scope), а высотой является вероятность успеха (Probability of Success – фактически используется не вероятность, а некоторая величина, с нею связанная, которая позволяет применить простой инвариант). Эти пять характеристик проекта рассматриваются как переменные, значения которых связаны инвариантом для имеющихся условий развития проекта силами данной команды. В качестве инварианта выбирается объем пирамиды.
Эта модель позволяет более реалистично отслеживать деятельность менеджера при выборе стратегии развития проекта, а также при ее корректировке. Так, поскольку вероятность успеха проекта есть величина, изменяющаяся во времени, а объем пирамиды для данного проекта постоянен, изменение этой величины неизбежно влечет за собой изменение значений переменных в основании пирамиды. Иными словами, когда в результате тех или иных событий меняется вероятность успеха, это неизбежно влечет за собой изменение остальных параметров проекта. Обратное утверждение — о том, что вероятность успеха зависит от «площади» основания, — очевидно.
В результате появляется возможность более оптимистично оценивать эффективность ведения проекта, не опираясь на известное суждение о том, что из пяти программных проектов лишь один завершается успешно. В соответствии с пирамидой менеджмента это означает, что в ряде случаев не выполняются только первоначальные планы, для которых была низкой вероятность успеха, но которые затем приобрели более реалистичные очертания (например, за счет формирования у исполнителей четкого представления о предметной области и о потребностях пользователей). На уровне модели ситуация отображается как уменьшение площади основания пирамиды при соответствующем увеличении ее высоты, поскольку действует предположение о сохранении объема. Мараско предлагает рассматривать подобные проекты как умеренно успешные.
Проиллюстрированное выше развитие треугольника менеджмента полезно. Новые модели позволяют глубже понимать процессы, которыми приходится управлять при выполнении программных проектов. Однако не стоит ожидать от них того, для чего они не предназначены. Все подобные модели остаются иллюстративными. И опять следует предостеречь, что впечатление очевидности того, что нужно делать при планировании проекта, складывающееся при работе с новыми схемами, не должно заслонять необходимость обращения к другим методикам.
Менеджер распределяет имеющиеся в его распоряжении ресурсы по различным деятельностям проекта. Его средства и инструменты предназначены как для решения задач распределения ресурсов, так и для осуществления непосредственного влияния на ход работы (для наблюдения и контроля, воздействий и т.п.). Методы менеджмента включают в себя различные методики, в том числе и организационные средства (мероприятия, поручения и т.п.). Общий методический шаблон работы менеджера заключается в том, что сначала определяется проектная деятельность, подвергаемая воздействию, затем выясняется, что требуется откорректировать и какие для этого имеются средства; далее выбирается и осуществляется воздействие. Результаты деятельности менеджера весьма разнообразны, но все они так или иначе укладываются в решение задач соблюдения баланса при достижении целей, иллюстрируемого треугольником менеджмента проектов или иной подобной моделью, например пирамидой менеджмента. Чтобы описать, какие варианты подходов к решению в деятельности менеджера возможны, необходимы понятия, отражающие динамику выполнения проектных заданий. Этот аспект системы проектных деятельностей обсуждается в следующем разделе.

Операционные маршруты и траектории деятельности
Рассмотрение развития проекта под углом зрения производственных функций и исполнителей системы проектных деятельностей требует введения понятия, определяющего для субъекта-исполнителя последовательность действий, которая приводит к продвижению выполнения функции данного исполнителя к ее результату.
Поскольку в деятельности субъекта чаще всего есть возможность выбора вариантов продолжения, мы говорим об операционных маршрутах деятельности как о возможных последовательностях действий, которые характеризуют каждый момент выполнения деятельности. Маршруты могут быть произвольными и зависят только от предлагаемых субъекту вариантов. Реализованный при выполнении деятельности операционный маршрут называется траекторией деятельности.
Маршруты и траектории задают динамический аспект деятельности. Однако без привязки к целям и результатам эти понятия несут мало содержания. При прохождении операционного маршрута продуцируются какие-то результаты. Мы говорим об осмысленности действий и осмысленности операционного маршрута, если он является целенаправленным, т.е. определено, какие результаты должны достигаться при его прохождении.
Термины «операционный маршрут» и «траектория деятельности» всегда понимаются как последовательности действий, предписываемые для той или иной роли. Это означает, что маршрут может выполнять индивидуум, наделенной ролью, с которой связывается маршрут, выполняемый в те моменты, когда требуется выполнить соответствующую производственную функцию. Однако индивидуальные особенности сотрудника влияют на то, какие из последовательностей действий осуществимы, какие из них реализуются. Как следствие, в любой момент развития проекта выбор операционных маршрутов, которые надлежит проходить разработчикам, индивидуализирован. Обусловленный обстоятельствами, складывающимися при развитии проекта, этот выбор чаще всего не может быть зафиксирован заранее. Управление проектом как раз и заключается в том, чтобы выстраивать конкретные целенаправленные операционные маршруты, с одной стороны, а с другой — проверять, в какой мере результаты траекторий, реализованных для этих маршрутов исполнителями, соответствуют первоначально установленным целям выполнения функций.
Полезность привязки операционных маршрутов к ролям способствует соблюдению принципа разделения ролей: если сотруднику поручается несколько ролей, то он всегда должен знать, какую из них выполняет в данный момент (см. лекцию 2). Кроме того, привязка позволяет явно указывать условия, в которых принципиально осуществимо выполнение функции, задавать ресурсные потребности, более объективно определять реалистичные сроки возможного получения результатов. В то же время можно говорить и об индивидуализации маршрута, учитывая факторы, которые определяют возможные траектории для конкретного индивидуума. Если можно говорить о двойственности операционных маршрутов, то траектория — это атрибут выполнения маршрута индивидуумом; к роли, ему назначенной, она имеет лишь косвенное отношение.
Таким образом, понятие операционного маршрута правомерно употреблять применительно и к ролям, и к исполнителям. Кроме того, оно уместно и по отношению к использованию инструментов. Назначение инструмента естественно задавать как осуществимость с его помощью определенных маршрутов, прохождение которых оказывается полезным для выполнения тех или иных производственных функций. При таком рассмотрении функция выступает в качестве своеобразного параметра, спецификация которого определяет все возможные функции, а точнее, ситуации, когда применение инструмента оправданно. Так, текстовый редактор — это инструмент, с помощью которого можно набирать и редактировать произвольные тексты, в том числе и тексты программ. Если редактор специализирован для работы с программными текстами, то он, скорее всего, окажется менее приспособленным, скажем, для составления документации. Как следствие, для этой функции может потребоваться другая инструментальная среда, в которой, к примеру, предусмотрена проверка орфографии.
Аспекты деятельности, описываемые как операционные маршруты и траектории, целесообразно характеризовать еще одним понятием, отражающим возможность выполнения действий субъектом-исполнителем. Мы говорим об обстановке операционного маршрута в некоторый момент как обо всех элементах деятельности, которые могут использоваться субъектом для выбора продолжения. Обстановка включает в себя окружение деятельности. Это независимая от субъекта часть обстановки (см. определение, данное выше). Описанные понятия позволяют разграничить объективное и субъективное в выполнении деятельности.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика