НовостиСобытияКонференцииФорумыIT@Work
Идеи и практики автоматизации:

Блог

Как не надо осваивать проектные объемы

Сергей Бобровский
31.05.2011 10:22:43
Теги: EVM, agile

Очередная проектная методология, которую неугомонные айтишники-аджайлисты пытаются приспособить под свои нужды -- earned value management (EVM), управление освоенным объемом. Она подразумевает сравнение запланированного объема работ (плановой стоимости) с фактически выполненным (или с фактической стоимостью). EVM весьма стара -- была создана в 1960-е в Пентагоне, а оказалась столь удачной, что вошла аж в самое первое издание PMBoK 1987 г.
Форум Agile Alliance недавно провел обсуждение этой темы, а общие итоги обобщил Scott Ambler, главный методолог по аджайлу в IBM Rational.

EVM относительно сложна и требует определенных математических расчетов
(подробное описание на русском с картинками). Она позволяет, сравнивая запланированные объемы (затраты) с фактическими, прогнозировать итоговый бюджет и сроки, а в более продвинутых версиях помогает находить и причины отклонений от планируемых показателей, хорошо стыкуется с диаграммами Ганта и методом критического пути и т. д.

Но, оказывается, для ИТ- (и, в частности, программистских) проектов EVM подходит, мягко говоря, не очень хорошо. Например, для модели "водопада" она не годится вообще, потому что в этой модели общая стоимость проекта не будет известна до самого конца, а ранние ее оценки будут крайне приблизительны и могут не совпадать с итоговыми в разы. Ведь в программировании "готовность на 90%" часто означает, что реально предстоит сделать еще 90% работы.

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

При использовании аджайлов ситуация выглядит лучше -- по каждой короткой итерации появляется некий законченный прототип, и по его функциональности можно оценить, какие требования удастся реализовать на следующей итерации. Однако все равно с объемом работ из классических проектов такие оценки имеют мало общего, и управлять аджайлом с помощью EVM-графиков почти всегда невозможно. Так, 45% итоговой функциональности системы обычно никогда не используется, а 19% -- используется лишь частично, и понять нужность или ненужность функций до начала эксплуатации системы невозможно. В итоге на практике ИТ-командам в лучшем случае удавалось "произвести" 55% запланированного по EVM объема в заданные сроки.

Scott Ambler откровенно называет EVM плохой проектной ИТ-стратегией, хотя оппоненты, конечно, находят достаточно весомые контр-аргументы. Так, измерять объем работ можно в деньгах (или же во временных трудозатратах) -- тогда EVM превращается в типичный инструмент финансового мониторинга, и PM-у как минимум он не помешает (но и преувеличивать его значимость тоже не стоит). Да и указанные Эмблером проблемы связаны скорее с плохой организацией работ и недостатке практики в самой EVM. Но все же пытаться управлять осваиванием объемов ИТ-работ по EVM, не имея соответствующего опыта, явно не стоит.

Комментариев: 0

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии