Нужно — не значит выйдет. И кому нужно? Давайте взглянем шире, а нужно ли на перспективу? У нас 100 конкурирующих фирм. Производящих одно и тоже, и из за неверного управления если вылетает 10% из них мы ничего не теряем. ДА теряет фирма, ее сотрудники (и то мало сомневаюсь, они себе найдут место, даже подороже, так как изменение развития, они только в комфорте потеряют на некоторое время). как вы правильно заметили, вылетели с рынка они из за неумения спрогнозировать конъюнктуру рынка, смогли бы, перестроились заранее. А некоторому бизнесу вообще на конъюнктуру по боку, все работает на договорённостях, да издержки у них неадекватно высокие на такое ИТ, но с другой стороны перекрывается. А когда договоренности накрываются, не важно что ты в трижды издержки ИТ снизишь, договоренности полетели, фирма на рынке не выживет. Им проще новую открыть, со своими поэтессами и лимонадом, заново.
> как вы правильно заметили, вылетели с рынка они из за неумения спрогнозировать конъюнктуру рынка, смогли бы, перестроились заранее.
Итеративные разработки как раз потому и получили широкое распространение в индустрии, что прогноз и планирование тоже имееют свою стоимость. И, как утверждают некоторые исследователи, кривая зависимости стоимости планирования от ее точности взлетает намного круче, чем бизнес-выгоды от этой точности. Это приводит к появлению точки баланса на пересечении этих двух графиков.
А развитие практик архитектуры и разработки привело к тому, что стоимость адаптации под изменяющиеся требования стала дешевле их прогнозирования. Этот момент произошел где-то в начале 2000-х, когда чаша экономической целесообразности качнулась от BDUF к итеративным разработкам, как к способу управления неопределенностью.
Если обратиться к истории, то можно заметить, что снижение стоимости адаптации произошло благодаря развитию практик software design - произошел момент, когда количественные изменения перешли в качественные (
2-й закон диалектики). А практики software design - это исключительно технический аспект, а не бизнесовый. Он имеет свою стоимость, но он так же имеет и точку окупаемости, т.н. "Design Payoff Line" (
https://martinfowler.com/bliki/DesignPayoffLine.html ). Поиск баланса краткосрочных и долгосрочных интересов - это техническая задача, которая может входить в противоречие с сиюминутными интересами бизнеса. И если бизнес игнорирует технические интересы, то это приводит к стремительному росту стоимости изменения кода (на основе анализа некоторых реальных проектов, этот рост может приближаться к экспоненциальной зависимости), а значит, и к росту стоимости его адаптации под скоротечно меняющуюся рыночную обстановку. А это приводит к экономической нецелесообразности итеративной разработки, по сравнению с BDUF.
Таким образом, при игнорировании технических интересов, адаптация, действительно, становится экономически нецелесообразной по сравнению с прогнозом. Здесь я согласен. Но это не отвечает на вопрос о том, дешевле ли прогноз нежели адаптация. Мой опыт подсказывает, что грамотно организованная итеративная разработка все-таки обладает бОльшей экономической целесообразностью. Но, для того, чтобы эта целесообразность была достигнута, должен быть соблюден баланс бизнес и технических интересов в развитии проекта. Причем, как я уже говорил, дисбаланс в пользу технических интересов также
имеет негативные последствия для успешности проекта.
