Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Традиционно — суммированием произведений количества на цену. В чём вопрос-то?
PD>Как определить количество и цену ?
Количество:
1. По таблицам.
2. По формулам.
3. Экстраполяцией.
Цену — по прайс-листам.
Обычная, простая инженерная деятельность. Что именно непонятно?

S>>Получит неприемлемые оценки для быстродействия и закроет проект
PD>От кого ? От инженеров ?
Конечно от инженеров. А от кого ещё?

PD>А, все же инженер должен дать оценки ?
Что значит "всё же"??? Я с самого начала писал, что оценки делает именно инженер.

PD>Это все слова, а реально это может означать, что проект вообще не осуществим. Сказать об этом может только инженер.
Опять пошёл бред после минуты просветления. Я же написал, как устроен критерий неосуществимости проекта.
Как раз в большинстве случаев инженер не владеет нужными данными для принятия решения об осуществимости или неосуществимости.
Инженер не знает ничего ни о ёмкости рынка, ни о доступности финансов

S>>Ну, да, можно иногда ограничиться низкими степенями и всё ещё уложиться в нормативы — например, если мы возьмёмся факторизовывать маленькие числа, то несмотря на NP-полноту получим приемлемое время работы.
S>>Но приемлемость определяется не инженерами, а обратно бизнесом. Хороший инженер, конечно же, помогает бизнесу с этим определением. Потому что бизнес не всегда имеет экспертизу в UX, а инженеру, если он берётся рассуждать о требованиях, такая экспертиза крайне полезна.
PD>Значит, инженер, хоть и как-то туманно, но все же помогает ?
Ну, да. Например, когда заказчик говорит "давайте всё зафигачим в одну форму с 297 вопросами", инженер может предложить что-нибудь типа "давайте порежем на несколько под-форм, или хотя бы разрешим сохранять недозаполненную версию. Потому что вы, как бизнесмен, видите только оптимистичный сценарий, а я, с учётом моего опыта, вижу ещё с десяток, которые тоже для вас важны, хоть вы этого и не осознаёте".

PD>Да. С приближенными решениями не получить нужный результат.

А откуда инженер знает, что такое "нужный результат"?

PD>Бизнес вообще не знает, чем приближенное решение отличается от точного, и вообще даже, есть тут точные решения, приближенные или вообще только эвристические, и насколько они годятся.
У вас какие-то очень, очень мифологические представления о бизнесе.

PD>Бизнес уже знает про задачу коммивояжера ? И может определить без инженеров, что она тут возникает ?
Конечно. Как вы думаете, откуда эта задача вообще возникла? Формулировка задачи была дана никакими не инженерами, а вполне себе бизнесменами: Der Handlungsreisende – wie er sein soll und was er zu tun hat, um Aufträge zu erhalten und eines glücklichen Erfolgs in seinen Geschäften gewiß zu sein – von einem alten Commis-Voyageur.

PD>А он и не должен знать. Его дело — оценить задачу и затраты. А потом выяснится, устраивает ли это заказчика. По деньгам, срокам разработки и окупаемости.
Ну, вот видите. Получается, что у заказчика есть требования к деньгам, срокам, и окупаемости. Задача инженеров — либо уложится в эти требования, либо своевременно предупредить, что не выходит.

PD>Мне кажется, что мы говорим о разных вещах. Ты — о том, как бизнес выставляет требования. Это понятно, что он их должен выставлять из бизнес-соображений, но не будучи компетентен в технической реализации, он может что угодно выставить.
PD>И только специалисты-инженеры могут определить, насколько такие требования реальны. И сказать — нет, за время T мы не сделаем, сделаем только за 2T. И железа нужно не на N USD, а на 10N. И обрабатывать K элементов в минуту мы вообще не сможем, техника не позволяет, а только K/2. И т.д.
PD>С этим согласен ? Да или нет ?
Да, всё верно. Но точно так же — специалисты-инженеры оценивают параметры будущего решения. И только бизнес-специалисты могут сказать, будут ли эти параметры коммерчески оправданы, или нет. Потому что будучи некомпетентны в вопросах бизнеса, инженеры могут нарисовать лишних расходов на разработку там, где это не даст никакого бизнес-выхлопа.

PD>Разумеется, только бизнес определяет, устроит или нет его. Деньги-то его. А инженеры определяют эти данные для бизнеса.
Ну, теперь, надеюсь, понятно, откуда берутся требования к софту?
Или всё ещё остались иллюзии про то, что это инженер придумывает что-то вроде "нам нужно обрабатывать одновременные запросы от 10B пользователей", и пофиг, что столько пользователей на всей планете не найдётся?