Капитан Очевидность об управлении требованиями

Об управлении требованиями к программному продукту можно говорить только в привязке к выбранным формам поставки этого продукта конечным пользователям. То есть применительно к инсталляциям, версиям, релизам, билдам, обновлениями, патчам и т. п. Если формы поставки размыты и не регламентированы, то и требования остаются сферической моделью продукта в вакууме. То есть требования существуют в своей вселенной, а продукт в своей.

Нет, конечно, команда прикладывает постоянные усилия к тому, чтобы одна вселенная (требования) отражалась на другой (продукт), но говорить об управлении здесь можно только в стиле китайского комсомола: создание себе трудностей для их последующего героического преодоления. Программист говорит «у меня всё работает», менеджер рапортует о том, что требования реализованы, а пользователь не может понять чо-где-как.

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

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