Монография 2020

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

Несмотря на то что многие команды отдают предпочтение либо методологии водопада, либо Agile, преимущества обоих подходов привели к появлению гибридной методологии, когда этапы планирования и определения требований выполняются согласно методологии водопада, а этапы проектирования, разработки, внедрения и оценки соответствуют гибкому подходу. Гибридный подход – это сочетание методологий Waterfall и Agile. Это гибкий и при этом хорошо структурированный метод, который можно использовать для различных проектов. Гибридная модель уделяет особое внимание первичному сбору и анализу требований, чем и похожа на «водопад». На следующем этапе она характеризуется гибкостью, присущей Agile и быстрым внесением изменений.

Если не считать этап планирования, гибридной методологии свойственна значительно большая гибкость, чем методу Waterfall. Если требования не будут значительно меняться, в проект можно будет вносить изменения по мере необходимости. Позаимствовав этап первоначального планирования из Waterfall, гибридная методология решает одну из основных проблем подхода Agile – недостаточную организованность и отсутствие плана. Таким образом, эта методология сочетает в себе лучшее от этих подходов. Вместе с тем, поскольку приходится поддерживать баланс между двумя совершенно противоположными подходами, нужно искать компромиссы в области требований и гибкости. Гибридная методология больше всего подойдет проектам с размытыми требованиями, в которых важны и планирование, и гибкость. В основном это проекты среднего объема с высокой сложностью и фиксированным бюджетом [16].

180

А. Сооляттэ в работе [11] отмечает, что выбор между новой парадигмой, новой гибкой или гибридной моделью управления проектами и действующими, проверенными стандартами не всегда прост. Внесение Agile-элементов в PMBОK [18] пока не выглядит органичной частью стандартных процессов управления проектами. PMBOK это свод знаний, который носит рекомендательный характер и отвечает на вопрос: какие процессы управления проектом нужно выстроить, чтобы создать продукт и достичь цель, а Agile – это семейство фреймворков, методов, моделей, инструментов, объединенных общими идеями и принципами по быстрой и гибкой разработке продуктов, имеющих ценность для потребителей. Гибкая модель предполагает перенос фокуса со статуса и власти лиц, принимающих решения по проектам – на результаты и продукты и их ценность для компании, для пользователей, для инвесторов. Это быстрое обучение на опыте и быстрое исправление ошибок, которые недопустимы и опасны для руководителей проектов в традиционной системе [11].

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

Элементами структуры «базовых» методологий (PMBOK, IPMA, P2M, PRINCE2 и др.) являются проверенные практикой инструменты и методы проектного менеджмента. Инструменты управления проектами играют две роли в обеспечении поддержки процесса стандартизованного управления проектами: во первых, традиционную, являясь средствами, облегчающими получение результатов этого процесса; а во вторых, новую, выступая в качестве базовых блоков, из которых можно построить «инструментальный ящик», обеспечивающий поддержку процесса управления проектами и играющий стратегическую роль в достижении конкурентных преимуществ компании [9].

181

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

Рассмотрим далее в качестве такого инструмента метод освоенного объема. Использование метода освоенного объема для традиционного (водопадного) способа реализации проекта свидетельствует о полезности этого инструмента для целей контроля проекта [4,12,13,17,22,24,25], а как способ экономического мониторинга стоимости проекта рассмотрен нами в работе [7].

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

Плановый объем (плановая стоимость запланированных работ, Budget Cost of Work Scheduled, BCWS, Planned Value, PV) – бюджетная стоимость работы, которая согласно расписания должна быть выполнена к определенному сроку;

Фактическая стоимость (фактическая стоимость выполненных работ,

Actual Cost of Work Performed, ACWP, Actual Cost, AC) – общая стоимость выполнения работы в результате плановой операции в течение определенного периода времени.

Освоенный объем (плановая стоимость выполненных работ, Budget Cost of Work Performed, BCWP, Earned Value, EV) это объем выполненной работы в показателях утвержденного бюджета, выделенного для данной работы в рамках операции или элемента иерархической структуры работ [4,7,8,12,16].

Так как метод освоенного объема учитывает фактор времени, то он позволяет определить - как реальное отклонение по затратам, так и отставание по графику выполнения работ.

182

Отклонение по затратам – CV (Cost Variance) (перерасход денежных средств) представляет собой величину, полученную как разность плановой стоимости (EV) выполненных работ и фактической стоимости (AC)):

#$ = &$ − (# (1).

Отставание от графика – SV (Schedule Variance) определяется разностью между плановой стоимостью выполненных работ (EV) и плановой стоимостью работ по графику (PV):

-$ = &$ − .$ (2).

Индекс выполнения бюджета – CPI (Cost Performance Index) показывает отношение освоенного объема к фактическим затратам:

#.0 = &$/(# (3).

Индекс выполнения расписания – SPI (Schedule Performance Index) показывает отношение освоенного объема к бюджетным затратам:

-.0 = &$/.$ (4).

Анализ проекта по приведенным выше показателям можно выполнить с помощью табл. 3.

Таблица 3 - Характеристика состояния проекта

Обобщающим показателем текущего состояния проекта является критический коэффициент (Critical Ratio, CR), равный произведению индекса выполнения сроков и индекса выполнения стоимости: #4 = #.0 × -.0.

183

Если критический коэффициент превышает единицу, т.е. CR > 1, то статус проекта следует признать удовлетворительным, и неудовлетворительным, если имеет место обратное неравенство: CR < 1.

Рассмотрим далее применения метода освоенного объема на примере проекта, реализуемого по методу Scrum. Следует отметить, что все показатели проекта в методе освоенного объема, описываются в терминах затрат. В Agile предпочтительно использовать эмпирические, сфокусированные на поставке ценности заказчику, а не предиктивные измерения. В методе Scrum объемы работы за спринт измеряются в том числе в условных единицах (стори-поинтах, SP), характеризующих оценку поставляемых свойств инкремента готового продукта. Поэтому наряду с финансовыми показателями (PV, AC, EV, BAC, EAC, VAC) введем показатели объема инкремента готового продукта, поставляемого за время спринта.

Плановый объем работ (Planned Quantity of Story Point, PQSP) – это объемы работ в SP, запланированных в соответствии с расписанием к текущей дате.

Фактические объемы работ – (Actual Quantity of Story Point, AQSP) – это объемы работ в SP, фактически выполненных на текущую дату.

Освоенный объем работ – (Budgeted Quantity of Story Point, BQSP) – совпадает с показателем фактического объема работ.

Суммарный объем работ по спринту QAC (Quantity At Completion) –равен кумулятивному значению плановых объемов работ BQSP.

Графическое представление метода освоенного объема по показателям поставляемых результатов приведено на рис. 11.

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

184

показывает фактическое отклонение между запланированными и выполненными объемами работ на определенную дату:

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

Таблица 4 - Состав первого спринта

Также команде удалось в рамках бэклога спринта сформировать условный календарный график реализации операций на основе приоритета задач и их технологической взаимосвязи. Планируемый объем работ в SP (PQSP) первого спринта составил 299 единиц, а стоимость работ 2960 тыс. руб. (рис. 12).

А – операция

SP - 20 / 180 - стоимость

Рисунок 12 – Опорный план реализации первого спринта

186

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

Входе реализации спринта произошли изменения как в топологии выполнения отдельных задач, так и в их стоимости (рис.13).

Рисунок 13 – Отчет о реализации первого спринта

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

Руководство [15] рекомендует использовать для визуализации контроля за ходом реализации проекта диаграммы сгорания / выгорания, в которых отображаются выполненные (поставленные) свойства в определенный этап времени в сравнении с плановым объемом этих свойств. Диаграмма выгорания,

187

Рисунок 14 – Диаграмма выгорания задач

В силу изменения приоритета выполнения задач и ряда субъективных причин на дату 4 сентября наблюдалось существенное (на 40 SP или 50%) отставание от графика освоения свойств продукта. К 6 сентября отставание сократилось до 7 SP, однако 9 сентября команда уточняла содержание оставшихся задач бэклога спринта, не смогла поставить ни одного свойства и положение проекта ухудшилось: отставание на 40 SP (на 25,3%). В последующие дни команде удалось увеличить темп работ и к 13 сентября закрыть бэклог

188

спринта. Таким образом применение метода освоенного объема дает возможность команде проекта следить за прогрессом своей работы и принимать решения по корректировке своих действий. Scrum-команда в рамках ежедневных встреч (Daily Meeting) может отследить текущее положение проекта путем сравнения запланированных к текущей дате SP (PQSP) и фактически поставленных / освоенных SP (AQSP).

Анализ стоимостных параметров проекта в рамках первого спринта представлен на рис. 15.

Рисунок 15 – Характеристика стоимостных параметров проекта.

189