Для больших компаний

Метрики в проектах по разработке ПО
IT-стандарты*
Наверное, я не буду слишком оригинальной, повторяя, что управление подразумевает измерение. Особенно актуальна эта тема для больших компаний.
Эта статья не претендует на абсолютную полноту и на абсолютную истину. Меня тут недавно просто попросили по-человечески предложить список метрик, которые нужно измерять в проектах, и подумать, какие из них можно давать высшему руководству для оценки ситуации. Статью можно рассматривать как первую итерацию моих предложений.
Любые замечания, дополнения и предложения со стороны приветствуются.

Основные идеи

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

Факторы риска

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

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

Не все эти факторы можно всегда положить в основу численных метрик. Однако, поставить своеобразные «индикаторы положения дел» в тех рисках, которые вы пока еще не можете выразить количественно, но можете оценить качественно («всё пока хорошо/плохо/ужасно»), по-моему, не помешает.

Основные типы метрик

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

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

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

1. 
   Метрики этапов ЖЦ и календарного плана: Следить за графиком работ по этапам ЖЦ и сравнивать фактические и запланированные значения.
   
2. 
   Метрики расходов по проектам / добавленной стоимости: Следить за значениями кумулятивной величины расходов в сравнении с бюджетом, а также общей стоимости проекта, постоянно обновляя данные по мере реализации проекта.
   
3. 
   Метрики отслеживания изменений в требованиях: Число изменений в требованиях в масштабах проекта.
   Метрики процесса разработки: Следить за числом реализованных в модели требований в сравнении с общим числом требований в проекте.
   
4. 
   Метрики типов отказов: Отслеживать причины отказов ПО.
   
5. 
   Остальные метрики по дефектам: Графическое представление числа отказов в месяц по месяцам на протяжении всего времени выполнения проекта.
   
6. 
   Обзор метрики эффективности: Отслеживать плотность ошибок по фазам и использовать диаграммы для определения «пиков» и «провалов» на кривой, а также превышений предельно допустимых значений.
   

Анализ состояния проекта

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

Упреждающий анализ

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

•