💭 В идеальном мире вы смогли бы собрать все требования к новой системе до начала разработки и сохранить их стабильность на протяжении всего процесса, но на практике, к сожалению, всё не так просто.

👉 На определённом этапе вам нужно будет «заморозить» требования до определённой версии, иначе вы не сможете достичь результата. Однако, если вы приостановите работу над требованиями слишком рано, вы проигнорируете тот факт, что клиенты не всегда уверены в своих потребностях. Клиентам могут потребоваться изменения, и разработчикам нужно будет отреагировать на это.

Незапланированным изменением требований считается предложение новой функциональности и существенной модификации после утверждения базовой версии требований к проекту, о которой мы говорили несколько недель назад. Чем дольше продолжается работа над проектом, тем больше увеличивается его объём.

Требования к системе управления информацией обычно увеличиваются на 1–3% в месяц. Некоторые изменения требований вполне обоснованы, неизбежны и даже полезны. Однако рост объёма, когда в проект постоянно добавляется новая функциональность без учёта ресурсов, графика или целей качества, гораздо более опасен ❌

Проблема не в самих изменениях требований, а в том, что поздние изменения оказывают значительное влияние на уже выполненную работу. Если все изменения будут одобрены, может оказаться, что нет никакой надежды на разработку продукта, и он не будет разработан 😒