Dovrei includere i costi di uscita nella scelta di una soluzione

10

Attualmente sto scegliendo tra due progetti / soluzioni software realizzabili. La soluzione 1 è facile da implementare, ma bloccherà alcuni dati in un formato proprietario e sarà difficile modificarla in seguito. La soluzione 2 è difficile da implementare, ma sarà molto più facile da cambiare in seguito.

Devo andare YAGNI su questo o dovrei includere il costo di uscita nel processo decisionale? O chiesto diversamente, il costo di uscita fa parte del TCO?

Sto pensando di tornare dal cliente con questo per chiedere se ritiene che i costi di uscita siano rilevanti o meno, ma mi piacerebbe sapere cosa pensa prima la community.

PS Il costo di uscita è il termine corretto?

— dvdvorle
fonte

Puoi aggiungere perché pensi che la prima soluzione bloccherà i dati e sarà difficile cambiarli in seguito?

— Jaap,

In sostanza, non tutti i formati sono proprietari, nemmeno quelli che si presume siano "standard" o "aperti"? Yagni probabilmente si applica se il formato "proprietario" è più facile da implementare, diretto da usare e / o il formato defacto per lo scambio.

— Giustino

Senza entrare nei dettagli; pensalo come posizionare un foglio Excel (progettato dal cliente) in un sistema di gestione dei documenti (soluzione 1), anziché creare le tabelle e le GUI appropriate e generare il foglio Excel su richiesta (soluzione 2). Solo che non è Excel.

— dvdvorle,

Tuttavia, ciò probabilmente non preclude di notare questo aspetto di preoccupazione nel presentare la scelta e la decisione allo sponsor del progetto.

— Giustino

@JustinC bene alla fine stiamo parlando di contanti qui. È più economico utilizzare il formato "proprietario" a lungo termine o no? Questo è ciò che penso sia più importante per lo sponsor del progetto

— dvdvorle

4

Il costo di uscita fa parte del TCO (la T rappresenta il totale ), ma è difficile stabilire se non si conosce a priori quanto tempo durerà il sistema. In altre parole, se sai che il sistema verrà utilizzato esattamente per un anno e costerà $ 52.000 per disattivarlo tra un anno, puoi essere abbastanza sicuro di aggiungere $ 1.000 a settimana al budget operativo per coprirlo.

Quel modello esce dalla finestra quando non si conosce la durata del sistema. Il sistema potrebbe, in teoria, rimanere in uso per sempre, il che significa che non ci saranno soldi spesi per spegnerlo. Qualunque cosa tu consideri ora sarà in dollari di oggi, e quelle cifre potrebbero essere insignificanti tra cinque anni a causa dei cambiamenti nei tassi di lavoro e nella tecnologia che rendono il processo più semplice (o più difficile).

Faresti meglio a dare ai tuoi clienti un'idea di ciò che è necessario per uscire dal sistema e lasciare che li trasformino in decisioni sulla sostituzione quando sarà il momento.

(E ora, dopo aver scritto questa risposta, posso votare per chiuderlo come fuori tema.)

— Blrfl
fonte

L'alternativa al costo di uscita che fa parte del TCO di questa soluzione, sarebbe che sarebbe parte del TCO della soluzione successiva. Ora so che sembra strano se lo dico in questo modo, ma nella mia esperienza il costo della disattivazione di un sistema fa parte del piano di progetto / budget del sistema successivo, non del piano di progetto / budget per il sistema attuale. Ha senso?

— dvdvorle,

1

Ha senso per me, e questa è praticamente la conclusione a cui sono arrivato. Non puoi davvero ottenere un totale reale fino a quando l'intera faccenda non sarà finita.

— Blrfl,

Concordo sulle difficoltà di stimare con precisione i "costi di uscita", penso che ci sia valore nel fornire uno anche se è nel denaro di oggi. Confronta "questo sarebbe difficile e dispendioso in termini di tempo" e "questo probabilmente costerebbe tra $ 25000 e $ 50000 se fatto domani".

— vaughandroid,

@Blrfl, cosa rende questa domanda fuori tema?

— Neontapir,

1

@neontapir: la carne della domanda riguarda davvero la gestione del progetto; il fatto che si tratti di un programma non lo fa davvero sulla programmazione. La stessa cosa potrebbe applicarsi altrettanto facilmente agli interruttori telefonici o ai forni per pizza.

— Blrfl,

2

YAGNI è una grande regola al suo posto, ma non sono sicuro che dovrebbe applicarsi in questo caso. Stai stimando i costi futuri qui, un'attività che dovrebbe comportare una certa considerazione delle modifiche ai requisiti futuri. Se stavi scrivendo l'implementazione sarebbe una storia diversa!

Ti suggerirei di fare i costi, ma assicurati che il cliente capisca perché l'hai fatto. Se non sono molto tecnici, non sorprenderti se dicono qualcosa sull'effetto di "non può essere una buona soluzione se stai già pensando di usare qualcos'altro!"

Ci possono essere alcuni aspetti più precisi da considerare quando stai facendo / presentando le tue stime dei costi:

Con quale probabilità i dati verranno migrati in un altro sistema in futuro?
È probabile che il fornitore della soluzione modifichi il proprio formato di dati in modo che sia più facile / difficile migrare i dati in futuro? In tal caso, ciò influirà sulla tua soluzione?
Anche se non desideri modificare i dati in un secondo momento, è possibile che tu voglia presentare / accedervi in modo diverso? La mia esperienza è che questo è abbastanza comune!

— vaughandroid
fonte

1

Lavorando dal tuo commento sulla situazione del file Excel, lo guardo come:

non modificare il formato corrente (soluzione 1)
anziché analizzare il formato ora e memorizzarlo in un formato diverso (possibilmente / si spera più adatto / pronto per il futuro) (soluzione 1 + passaggio di analisi, ovvero soluzione 2)

Credo che YAGNI si applichi a quel passaggio di analisi; assicurati di mantenere le conoscenze sulla struttura attuale, ma non implementare ancora l'analisi.

Inoltre, la struttura dei dati analizzati potrebbe non essere flessibile come si pensa; i requisiti potrebbero anche andare verso la memorizzazione di informazioni / file diversi, il che significherebbe che devi aggiornare / espandere le tue tabelle.

— Jaap
fonte

Per essere chiari, al momento non esiste una soluzione (soluzione 0 se lo desideri). Attualmente conservano tutte le informazioni in file cartacei. Concordo pienamente con questa risposta se avessero già usato il file "Excel" nel sistema di gestione dei documenti, ma qui c'è ancora una scelta.

— dvdvorle,

O pensi che non sia rilevante perché l'implementazione della soluzione 1 è economica?

— dvdvorle,

Il mio punto è che credo che se la soluzione 2 può essere considerata un miglioramento della soluzione 1, ma quel miglioramento non è strettamente necessario ora, YAGNI si applica.

— Jaap,

Capisco cosa intendi. È qualcosa a cui pensare. Anche se penso che sia ora di andare dal cliente ora, vedi cosa pensa che sia un miglioramento e quant'altro.

— dvdvorle,

0

Se non sei sicuro al 95%, sarà cambiato in futuro - Soluzione 1 - YAGNI =)

Sicuramente dipende dai tuoi clienti e dalla tua esperienza nella programmazione di qualcosa per questo cliente.

— MikroDel
fonte

2

Quindi stai dicendo che qualsiasi costo legato alla probabilità del 5% che la soluzione cambierà è irrilevante?

— dvdvorle,

Voglio dire che questo è un qualche tipo di sentimento ... Sai cosa significa "YAGNI" - il resto è sentimento =)

— MikroDel

0

Nella mia esperienza, le ruote reinventate impiegano più tempo a reinventare di quanto si pensi, e le ruote esterne tendono ad essere più facili da sostituire. Entrambi i tipi di ruote tendono ad apparire peggiori una volta acquistati rispetto a quando hanno preso la tua decisione.

Se pensi davvero che il n. 1 sia facile da implementare e ti stai chiedendo quanto tempo impiegherà il n. 2, ascolterei la domanda. Implementa subito il numero 1 e pensa al design più grande mentre procedi. Questo ti aiuterà se in seguito vuoi reinventarlo.

Viceversa se il n. 1 non sembra più facile come pensavi, passa al n. 2.

— btilly
fonte