10.2 Управляй метриками / Приемы

Убедитесь, что Ваши измерения приносят пользу для проекта

(10.2.P1)

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

• Повышение производительности процессов производства и проекта в целом
• Улучшение методик оценивания для будущих проектов
• Подтверждение для проекта сроков, стоимости, трудозатрат и целей качества
• Выявление и распространение передовых методов работы
• Повышение удовлетворенности заказчика.

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

Используйте собранные метрики

(10.2.P2)

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

Сравнивайте затраты на сбор метрик c получаемыми выгодами

(10.2.P3)

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

Связывайте производительность команды с индивидуальной производительностью

(10.2.P4)

Старая пословица "что измерено - то сделано" остается совершенно верной в применении к проектам. Если для Вашего проекта важен процесс передачи информации, постройте некие метрики вокруг коммуникаций. Например, можно на квартальной основе проводить опрос заказчика и главных заинтересованных лиц, чтобы увидеть, как они воспринимают Вашу коммуникацию. Если Вы поощряете многократное (повторное) использование Вашей командой существующих компонентов или результатов, отслеживайте примеры такого использования, а также соответствующую экономию времени и трудозатрат.

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

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

Остерегайтесь незапланированных последствий при назначении метрик

(10.2.P5)

Сбор метрик будет побуждать команду проекта к определенным изменениям в режиме работы. Поэтому важно, чтобы метрики действовали правильно и не приводили к непредвиденным и нежелательным изменениям. Рассмотрим следующий пример.

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

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

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

Определите базовый уровень метрики, если целевое значение недоступно

(10.2.P6)

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

Для многих метрик, однако, такого предопределенного целевого значения не существует. Например, если Вы измеряете удовлетворенность клиента, он может оценить Вашу команду на уровне 3,8 по 5-бальной шкале. Но как определить, это плохая оценка или хорошая? Так как Вам не с чем ее сравнивать, ответить трудно. Один из способов повышения информативности метрик - использовать первое измерение в качестве базового значения, отражающего Ваше состояние на сегодняшний день. В этом случае Вам захочется рассматривать первые результаты, как исходный уровень, чтобы затем постараться его улучшить. Например, после получения базовой оценки удовлетворенности клиента в 3,8 баллов из 5, Вы можете поставить цель повысить оценку до 4.2 из 5.0 баллов к завершению проекта. Или другой вариант - добиться улучшения значений метрик на 10% по отношению к базовым.

Следует отметить, что определить базовое значение метрики бывает не так и легко. В некоторых случаях, Вам захочется накопить ряд начальных значений прежде, чем зафиксировать базовый уровень. Например, Вы можете отслеживать дефекты в системе в течение трех месяцев, а затем воспользоваться среднемесячной величиной. Это и будет то значение, которое Вы постараетесь улучшать по ходу проекта.

Подходите творчески к измерению ценности проекта для бизнеса

(10.2.P7)

Один из Священных Граалей в измерениях - умение точно фиксировать ценность проекта для бизнеса. В некоторых случаях она очевидна. Продажи могут возрасти. Уровень складских запасов может снизиться. Может увеличиться производительность труда. Однако, во многих проектах бывает трудно или даже невозможно оценить влияние на бизнес в количественном измерении. Некоторые общие проблемы измерения ценности для бизнеса включают следующее:

• Проект приносит неосязаемые выгоды, такие как, например, повышение удовлетворенности заказчика или качества продукта.
• Проект охватывает инфраструктуру, которой пользуются большие группы людей. Например, насколько производительнее будет работать Ваша организация, если Вы удвоите память во всех настольных компьютерах? Как выразить количественно пользу от внедрения новой внутренней телефонной системы? Нечеткость ответов на эти вопросы затрудняет определение деловой выгоды.
• Результаты проекта могут заключаться в увеличении объеме информации, доступной для использования на всех либо на некоторых уровнях организации. Очень трудно установить точно, как эта дополнительная информация трансформируется в принятие лучших решений.
• Положение может улучшиться в результате большого количества проектов за продолжительный период времени. В таком случае, будет трудно определить точно, какую пользу принес каждый из этих проектов в отдельности.
• Результатами проекта могут являться усовершенствования на низком уровне, которые трудно однозначно интерпретировать на уровень бизнеса. Например, сокращение числа этапов в каком-то процессе. Этому процессу потребуется меньше времени, но одновременно могут увеличиться временные затраты на других работах.

Лучшим подходом к определению метрик ценности проекта для бизнеса обычно бывает рассмотрение бизнес-обоснования или анализа "стоимость/выгоды", которые были сделаны до начала проекта. Посмотрите, как была количественно определена польза проекта в данном документе, и оцените, сможете ли Вы фактически измерить подобные результаты после завершения проекта. Если польза определена точно, метрики смогут показать количество фактически принесенной пользы. В случае нечеткого определения пользы, Вам, вероятно, придется применять опросы и косвенные доказательства обеспечения ценности проекта для бизнеса.

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

Собирайте субъективные метрики путем опроса удовлетворенности заказчика

(10.2.P8)

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

Сбор метрик и демографических данных может помочь будущим проектам

(10.2.P9)

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

Если Вы собираете метрики по всей организации, Вам стоит дополнить их некоторыми демографическими данными проекта. Демографические данные - это только предопределенные характеристики проекта, которые обеспечивают его общее описание. Если Вы сохраняете их вместе с метриками в общем файле или в базе данных, то их также можно анализировать, чтобы более подробно и точно выявлять общие тенденции.

Если Вы не собираете демографические данные, Вы все еще сможете сравнить, например, фактические затраты с их первоначальной оценкой. Преимуществом сбора демографических данных проектов является то, что можно сравнивать похожие проекты. Например, можно сравнивать стоимости и трудозатраты, связанные с разработкой "настольных" бизнес-приложений и связанные с веб-программированием. Или же можно сравнивать, насколько успешно проекты Департамента продаж соответствуют своим крайним срокам и бюджетам в сравнении с проектами Финансового департамента.

Другая польза от сбора демографических данных проектов заключается в том, что можно использовать собранную информацию при оценивании будущих проектов. Например, представим, что у Вас имеется проект разработки веб-прилложения, использующего ASP и SQL сервер. Вы могли бы извлечь из базы данных проектов, сколько времени, трудозатрат и денег потребовалось для выполненных ранее подобных проектов. Такая информация может служить подспорьем в оценке Вашего проекта. В целом, демографические данные завершенных проектов, могут быть широко использованы для последующего планирования новых проектов. Пример формы для регистрации демографических данных и метрик проекта можно посмотреть в Библиотеке шаблонов.

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

(10.2.P10)

Проблема со многими метриками может состоять в том, что они описаны таким образом, что не дадут читателю полной картины. Менеджер проекта и команда проекта, возможно, знают, о чем говорит данная метрика, но другие читатели информации не поймут почти ничего. Единственный способ исправить такое положение - всегда сообщать о метрике наряду с ее целевым значением. Например, если Вы сообщаете текущие расходы проекта к определенной дате, включите в сообщение также и плановые затраты к этому моменту времени. Если вы просто заявляете, что проект истратил $100,000, а Ваш общий бюджет составляет $150,000, читателю все еще не понятно, хорошо это или плохо. Безусловно, Вы находитесь в пределах бюджета, но работа еще не закончена. Лучший способ подать такую информацию - сообщить, что Вы потратили $100,000 к определенной дате и что, согласно Вашей оценке, Вам следовало бы потратить $110,000 к данному моменту. Если существующая тенденция продолжится, Вы оцениваете в конце проекта общую сумму издержек проекта, составляющую $135,000, в сравнении с Вашим бюджетом в $150,000. Если Вы доложите метрики с такой припиской, читатели легко поймут, о чем говорят цифры.

Пропагандируйте назначение и пользу метрик и обучайте команду их собирать

(10.2.P11)

Если Вы обсуждаете с командой важность создания качественного продукта, как правило, они понимают, о чем Вы говорите. Качество - это термин, имеющий общепринятое значение, знакомое всем. Общее определение понятия "метрика" не так очевидно. Руководитель проекта может пытаться создать программу измерений для большого проекта, в то время как проектная команда не будет видеть связи между сбором метрик и полученной пользой для бизнеса. Подобное непонимание может также повлиять и на отношение к Вашим инициативам со стороны заказчика. Большинство людей может просто не знать, что Вам необходимо измерять для получения объективной информации о прогрессе проекта и его соответствия ожиданиям клиента. Они также могут не видеть связи между сбором метрики и возможностью улучшать процессы.

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

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

(10.2.P12)

Термины "Критический фактор успеха" (Critical Success Factor, CSF) и "Ключевой показатель производительности" (Key Performance Indicator, KPI) используются для обозначения целевых метрик, связанных с успешностью бизнеса всей компании или организации. (KPI иногда также называют Ключевыми бизнес-индикаторами, KBI). Метрики относятся к категориям CSF и KPI, если здравый смысл подсказывает, что они характеризуют вещи, критически важные для успеха бизнеса. Общий критерий отбора здесь состоит в том, что организация, скорее всего, не достигнет поставленных целей, если не будут соблюдаться эти CSF и KPI.

Многие организации пользуются этими двумя терминами для обозначения одних и тех же вещей, хотя между ними есть некоторая разница. Обычно, ключевые показатели производительности сконцентрированы на процессах. Например, один из ваших KPI может заключаться в сокращении времени доставки заказа клиенту. Это процессно-ориентированная метрика, то есть относящаяся к обеспечению качества. С другой стороны, CSF, напротив, имеет отношение к характеристике выходного продукта. Например, Ваш CSF может быть связан с сокращением количества дефектов в одном из выходных продуктов. Таким образом, CSF будет относиться к метрикам контроля качества.

Определяйте выходную продукцию (конечные результаты) как факторы успеха

(10.2.P13)

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

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

Интересные ссылки:

Project management-related - PMStudent at pmstudent.com
A "cool" website - Petfinder at www.petfinder.com