Dopo che un'applicazione esternalizzata / offshored è "completata", chi eseguirà la manutenzione?

Questo è uno dei problemi non dichiarati (bene, non detto a livello di gestione).

Lo scenario 1 prevede che la manutenzione, il supporto e i miglioramenti vengano effettuati dalla società esterna al sito. Questo presume che esistano ancora tra 5 anni (c'è un rischio per gli affari lì). All'inizio i costi relativi a questa assistenza in corso dovrebbero essere presi in considerazione.

Lo scenario 2 prevede che il lavoro venga "scaricato" sul reparto IT in loco. Per esperienza, spesso non è ben accolto, specialmente se sono stati fatti ridondanti in base alle decisioni di andare off-shore. Anche se è ben accolto, hai la possibilità di imparare a capire il codice di qualcuno. Se hai tempo per guardare il codice prima di andare in diretta, sei stato molto fortunato! Di solito è tutto materiale antincendio. È anche frustrante quando il tuo manager non riesce a capire perché ci vuole X volte più tempo per fare qualcosa, solo perché il 90% del tuo tempo era in comprensione.

Ci scusiamo se questo si presenta come eccessivamente a favore o contro il off-shoring. Credo che sia strettamente fuori tema, e ho cercato di moderare la mia risposta di conseguenza! ;)

Questo deve essere preso in considerazione quando il progetto inizia ma non c'è una risposta fissa, esso varierà da società a azienda e progetto da progettare.

Se c'è un team interno può essere consegnato a loro per supportare e migliorare su base continuativa. Ovviamente i problemi con questo sono i problemi con qualsiasi passaggio di consegne a persone che non erano coinvolte fin dall'inizio.

Se stai seguendo questa strada, ti consiglio di coinvolgere i membri del team interno fin dalle prime fasi del progetto, eseguendo le specifiche e le revisioni del codice e così via, così quando arriva il passaggio, capiscono cosa stanno guardando a. UAT è un buon momento per metterli a bordo in modo pratico in quanto potrebbero essere coinvolti in alcuni dei bug fixing in modo semplice mentre il supporto è ancora disponibile.

Devi assicurarti che il passaggio di consegne sia incluso nel contratto e sia dotato di risorse adeguate su entrambi i lati e che i pagamenti finali alla società di outsourcing dipendano dal completamento della tua soddisfazione.

In alternativa, la società che ha completato il progetto sarà probabilmente felice di supportarla su base continuativa (a pagamento). Il problema qui, a parte il costo, è che di solito non ottieni continuità del personale, certamente non a lungo termine, e il passaggio di consegne è fuori dal tuo controllo, quindi non puoi nemmeno assicurarti che sia gestito correttamente.

Ho visto accadere questo (da entrambi i lati della recinzione) e quello che spesso si finisce è un pessimo passaggio dagli sviluppatori originali ai ragazzi di supporto che poi si riflette non solo nel codice più basso e nella qualità del prodotto, ma anche nel costo dei miglioramenti (perché le stime del nuovo sviluppatore sono più alte perché lui non capisce il sistema e in effetti lo stai pagando per imparare, nonostante il fatto che tu abbia pagato per quella società per scrivere esso).

Personalmente ho sempre seguito il percorso interno per il supporto (ho visto terze parti perdere il codice sorgente e penso che queste cose siano troppo importanti per fidarsi di loro), anche se capisco che è una decisione strategica e se non esiste alcuna squadra è potenzialmente una vendita difficile.

Di solito una parte della manutenzione è inclusa nel contratto (con un prezzo dedicato o come parte del progetto), e gli aggiornamenti conseguenti hanno un costo.

In generale, è possibile creare un nuovo accordo in queste due forme per la manutenzione:

• Un piano di manutenzione per una certa quantità al mese (se il lavoro è in qualche modo sporadico).
• Una tariffa oraria per lavori di manutenzione.

Per nuove funzionalità / ottimizzazioni / estensioni:

• Negozia diversi imballaggi insieme come nuovo progetto (iterazione).
• Negoziare una tariffa oraria (e, se possibile, fornire una stima, chiarendo che si tratta di una stima).

Personalmente e come sviluppatore, mi piace gestire tutto come un progetto, e bug, li aggiusto gratuitamente. Piccole ottimizzazioni / modifiche, se mi prendono meno di mezz'ora, le do anche gratis (che mantiene felice il mio cliente), in caso contrario, addebito a ore.

La situazione ideale sarebbe se il tuo cliente ha un dipartimento IT, quindi puoi fornire loro la documentazione tecnica necessaria in modo che possano prendere in carico la manutenzione mentre continui ad aggiungere nuove funzionalità.