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

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

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

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

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

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

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

увеличить изображение
Рис. 4.3. Треугольник менеджмента проектов

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

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

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

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

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

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

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

Рис. 4.4. Равноправные переменные: ВРЕМЯ (TIME), ОБЛАСТЬ ДЕЙСТВИЙ(SCOPE), ЗАТРАТЫ(COST) И КАЧЕСТВО(QUALITY) в звезде с четырьмя лучами [53]

Рис. 4.5. Равноправные переменные: ВРЕМЯ (TIME), ОБЛАСТЬ ДЕЙСТВИЙ(SCOPE), ЗАТРАТЫ(COST) И КАЧЕСТВО(QUALITY) в тетраэдре [53]

Рис. 4.6. Пирамида менеджмента: СКОРОСТЬ(SPEED), ЭКОНОМИЧНОСТЬ(FRUGALITY), КАЧЕСТВО(QUALITY), ОБЛАСТЬ ДЕЙСТВИЙ(SCOPE), ВЕРОЯТНОСТЬ УСПЕХА(PROBABILITY OF SUCCESS) [57]

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

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

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

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

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