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

Здесь как раз и встает вопрос о целесообразности выпуска новой версии.
Если 1 клиент из 1000 обнаружил критический для него баг - проще вернуть ему деньги за программу (это может и не афишироваться), чем выпускать новую версию.

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

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

>Но для упрощения я считал стомость пофикса против недополученной прибыли.

Тогда я согласен с формулой, но с ограничением (!) - если речь идет о шароварных продуктах, причем с допущениями:
1) нет ограничения на функциональность (иначе с работой “запрещенных” функций клиент впервые столкнется уже после покупки проги)
2) в период ограничения по времени (когда клиент пользуется еще бесплатной версией) вероятность обнаружения клиентом бага приблизится к вероятности его обнаружения при дальнейшем использовании программы.
Т.е. проще говоря, в evaluate периоде он может проверить пару функций - и купить. А после покупки начнет пользоваться и доп. функциями, содержащими баги. Либо запустить те же функции при других условиях, в которых они сбоят.

Если же это изначально платный продукт - то клиент сначала купит его, а потом уже обнаружит баг, а тогда вопрос решать уже придется по “моей” формуле, что гораздо более затратно:)

Кстати, отсюда можно сделать вывод - в случае неуверенности в качестве разработанного продукта - делайте его shareware.

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

Для ПО, скорее баг может быть известен заранее и нужно решать, фиксить его или так выпустить. Отзыва программ вообще насколько я слышал не существует. Просто фиксят и дают новую версию.

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

Но для упрощения я считал стомость пофикса против недополученной прибыли.

Вы почему-то умножаете 1% еще на 1%, т.е. из 100 заметивших баг лишь 1 откажется от ее покупки??? Это неверно.

Давайте на примере эпиграфа: 1 000 выпущенных машин * 1% машин с неисправностью * $1000 стоимость урегулирования вопроса без суда = $10К

Теперь на ПО: 1 000 выпущенных копий продукта (по $1000 - чтоб была стоимость 1М как у Вас) * 1% вероятности обнаружения конкретного бага * $100 стоимость урегулирования вопроса (более-менее адекватно, хотя можно брать и $1000 в случае возврата денег) = $1000

Т.е. получается 1к$ при самом оптимистичном прогнозе ( стоимость урегулирования - 10% от стоимости программы), либо 10к$ при возврате денег за программу.

Сорри, если офф-топ - вспомнилось что-то…

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

Если находятся новые мелкие баги в том, что уже тестировалось, скорее это говорит о том, что тестирование ведется правильно - в несколько проходов
а) Сначала самые важные баги
б) Потом мельче
и т.п.

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