Берем количество выпущенных машин — А,
умножаем на вероятную долю машин с неисправностями — B,
и умножаем произведение на стоимость урегулирования вопроса без суда — С.
A на B на C равно X
Если X меньше затрат на доработку, возврата не будет.
И часто случаются такие аварии?
Вы и представить не можете.
Бойцовский Клуб
Если говорить честно, то этого эпиграфа достаточно, чтобы выразить всю мысль моей статьи. Но, таки погружусь в детали.
Фактически все, раз в некоторое время жалуются – почему <вставить название программы> работает так глючно. Вспомним, тот же Windows 95, благодаря которому Microsoft получила такую плохую репутацию.
А ведь, если вдуматься, то формула приведенная в эпиграфе верна. Если цена предполагаемо проданных программ (количество программ * цена программы) – A, вероятность того, что заказчик увидит баг – B и вероятность того, что заказчик не купит из-за бага программу, то A*B*C = X равно недополученной прибыли из-за бага. И соответственно, цена исправления бага Y. Как вы понимаете до тех пор пока X < Y, то никому не интересно будет исправлять этот баг.
Просто для того, чтобы показать порядок цифр. Предположим, что цена предполагаемо проданных программ $1M. Вероятность того, что заказчик увидит какой-то конкретный баг 1% и вероятность того, что заказчик не захочет покупать программу из-за этого бага 1%. Итого мы имеем 1M*0.01*0.01 = $100. Ну, что можно сказать… Сто баксов – это сто баксов. Есть баги, которые можно будет решить дешевле, есть которые дороже.
Несколько производных из этой формулы:
— если программа не будет курицей несущей золотые яйца, то размер багов, которые можно не исправлять будет больше. И наоборот, чем больше продажи, тем постепенно становится выгодно исправлять все меньшие баги.
— часто в компаниях оценивают только вероятность появления бага или только критичность бага для заказчика. Только вместе эти параметры имеют смысл.
Пару вещей, которые находятся вне формулы:
— часто во время исправление вносятся новые баги (и это тяжело внести в формулу)
— в программа есть эффект аккумуляции багов. Если багов очень много, то вероятность отказа каждого бага повышается и наоборот, если багов мало, то вероятность отказа от бага уменьшается.
— чем дольше исправляются баги, тем дольше время до выхода версии.
Так, что не спешите ругать чужие (или свои программы) за баги, просто подумайте, выгодно было ли дальше исправлять программу или нет.
Эффект аккумуляции играет очень большую роль. Если продукт не состоит из независимых частей, то старые баги будут приводить к новым. Процесс станет лавинообразным.
В XP есть принцип zerobugrows, который говорит, что новый функционал должен писаться только после закрытия всех багов.
Я думаю, ответ какие баги исправлять лежит где-то посередине между денежной формулой и zerobugrows.
Проблема в том, что новые баги выявляются довольно часто тогда когда всё вроде бы протестировали и всё работало.
Это говорит только о плохом качестве тестирования
И солидарен и нет.
Если находятся новые серьезные баги в том, что протестировано — это плохое качество тестирования.
Если находятся новые мелкие баги в том, что уже тестировалось, скорее это говорит о том, что тестирование ведется правильно — в несколько проходов
а) Сначала самые важные баги
б) Потом мельче
и т.п.
Да, я согласен. Эффект аккумуляции очень важен. Однако большинство програм лежат где-то посередине между лавинообразным накопление и полным отсутствием багов. В это промежутке описанная формула работает.
Насчет zerobugrows. Есть у меня такая присказка, что если в системе контроля версий 0 багов, значит тестеров можно уволить. В любой программе можно фактически до бесконечности находить баги, особенно если программа развивается. Я еще не видел проекта, в котором доходили до 0 багов. Разве что это возможно для какого-нибудь маленького модуля.
ага, в экономике цена чего-то определяется альтернативой:
— цена бага равна не цене пофикса ,а тем деньгам которые компания получила если бы бага не было.
— Простой пример дает анекдот о портном, который мечтал стать английским королем и при этом «был бы еще немножечко богаче, потому, что еще бы немножко шил». Однако поскольку быть королем и портным одновременно невозможно, то доходы от портновского бизнеса будут потеряны. Их то и следует считать стоимостью упущенной возможости при восшествии на трон. Если же остаться портным, то будут потеряны доходы от королевской должности, что и будет стоимостью упущенной возможности в этом случае.
Источник — http://ru.wikipedia.org/wiki/%D0%90%D0%BB%D1%8C%D1%82%D0%B5%D1%80%D0%BD%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B5_%D0%B8%D0%B7%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B8
Да, собственно это я и хотел сказать 🙂
Вот поэтому и получается что больше надо уделять внимание основному функционалу продукта, и тестировать при нормальных условиях стандартные действия, так как это место сосредоточения самых «дорогих» багов. А вот как раз в стресс тестирование и тд. надо особо не вкладываться, так как это может и не окупиться.
Теперь чтоб не выпадать из своего амплуа, немного расширю эту тему 🙂
Существует математический аппарат, который решает ту проблему, которую ты описал — нормальное распределение вероятностей. Думаю многие слышали о нем, только, к сожалению, мало кто понимает как можно это применять 🙂
На самом деле появление бага (дефекта) в том или ином месте продукта — есть случайная величина (если конечно кто-то злобно их не добавляет каждый день). Учитывая различные параметры в конкретном продукте можно построить распределение данной вероятности, из которого можно будет увидеть зависимость вероятности возникновения дефектов от вложенных ресурсов в оборудование, технологию, качество и тд. Так как зависимость эта не линейная, то всегда можно найти точку которая даст низкий уровень дефекта при не высоких затратах. Или же будет видно когда увеличение затрат уже особо не влияет на возникновение дефектов. Если хорошо оперировать данной вещью, то можно экономить большие деньги. Я честно не знаю, занимаются ли этим крупные IT фирмы(сходу ничего не смог найти в инете), но крупные промышленные предприятия на этом деле экономят колосальные деньги при выпуске деталей, изделий или готовых продуктов.
Да, кстати, хорошо, что ты вспомнил. Именно за это я и не люблю стресс тестирование. Для космических технологий стресс тестирование актуально — в случае даже мельчайших ошибок могут в прямом смысле сгореть сотни миллионов.
А в обычных программах, месяцы потраченные на стресс тестирование, в результате ведет к тому, что пару дополнительных клиентов покупает программу, что ни капельки не окупает потраченное время.
Насчет нормального распределения. Математический аппарат потрясающая вещь, когда можно собрать много числовых характеристик. Причем собрать достаточно легко.
Как ты точно заметил: «Учитывая различные параметры в конкретном продукте можно построить распределение данной вероятности, из которого можно будет увидеть зависимость вероятности возникновения дефектов от вложенных ресурсов в оборудование, технологию, качество и тд.»
Фактически самым эффективным и дорогим оборудованием в этом случае являются программисты и тестировщики. Увы, оборудование это жестоко нелинейное и не позволяет
простым методом снять замеры.
Я конечно уверен, что в некоторых крупных фирмах есть достаточно много метрик, чтобы оценивать эти вещи. Но, честно говоря не видел пока как оно работает вживую.
«Увы, оборудование это жестоко нелинейное и не позволяет простым методом снять замеры» Да создание программного продукта ни чем не отличается от создания автомобиля, та же сборка, модули, тестирование, регулировка и тд. Разница только заключается в затратах на модификацию и тиражирование 🙂
Понятно что от покупки новых компьютеров качество программного продукта не увеличиться, но есть чисто линейные затраты — вложение денег в: время тестирования, автоматизация разработки, управление и тд. Все эти вещи уменьшают вероятность возникновения багов в конечном продукте. Я еще раз замечу что я пока еще не нашел инфы по тому применяют ли мат аппарат в ведущих IT фирмах по этим направлениям, но даже если взять затраты на внедрение и сопровождение MSF или RUP (в контексте тестирования) — это есть в чистом виде инвестиции в качество продукта.
М… Проблема пожалуй, в том, что линейность затрат даст нелинейное изменение качества. Причем нелинейности будет две
а) Связанная с тем как раз, что мы хотим вычислить. Зависимость вложений и качества.
б) Связанная собственно с правильностью вложения денег. Можно нанять 100 тупых программистов и тестеров, может нанять 10 профессионалов. На входе одинаковая стоимость на выходе разные качество.
«Проблема пожалуй, в том, что линейность затрат даст нелинейное изменение качества» да это не «проблема» — это закон нормального распределения 🙂
Я ж про то и сказал с самого начала что как раз его нелинейность позволяет понимать когда ты либо можешь повысить качество, либо тратить уже деньги зря.
Я имел в виду, что с нелинейностью а) так можно поступить, потому как ее можно будет измерить и нарисовать график.
Нелинейность б) гораздо сложнее будет оценить в численных величинах, соответственно построить график не удастся, соответственно оценить будет сложно.
— А в какой компании Вы работаете?
— В крупной…
Сорри, если офф-топ — вспомнилось что-то…
;))
Не согласен с расчетами.
Вы почему-то умножаете 1% еще на 1%, т.е. из 100 заметивших баг лишь 1 откажется от ее покупки??? Это неверно.
Давайте на примере эпиграфа: 1 000 выпущенных машин * 1% машин с неисправностью * $1000 стоимость урегулирования вопроса без суда = $10К
Теперь на ПО: 1 000 выпущенных копий продукта (по $1000 — чтоб была стоимость 1М как у Вас) * 1% вероятности обнаружения конкретного бага * $100 стоимость урегулирования вопроса (более-менее адекватно, хотя можно брать и $1000 в случае возврата денег) = $1000
Т.е. получается 1к$ при самом оптимистичном прогнозе ( стоимость урегулирования — 10% от стоимости программы), либо 10к$ при возврате денег за программу.
В эпиграфе чуть другая ситуация рассматривается и поэтому чуть другие расчеты.
Они не могут исправить баг в выпущенном автомобиле, они могут только отозвать выпущенные автомобили. И достаточно редко в момент выпуска авто баг уже известен. Поэтому складывается ситуация урегулирование против отзыва.
Для ПО, скорее баг может быть известен заранее и нужно решать, фиксить его или так выпустить. Отзыва программ вообще насколько я слышал не существует. Просто фиксят и дают новую версию.
И зачастую вопросы не урегулируются деньгами по поводу багов. Хотя бесспорно, для более точных расчетов, нужно учитывать время потраченное менеджерами по продажам на обсуждение этого бага с теми заказчиками, которые его найдут.
Но для упрощения я считал стомость пофикса против недополученной прибыли.
>Отзыва программ вообще насколько я слышал не существует. Просто фиксят и дают новую версию.
Здесь как раз и встает вопрос о целесообразности выпуска новой версии.
Если 1 клиент из 1000 обнаружил критический для него баг — проще вернуть ему деньги за программу (это может и не афишироваться), чем выпускать новую версию.
>И зачастую вопросы не урегулируются деньгами по поводу багов.
Опять же, если это еденичный случай — то деньгами вопрос решаем. Если нет — клиент может и в сад пойти, причем безболезненно для разработчика.
Если же случай массовый тогда, действительно, может возникнуть ситуация, когда деньгами вопрос не решить.
>Но для упрощения я считал стомость пофикса против недополученной прибыли.
Тогда я согласен с формулой, но с ограничением (!) — если речь идет о шароварных продуктах, причем с допущениями:
1) нет ограничения на функциональность (иначе с работой «запрещенных» функций клиент впервые столкнется уже после покупки проги)
2) в период ограничения по времени (когда клиент пользуется еще бесплатной версией) вероятность обнаружения клиентом бага приблизится к вероятности его обнаружения при дальнейшем использовании программы.
Т.е. проще говоря, в evaluate периоде он может проверить пару функций — и купить. А после покупки начнет пользоваться и доп. функциями, содержащими баги. Либо запустить те же функции при других условиях, в которых они сбоят.
Если же это изначально платный продукт — то клиент сначала купит его, а потом уже обнаружит баг, а тогда вопрос решать уже придется по «моей» формуле, что гораздо более затратно:)
Кстати, отсюда можно сделать вывод — в случае неуверенности в качестве разработанного продукта — делайте его shareware.
Согласен, если углубиться в разнообразные формы ведения бизнеса, то форма может измениться и усложниться.
На самом деле, самое важное была идея поста, а расчеты все равно были всего лишь примером, так как они существенно упрощены относительно реальной ситуации.
Идея, безусловно, правильная 🙂