Стоимость разработки и эксплуатационные расходы

Я пытаюсь объяснить соотношение затрат на развитие и обслуживание для нашего отдела продаж, и в настоящее время у меня в основном возникает ощущение, что мы тратим около 60% времени на обслуживание.

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

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

Есть ли у вас какие-либо хорошие предложения относительно того, на что я должен ссылаться, чтобы построить твердый аргумент? И какие моменты я должен воспитывать, чтобы дать им хорошее понимание проблемы?

Может быть, есть какой-то отличный текст там, где я могу указать.

Ответ 1

В "Часто забытых фундаментальных фактах о разработке программного обеспечения" Роберта Л. Стекля (статья в IEEE Software May/June 2001), он говорит о правиле программного обеспечения "60/60", то есть техническое обслуживание обычно потребляет 40 80% (60% в среднем) затрат на программное обеспечение, а затем это повышение отвечает примерно за 60% затрат на обслуживание программного обеспечения, в то время как исправление ошибок составляет около 17%.

Ответ 2

Через 29 лет в отрасли я могу сказать, что обслуживание составляет 60-80% от общей стоимости. Развитие составляет не более 20%. Но большинство компаний сегодня, похоже, не признают, что они уделяют самое пристальное внимание быстрому развитию и назначают сроки без надлежащей оценки. Это заставляет разработчиков сбрасывать и уходить, что только усложняет обслуживание. Итак, что делают execs в результате? Они выбрасывают все собственное программное обеспечение и покупают сторонние вещи. Затем происходит кошмар системной интеграции, и, возможно, через 4 или 5 лет они будут иметь вид, вроде бы заставить все это работать, но затраты на это экспоненциально выше, чем тратить время и делать это в первый раз. Тем временем все закаленные старые таймеры повесили шляпы, и новая порода молодых долларов полетела с отношением "мы можем исправить что угодно". И это, мой друг, это то, что они будут делать в течение долгого времени.

Вот почему Agile в конечном итоге выиграл меня, потому что водопад просто не работает в программном обеспечении. Никогда не было и никогда не будет. Все дело в небольших рабочих итерациях и разработке деталей. Так же, как Генри Форд показал нам в 1900 году...

Ответ 3

Изучить концепцию технического долга. Кроме того, попробуйте пообщаться с работниками отдела продаж. Скорее всего, они не злы или не заботятся; они просто подвергаются различным вещам, имеют разные навыки и интересы, чем вы. Мягкие навыки имеют большое значение. Самые большие ошибки позволят им узнать, что "они не понимают компьютеры". Самый простой парень по продажам, с которым я когда-либо работал, был ex-QA, поэтому он получил много всего. Кстати, работа продавцов заключается в том, чтобы свести правду и сохранить эти доллары. Это тонкий баланс между несоблюдением слишком большого технического долга и отсутствием деловых возможностей.

Ответ 4

Попробуйте заставить их думать о программном обеспечении как о машине. Для его создания может потребоваться всего несколько недель или месяц, но пока он используется в течение следующих недель, месяцев и лет, потребуется техническое обслуживание. Возможно, это просто рутинное обслуживание для бесперебойной работы; но это может быть также аварийное обслуживание, когда оно делает что-то неожиданное и нуждается в фиксации.

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

Ответ 5

То, что я испытал, составляет около 35% стоимости разработки, будет потрачено на первый год обслуживания, 30% - на второй год, 25% - на 3-й год. Итак, если я потрачу 1 миллион долларов на разработку, я бы потратил 350 тысяч в течение первого года и так далее. Через 3 года стоимость снова увеличивается на 5-10% каждый год. Следовательно, полная реинжиниринг заявки может потребоваться через 5 или 6 лет.