Практика проектных метрик в разработке программного обеспечения

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

Руководителям трудно получить точное представление о том, что на самом деле происходит в проекте. Чем выше позиция, тем сложнее лично наблюдать за производственным процессом или оценивать прогресс на основе видимых результатов. Руководители вынуждены полагаться на отчеты и информацию, предоставляемую подчинёнными. Однако такие сведения далеко не всегда отражают реальную картину и могут быть субъективными или неполными.

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

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

Возникает вопрос: как получать достоверные сведения в реальном времени с минимальными издержками?

Индикаторы

Мы используем данные из корпоративных систем, которые могут в реальном времени отображать текущее состояние дел и подсвечивать области, требующие вмешательства менеджмента. Важно понимать, что такие сведения служат лишь индикаторами, на которые следует обратить внимание. Если какие-то данные сигнализируют о проблеме или выбиваются из общего ряда, их стоит дополнительно проверить.

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

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

Управление на основе данных

Рассмотрим общую схему управления на основе данных.

Схема управления на основе данных
Схема управления на основе данных

1. Процесс в физическом мире.
   Под процессом мы понимаем все производственные и непроизводственные активности.
2. Отражение процесса в корпоративных системах.
   В корпоративных системах мы всегда видим некоторую модель, которая с определённой степенью приближения отражает процессы физического мира.
3. Метрики процесса.
   На основе данных в корпоративных системах мы можем создавать различные показатели и контролировать их динамику.
4. Анализ метрик.
   На основе показателей и их динамики мы можем выявлять проблемные места, делать какие-то выводы.
5. Управленческие решения.
   На основании проведённого анализа руководство принимает управленческие решения, которые должны изменить к лучшему процессы в физическом мире, а корректность решений должна в последующем подтвердиться изменением показателей.

Чтобы применять данную схему на практике необходимо учитывать и обрабатывать следующие риски:

1. Если в физическом мире процесс не стандартизирован и исполнение отдаётся на откуп исполнителям или выполняется по-разному, то дальнейшие шаги схемы управления на основе данных не имеют смысла. Поэтому мы стандартизировали основные бизнес-процессы управления проектами.
2. Отражение процесса в корпоративных системах может быть искажено и не отображать реальную картину происходящего. Это случается из-за отсутствия регламента отражения процессов, а также действий сотрудников, которые могут намеренно искажать данные либо лениться соблюдать регламент. Здесь мы также пошли по пути стандартизации отображения процессов.
3. При некорректных настройках метрик они могут давать искажённые сведения. Здесь нам помогли стандарты отображения процессов в корпоративных системах, автоматизация сбора данных для метрик и валидация офисом управления проектами.
4. На основании метрик могут делать неправильные выводы либо некорректно их транслировать.

Обработка рисков
Обработка рисков

Метрики проектов с фиксированной стоимостью

В этой статье мы будем рассматривать только проекты с фиксированной стоимостью. Для таких проектов важен контроль "проектного треугольника": объём работ (scope), стоимость (cost) и продолжительность (time). Мы используем методику освоенного объёма (Earned Value Management, EVM) для мониторинга этих ключевых показателей.

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

При планировании проекта необходимо:

1. Определить что понимается под 100% работ проекта.

2. Декомпозировать 100% работ на более мелкие части, то есть создать иерархическую структуру работ проекта (WBS). Тут важно дополнить что декомпозированы должны быть поставляемые результаты, либо пакеты работ.
Активности нижнего уровня на практике невозможно предугадать на этапе планирования и они появляются уже на этапе выполнения.

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

После определения часовых ставок специализаций, выравнивания ресурсов и создания расписания фиксируем базовый план проекта, формируем план по динамике затрат на проект.

4. Разработать директивный график освоения объёма. Для построения планового директивного графика или плана расхода бюджета и освоения объёма работ проекта используем следующие значения:

BAC (Budget At Completion) - планируемые суммарные затраты по завершению проекта. Какой бюджет затрат запланирован на проект.

PT (Planned Time) - планируемый срок выполнения проекта

PV (Planned Value) - планируемая динамика затрат и освоения объёма (в данной методике они равны).

Исполнение проекта

После начала работ по проекту мы периодически собираем фактические данные из корпоративных систем по объёму выполненных работ и затраченным ресурсам.

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

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

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

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

По мере выполнения проекта периодически фиксируем значения следующих показателей и отражаем их на графике:

AC (Actual Cost) - фактическая динамика затрат, то есть какой бюджет затрачен на дату измерения. Умножаем часовые ставки специалистов на затраченное ими время.

EV (Earned Value) - фактическая динамика освоения объёма. На основе оценок элементов декомпозиции суммируем выполненных элементов.

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

SV (Schedule variance) - отклонение по расписанию по освоению объема (SV = EV − PV).

SVT (Schedule variance time) - отклонение по расписанию по срокам.

CV (Cost variance) - отклонение фактической стоимости выполненных работ от их запланированной стоимости (CV = EV − AC).

PC (Percent complete) - процент освоения объёма (PC = EV / BAC)

PS (Percent spent) - процент затрат (PS = CV / BAC).

Показатели SV и CV отражают текущее состояние проекта (соблюдение бюджетов и сроков).

Измеряем относительные показатели:

SPI (Schedule performance index) - индекс выполнения расписания (SPI = EV / PV).

CPI (Cost performance index) - индекс выполнения стоимости (CPI = EV / AC).

Первая контрольная точка для прогнозирования показателей завершения проекта — 15-20% его выполнения. На этом этапе используем метрику прогноза:

EAC (Estimate At Completion) - прогноз расходов по завершению проекта (EAC = BAC / CPI).

При планировании проекта мы дополнительно определяем зоны рисков, связанные как со сроками, так и с затратами. В зависимости от того, в какую зону попадает текущий прогноз, мы можем настроить так называемый "светофор проекта". Это позволяет увидеть, в каком состоянии находится проект на данный момент и какие риски могут возникнуть по ходу его реализации.

Заключение

Методика освоенного объёма (EVM) и её инструменты при корректном внедрении предоставляют необходимые возможности для эффективного управления проектами с фиксированной стоимостью.

Методика освоенного объёма является необходимым базовым инструментом в управлении проектами, так как она снижает серьёзные риски, связанные с превышением бюджета и срывом сроков.

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

Показатели и прогноз итоговых значений проекта дают сведения для выработки своевременных оперативных управляющих воздействий.