Принципы количественного управления
в рубрике Project Management
«Тем, что нельзя измерить, нельзя управлять». Измерения по проекту необходимо выполнять регулярно, не реже одного раза в 1-2 недели. Для каждого измеримого показателя должны быть определены его плановые значения. Для каждого планового значения должны быть определены три области критичности отклонений:
- Допустимые отклонения. Предполагается, что никаких управляющих воздействий не требуется.
- Критичные отклонения. Требуется тщательный анализ причин отклонения и при необходимости применение корректирующих действий.
- Недопустимые отклонения. Требуется срочный анализ причин отклонения и обязательное применение корректирующих действий.
Измерения необходимо производить регулярно. Цель – выявить причины наступивших или возможных критичных и недопустимых отклонений. Результатом анализа должны стать планирование корректирующих действий по компенсации недопустимых отклонений, их реализация и мониторинг результативности применения этих корректирующих действий.
Все измерения необходимо сохранять в репозитарии проекта. Измерения, накопленные в ходе проекте, являются наиболее достоверной основой при детальной оценке и планировании работ на следующих итерациях проекта.
Поскольку главная задача менеджера удержать проект в пределах «железного» треугольника, то, в первую очередь, необходимо анализировать отклонения проекта по срокам и затратам. Делается это при помощи метода освоенного объема [1]. Приходилось сталкиваться с мнением, что этот метод не применим в управлении программными проектами. Это действительно так, если мы используем «водопадную» модель процесса разработки. Но если ИСР проекта, ориентирована на инкрементальную разработку, то это означает, что на верхних уровнях декомпозиции находятся компоненты проектного продукта и их функционал, а не производственные процессы. Следовательно, если в проекте реализованы, протестированы и документированы 50 % функциональных требований, то есть все основания полагать, что осталась приблизительно половина проектных работ.
Суть метода оценки проекта по освоенному объему заключается в следующем. Сначала оценивается отклонение от графика SV (Shedule Variance) в денежных единицах:
SV = EV – PV,
где
EV (Earned Value) - освоенный объем. Плановая стоимость выполненных работ. Объем выполненных работ, выраженный в терминах одобренного бюджета, выделенного на эти работы для плановой операции и элемента иерархической структуры работ;
PV (Planned Value) - плановый объем. Плановая стоимость запланированных работ. Утвержденный бюджет, выделенный на плановые работы, выполняемые в рамках плановой операции или элемента иерархической структуры работ.
Например. Пусть мы на текущий момент реализовали (протестировали и документировали) 20 функциональных требований, на каждое из которых было запланировано затратить по 40 чел.*час. по 1000 руб, то освоенный объем будет
EV = 20 * 40 * 1000 = 800 000 руб.
Если же на текущий момент планировалось реализовать только 15 требований, то плановый объем будет
PV = 15 * 40 * 1000 = 600 000 руб.
Следовательно, мы опережаем график (отклонение от графика положительное) на величину
SV = EV – PV = 800 000– 600 000 = 200 000 руб.
Как пересчитывается отклонение от графика, выраженное в денежных единицах, в сокращение сроков проекта иллюстрируется на Рисунок 43.
Если мы опережаем график, то это не обязательно означает что проект идет успешно. Хорошо это или плохо зависит от значения другого показателя метода освоенного объема: CV (Cost Variance) - отклонения по затратам, которое оценивается по формуле:
CV = EV – AC
где
AC, (Actual Cost) - фактические затраты. Фактическая стоимость выполненных работ. Фактические затраты на выполнение работ за определенный период в рамках плановой операции или элемента иерархической структуры работ.
Например, если мы для того что сократить время работ по проекту работали 25% времени сверхурочно и в выходные дни с двойной оплатой, то фактические трудозатраты составили:
AC = 20 * (30 * 1000 + 10 * 2000) = 1 000 000 руб.
Поэтому отклонения по затратам в нашем случае будет
CV = EV – AC PV = 800 000 – 1 000 000 = - 200 000 руб.
Отрицательное значение отклонения по затратам означает, что мы превысили бюджет, что, в общем случае, не очень хорошо. Но если срок завершения проекта для нас имеет высший приоритет, и наши прогнозируемые затраты по завершению проекта не превышают плановых с учетом управленческого резерва (Рисунок 43), то в этом случае можно считать, что проект выполняется успешно.
43. Оценка и прогноз показателей по методу освоенного объема
Отклонение от бюджета и по срокам в абсолютных денежных единицах недостаточно для характеристики проектов разных масштабов. Более наглядны относительные показатели: индекс выполнения сроков SPI (Schedule Performance Index)
SPI = EV / PV
и индекс выполнения стоимости CPI (Cost Performance Index)
CPI = EV / AC,
которые характеризуют проект независимо от его размера. Если значения обоих индексов больше 1, то это свидетельствуют о благополучном состоянии в проекте.
Какие еще измеримые показатели целесообразно применять в управлении программным проектом?
В первую очередь это показатель прогресса проекта, доля реализованных и проверенных высокоуровневых требований к проекту, например отношение числа завершенных сценариев использования продукта к их общему числу.
Другой показатель - стабильность проекта, общее количество принятых (утвержденных спонсором или заказчиком) изменений в плане управления проектом. Чем выше нестабильность в проекте, тем больше сложность в управлении работами и ниже производительность участников.
Если кто-то думает что код это решение проблемы, то это не так. Код это новый источник проблем. Поэтому всегда следует измерять текущий размер проекта - количество строк исходного кода, добавленных, измененных и удаленных в ходе выполнения проекта разработки ПО. Чем больше объем исходного кода, тем больше времени потребуется на внесение изменений и исправление ошибок.
При увеличении объема проектного продукта трудозатраты на каждую новую строку исходного кода увеличиваются. Если за номинал взять производительность проектной команды при производстве продукта в 10 KSLOC, то та же команда на проекте в 100 KSLOC покажет производительность в 1.3 – 1.7 раз меньшую, а на проекте в 1000 KSLOC следует ожидать, что производительность снизится в 1.6 – 3.0 раза [2].
Большой объем кода так же потребует большего количества людей на его сопровождение. Поскольку, даже если будет выявляться только несколько критических ошибок в год, то для того чтобы их исправить в приемлемые сроки, например, за 24 часа, в продукте общим объемом в 1000 KSLOC то один программист с этим не справится. Это связано с тем, что для того чтобы исправить ошибку в ограниченные сроки необходимо оперативно выявить и устранить ее причину, а для этого надо хорошо знать архитектуру и код программного продукта. Чтобы эффективно сопровождать продукт подобного объема необходимо иметь в «горячем» резерве примерно 20 разработчиков, потому что 50 KSLOC, на мой взгляд, это предельный объем кода, который может удерживать в голове и эффективно сопровождать один человек. И еще проблема: чем этих людей занимать в свободное от исправлений ошибок время, если нет новых проектов развития продукта.
Следующий важный показатель состояния проекта – это средняя производительность, отношение текущего размера проекта к фактическим затратам по проекту. С. Макконнелл приводит следующие показатели (минимальное, максимальное и среднее значение) производительности в KSLOC на один чел.*мес. фактических затрат для стандартных типов проектов объемом в 100 KSLOC:
- 300-7000 (800) - интранет система.
- 200-7000 (600) - бизнес система.
- 100-2000 (300) - Интернет система.
- 50-600 (100) - системное ПО, телекоммуникации.
- 20-300 (50) - системы реального времени.
Высокая производительность в проекте – это далеко не всегда хороший признак. Приходилось встречаться с проектами, в которых вследствие активного применения метода «copy+past», средняя производительность в разработке бизнес системы достигала 2000 SLOC/чел.*мес. Однако для реализации функционала было написано в 3 – 4 раза больше кода, чем это могло бы потребоваться при адекватной проработке архитектуры.
Еще одна группа количественных показателей, которые следует наблюдать в ходе реализации проекта, характеризует качество программного продукта:
- Дефектность продукта – количество выявленных дефектов на единицу объема продукта (например, KSLOC).
- Доля не устраненных дефектов - отношение количества незакрытых максимально критичных и критичных дефектов к количеству выявленных несоответствий.
- Средние затраты на сопровождение – средние трудозатраты на исправление одного дефекта. Высокое значение этого показателя может свидетельствовать о некачественной архитектуре программного продукта.
- Документированность кода - определяет процент строк исходного кода с комментарии по отношению к общему количеству строк.
Следует подчеркнуть, что наблюдать надо за средними по проекту значениями показателей, и ни в коем случае не пытаться измерять индивидуальные характеристики производительности и качества. Главные причины, почему это не следует делать, заключаются в том, что, во-первых, в этом случае вместо слаженной командной работы мы получим личную конкуренцию, а, во-вторых, наиболее «продвинутые» разработчики станут работать на формальные показатели, а не на достижение целей проекта.
Если команда действительно состоялась, то для нее характерна коллективная ответственность за достижение общих целей. И, как пишет, Т.Демарко, «менеджер проекта должен занимать очередь, чтобы покритиковать сотрудника, не выполняющего свои обещания», поскольку в правильной команде для этого всегда найдется масса желающих.
Комментариев: 12 на “Принципы количественного управления”
Прокомментировать
Вы должны быть авторизованы для комментирования.
Бындю Александр:
Спасибо за статью.
У меня вопрос не по основной теме.
“чем этих людей занимать в свободное от исправлений ошибок время, если нет новых проектов развития продукта”
Вот интересно чем вы обычно этих людей занимаете? Другими словами, что делать, когда от проекта до проекта пару месяцев? Не распускать же команду…
25 ноября, 2009 в 15:43
Архипенков Сергей:
Например, в свое время (не знаю как сейчас) в компании PriceWaterhouseCoopers был открыт внутренний проект профессионального развития сотрудников. У каждого был план личного развития (самообразование, тренинги, конференции), по которому он работал в свободное от коммерческих проектов время, и списывал потраченные часы на этот проект. У каждого был ментор, который подтверждал результаты, достигнутые в этом проекте.
Кстати, если в течение года сотрудник был загружен в коммерческих проектах более 60% своего рабочего времени, то это считалось плохо. Потому что консультант PWC должен знать и уметь намного больше, чем любой потенциальный клиент.
25 ноября, 2009 в 16:00
Бындю Александр:
Да, вы же говорили об этом на лекции! Только это было про вашу работу, но теперь видно, что и для разработчиков “внутренний проект профессионального развития ” подойдет.
“У каждого был план личного развития…”
Я правильно понял, что этот план составлялся самим разработчиком и утверждался начальством?
25 ноября, 2009 в 22:02
Архипенков Сергей:
По поводу плана личного развития. Он составлялся на основе стратегии компании и, разумеется, согласовывался с каждым сотрудником. Например, в PWC я занимался технологиями DW и OLAP. Специализировался на решениях от Oracle. В планы PWC входило расширение линейки предложений по этому направлению. Мне было предложено освоить еще одно решение кого-нибудь из конкурентов Oracle. Я выбрал продуктовую линейку от SAS Institute. И в течение года занимался самообразованием, посещал тренинги, съездил на конференцию SAS в Германии.
26 ноября, 2009 в 10:05
Бындю Александр:
Сергей, спасибо за ответы!
26 ноября, 2009 в 13:04
Veller Pavel:
Том ДеМарко - автор заглавной цитаты “you can’t control what you can’t measure” - совсем недавно опубликовал свой свежий взгляд на когда-то им же пропагандированный принцип:
http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf
31 декабря, 2009 в 7:22
Спанч Боб:
2Pavel: Павел, спасибо большое, какая замечательная статья, спасибо за ссылку! Интересно, есть ли ее перевод на русский для тех, кто не читает по английски?
Я и сам чувствовал нечто подобное, читая статью Сергея. Кто знает, может быть Сергей тоже со временем пересмотрит свои взгляды на “измерения по проекту ”
15 января, 2010 в 6:12
Архипенков Сергей:
Привет, Павел!
Спасибо за ссылку. Прочитал.
Привет, Боб!
Что нового сказал Демарко?
Он сказал, что бывают проекты класса « A will eventually cost about a million dollars and produce value of around $1.1 million» и класса «B will eventually cost about a million dollars and produce value of more than $50 million».
Он сказал, что в проектах класса B можно ослабить контроль.
Но, к сожалению, из всех известных мне программных проектов, которые реализуются на территории РФ, ни один не относится к классу B.
Так что, пока я не вижу оснований для пересмотра своих взглядов
15 января, 2010 в 14:29
Veller Pavel:
и еще Демарко риторически посетовал в сердцах (дальше в свободном переводе) - “чем пытаться ответить на вопрос, как же именно контролировать проект разработки ПО, давайте лучше разберемся, какого же черта мы делаем так много проектов, задуманных приносить такую незначительную ценность”.
–
Я, вообще, не противник измерений. И, готовясь к своему PMP два года назад, в который раз проникся техниками EV. Просто как и все гениальное. А до этого, имев удовольствие поработать с Primavera Software, еще больше проникся, наблюдая, как компания, знающая про EV больше многих и выпускающая нишевый програмный продукт для управления проектами огромных сртоек (Дубаи, Гонконг), делает это по книжному SCRUM-у (вот тут есть case study - http://www.controlchaos.com/download/Primavera%20White%20Paper.pdf)
Это не значит что измерениям в разработке ПО не место. Очень мнгого пишут и рассуждают о том, что же все-таки (и главное как) надо мерять в Agile. Не ошибусь, если скажу, что минимум раз в неделю встречаю заголовки об измерениях в agile на agile трэке infoq.com. Eсли звёзды зажигают - значит - это кому-нибудь нужно.
Вот только мерять KLOC, а тем более - мерятся KLOC-взвешанными метриками, мне кажется, вряд ли показательно. Кодегенерация, DSL, MDD, *Rails, а главное - количество 3-те стороннего кода (например в виде OSS библиотек, котейнеров, в которые ставится приложение и его части, внешних сервисов и точек интеграции) делают KLOC измерения достаточно условным отражением сложности и объемности системы, и не менее условным мерилом производительности команды.
20 января, 2010 в 9:20
Баранцев Алексей:
Добавлю капельку дёгтя…
Выбранное в качестве типа-эпиграфа высказывание ДеМарко восходит к часто встречающейся в литературе по измерениям цитате лорда Кельвина:
“When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of science.”
Однако это натуральное шулерство! Вот более полная версия этого высказывания, а не выдернутый из контекста кусок:
“In physical science the first essential step in the direction of learning any subject is to find principles of numerical reckoning and practicable methods for measuring some quality connected with it. I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be.” [PLA, vol. 1, "Electrical Units of Measurement", 1883-05-03]
(http://www.jmorganmarketing.com/lord-kelvin-on-measurement/)
“In physical science”, ясно? Это в естественных науках вы не можете добиться успеха, если не научитесь измерять явления и выражать это в числах, а также не научитесь добиваться устойчивого повторения этих измерений от эксперимента к эксперименту.
Программная инженерия — не естественная наука, а социальная (и даже не наука, а социально-инженерная дисциплина, но это уже не так важно на фоне первого).
Хотите измерять — нет проблем, измеряйте. Но не пытайтесь делать вид, что вы умеете добиваться стопроцентной повторяемости эксперимента, а если что-то не сходится, умеете определять факторы, которые привели к отклонению.
3 февраля, 2010 в 12:53
Архипенков Сергей:
Алексей, привет!
Ты совершенно прав, когда пишешь, что в разработке ПО гораздо больше психологии и социологии, чем инженерии. В этом одна из отличительных особенностей программирования по сравнению с отраслями материального производства.
Но я не понял, ты что вообще против измерений в программном проекте?
Я уже много лет использую небольшой по количеству и простой по сбору набор метрик, описанный в статье. Это позволяет мне увереннее предвидеть будущее и спокойнее спать:)
Описание программного проекта этими макро-показателями сродни подходу статистической физики, которая описывает, как из движений частиц системы складывается усреднённая эволюция системы в целом. Я никогда не пытаюсь измерять направление движения и скорость каждой отдельной частицы. Но направление, скорость и температура потока (проекта разработки) в целом - показатели достаточно стабильные, чтобы на их основе строить прогнозы, находить причины отклонений и корректировать движение.
Вот, например, одна стабильная статистика, накопленная мной в проектах заказной разработки бизнес-приложений, которая сильно облегчает мне жизнь. Это распределение проектных трудозатрат по видам деятельности:
Управление проектом – 10%
Бизнес-анализ – 10%
Архитектура и проектирование – 15%
Кодирование – 25%
Тестирование – 25%
Управление конфигурациями – 10%
Документация пользователя – 5%
Дисклаймер. Про распространение на другие прикладные области речь не идет.
Чем это облегчает мне жизнь?
Рассмотрим пример. Мне приносят вменяемое (уже большой успех!) ТЗ на 300 стр. Неплохую оценку трудоемкости разработки можно получить по формуле
ТРУД= Кстр.*Т * 9 = 8100 чел.*час.
Здесь ТРУД – трудоемкость разработки ПО по ТЗ с количеством страниц Кстр., а Т – количество чел.*часов, на написание 1-ой страницы. Адекватный аналитик, опять же по моей статистике, тратит ан создание 1-ой страницы ТЗ в среднем 3 часа (не веришь мне, готов сослаться на ГОСТ Р ИСО/МЭК 15910-2002. Приложение F).
И эта оценка, как показывает, опять же, статистика, имеет доверительный интервал от -15% до +30%, что совсем неплохо в нашей отрасли!
3 февраля, 2010 в 17:05
Баранцев Алексей:
>> Но я не понял, ты что вообще против измерений в программном проекте?
Нет, я не против измерений. Я против количественных измерений. Ещё более точно — я против использования количественных измерений там, где можно обойтись качественными показателями.
Давай за что нибудь конкретное зацепимся. Пусть это будет твоё заявление в конце предыдущего комментария
>> Мне приносят вменяемое (уже большой успех!) ТЗ на 300 стр. Неплохую оценку трудоемкости разработки можно получить по формуле ТРУД= Кстр.*Т * 9 = 8100 чел.*час.
Скажи, как ты получил значения доверительного интервала? Сколько было проделано экспериментов? Проводилась ли оценка репрезентативности выборки?
Я предполагаю, что на самом деле это твоё количественное высказывание следует интерпретировать следующим образом.
Ты проделал несколько экспериментов (проектов), завершившихся относительно успешно (а может быть даже мегауспешно). На основании этого накопленного опыта ты вывел эмпирику — если я буду поступать так же и в дальнейшем, проекты снова будут завершаться успешно. Что значит “поступать так же”? Ты решил описать это количественной характеристикой, которая относительно стабильно повторялась от проекта к проекту. И теперь пытаешься сказать, что эта характеристика и есть выражение сути эмпирики.
Где здесь логические ошибки?
1. Во-первых, эмпирика может оказаться неверной, то есть уже на следующем проекте она не сработает.
2. Во-вторых, эмпирика может быть хорошей, но ты можешь неверно оценивать её границы применимости.
3. В-третьих, выбор количественной характеристики может быть ошибочным. Это может быть корреляция, а может быть просто случайное совпадение.
4. В-четвёртых, если из A следует В, это не значит, что из B следует A. Если даже во всех в успешных проектах значение этой характеристики было такое, это не значит, что обеспечение нужного значения гарантирует успех.
Соответственно, продолжаю я развивать свою интерпретацию, твоё утверждение следует понимать так: ты, Сергей, опытный менеджер, готов сделать такой-то проект успешно с определённой долей уверенности, если тебе дать сколько-то времени и ресурсов. Это базирующаяся на твоей интуиции и опыте эмпирика. А если тебе дать больше времени и ресурсов? Или меньше? Тогда степень твоей уверенности повысится или снизится, и ты почему-то выражаешь это повышение или понижение уверенности словами “доверительный интервал” и пытаешься выразить в процентах чего-то.
В общем, можно долго обсуждать тему количественные vs. качественные оценки. Интересующимся рекомендую почитать книжку Роберта Гласса “Факты и заблуждения профессионального программирования” http://www.ozon.ru/context/detail/id/3707281/ , замечательно прочищает мозги
Конкретно обсуждаемому вопросу посвящена глава 5 этой книги, оригинальную английскую версию этой главы можно на халяву почитать на сайте издателя: http://ptgmedia.pearsoncmg.com/images/0321117425/samplechapter/glassch05.pdf
3 февраля, 2010 в 18:12