Lesson 162

Слово Канеру

Изменения всегда опаздывают.

Многие традиционные подходы к управлению проектами предназначены для ограничения и контроля изменений, но другие подходы готовы к ним (например см. Weinberg 1992, Beck 1999, Beck et al. 2001, и Krutchen 2000). Тем не менее, все подходы к управлению проектами имеют дело с изменениями.

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

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

Требования являются результатом непрерывной борьбы между тем, что мы хотим и тем, что мы можем (Bach 1999a). По мере развития проекта требования меняются.