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

C>На какие вопросы?

Практически на все.

C>Про инженеров я ответил.

Нет. Из ваших слов даже не понятно, это разработчики программного обеспечения вообще (т.е. software engineers) или же железячники, которым нужно еще и что-то запрограммировать.

S>>Предварительная трудоемкость работ оговаривается с заказчиком. Дальше как пойдет, см. выше про победивший agile.
C>Вот именно это и интересно — как она оговаривается?

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

S>>Да, в договоре описывается срок гарантийных обязательств. Обычно пропорционально сроку самого договора. Например, если договор на 2 месяца, то гарантия -- месяц.
C>Вы продаёте код, который через месяц может протухнуть?

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

C>Или я что-то неправильно понял?

Больше похоже, что не дали себе труда понять.

C>Что вам мешает давать гарантию в 10 лет?

Тот простой факт, что программ без ошибок не бывает.

И опыт.

У нас был случай, когда у заказчика вообще не было QA, ни в каком виде. То, что мы им отдавали, сразу шло в прод и проверялось на клиентах. А в силу специфики особенностей задачи у нас не было возможности собрать тестовый стенд, хотя бы отдаленно напоминающий реальную нагрузку.

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

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

S>>А вот это вот одна из фундаментальных проблем разработки, но, если вы этого не поняли, то от ЯП она вообще не зависит.
C>Нет, это одна из фундаментальных проблем некоторых компаний, которые любят за чужой счёт заниматься творчеством.

Да? Ну ладно, в вашей вселенной всякое может быть.

C>RnD у нас это выяснение проблем заказчика и первичное проектирование решений.

Простите, ничего не понял. Раньше на русском это называлось "обследованием объекта заказчика". К собственно к "поиску и реализации" это имеет крайне опосредованное отношение.

C>Painters and plumbers Всё верно насчёт сантехников, только так получается на практике, что если они не могут для конкретной задачи ответить на вопрос о стоимости, то идут лесом.

Хватит вносить отсебятину. Вы берете предварительный набросок здания и список хотелок (например, одновременно в бизнес-центре могут находится до 1500 человек, в пике до 4500, а еще нам нужны санузлы для инвалидов-колясочников на каждом этаже (в количестве двух штук) и было бы неплохо иметь отдельные санузлы для представителей первых 15 гендеров из очередного радужного списка), прикидываете сколько и каких санузлов нужно на каждом, их пропускную способность, длину и объем коммуникаций, примерное расположение здания, возможные варианты интеграции с городскими коммуникациями и т.д., и т.п. Берете какое-то типовое оборудование (обычно то, с которым привыкли работать), стоимость каких-то типовых расходных материалов (обычно от поставщиков с которыми долго работаете), прикидываете количество людей и как-то учитываете сроки, в которые заказчик хочет уложиться, суммируете это все, домножаете на выработанный годами поправочный коэффициент и озвучиваете некоторое значение (или обозначаете вилку вокруг оного).

А дальше начинается реальная жизнь, в который выясняется, что количество и расположение санузлов изменилось, на каких-то этажах теперь размещается VIP-зона, поэтому там стоимость узлов и материалов умножается на 5, где-то в санузлы захотелось добавить еще и душевые кабины, а где-то изменилась планировка этажей и расположение труб поменялось. И т.д., и т.п.

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

C>А как их выбрать, если это уже моя задача предоставить заказчику среди прочего и расчёт окупаемости?

А я вот не знаю, какие расходы по окупаемости можно предоставить заказчику, который приходит к нам с проблемой вроде "мы импортозамещаем AWS S3, сделали обслуживание входящих запросов на X, уперлись в проблемы, их нужно разрешить". В процессе разбирательств приходим к заключению, что решается это заменой X на Y и обойдется это в ~N денег +- лапоть. При этом само обслуживание этих самых входящих запросов составляет, условно, 5% от общего объема проекта, а то и меньше.

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

C>На какие вопросы?

Практически на все.

C>Про инженеров я ответил.

Нет. Из ваших слов даже не понятно, это разработчики программного обеспечения вообще (т.е. software engineers) или же железячники, которым нужно еще и что-то запрограммировать.

S>>Предварительная трудоемкость работ оговаривается с заказчиком. Дальше как пойдет, см. выше про победивший agile.
C>Вот именно это и интересно — как она оговаривается?

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

S>>Да, в договоре описывается срок гарантийных обязательств. Обычно пропорционально сроку самого договора. Например, если договор на 2 месяца, то гарантия -- месяц.
C>Вы продаёте код, который через месяц может протухнуть?

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

C>Или я что-то неправильно понял?

Больше похоже, что не дали себе труда понять.

C>Что вам мешает давать гарантию в 10 лет?

Тот простой факт, что программ без ошибок не бывает.

И опыт.

У нас был случай, когда у заказчика вообще не было QA, ни в каком виде. То, что мы им отдавали, сразу шло в прод и проверялось на клиентах. А в силу специфики особенностей задачи у нас не было возможности собрать тестовый стенд, хотя бы отдаленно напоминающий реальную нагрузку.

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

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

S>>А вот это вот одна из фундаментальных проблем разработки, но, если вы этого не поняли, то от ЯП она вообще не зависит.
C>Нет, это одна из фундаментальных проблем некоторых компаний, которые любят за чужой счёт заниматься творчеством.

Да? Ну ладно, в вашей вселенной всякое может быть.

C>RnD у нас это выяснение проблем заказчика и первичное проектирование решений.

Простите, ничего не понял. Раньше на русском это называлось "обследованием объекта заказчика". К собственно к "исследованиям и реализации" это имеет крайне опосредованное отношение.

C>Painters and plumbers Всё верно насчёт сантехников, только так получается на практике, что если они не могут для конкретной задачи ответить на вопрос о стоимости, то идут лесом.

Хватит вносить отсебятину. Вы берете предварительный набросок здания и список хотелок (например, одновременно в бизнес-центре могут находится до 1500 человек, в пике до 4500, а еще нам нужны санузлы для инвалидов-колясочников на каждом этаже (в количестве двух штук) и было бы неплохо иметь отдельные санузлы для представителей первых 15 гендеров из очередного радужного списка), прикидываете сколько и каких санузлов нужно на каждом, их пропускную способность, длину и объем коммуникаций, примерное расположение здания, возможные варианты интеграции с городскими коммуникациями и т.д., и т.п. Берете какое-то типовое оборудование (обычно то, с которым привыкли работать), стоимость каких-то типовых расходных материалов (обычно от поставщиков с которыми долго работаете), прикидываете количество людей и как-то учитываете сроки, в которые заказчик хочет уложиться, суммируете это все, домножаете на выработанный годами поправочный коэффициент и озвучиваете некоторое значение (или обозначаете вилку вокруг оного).

А дальше начинается реальная жизнь, в который выясняется, что количество и расположение санузлов изменилось, на каких-то этажах теперь размещается VIP-зона, поэтому там стоимость узлов и материалов умножается на 5, где-то в санузлы захотелось добавить еще и душевые кабины, а где-то изменилась планировка этажей и расположение труб поменялось. И т.д., и т.п.

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

C>А как их выбрать, если это уже моя задача предоставить заказчику среди прочего и расчёт окупаемости?

А я вот не знаю, какие расходы по окупаемости можно предоставить заказчику, который приходит к нам с проблемой вроде "мы импортозамещаем AWS S3, сделали обслуживание входящих запросов на X, уперлись в проблемы, их нужно разрешить". В процессе разбирательств приходим к заключению, что решается это заменой X на Y и обойдется это в ~N денег +- лапоть. При этом само обслуживание этих самых входящих запросов составляет, условно, 5% от общего объема проекта, а то и меньше.