2010-08-13 14 views
21

Sto cercando di spiegare il rapporto tra costi di sviluppo e costi di manutenzione per il nostro reparto vendite, e al momento ho la sensazione che spendiamo il 60% delle volte con la manutenzione.Costi di sviluppo e costi di manutenzione

Abbiamo alcune persone nel team che tende a vendere soluzioni personalizzate, che dobbiamo costruire, e se i venditori non capiscono il costo totale dello sviluppo, quindi non saranno in grado di vendere a prezzi realistici .

Un altro "problema" è che stiamo ampliando il nostro servizio e abbiamo bisogno di ridefinire parte dell'infrastruttura sottostante per ridurre il time-to-market e altri punti di misura.

Avete qualche suggerimento su cosa dovrei fare riferimento per costruire un argomento solido? E quali punti dovrei sollevare per dare loro una buona comprensione del problema?

Forse c'è qualche bel testo là fuori da qualche parte che posso indicare.

risposta

18

In "Fatti fondamentali spesso dimenticati sull'ingegneria del software" di Robert L. Glass, (un articolo nel software IEEE maggio/giugno 2001), parla della regola "60/60" del software, ovvero che la manutenzione normalmente consuma 40 all'80% (media del 60%) dei costi del software, e quindi tale miglioramento è responsabile di circa il 60% dei costi di manutenzione del software, mentre la correzione degli errori è di circa il 17%.

+0

grazie per il collegamento, farò qualche lettura. –

+0

Ho visto questo riferimento in un messaggio slideshare su microservices (http://www.slideshare.net/INPAY/the-why-what-and-how-of-microservices). Il fatto è che i costi sono aumentati o diminuiti di 16 anni in futuro? – Irwin

3

Prova a convincerli a pensare al software come a un'auto. Potrebbero essere necessarie solo un paio di settimane o un mese per costruirlo, ma mentre è in uso nelle settimane, nei mesi e negli anni successivi, è necessaria una manutenzione. Forse è solo la manutenzione di routine per mantenere le cose senza intoppi; ma potrebbe anche essere la manutenzione di emergenza quando fa qualcosa di inaspettato e ha bisogno di essere riparato.

Allo stesso modo, potrebbe essere tutto ok quando lo si ottiene per la prima volta, ma dopo un po 'di uso sarà necessario lucidare per renderlo come ci si aspettava che fosse tutto il tempo.

+1

L'utilizzo di un'analogia quotidiana è un ottimo modo per discutere di argomenti come questo. –

+3

Per essere onesto, non penso che sia una buona analogia. Il costo di manutenzione di un'auto è insignificante rispetto al prezzo di acquisto. Quindi, perché la manutenzione del tuo software è costata più della metà del budget totale di sviluppo? Questo è esattamente il tipo di ragionamento che a volte devi contrastare. –

+0

@BartGijssens, sono d'accordo. Il costo di mantenere un'auto è di preservare la sua funzionalità attuale. L'analogia di ciò nel software sarebbe un bug bug minuzioso per risolvere perdite di memoria, eseguire la pulizia dei dati, eliminare vecchi file di registro e così via. Il costo reale della "manutenzione" nel software è di solito riadattamento e miglioramento, o correzione di difetti concettuali fondamentali - e una volta che la macchina è in uso costante e si è accumulata, il costo è più analogo all'adattamento o alla sostituzione di un motore aeronautico. volo. – Steve

4

Studio del concetto di debito tecnico. Inoltre, cerca di uscire con gli addetti alle vendite. Le probabilità sono che non siano cattivi o non se ne preoccupino; sono stati esposti a cose diverse, hanno abilità e interessi diversi da te. Le abilità soft contano molto. Gli errori più grandi sarebbero far loro sapere che "non capiscono i computer". Il venditore di vendite più facile con cui abbia mai lavorato era l'ex QA, quindi ha avuto un sacco di roba. A proposito, il lavoro delle persone di vendita è piegare la verità e mantenere quei dollari in arrivo. È un delicato equilibrio tra non incorrere in un eccessivo debito tecnico e non mancare di opportunità di business.

+0

Grazie, leggerò un po 'il debito tecnico. –

8

Dopo 29 anni nel settore, posso dire che la manutenzione è del 60-80% del costo totale. Lo sviluppo è al massimo del 20%. Ma la maggior parte delle aziende oggi non sembra riconoscere di aver messo maggiormente a fuoco lo sviluppo veloce e di fissare scadenze senza una stima adeguata. Ciò costringe gli sviluppatori a scaricare e andare, il che rende solo più difficile la manutenzione. Quindi cosa fanno gli exec come risultato? Buttano via tutto il software interno e acquistano cose di terze parti. Poi succede l'incubo dell'integrazione del sistema e forse 4 o 5 anni dopo si troveranno a far funzionare tutto, ma il costo per farlo è esponenzialmente più alto che passare il tempo in anticipo e farlo bene la prima volta. Nel frattempo tutti i veterani di vecchia data lasciano cadere il cappello e una nuova razza di giovani dollari vola con l'atteggiamento di "possiamo aggiustare qualsiasi cosa". E quello, il mio amico è quello che faranno da molto tempo.

Ecco perché Agile alla fine mi ha conquistato perché Cascata non funziona nel software. Mai e mai. Si tratta di piccole iterazioni di lavoro e sviluppo di parti. Proprio come Henry Ford ci ha mostrato nel 1900 ...

+0

Il punto è, quando hai progettato un motore di un'auto in modo incrementale? Nell'arena meccanica, non progettano realmente le parti principali dell'auto (o le loro relazioni) da zero con metodi agili - hanno semplicemente stabilito schemi di progettazione (che sono emersi da oltre un secolo di utilizzo dei motori a combustione), che hanno potrebbe perfezionare l'uso di principi agili, ma non ridefinire radicalmente. Nel software, la ridefinizione fondamentale è comune, motivo per cui i più grandi progetti IT (che sono spesso progettati per integrare soluzioni pezzo-pasto più piccole ma funzionali) sono inclini al fallimento. – Steve

1

Quello che ho sperimentato è che il 35% del costo di sviluppo verrà speso durante il primo anno di manutenzione, il 30% nel secondo anno, il 25% nel 3 ° anno. Quindi, se spendo $ 1 MM per lo sviluppo, spenderei 350K durante il primo anno e così via. Dopo 3 anni, il costo aumenta ancora del 5-10% ogni anno. Quindi, la reingegnerizzazione totale dell'applicazione può essere richiesta dopo 5 o 6 anni.

Problemi correlati