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