Come misurare il valore potenziale del refactoring

It will earn the company F million pounds, over t years at a cost of x dev-days work

Che sta ignorando i costi di manutenzione, i costi di supporto, il costo delle vendite / marketing e fa un sacco di ipotesi su come la funzione verrà presa nel marketplace.

Ma qualunque cosa; la tua domanda è abbastanza chiara su ciò che stai cercando:

How can I make a business case for refactoring?

La cosa principale da capire è che il tempo è uguale al denaro. Puoi andare direttamente a "5 sviluppatori 2 settimane = 80 ore * 5 sviluppatori * $ 50 / ora - > $ 20.000" e questo ha senso per gli uomini d'affari. Gli uomini d'affari intelligenti noteranno che quei 5 sviluppatori vengono pagati in entrambi i modi, con il quale si contrappone che non spende / risparmia i $ 20.000 - sta usando i $ 20.000 nel modo più redditizio. Comunque, avanti con la lista.

• Efficienza - Presumibilmente, puoi ottenere più materiale con C # rispetto a VB6. Strumenti migliori, librerie migliori, qualunque cosa. Le nuove tecnologie tendono ad essere migliori rispetto alle vecchie. Se riesci a fare cose in meno tempo, significa che stai risparmiando i soldi dell'azienda.
• Spese generali : la codifica non è l'unico costo del software. Considera cosa succede quando esce Windows 2020. Quanto tempo e impegno dedicherete a far funzionare l'app VB6? Quanto tempo e fatica sono più di un'app C #? Questo sta risparmiando i soldi della tua azienda.
• Qualità - Presumibilmente, puoi ottenere risultati di qualità superiore in C # rispetto a VB6 (o con un'architettura più pulita, o qualsiasi altra cosa sia il tuo obiettivo di refactoring). Qualità superiore significa meno bug. Meno bug significa meno costi per correggere questi bug, meno costi di supporto ai clienti per risolvere questi problemi, meno perdita dei clienti a causa di problemi di qualità, aumento delle vendite dovuto alla reputazione di qualità ... tutti i dollari per la tua azienda.
• Risparmio di risorse umane - Affrontiamo i fatti: nessuno vuole lavorare con quella app VB6 di merda. Ciò significa che più persone lasceranno la società portando a tempo e denaro spesi per sostituirli. Ciò significa che ci vuole più tempo e denaro per assumere nuovi dipendenti. Peggio ancora, significa che avrai sviluppatori che stanno completamente bene commettendo un suicidio di carriera lavorando con quell'app VB6. Questi sviluppatori a loro volta accelerano la spirale della morte di problemi di qualità. Ridurre i tempi di fatturazione e di assunzione risparmia i soldi della tua azienda. Mantenendo gli sviluppatori compiacenti e schifosi, salva la tua azienda.
• Morale - Allo stesso modo, i programmatori che già sono odiati lavorano in VB6. Lo faranno e potrebbero anche farlo bene. Ma fa schifo. Forse non per tutti, ma sicuramente per alcuni. Ciò significa più tempo trascorso a navigare sul Web per recuperare la motivazione. Significa pranzi più lunghi. Significa fare meno cose mentre i programmatori impiegano più tempo a riprendersi dal lavoro.
• Capacità - Questo è meno applicabile con i refattori basati sulla tecnologia, ma si applica ai tipi di refactoring dell'architettura. Alcuni problemi di codice ti impediscono attivamente di fornire funzionalità interessanti X per fare un sacco di soldi. Forse non puoi scalare. Forse non puoi prendere i dati per fare cose interessanti. Forse il codice è il nido di un topo che è proibitivamente difficile fare effettivamente il lavoro. Qualunque cosa. A volte sei a quel punto, a volte stai guidando dritto verso quel punto. È difficile tradurre in parole d'affari, ma se puoi "il problema ci impedisce di sfruttare le opportunità X, Y e Z" può essere potente.

Tutto sommato, si tratta di "questa roba ci aiuterà a fare meglio il nostro lavoro, se facciamo meglio i nostri lavori, possiamo fare / risparmiare più soldi".

La domanda che dovresti porci è come fa il venditore sapere che la funzione costerà x giorni di sviluppo del lavoro. Dato che persino i bravi project manager con anni di esperienza professionale non possono spesso dirlo, tali dati provenienti da un venditore sembrano estremamente ... speculativi .

Secondo la mia esperienza, i venditori di solito non fanno stime, ma indovina quanto è troppo per la gestione o il cliente: se la direzione è pronta a pagare 50 settimane uomo di lavoro, ma Rifiuteremo assolutamente 75 settimane uomo, diciamo che la funzione impiegherà 70 settimane uomo per essere pronta a rinegoziare (qualcosa che è fuori discussione per una stima reale) fino a 55 settimane uomo.

• Da un lato, ci sono stime fatte da esperti IT che dicono qualcosa del tipo:

  According to this specific audit, we are wasting $8 000 per day using an outdated technology compared to similar projects of similar size which use newer technologies. It also appears that it will take from 50 to 80 man-weeks to migrate the whole code base; during this time, there would be no new features released. There is also a 10% risk that migrating a specific component may result in 20-30 additional man-weeks of work.

• D'altra parte, hai indovina fatto dai venditori, in base alla loro influenza quando negoziano con la persona di cui hanno bisogno per convincere.

Tutto dipende da quanto sei influente nella tua azienda. La comunicazione è la chiave qui, ed è qui che i venditori di solito conquistano i professionisti IT quando si tratta di spiegare i vantaggi di una funzionalità alla gestione (o al cliente).

Nota che se in passato le tue stime erano abbastanza precise, guadagnavi reputazione e influenza. Se le tue stime fossero sempre sbagliate, la direzione probabilmente ignorerebbe le tue proposte.

Per quanto riguarda le stime, è estremamente difficile fare un valore qui, dato che c'è un numero enorme di parametri da tenere in considerazione. Tra gli altri:

• Sai davvero quanto è abile il tuo team in C # rispetto a VB6? Si basa su misurazioni reali o solo su ipotesi?

• Questo team ha sviluppato grandi progetti in C #? Conoscono gli strumenti che dovrebbero usare (IDE, debugger, profiler, ecc.)? Hai bisogno di licenze aggiuntive (che nel mondo di Microsoft significano migliaia di dollari per macchina)?

• Il progetto attuale è completamente chiaro e puoi garantire che non ci saranno sorprese durante la migrazione? È semplice riscrivere tutto , ogni funzione o ci sarebbero sorprese?

• Hai l'infrastruttura che supporta C #? Che dire dell'integrazione continua? E il tuo server di build? Guide di stile? Controllori statici?

• Nella produzione, i server (se questa è un'app Web) oi PC cliente (se si tratta di un'applicazione desktop) sono in grado di eseguire la versione di .NET Framework che si prevede di utilizzare?

Ma la cosa più importante è sapere perché vuoi riscrivere tutto. Quale è il problema che stai cercando di risolvere tramite una riscrittura? Una perdita di produttività? Come lo misurate? Come fai a mostrare questa perdita di produttività alla gestione?

Una volta che hai dimostrato che stai sprecando, diciamo, $ 8.000 al giorno a causa di VB6 (il che significa che risparmierai $ 8.000 al giorno una volta migrato a C #), come spieghi il vantaggio di tenere ogni nuovo caratteristiche di sviluppo e concentrandosi su una riscrittura completa? Qual è il vantaggio rispetto a riscrittura progressiva in cui migra i componenti in piccoli blocchi uno per uno, mentre vengono spedite nuove funzionalità?

In primo luogo, è necessario stimare il costo di sviluppo per il risanamento come si farebbe con la richiesta di funzionalità guidata dalle vendite.

Questo potrebbe essere difficile da ottenere accurato se si tratta di un lavoro di grandi dimensioni ma, assumendo che tu abbia abbastanza persone con esperienza nelle 2 tecnologie, dovrebbe essere fattibile.

In secondo luogo, è necessaria una stima del costo del non ri-factoring. Se tu stessi facendo le stime per me, mi aspetterei un certo livello di metrica. Ad esempio, la differenza tra il costo di sviluppo medio per codice VB e il codice C # su un quarto. O alcuni di questi. Dipenderà ovviamente dalla precisione con cui tieni traccia di questo.

Con questi 2 numeri, puoi stimare il periodo di ammortamento che il risanamento ti darà, cioè a che punto il ri-factoring passa da un costo netto a un guadagno netto.

Posso solo immaginare quanto sia persuasivo ogni dato risultato. Tuttavia, se è meno di un anno probabilmente sarà abbastanza strong, molto più di 2 anni, quindi potresti lottare.

Inoltre, probabilmente è utile aggiungere altre dimensioni per aiutarti a costruire il tuo caso. Uno che ho usato in passato è vedere se alcune interviste di uscita citavano la tecnologia come un driver. In tal caso, si può sostenere che il ri-factoring manterrà il personale (assunzione e formazione v costose).

Ovviamente, puoi discutere queste cose senza prove a sostegno, ma trovo che possa fare un'enorme differenza per l'impatto del caso.

Il valore del refactoring si presenta in molti modi diversi.

Ti aiuta a fare altre modifiche in seguito, quindi gli X giorni che la funzione avrebbe richiesto ora impiegheranno 2/3 giorni per essere completato. Per usare la terminologia agile aumenta la velocità.

Il cambiamento esplicito elencato avrebbe aiutato nel tempo poiché non avresti più bisogno di mantenere gli sviluppatori con esperienza VB6, solo quelli con esperienza C #.

Aiuta anche in altri modi meno tangibili come la conservazione del personale e il reclutamento. Un lavoro con C # e VB6 sarebbe più o meno attraente di un lavoro che fa solo C #? Saresti più o meno propenso a prendere un lavoro o stare a lavorare su una buona base di codice o su uno scadente?

Penso che il punto in cui le altre risposte mancano è che devi misurare il costo del refactoring rispetto alle entrate perse dal non refactoring.

Il refactoring per il cambio di codice è una perdita di tempo. Deve apportare valore al tavolo. In questo contesto non intendo passare un'ora a refactoring di una classe di problemi, ma il refactoring più importante come cambiare in un linguaggio CLR diverso come hai usato nel tuo esempio.

• Se continuiamo a fare quello che stiamo facendo, stiamo perdendo qualcosa? Esiste un vecchio design crudele che ci trattiene dal realizzare valore? Ad esempio, se vogliamo aggiungere una funzione è così difficile che potrebbe richiedere ad es. 100 ore di implementazione, 50 ore di refactoring e 25 ore di implementazione rispetto al nuovo design?

• Il codice esistente comporta un debito tecnico che ci costa denaro? Questo codice scadente è fonte di bug? Finiamo a lavorare gratuitamente per risolvere i problemi a causa di esso? A nessuno piace regalare lucrative ore fatturabili gratuitamente.

• Il costo del refactoring è uguale o inferiore al costo di non refactoring?

• E 'possibile ammortizzare il costo facendo in modo che un piccolo gruppo di rockstar rifatti il codice causando il maggior numero di problemi? Possiamo diffondere il refactore tra le pubblicazioni? Ci sono piccole inefficienze ovunque: possiamo "colmare le lacune" per parlare con questo lavoro extra?

Vantaggi di avere un sistema refactored

Esegui un business case per il refactoring confrontando i benefici di business bottom-line tra il fare e non farlo. Significa riduzione degli attuali costi reali o aumento del flusso di cassa reale futuro.

Le voci di budget chiave interessate dal refactoring sono le seguenti:

• Costi di manutenzione - se il sistema attuale è un fragile mucchio di spaghetti, e in pratica è osservabile che la risoluzione di piccoli bug (sia nello sviluppo che nelle operazioni) richiede una grande quantità di ore uomo, quindi ci si potrebbe aspettare che il i costi di tale manutenzione saranno inferiori per un sistema "adeguatamente riprogettato". Dai un'occhiata a quali sono i tuoi costi annuali di manutenzione pura e come potrebbero realisticamente cambiare dopo la riscrittura.

• Costo dell'aggiunta di nuove funzionalità - anche in questo caso, se la struttura e la struttura del sistema in uso rendono irragionevolmente dispendioso in termini di tempo per scrivere nuove funzionalità, una riscrittura potrebbe fornire risparmi. Dai un'occhiata al tuo budget pianificato per le nuove funzionalità, ma sii realistico - se affermi che vedrai un miglioramento del 50% aspettati di sviluppare effettivamente funzionalità in x man-month che prima richiedevano 2 * x man-month per realizzarle; tali promesse potrebbero essere difficili da mantenere.

• Impatto sulla qualità del software sulle vendite - se il sistema attuale causa frequentemente problemi visibili ai clienti, ad es. Arresti anomali o tempi di inattività nonostante gli sforzi di manutenzione adeguati, quindi una riscrittura può essere una soluzione. SE questo è un problema importante, quindi gli stessi addetti alle vendite possono quantificare il valore di una 'funzione' chiamata 'prodotto più stabile'.

Se i tre punti sopra non raggiungono il costo previsto per la riscrittura (e altro ancora, il costo opportunità di spendere x dev-days su non-funzioni è uguale al valore di quelle caratteristiche, che è maggiore del costo puro di the x dev-days) allora temo che sia proprio così: i risparmi attesi non giustificano la riscrittura.

Inoltre, se la tua roadmap non mostra la necessità di "tutte le nuove funzionalità che puoi fornire", allora i risparmi dovrebbero essere in una forma "per portare 10 persone a fare tutto il necessario , ma dopo la riscrittura saremo in grado di fare lo stesso con solo 6 persone . Se riesci a "vendere" più progetti di sviluppo di quelli che hai sviluppatori, allora migliorare l'efficienza ti consente di sviluppare più cose, ma se l'azienda con le risorse attuali è già in grado di sviluppare tutte le cose che apportano un valore aggiunto, allora l'unico vantaggio finanziario può venire dal pagare meno persone o avere persone più economiche.

Il valore del refactoring può essere misurato in questo modo: attualmente la nuova funzione x costerà 5 sviluppatori per 2 settimane. Se refactoring y vecchio componente, il costo delle nuove funzionalità sarà ridotto di circa il 20%. Quindi la nuova funzione x costerà solo 4 sviluppatori in 2 settimane.

Il refactoring è un investimento per ridurre il costo degli sviluppi futuri. Se non riesci a creare questo argomento per il tuo refactoring, probabilmente non è un caso aziendale.