Quando si rinuncia alla compatibilità con le versioni precedenti a favore di una nuova e migliorata implementazione dell'interfaccia? [chiuso]

Mentre "quando" è una buona domanda, penso che "come" sia ancora più rilevante. Può essere difficile fare una transizione di rottura in un modo che non renda gli utenti frustrati o infelici. Alcuni elementi da considerare:

• Comunicare con i vostri clienti / clienti prima di qualsiasi transizione. Spiegare perché e come sarà implementato. Citando sicurezza, prestazioni, stabilità e flessibilità futura in quanto le ragioni sono tutte valide.
• Se fai comunque una pausa pulita, sollecita il feedback.
• Se ci sono sviluppatori di terze parti, assicurati di includere anche i loro input in quanto ha senso.
• Se possibile, fornisci un livello di compatibilità.
• Fornisci una guida all'aggiornamento completa.
• Rendi l'aggiornamento il più semplice e indolore possibile. Riduci al minimo il dolore degli utenti, anche se ciò significa un po 'più di lavoro per te.
• Se addebiti, offri uno sconto per gli aggiornamenti alla nuova versione.
• Aggiungi almeno alcune nuove funzionalità utili in una nuova versione per incentivare l'aggiornamento. Questo è particolarmente importante per rendere l'aggiornamento più attraente per i gestori.
• Se fai una pausa, fallo l'ultima volta che ne hai bisogno. Ciò significa in anticipo una pianificazione completa e fare in modo che tutto sia impostato correttamente.
• Se hai un'interfaccia utente, agisci con facilità sulle modifiche. Pensa rinfrescare piuttosto che riprogettare. Per utenti non tecnici, le drastiche modifiche all'interfaccia utente da una versione all'altra possono essere una grande causa di frustrazione.
• La tua nuova versione dovrebbe essere notevolmente più stabile e performante rispetto alla precedente. Non dare ai tuoi utenti un motivo per risentirti dell'aggiornamento. Non rilasciare in anticipo una nuova versione senza test approfonditi (unità, integrazione e test beta).
• Mantieni la versione precedente contemporaneamente per un lungo periodo di tempo. Se decidi di eliminarlo e interrompere il supporto, dai almeno 6-12 mesi di preavviso, più se puoi.
• Puoi permetterti di mantenere due versioni contemporaneamente in termini sia di finanze che di mano d'opera? (Inoltre, dal punto di vista del business, non dovresti interrompere il supporto della vecchia versione finché non ti puoi permettere di perdere i restanti clienti che si aggrappano alla vecchia versione e non vuoi aggiornarli. mantenendolo superano i tuoi profitti da esso.)
• Impegnati a fare aggiornamenti di sicurezza per un periodo di tempo dopo che la vecchia versione è stata interrotta se necessario.
• Ancora una volta, la comunicazione è enorme durante tutto il processo. Non lasciare che i tuoi utenti / clienti / clienti si sentano abbandonati in qualsiasi momento. La loro lealtà e passione sono alla base della tua attività. Assicurati di rispondere alle loro domande sul tuo blog o nei tuoi forum. Il fattore sociale non dovrebbe essere sottovalutato.

Per quanto riguarda il "quando", probabilmente avrai un'idea migliore per la tua applicazione di chiunque altro. In generale, tuttavia, potrebbe essere il momento giusto per una pausa quando il debito tecnico e l'architettura inibiscono completamente la stabilità, impediscono prestazioni ragionevoli e rendono lo sviluppo di nuove funzionalità travolgenti o inutilmente difficili.

Tutto ciò che ha detto, non fare questo passo alla leggera. Anche fatto bene, rompere la compatibilità con le versioni precedenti è un grosso problema. Dovresti considerare seriamente di aumentare prima la copertura del test e il refactoring e, se possibile, prima di prendere in considerazione una pausa.

In generale sono d'accordo con James Anderson. Nella mia esperienza, tuttavia, vi sono aspetti aggiuntivi che possono giustificare considerazioni e che possono puntare a un'opzione che consente effettivamente interfacce in evoluzione.

Questo esempio è di una delle squadre con cui lavoro. Spediscono un prodotto su base regolare, almeno una volta al mese, a volte anche settimanalmente. I clienti sono incoraggiati ad eseguire l'aggiornamento poiché le nuove funzionalità e le nuove piattaforme sono supportate solo sulle versioni più recenti. L'aggiornamento è semplice e i clienti possono anche saltare le versioni intermedie. Il downgrade non è supportato. Inoltre, le versioni sono supportate solo per 3 anni. Dopodiché c'è un periodo di grazia di un anno in cui le spese di manutenzione raddoppiano.

Di conseguenza la stragrande maggioranza - circa il 95% dei clienti - sta aggiornando regolarmente, almeno una volta all'anno. Ciò significa anche che è possibile introdurre gradualmente nuove interfacce.

E le vecchie interfacce? La tecnica usata da questo team sta dichiarando le vecchie interfacce come "fine vita". Poi c'è un periodo di 12 mesi in cui la nuova interfaccia è disponibile e la vecchia interfaccia non è ancora stata ritirata. Le nuove interfacce offrono funzionalità migliori rispetto alla vecchia interfaccia, quindi ci sono due incentivi: la vecchia interfaccia di fine vita e la nuova interfaccia sono molto migliori.

La vecchia interfaccia concreta in questo caso era una tecnologia specifica per piattaforma che è stata gradualmente sostituita da un'interfaccia di servizio basata sulla tecnologia standard tradizionale.

Ovviamente questo cambiamento non avviene durante la notte e ci vogliono molti anni prima del completamento. Ma ha permesso di fermare gli investimenti nella vecchia tecnologia e invece di investire nella nuova tecnologia. Il cliente riceve assistenza e ha un percorso in avanti. La maggior parte di loro accolgono favorevolmente anche il passaggio alla tecnologia più recente.

Tieni presente, tuttavia, che questo particolare approccio potrebbe non funzionare nel tuo scenario. Certamente funziona per il team con cui lavoro.

Hai già delle buone risposte qui, quindi vorrei solo aggiungere un puntatore a un articolo molto carino di Joel Spolsky su questo argomento. Sta discutendo i piani di rinunciare alla retrocompatibilità in IE 8, che è essenzialmente la stessa del tuo problema:

link

La risposta breve è Mai!

L'esperienza dimostra che abbandonare la retrocompatibilità per lo meno infastidisce clienti e utenti e, nel peggiore dei casi, li perde completamente.

Se chiedi ai tuoi utenti di riscrivere il codice, dopo aver terminato la solita maledizione di te e di tutti i tuoi discendenti, penseranno "Se devo riscrivere comunque, forse dovrei semplicemente passare a quella bella libreria ACME I hai letto tanto? ".

Il trucco è quello di migliorare l'interfaccia corrente in modo tale da non rompere la compatibilità con le versioni precedenti, o, per offrire un'interfaccia brillante e ovviamente superiore, mantenendo la vecchia interfaccia. A un certo punto nella nuova interfaccia ci saranno delle funzionalità che non saranno possibili nell'interfaccia precedente, ma questo dà alle persone un incentivo per muoversi, senza forzare il problema.

Modifica per chiarire ulteriormente.

Ciò che pensi come programmatore è -

"Migliorerò questa API e renderò il sistema il più buono possibile e tutti mi ammireranno".

Ciò che gli utenti della tua API penseranno è -

"A * * * e crede che il mio tempo e il mio programma non siano importanti. Devo smettere di fare quello che sto facendo e rifattorizzare tutto il mio codice per nessun'altra ragione che soddisfare il suo ego. Devo refactoring, quindi ho intenzione di passare a un'altra API solo per attaccarlo anche lui. "

Questa è davvero una decisione commerciale più che tecnica. Di solito, questo viene fatto come parte di una versione principale (ad esempio dalla versione 3.5 alla versione 4.0), e spesso le due versioni sono supportate in parallelo per un po '. Ciò significa che dovrai eseguire la manutenzione sulla vecchia versione ma tutte le nuove funzionalità verranno visualizzate solo nella nuova versione. La vecchia versione è supportata fintanto che l'azienda guadagna denaro o quanto basta per compensare i costi di manutenzione. Siate pronti a lanciare questo alla gestione.

Sono stato dalla parte dei clienti di questo, quindi direi che dipende molto da cosa pensi di fare per la transizione.

Attualmente stiamo aggiornando il nostro sistema di account. La società che esegue l'aggiornamento supporta anche la precedente versione incompatibile. Progettano di prendere i dati e spostarli nel nuovo sistema in modo che (in teoria) tutti i vecchi dati siano lì. Pagheremo un paio di centinaia di sterline per la conversione dei dati. Nessun problema.

Confrontati con una situazione precedente in un'altra azienda per cui ho lavorato. Il fornitore non ha avuto modo di passare dal vecchio al nuovo sistema. Questo li ha messi nella stessa situazione di ogni altro fornitore. In realtà la loro situazione era peggiore perché sapevamo che non erano impegnati ad aiutarci con gli aggiornamenti. Non hanno ottenuto il nuovo contratto.

Hai svolto il duro lavoro per ottenere e mantenere i clienti, come puoi facilitare la transizione?