“Changes, changes, changes; they’re the real killers”, — сказал один из менеджеров проектов, с которыми проводила интервью компания Standish group при написании своей знаменитой работы Chaos report, которая анализирует факторы успехов и провалов ИТ проектов. Действительно, изменения — это очень неоднозначная и противоречивая вещь в любом проекте. Возвращаясь к тому же Chaos report мы столкнулись с очень интересными суждениями. К ключевым факторам неудачи IT проекта относится “Заморозка дизайна”, “Негибкие требования” и “Постоянные изменения”. Так что же получается, с одной стороны отсутствие изменений — это плохо, с другой стороны наличие изменений — это тоже плохо?
Управление изменениями (Change management) — это очень комплексная и сложная дисциплина, которая зачастую в стандартах управления проектами выделяется в отдельный блок (например, в стандарте PRINCE2). Эту тему мы будем разбирать постепенно, и в этой небольшой статье разберемся в стоимости изменений в IT проекте от этапа к этапу.
Итак, вполне очевидно (а может и не очень), что чем ближе мы к концу проекта, тем выше стоимость изменений. Но этот фактор связан отнюдь не с тем, что при каждом изменении команда проекта вздрагивает и все переделывает, а в конце проекта психологически это перенести очень тяжело. Разумеется не без этого, но здесь проблема в другом.
IT проект — это комплексная организация и его конечный продукт — это не только работающий софт, хотя он и является самым главным. Помимо продукта, в ходе проекта доставляется и ряд других артефактов. Все эти артефакты тесно взаимосвязаны между собой: из желаний заказчика (в документе Бизнес-кейс) складываются требования (Спецификация), из спецификации формируется модель данных (еще один артефакт) и интерфейс (тоже артефакт), а из них затем формируется программный код. Количество артефактов в проекте увеличивается с каждым этапом и соответственно, каждое изменение, влияет на все большее количество артефактов.
