<<
>>

Главный риск №2: Раздувание требований

Программное обеспечение, которое вы со своей командой разрабатываете, всегда предназначено для того, чтобы вписаться в область деятельности вашего клиента. В одном вы можете быть уверены — в том, что эта область не останется статичной за время создания программного обеспечения.

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

С точки зрения проекта, это изменение всегда является раздуванием. Даже удаление того, что уже создано — своего рода раздувание, поскольку требует дополнительной работы.

Сколько именно дополнений разумно ожидать? Если вы согласны с нашим мнением, изложенным в последних двух параграфах, то понимаете, что 0% не будет правильным ответом.

Но именно такой ответ подразумевается при нашем обычном планировании нового проекта. Наши рассуждения выглядят примерно так:

Если вы хотите X, мы можем дать вам его через 10 месяцев; если окажется, что вам нужно что-то иное, чем X, это ваши трудности.

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

Логичнее поступить как-то так: «Вы говорите, что хотите X, наш опыт подсказывает, что в процессе работы возникнут изменения в требованиях и вы в итоге захотите что-то слегка иное, поэтому мы будем планировать создание X с некоторой готовностью к ожидаемым изменениям».

Но какой именно готовностью? В середине 1990-х министерством обороны США было предложено количественное определение того, как должны вести себя хорошо управляемые проекты.

Они количественно измерили размер разумно ожидаемых изменений примерно на уровне менее 1% в месяц. Итак, проект, по созданию продукта размером в 20000 функциональных точек[23] за два года, должен быть рассчитан на создание примерно 25000 функциональных точек программного обеспечения (20000 фт х (1.00 + 24 месяца х 1 % в месяц)). Реальный размер будет где-то посередине, поскольку часть изменений потребует отмены уже выполненных и оплаченных работ.

Опыт Минобороны США, может быть, трудно применить к вашему проекту. Поскольку типичные программные продукты для Минобороны велики, проекты часто выполняются с привлечением субподрядчиков (иногда нескольких уровней) и их продолжительность дольше, чем у большинства коммерческих проектов, более того, приближение, предложенное Минобороны США выражено, скорее, «терминах самого объема, чем в его влиянии на продолжительность по времени.

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

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

<< | >>
Источник: Том ДеМарко. Вальсируя с Медведями Управление рисками в проектах по разработке программного обеспечения. 2005

Еще по теме Главный риск №2: Раздувание требований:

  1. § 24 Замена одного требования другим противоположным (компенсация). – Основания сей замены и законные для нее условия. – Однородность требований. – Отношение их по количеству. – Действие несостоятельности на замену. – Требования несоизмеримые. – Необязательность замены.
  2. 4. Кондикционное требование и требование стороны в обязательстве о возврате исполненного
  3. 2. Кондикционное требование и требование о возврате исполненного по недействительной сделке
  4. § 5. Соотношение кондикционного требования с обязательствами возврата, а также с требованиями, составляющими содержание договорной ответственности (п. 2483—2485)
  5. РИСК
  6. 2. Страховой риск
  7. Риск и личная безопасность.
  8. Риск
  9. Риск - это всегда характеристика преуспевающих людей.
  10. СПТ уменьшает риск в жизни психотерапевта
  11. Статья 580. Риск случайного уничтожения или случайного повреждения предмета залога
  12. Статья 772. Риск случайного уничтожения или случайного повреждения вещи
  13. Статья 323. Риск случайного уничтожения и случайного повреждения имущества