Стоимость разработки против стоимости обслуживания - PullRequest
33 голосов
/ 13 августа 2010

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

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

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

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

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

Ответы [ 5 ]

29 голосов
/ 13 августа 2010

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

14 голосов
/ 08 октября 2014

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

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

6 голосов
/ 13 августа 2010

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

3 голосов
/ 13 августа 2010

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

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

1 голос
/ 17 февраля 2015

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

...