Grafico per mostrare una diminuzione della desiderabilità quando si prendono scorciatoie

2

Sono responsabile della creazione di una presentazione per la gestione che dettagli come un sistema dovrebbe essere refactored o riscritto. Abbiamo un sistema esistente che ha avuto errori di produzione e il codice base non è in uno stato desiderabile.

Ecco le opzioni attuali possibili:

  1. Riscrivi il sistema usando gli sviluppatori che forniscono la migliore qualità del codice
  2. Riscrivi il sistema usando sviluppatori che scrivono meno codice di qualità ideale
  3. Lascia il sistema così com'è e mantienilo
  4. Riscrivi il sistema usando manodopera più economica dall'altra parte del mondo

Il problema non è tra quelli da scegliere, perché credo che il # 1 offra il miglior valore a lungo termine per il business. Il problema è come presentare questo al management in modo che capiscano i costi di ogni scorciatoia che prendono dal # 1.

Ad esempio, inizierei con la presentazione # 1 ... e poi? La mia idea originale è di mostrare in qualche modo ogni scorciatoia e cosa significa in termini di costi / benefici a lungo termine. Quindi, forse la direzione vuole usare manodopera più economica. Devo mostrare che cosa fa alla qualità, al tempo, ecc. Come posso dimostrarlo? Forse la direzione vuole usare un ibrido tra le opzioni di cui sopra. Come lo mostro? Ci potrebbero essere 20 diverse permutazioni delle opzioni di cui sopra, e mi piacerebbe dimostrare che se adottano l'approccio a breve termine di tutto a basso costo, ciò che alla fine significa per la qualità del prodotto.

Ci sono grafici per questo tipo di cose? Un approccio consigliato? Potrei semplicemente iniziare a scrivere, ma non voglio che gli occhi della direzione si smaterializzino da troppe parole. Spero che tutto abbia un senso.

Un'idea è di presentare qualcosa di simile a ciascuna opzione:

    
posta Bob Horn 12.08.2013 - 18:57
fonte

2 risposte

2

L'azienda è interessata a tempo, denaro ed emozioni (a seconda del prodotto). Ho affrontato un problema simile e l'ho presentato da diverse prospettive:

  1. Ci costa "X" al mese per mantenere TerribleApp, senza aggiungere alcun valore al business. Se spendessimo "X" in anticipo, questo progetto si ripagherebbe in tempo "X" e sarebbe molto più affidabile, più facile da usare, ecc.

  2. TerribleApp impiega "X%" del tempo dedicato ai team di sviluppo, il che significa che siamo molto più lenti nel portare i nostri nuovi progetti, come AwesomeApp, fuori dalla porta.

  3. Ricorda l'ultima volta che TerribleApp si è arrestato in modo catastrofico e ha impiegato "X" giorni per tornare operativi? Ciò ha causato insoddisfazione a tutti i nostri clienti, ha rispecchiato male l'organizzazione, ha esercitato pressioni sui dirigenti e sull'intero team IT, ha causato la partenza di John, ecc., E potenzialmente ci ha perso X% di quota di mercato, che è meno probabile di AwesomeApp quando rilasciamo esso. Queste interruzioni si ripeteranno non importa quanto lavoro supportiamo questa applicazione e continueremo a danneggiare il nostro marchio.

  4. Il nostro team di sviluppo è di qualità molto più elevata rispetto a quelli che hanno creato TerribleApp, come si può vedere dalla GreatApp rilasciata di recente. Se è costruito da una buona squadra che si fida e sa cosa sta facendo, il rischio che TerribleApp2.0 (potrebbe voler rinominare questo) soffrire dello stesso destino è molto basso. Se esternalizziamo o impieghiamo sviluppatori sconosciuti, aumentiamo il rischio di guasti o costi di manutenzione elevati. Se è costruita la gestione del progetto off-shore sarà molto più costosa dal contatto locale e il rischio di un altro fallimento è più alto.

risposta data 09.10.2013 - 10:31
fonte
0
  • Prima stima lo sforzo richiesto per il refactoring / riscrittura del codice.
  • Quindi scopri le implicazioni di costo di tutte e 4 le opzioni.
  • Scopri le perdite causate da interruzioni di produzione del sistema legacy e quindi confrontare il vantaggio che ogni approccio darebbe confrontandolo con una potenziale perdita se c'è un'interruzione del prodotto.

Puoi sottolineare che i punti 2 e 3 non sono qualcosa che consiglieresti e puoi concentrarti sui punti 1 e 4 della tua presentazione

Offri vantaggi e svantaggi a entrambi gli approcci e cerca di mantenerti obiettivo di presentazione. In realtà, la gestione sarà più interessata al rapporto costi-benefici, piuttosto che al solo costo. SE gli sviluppatori offshore a basso costo stanno andando a risolvere il tuo problema a buon mercato perché non usarli.

    
risposta data 13.08.2013 - 09:40
fonte