Наверное, я не буду слишком оригинальной, повторяя, что управление подразумевает измерение. Особенно актуальна эта тема для больших компаний.
Эта статья не претендует на абсолютную полноту и на абсолютную истину. Меня тут недавно просто попросили по-человечески дать список метрик, которые нужно измерять в проектах, и подумать, какие из них можно давать высшему руководству для оценки ситуации. Статью можно рассматривать как первую итерацию моих предложений.
Любые замечания, дополнения и предложения со стороны приветствуются.
Основные идеи
Первое, что мы должны спросить себя при использовании метрик — зачем мы это делаем. Очевидно, затем, чтобы заранее оценить возможные риски. Поэтому для начала нужно определить основные факторы риска для вашего проекта. Это можно сделать различными способами; лично мне больше всего нравятся три: анализ прошлых аналогичных проектов, подготовка всей проектной команды к общему совещанию, на котором каждый озвучивает риски, которые он видит в проекте, и использование стандартных списков рисков, как правило, имеющихся в каждом проекте (специфичных для отрасли в целом или для вашей компании).
Факторы риска
Факторы риска — это не сами риски. Это причины, лежащие в основе появления рисков.
Для своего проекта (разработка информационной системы для внешнего заказчика) можно определить следующие основные факторы риска:
- Риски, связанные с текучестью кадров (в отрасли, в компании)
- Ограничения по срокам, бюджету и времени
- Ограничения, налагаемые требованиями к качеству
- Внутренние политические факторы (внутренняя политика в компании заказчика и в вашей компании, которая может помешать выполнению проекта)
- Внешние политические факторы (могут быть важны при работе с крупными государственными заказчиками)
- Недостаточный уровень технологической экспертизы в команде
- Человеческий фактор: люди, избегающие ответственности, имеющие негативный опыт в предыдущих проектах
- Низкий уровень организационной зрелости в компании
Не все эти факторы можно всегда положить в основу численных метрик. Однако, поставить своеобразные «индикаторы положения дел» в тех рисках, которые вы пока еще не можете выразить количественно, но можете оценить качественно («всё пока хорошо/плохо/ужасно»), по-моему, не помешает.
Основные типы метрик
В общем случае, для проекта я считаю вполне разумным начинать определять следующие типы метрик:
- Показатель текучести кадров
- Показатель утилизации ресурсов
- Показатели, связанные со сроками и бюджетом проекта
- Показатели, позволяющие оценить качество разрабатываемого продукта
- Интегральные показатели прогресса проекта
В целом, можно использовать следующий подход к выбору метрик для проекта:
- Метрики этапов ЖЦ и календарного плана: Следить за графиком работ по этапам ЖЦ и сравнивать фактические и запланированные значения.
- Метрики расходов по проектам / добавленной стоимости: Следить за значениями кумулятивной величины расходов в сравнении с бюджетом, а также общей стоимости проекта, постоянно обновляя данные по мере реализации проекта.
- Метрики отслеживания изменений в требованиях: Число изменений в требованиях в масштабах проекта.
Метрики процесса разработки: Следить за числом реализованных в модели требований в сравнении с общим числом требований в проекте. - Метрики типов отказов: Отслеживать причины отказов ПО.
- Остальные метрики по дефектам: Графическое представление числа отказов в месяц по месяцам на протяжении всего времени выполнения проекта.
- Обзор метрики эффективности: Отслеживать плотность ошибок по фазам и использовать диаграммы для определения «пиков» и «провалов» на кривой, а также превышений предельно допустимых значений.
Анализ состояния проекта
Для анализа состояния проекта можно использовать три вида метрик: метрики, работающие на упреждающий анализ, диагностические метрики и ретроспективные метрики. Первые нужны нам, чтобы попытаться устранить беду задолго до того, как она случилась. Вторые нужны нам для того, чтобы видеть, как идут дела в проекте. Третьи нужны для того, чтобы учиться на истории собственных побед и поражений.
Итак:
Упреждающий анализ
Для того, чтобы понимать, какие проблемы ждут нас впереди, и что может получиться в итоге, можно подготовить для анализа несколько цифр:
- Запланированный объем работ, бюджет, ресурсный план.
- Аналогичные цифры (объем работ, бюджет, ресурсный план) для других проектов того же профиля — для сравнения (сильные вариации должны указывать на проблемы)
- Фактор сложности проекта — величина, характеризующая общий объем всех внешних артефактов проекта, умноженная на коэффициент сложности, определенный для каждого из внешних артефактов.
- Суммарный риск, связанный с расписанием — суммарная величина, отражающая изменения расписания в проекте, с учетом вероятности их возникновения (выражается в человеко-часах). Например, можно оценить, сколько времени ваша проектная команда проведет на больничном, и сколько времени будет находиться в отпусках. Можно попробовать оценить, на сколько времени задержит поставку оборудования поставщик, вечно опаздывающий с поставками как минимум на три недели.
- Общий риск, связанный с бюджетом — суммарное значение всех непредвиденных расходов по проекту, на основании плана бюджета на непредвиденные расходы, с учетом вероятности их возникновения. Например, можно включить сюда компенсации непредвиденных изменений трудозатрат, накладных расходов и т. п., возникающих в ходе работы над проектом.
- Сложность плана проекта — число взаимосвязей и взаимозависимостей между различными работами в плане-графике, отнесенное к общему числу всех работ в плане-графике. Влияет на резерв времени, который нужно заложить в проект для учета сдвига сроков выполнения задач, неожиданно «подвинутых» за счет связей. Кроме того, в проект с большим числом взаимосвязей бывает очень сложно добавлять новых людей, и делать это нужно (как правило) не раньше, чем удастся упростить план проекта — например, за счет реорганизации бизнеса.
- Плотность проекта — отношение суммарной продолжительности всех работ в плане-графике при их последовательном выполнении к сумме ее же и общего запаса (резерва) времени для всех запланированных работ. Чем выше плотность, тем сложнее будет выполнить проект. Не просто выполнить в срок — тем будет сложнее вообще выполнить проект.
- Независимость проекта — отношение между числом зависимостей для внутренних работ проекта и общим числом зависимостей, включающим зависимости от внешних работ и поставщиков. Думаю, здесь все очевидно: чем независимее проект, тем больше шансов на успех. Жаль только, что такие проекты в IT-индустрии в последние 10 лет практически не встречаются.
- Людские ресурсы: максимальное число участников проекта (время подумать: а есть ли у нас вообще необходимое количество людей? а есть ли «запасные» на непредвиденный случай?)
- Суммарный запас времени: общий запас (резерв) времени для всех запланированных работ.
- Оценки требований SLA или требований к качеству, минимально удовлетворяющих требованиям для разрабатываемого продукта, системы или сервиса.
Разумеется, все эти цифры:
а) берутся не с потолка. Они вырисовываются на основании известных вам фактов (например, плана-графика отпусков, среднегодового количества дней, проведенных на больничном каждым из членов вашей проектной команды, и прочих статистических данных о ее работе).
б) регулярно обновляются. И вообще могут быть достаточно корректными только после того, как у вас подошла к концу фаза анализа.
Думаете, все это настолько тривиально, что совершенно не стоит упоминания? Тогда те менеджеры проектов, кто в любой момент времени может ответить, не вышел ли он за пределы бюджета на непредвиденные расходы по своему проекту, пусть расскажут, как они это делают. Как расчитывают непредвиденные расходы бюджета по портфелю проектов, находящемуся в их управлении? Кто умеет составлять ресурсные планы с точностью до 10% — как он делает это?
Диагностические метрики
Основные метрики, позволяющие вам оценить, что происходит:
- Бюджет выполненных работ (плановый и фактический): постоянно изменяющаяся величина (с нарастающим итогом) суммарной стоимости всех запланированных работ по проекту, завершенных на настоящий момент.
- Отношение фактического бюджета к плановому бюджету: если этот коэффициент не превышает 1, то проект укладывается в бюджет в среднесрочной перспективе; если нет, то, вероятнее всего, бюджет будет перерасходован.
- Дисперсия издержек: разность между запланированным бюджетом работ, которые должны были быть завершены на текущий момент согласно календарному плану, и фактическим бюджетом, позволяющая оценить размер перерасходов или неосвоенного бюджета в проекте.
- Исполнение расписания: отношение фактических трудозатрат на выполнение завершенных работ, к запланированным на выполнение этих работ трудозатратам (планируемой трудоемкости). Этот параметр используется для оценки рисков возможности несоблюдения графика.
- Дисперсия календарного плана: разность между фактическими трудозатратами для выполненных работ и планируемыми трудозатратами. Это абсолютное выражение того же параметра, который представлен в виде коэффициента.
- Отставание от графика: суммарная продолжительность времени задержки задач, не уложившихся в план-график.
- Коэффициент закрытых работ: отношение числа завершенных (закрытых) работ к общему числу запланированных к завершению на данный момент работ.
- Производительность труда, вычисляемая как отношение объема работ к затраченному времени (отклонение от запланированных значений)
- Фактические значения результатов проверки требований SLA или требований к качеству для разрабатываемого вами программного продукта или сервиса. Об SLA я когда-нибудь расскажу подробнее.
Каждая из перечисленных величин измеряется на регулярной основе. Можно строить графики, а можно представлять цифры в табличном виде.
Ретроспективные метрики
Я думаю, всем понятно, почему важно их собирать. Разделение между диагностическими и ретроспективными метриками — в том, что первые используются для анализа ситуации «здесь и сейчас» с целью экстренного реагирования, а ретроспективные служат для оценки прошедших событий и сравнения со светлым будущим.
- Коэффициент надежности оценки: отношение произведения стоимости проекта на его продолжительность к кумулятивному значению нарастающей ошибки планирования.
- Отношение фактической производительности труда к запланированной, вычисленное по фактическому и запланированному графику: разница вычисляется в процентах от запланированного графика.
- Процент трудозатрат, приходящихся на фазу проекта/отдельную группу задач
- Отношение объема работ в тестировании к общему объему работ
Пожалуй, на сегодня все.
Есть ли у кого-то еще свои соображения по поводу метрик, относящихся непосредственно к области управления проектом?
Автор: enotinka
