Здравствуйте, Shmj, Вы писали:

S>Вопрос такой.

Сегодня быстрее всего развиваются всякого рода свистоперделки для всех типов гаджетов.

Здравствуйте, mike_rs, Вы писали:

_>ты еще раз прочти написанное выше. на пальцах — есть заказчик с конкретной задачей, при решении которой в те сроки, что требуются заказчику, он (заказчик) готов за это заплатить чемодан денег. Вот тебе пример откуда идут требования и сроки.

И ты попробуй понять, что эти требования и сроки сложились на основе программистской практики и технических возможностей. Без этого никакой заказчик не мог бы их сформулировать.
А практика, увы, такая, о которой я писал.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>И ты попробуй понять, что эти требования и сроки сложились на основе программистской практики и технических возможностей. Без этого никакой заказчик не мог бы их сформулировать.
PD>А практика, увы, такая, о которой я писал.

Снова телега впереди лошади. Еще раз — есть конкретная задача, за решение которой к определенному времени заказчик готов заплатить. Если ее решат позже, то платить уже не готов или заплатит сильно меньше. Все остальное вторично и пляшет уже внутри этих начальных условий.

Здравствуйте, mike_rs, Вы писали:

PD>>И ты попробуй понять, что эти требования и сроки сложились на основе программистской практики и технических возможностей. Без этого никакой заказчик не мог бы их сформулировать.
PD>>А практика, увы, такая, о которой я писал.

_>Снова телега впереди лошади. Еще раз — есть конкретная задача, за решение которой к определенному времени заказчик готов заплатить. Если ее решат позже, то платить уже не готов или заплатит сильно меньше. Все остальное вторично и пляшет уже внутри этих начальных условий.

Ладно, давай иначе. Из каких соображений он исходит, устанавливая эти требования и сроки ?

Вот допустим

Требования по фичам — вполне разумные, ничего невозможного
Требования по быстродействию — некая операция за N единиц времени
Требования по памяти — не более M единиц памяти
Требования по срокам — не более L месяцев.

На основании какой информации заказчик эти требования выдвинул ?

Обязательное условие — заказчик сам не программист , не архитектор и т.д, а лишь пользователь.

Как он определил N, M и L ?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>На основании какой информации заказчик эти требования выдвинул ?
PD>Обязательное условие — заказчик сам не программист , не архитектор и т.д, а лишь пользователь.

Заказчик так глубоко не копает. Ну например, нужна защита информации от утечек. У нас парк из 100 машин от win7 до win11, 4 сервера HP. Защита нужна максимум через месяц и сертифицированная, иначе мы в тендер не попадем. Заплатим условный чемодан денег. Сможете?

Здравствуйте, mike_rs, Вы писали:

_>Заказчик так глубоко не копает. Ну например, нужна защита информации от утечек. У нас парк из 100 машин от win7 до win11, 4 сервера HP. Защита нужна максимум через месяц и сертифицированная, иначе мы в тендер не попадем. Заплатим условный чемодан денег. Сможете?

Нет, не переводи вопрос на безопасность, да еще в каком-то кластере машин, это другая тема.

Просто разработка некоей программы (или серверной части). Требования к ней он дает.
Набор фич он точно должен сформулировать, кто же еще может ?.
И требования по быстродействию тоже.
Насчет памяти — тут он действительно может и не разбираться, ладно.

На основании каких соображений он эти требования может выдвинуть ?

Набор фич — ладно, должен же он знать, что ему надо.
А вот с быстродействием как ? На основании чего он может сказать, что вот такое его устроит, а такое нет ?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Просто разучились писать приложения компактно.

Так это нормально. Прогресс в железе, а довеском к нему — массовость профессии, которая ведет к снижению среднего уровня.

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

В общем, оно эволюционно пухнет на всех слоях — от ядра через api и либы с фреймворами до приложения. Еще случаются революции вроде запихивания броузера в нативные приложения. Броузер же с его песочницами и прочим — прожорливая скотинка.

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>На основании какой информации заказчик эти требования выдвинул ?
На основании объективной.
Вот берём что-нибудь простое — например, распознавалка номеров автомобилей на шлагбауме, который стоит на въезде на офисную парковку.
Любой аналитик тебе безо всякого программистского опыта скажет, что больше 10 секунд — нельзя, т.к. водитель решит, что система неисправна, и уедет.
И что меньше 0.5 секунды — нерелевантно, т.к. время проезда будет определяться временем реакции водителя, а не автомата.
Поэтому будет сказано "500 миллисекунд", а дальше — твоя работа, как разработчика, спроектировать так, чтобы всё работало.
В том числе и сформулировать требования к железке. И тут может возникнуть некое пространство вариантов.
Например, в одном варианте ты предлагаешь потратить лишние полтора месяца (то есть примерно 500к рублей, плюс налоги, плюс сборы, плюс накладные, умножить на риск) на оптимизацию, и упихаться в один сервер за 200к рублей.
Во втором — забить на оптимизацию, и просто поднять два сервера по 200к рублей.
И вот бизнес вполне способен выбрать между этими вариантами, если ты сам не сможешь.

PD>Обязательное условие — заказчик сам не программист , не архитектор и т.д, а лишь пользователь.
PD>Как он определил N, M и L ?
Из требований предметной области.
Или вот, скажем, надо тебе показывать пользователю фильм. Бизнес тебе говорит: надо показывать 30 FPS 4K, при этом терять можно не более 1 кадра в 10 секунд.
Почему? Потому, что вот такой видеоконтент, и вот таковы данные тестирования целевой аудитории — если теряем чаще, то пользователи это замечают и уходят. Ты идёшь и делаешь. Никому не надо воспроизводить видео со скоростью 900 FPS, особенно за дополнительные затраты.

Не бывает такого бизнеса, который бы говорил "сделай мне распознавание номеров машин как можно быстрее", а ты такой ему с высоты своего опыта поясняешь "я умею это делать за 1 миллисекунду, а если кто-то предлагает за 20 — гоните его в шею, он ламер".
Иногда бывает так, что бизнес приходит к тебе и говорит: "я тут посмотрел — на рынке есть планшеты, которые на одной зарядке могут играть 60FPS 4K видео четыре часа. Я считаю, что есть ниша долгоживущих плееров, которые смогут делать то же самое 12 часов — на рейсах между Европой и Южной Америкой. Возможности увеличивать вес батареи уже исчерпаны. Я говорил с учёными — увеличить ёмкость батареи при том же весе пока способов нет; разработка потребует 5 миллиардов долларов и неизвестное количество лет. Говорил с чипмейкерами — сократить энергопотребление втрое при сохранении производительности можно, но разработка потребует 5 миллиардов долларов и несколько лет.
Вот теперь тебя спрашиваю — можешь переписать код, чтобы плеер на том же чипе и с той же батареей работал 12 часов вместо 4х?"
И ты ему отвечаешь — можно или нельзя. И сколько стоит.
Типа — могу удвоить производительность, потребуется полгода работы. Утроить — не знаю, надо пробовать. Пробовать буду год, если не получится — увы, деньги будут потрачены зря.
И бизнес решает — дать тебе такую открытую задачу, или ну его нафик. Может быть и даст — "даже если получится 8 часов, то уже неплохо — будем позиционировать для рейсов Европа-Северная Америка".

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Набор фич — ладно, должен же он знать, что ему надо.
PD>А вот с быстродействием как ? На основании чего он может сказать, что вот такое его устроит, а такое нет ?
Да очень просто. Любой бизнес занимается планированием и анализом рынка.
Мы же не просто "делаем серверную часть". У нас известно:
а) сколько будет пользователей. Через 3, 6, 12 месяцев.
б) сколько и каких функций они будут выполнять
в) какие у пользователей ожидания по времени ответа на запрос.

Вот мы и получаем что-нибудь типа "20к запросов в сутки в среднем, в пике вырастает впятеро" + "95% запросов должны исполняться за 500мс".

Тут нет никакой rocket science, и техническая подготовка бизнесмена почти никакой роли не играет.

Понятно, что правила игры в основном задаются рынком. Я помню, как в начале 2000х мне в местном банке объясняли, что внутрибанковский перевод из московского офиса в новосибирский идёт до 3х дней, и это нормально.
Понятно — перевод на сберкнижку из другого города мог и месяц идти, поэтому три дня им казалось разумным сроком. А я им объяснял, что даже наличку можно привезти за 8 часов, а безнал должен идти со скоростью прохождения сигнала в кабеле.

Ну, так на то и бизнес — постепенно появились бодрые ребята, которые сломали эти стереотипы. Не программисты, а бизнесмены. Ведь три дня перевод "шёл" потому, что был такой процесс, в котором раз в сутки кто-то нажимал на кнопку "провести межфилиальные взаиморасчёты". А три дня — потому что перевод, отправленный в 13:00 пятницы будет обработан в 12:00 понедельника. А вовсе не потому, что сервера Собинбанка были написаны неквалифицированными программистами на медленных языках программирования.

Появляется у бизнесмена идея — и он начинает её исследовать, копать в нужную сторону.

Здравствуйте, Sinclair, Вы писали:

S>Вот мы и получаем что-нибудь типа "20к запросов в сутки в среднем, в пике вырастает впятеро" + "95% запросов должны исполняться за 500мс".

Во времена Windows NT 4 Server на 80486 процессоре c памятью 16 Мбайт можно было бы такое обеспечить ?

Если да — значит, 16 Мбайт хватит.

Если нет — начиная с которого можно было бы ?

Здравствуйте, Shmj, Вы писали:

S>Вопрос такой.

На персональных девайсах наиболее быстро развивается перифирия и характеристики ОЗУ.
Причём, это относительно замедлившегося развития быстродействия в пересчёте на ядро центрального процессора, а на самом деле перифирия всегда развивалась и продолжает развиваться медленно.

Еще неплохо развивилось ПО — сейчас на персональных девайсах возможности ПО, можно сказать, целиком используют возможности железа.

В деле развития инфраструктуры и степени интеграции различного ПО (в т.ч. через инфраструктурно-образующее ПО) — по-прежнему наблюдается серьезное отставание от располагаемых современных технологий в вопросе в продуманности самой инфраструктуры и обслуживающего ПО. Но именно здесь идёт самое быстрое развитие из всего перечисленного (в последние лет 10 точно), спасибо мобильным девайсам и мобильной связи.

Здравствуйте, Carc, Вы писали:

C>Новомодные "хипстеры" из подходов к разработке по моему знают только "хлоп, шлёп, хренакс и в продакшн".

Но эти действия выполняются на всё более мощных программных платформах.
Я тут не об эффективности этих платформ в пересчёте на тик процессора, а о предоставляемых "кирпичиках".

В идеале, решения типовых задач примерно так и должны выглядеть — как сборка из кубиков Лего, как оно происходит уже лет 40 в электронике (аналоговой и цифровой).
В ПО в этом смысле до сих пор происходит первобытный хаос, "поиск себя", утруска, усушка и т.д. ))


C>Какое уж тут профилирование, требования к ресурсам, да и заканчивая обычной UX, Use-case аналитикой, code-review, да usability в придачу.

Эти вещи должны всё чаще быть решаемы на платформенном уровне.
В т.ч. платформы должны предоставлять удобные ср-ва диагностики полученных с их помощью решений.

Взять тот же Питон — тормоз хуже некуда...
Но всё больше "кирпичиков" являются обертками над низкоуровневыми нейтивными библиотеками, что в ИИ Питон теперь рулит, выступая популярным клеем для готовых ИИ-алгоритмов.

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

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
S>>Вот мы и получаем что-нибудь типа "20к запросов в сутки в среднем, в пике вырастает впятеро" + "95% запросов должны исполняться за 500мс".
PD>Во времена Windows NT 4 Server на 80486 процессоре c памятью 16 Мбайт можно было бы такое обеспечить ?
Не могу сказать — не моя область специализации.
Вполне может быть, что можно было бы, только потребовалась бы серверная ферма и аккуратное распараллеливание задачи.
PD>Если нет — начиная с которого можно было бы ?
Это как раз вопрос к специалистам. Ещё раз: бизнес ставит задачу. Инженер её решает — в том числе и выбирая технические средства.

Здравствуйте, Sinclair, Вы писали:

S>Вполне может быть, что можно было бы, только потребовалась бы серверная ферма и аккуратное распараллеливание задачи.
PD>>Если нет — начиная с которого можно было бы ?
S>Это как раз вопрос к специалистам. Ещё раз: бизнес ставит задачу. Инженер её решает — в том числе и выбирая технические средства.

Я не случайно этот вопрос задал.

Ясно, что в MS-DOS она либо не могла быть вообще решена, либо пришлось бы писать какую-то собственную настройку распараллеливания.

А в какой-то момент она смогла быть решенной. Не в NT4 Server, так в 2008 Server или раньше, это и впрямь неважно.

И только тогда бизнес смог бы поставить эту задачу.

Так что вчера было еще нельзя, а сегодня стало можно.

Вопрос — как бизнес узнал, что уже можно и, главное, как определил цену ?

Задача тут могла быть любая. Например, серьезную обработку картинки вряд ли можно было делать в CP/M на 64 Кбайтах, а в MS-DOS уже можно.

Или другой пример, не из программирования. Деревянные и каменные мосты умели делать в глубокой древности, и не бизнес. А вот металлические мосты появились в конце 18 века. Как бизнес определил стоимость постройки. Инженеров спрашивать нельзя о стоимости. по твоим правилам — они должны потом выбрать технические средства.

Здравствуйте, Shmj, Вы писали:

S>А вот разница между компом 2014 и 2024 — уже почти нет ее. Ну может в 2 раза только — раньше ставили от 4 Гб ОЗУ, теперь от 8 Гб на минималке. Т.е. уже даже не в 5 раз. Ну разве что SSD подешевели.
...
S>А что сильно отличается?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я не случайно этот вопрос задал.
PD>Ясно, что в MS-DOS она либо не могла быть вообще решена, либо пришлось бы писать какую-то собственную настройку распараллеливания.
Эмм, распараллеливание в MS-DOS — это какой-то оксюморон. Эта ОС принципиально не умеет работать на многоядерном ЦПУ; а на одном ядре параллелить CPU-bound задачи — бессмыслица.
Верх параллельности под MS-DOS — это какой-нибудь fastback, который параллелил IO с компрессией.
PD>А в какой-то момент она смогла быть решенной. Не в NT4 Server, так в 2008 Server или раньше, это и впрямь неважно.
Брр. Какие-то непонятные прыжки от MS DOS к NT4, и потом — к 2008 Server.
С точки зрения задачи "распознавание цифирь на фото" NT4 от 2008 Server или там 10 Server ничем не отличаются.
Скорее можно говорить о том, какое железо для этого потребно, и от него уже плясать в выборе операционки.
PD>И только тогда бизнес смог бы поставить эту задачу.
Когда "тогда"? Задача была в некотором смысле всегда. Просто её решение было до какого-то момента недоступно

PD>Вопрос — как бизнес узнал, что уже можно и, главное, как определил цену ?
Очень просто он определил цену. Вот смотри: у нас есть, скажем, работающая (с 1990го года) система допуска народа на парковку. Система называется "сторож с кнопкой и списком номеров".
У этой системы есть эксплуатационная себестоимость — зарплаты четырёх сторожей, плюс налоги, плюс сборы, плюс отопление будки в зимний период. X рублей в год.
Бизнес говорит "а давайте тётеньку вытащим, автомат засунем". Сколько будет стоить эксплуатация распознавалки, которая будет эмулировать нажатие на кнопку? Допустим, некоторый Y рублей в год. Пока, ессессно, неизвестный — мы ж ещё даже не знаем, что там будет за железка, сколько их, и т.п. Когда инженер станет предлагать железку, мы сможем посчитать стоимость для неё электроэнергии, кондиционирования, обслуживания специалистом, и амортизацию. Но пока пишем в блокнотик просто Y.
Теперь — для запуска этой системы нам нужно потратить Z, который складывается из
— стоимости железок (камер, проводов, столбов, серверов) Z0
— стоимости разработки программы Z1
— стоимости инженерных работ по прокладке проводов, привинчивания камер, вкапывания столбов Z2.

Из общих соображений бизнес хочет, чтобы это новшество окупилось за время T.
Отсюда сразу имеем неравенство: 0 < Z/(X-Y) <= (T-T0), где T0 — это срок реализации проекта. Из которого следует, что Z <= (T-T0) * (X-Y).
В частности, Z0+Z1 <= (T-T0) * (X-Y) — Z2.
Даём задачу инженерам — они предлагают варианты. Если ни один из вариантов по Z0, Z1, T0, и Y не укладывается в неравенство — значит, проект не имеет экономического смысла, и мы его закрываем. Довольные тем, как быстро мы убедились в его нереализуемости.
Если есть разные варианты — смотрим, какой из них окупается быстрее, и выбираем его.
Это — уровень детского сада; реальные бизнес-уравнения несколько сложнее (иначе бы все программисты были бы уже мега-магнатами). В частности, нужно учитывать внутренние и внешние риски. Но пока достаточно и такого приближения.

PD>Задача тут могла быть любая. Например, серьезную обработку картинки вряд ли можно было делать в CP/M на 64 Кбайтах, а в MS-DOS уже можно.
Смотря какой картинки, и какую обработку. Распознавалки цифр на конвертах внедрили, емнип, в 1960х. Специализированную распознавалку регистрационных номеров, рассчитанную на невраждебных пользователей, можно построить с минимумом памяти и вычислительной мощности. Применяемые сейчас были разработаны для ГИБДД, где нужно работать с враждебно настроенным "пользователем" и минимизировать ошибки.

PD>Или другой пример, не из программирования. Деревянные и каменные мосты умели делать в глубокой древности, и не бизнес. А вот металлические мосты появились в конце 18 века. Как бизнес определил стоимость постройки.
Точно так же. Это же азы проектного планирования.
PD>Инженеров спрашивать нельзя о стоимости. по твоим правилам — они должны потом выбрать технические средства
Инженеров можно и нужно спрашивать о стоимости. Делаем именно так — спрашиваем "сколько будет стоить металлический мост". И пока такой мост обходился дороже каменного, никому и в голову не приходило строить металлические мосты. Или даже так — говорим "нужен мост, который бы соединял берега в таком-то месте, на шесть полос в каждую сторону". И инженеры соревнуются, предлагая свои проекты. Кто-то — каменные, кто-то — металлические, кто-то — железобетонные. У всех у них разные Y, Z, и T0. Бизнес смотрит на них и выбирает устраивающий его вариант.

Здравствуйте, Sinclair, Вы писали:

Все опущу, так как главное вот здесь


>Теперь — для запуска этой системы нам нужно потратить Z, который складывается из
> стоимости железок (камер, проводов, столбов, серверов) Z0
> стоимости разработки программы Z1
> стоимости инженерных работ по прокладке проводов, привинчивания камер, вкапывания столбов Z2.

PD>>Инженеров спрашивать нельзя о стоимости. по твоим правилам — они должны потом выбрать технические средства


О стоимости их спрашивать придется, а именно про твои Zi, так как только они могут сказать, во что примерно это может обойтись. Они , и только они знают, какова cтоимость всех этих Zi. Без этого ты вообще не можешь сказать, реализуем ли проект.

Что, если заказчик поставит в проекте требование решить мимоходом задачу NP-полную ? Приближенные решения не годятся, допустим. Но только инженер сможет сказать, при каких условиях ее все же можно решать полным перебором, а при каких задача неразрешима при текущем уровне железа. Да даже и не NP-полная — пусть там совсем не бог весть что по требованиям, но для Z1 надо потратить столько, что денег у заказчика не хватит.

S>Инженеров можно и нужно спрашивать о стоимости. Делаем именно так — спрашиваем "сколько будет стоить металлический мост". И пока такой мост обходился дороже каменного, никому и в голову не приходило строить металлические мосты. Или даже так — говорим "нужен мост, который бы соединял берега в таком-то месте, на шесть полос в каждую сторону". И инженеры соревнуются, предлагая свои проекты. Кто-то — каменные, кто-то — металлические, кто-то — железобетонные. У всех у них разные Y, Z, и T0. Бизнес смотрит на них и выбирает устраивающий его вариант.

Вопрос был слегка провокационный.

Для финансирования строительства были выпущены акции, но их не хватило, и Дарби согласился частично финансировать недостающее (в целом на 3200 фунтов стерлингов). По предварительным расчётам, для строительства требовались 300 тонн чугуна (стоимостью 7 фунтов за тонну), однако фактически было потрачено 379 тонн. Учитывая дополнительные расходы (монтаж, опоры и т. д.), проект оказался гораздо дороже, чем изначально предполагалось, и Дарби понёс большие убытки, оставшись в долгах до конца жизни.

https://ru.wikipedia.org/wiki/%D0%A7%D1%83%D0%B3%D1%83%D0%BD%D0%BD%D1%8B%D0%B9_%D0%BC%D0%BE%D1%81%D1%82_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_%D0%A1%D0%B5%D0%B2%D0%B5%D1%80%D0%BD#:~:text=%C2%AB%D0%A7%D1%83%D0%B3%D1%83%D0%BD%D0%BD%D1%8B%D0%B9%20%D0%BC%D0%BE%D1%81%D1%82%C2%BB%20(%D0%B0%D0%BD%D0%B3%D0%BB.,%D0%AE%D0%9D%D0%95%D0%A1%D0%9A%D0%9E%20%D0%BA%D0%B0%D0%BA%20%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D0%BD%D0%B8%D0%BA%20%D0%92%D1%81%D0%B5%D0%BC%D0%B8%D1%80%D0%BD%D0%BE%D0%B3%D0%BE%20%D0%BD%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%B8%D1%8F.

Может, конечно, инженеры были плохие, но выделенное мной говорит о том, что их сначала спрашивали, а потом уж оценивали. И, как видишь, не совсем точно.

Здравствуйте, Shmj, Вы писали:

S>А что сильно отличается?

в телефонах 14 и современных — камера отличается. в современном обыватель уже не отличает снимки от зеркалки, а камеры 14 года — это мыльное шумное говно.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>О стоимости их спрашивать придется, а именно про твои Zi, так как только они могут сказать, во что примерно это может обойтись.
Налицо какая-то путаница. Про "нельзя спрашивать о стоимости" я не писал — это ваша фантазия.
Я писал "Инженеров можно и нужно спрашивать о стоимости".

PD>Они , и только они знают, какова cтоимость всех этих Zi. Без этого ты вообще не можешь сказать, реализуем ли проект.
Я вроде бы написал прямо пошаговую инструкцию проверки реализуемости проекта. Что именно непонятно? Как это так получилось, что бизнес заранее знает верхний предел на Z?

S>>Инженеров можно и нужно спрашивать о стоимости. Делаем именно так — спрашиваем "сколько будет стоить металлический мост". И пока такой мост обходился дороже каменного, никому и в голову не приходило строить металлические мосты. Или даже так — говорим "нужен мост, который бы соединял берега в таком-то месте, на шесть полос в каждую сторону". И инженеры соревнуются, предлагая свои проекты. Кто-то — каменные, кто-то — металлические, кто-то — железобетонные. У всех у них разные Y, Z, и T0. Бизнес смотрит на них и выбирает устраивающий его вариант.
PD>Вопрос был слегка провокационный.
Да не вижу тут никакой провокационности. Вижу какое-то непонимание базовых принципов бизнес-планирования

PD>

PD>Для финансирования строительства были выпущены акции, но их не хватило, и Дарби согласился частично финансировать недостающее (в целом на 3200 фунтов стерлингов). По предварительным расчётам, для строительства требовались 300 тонн чугуна (стоимостью 7 фунтов за тонну), однако фактически было потрачено 379 тонн. Учитывая дополнительные расходы (монтаж, опоры и т. д.), проект оказался гораздо дороже, чем изначально предполагалось, и Дарби понёс большие убытки, оставшись в долгах до конца жизни.

PD>https://ru.wikipedia.org/wiki/%D0%A7%D1%83%D0%B3%D1%83%D0%BD%D0%BD%D1%8B%D0%B9_%D0%BC%D0%BE%D1%81%D1%82_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_%D0%A1%D0%B5%D0%B2%D0%B5%D1%80%D0%BD#:~:text=%C2%AB%D0%A7%D1%83%D0%B3%D1%83%D0%BD%D0%BD%D1%8B%D0%B9%20%D0%BC%D0%BE%D1%81%D1%82%C2%BB%20(%D0%B0%D0%BD%D0%B3%D0%BB.,%D0%AE%D0%9D%D0%95%D0%A1%D0%9A%D0%9E%20%D0%BA%D0%B0%D0%BA%20%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D0%BD%D0%B8%D0%BA%20%D0%92%D1%81%D0%B5%D0%BC%D0%B8%D1%80%0%BD%D0%BE%D0%B3%D0%BE%20%D0%BD%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%B8%D1%8F.

PD>Может, конечно, инженеры были плохие, но выделенное мной говорит о том, что их сначала спрашивали, а потом уж оценивали. И, как видишь, не совсем точно.
Не, это не инженеры плохие, это переводчики. В англоязычных источниках про "оставшись в долгах до конца жизни" нету. Зато

Darby had agreed to construct the bridge with a budget of £3,250 (equivalent to £426,353 in 2023)[iv] and this was raised by subscribers to the project, mostly from Broseley. While the actual cost of the bridge is unknown, contemporary records suggest it was as high as £6,000 (£787,113 in 2023)[iv], and Darby, who was already indebted from other ventures, agreed to cover the excess.[36] However, by the mid-1790s the bridge was highly profitable, and tolls were giving the shareholders an annual dividend of 8 per cent.[37]

То есть перед тем, как принять решение по проекту, было проведено ТЭО, учитывавшее популярность маршрута и ожидаемую таксу за проезд по мосту.
И в итоге бизнес-таки выиграл, несмотря на то, что инженеры лажанулись с оценкой затрат. Просто окупаемость оказалась подлиннее.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>О стоимости их спрашивать придется, а именно про твои Zi, так как только они могут сказать, во что примерно это может обойтись.
S>Налицо какая-то путаница. Про "нельзя спрашивать о стоимости" я не писал — это ваша фантазия.
S>Я писал "Инженеров можно и нужно спрашивать о стоимости".

Хорошо. Итак, на том, что инженеры должны ответить на вопрос, сколько это будет примерно стоить, мы согласны.
Тогда вопрос, к которому я и вел : каким образом инженеры будут оценивать эту стоимость ?

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

Что, если заказчик поставит в проекте требование решить мимоходом задачу NP-полную ? Приближенные решения не годятся, допустим. Но только инженер сможет сказать, при каких условиях ее все же можно решать полным перебором, а при каких задача неразрешима при текущем уровне железа. Да даже и не NP-полная — пусть там совсем не бог весть что по требованиям, но для Z1 надо потратить столько, что денег у заказчика не хватит.

Впрочем, все может быть даже проще. Ты хочешь распознавалку. Отлично. А откуда бизнес знает, можно ли ее вообще реализовать ? Если, вернемся к прежнему, у нас времена MS-DOS или NT4. Бизнес знает, что компьютеры есть, видеокамеры тоже, вообще-то распознавалки сделать можно. Но тебе надо же в риэлтайме, да еще и сколько-то в минуту. Это технически вообще возможно ? Откуда бизнесу это знать ?
А если можно все же, то каковы требования к ресурсам ? Во времена NT4 было одно, сейчас несколько иное. А от этого Zi зависят.

PD>>Они , и только они знают, какова cтоимость всех этих Zi. Без этого ты вообще не можешь сказать, реализуем ли проект.
S>Я вроде бы написал прямо пошаговую инструкцию проверки реализуемости проекта. Что именно непонятно? Как это так получилось, что бизнес заранее знает верхний предел на Z?

Цитирую

>Но пока пишем в блокнотик просто Y.

Y — прямо зависит от Z, только с учетом времени на окупаемость, так как X — текущие расходы, это константа, уже данная, а T устанавливает заказчик, по твоему механизму.

S>Да не вижу тут никакой провокационности. Вижу какое-то непонимание базовых принципов бизнес-планирования

Да не в принципах бизнес-планирования дело. Бизнес может, конечно, на основе этих принципов определить желаемую цену проекта. А вот насколько это реальная цена с точки зрения разработчиков ?

Кстати, зря ты так уверен, что, скажем, T — это константа планирования.

Бизнес хочет, чтобы это окупилось за T. Обсудили с инженерами, стоимость выходит в 2 раза больше, и за T не окупится. Но, возможно, окупится за 2T. Бизнес обдумывает ситуацию. Возможно, и согласится. Если T=1 год, как бизнес хотел бы, то, может, его и устроит 2 года.


PD>>Может, конечно, инженеры были плохие, но выделенное мной говорит о том, что их сначала спрашивали, а потом уж оценивали. И, как видишь, не совсем точно.
S>Не, это не инженеры плохие, это переводчики. В англоязычных источниках про "оставшись в долгах до конца жизни" нету. Зато

Скорее всего это вообще не перевод, а оригинальная статья. Например, вот такое

"В 1935 году мост закрыт для движения транспорта[4]."

в англоязычной версии отсутствует. Переводчик это никак добавить не мог.

S>И в итоге бизнес-таки выиграл, несмотря на то, что инженеры лажанулись с оценкой затрат. Просто окупаемость оказалась подлиннее.

Так все же не бизнес, а инженеры провели оценку затрат ?