Guida
Cambiare sviluppatore di un gestionale: cosa verificare prima del subentro
Cambiare sviluppatore non è soltanto una scelta tecnica.
Un gestionale o un'applicazione web può dipendere da account, infrastrutture, servizi esterni, procedure e conoscenze che nel tempo sono rimaste nelle mani del precedente fornitore.
Prima di interrompere il rapporto è quindi utile ricostruire ciò che serve per garantire continuità e permettere al nuovo sviluppatore di valutare il sistema.
Quando il cambio diventa necessario
Il cambio può essere valutato quando:
- il fornitore non è più disponibile;
- le richieste restano senza risposta;
- non esiste chiarezza su tempi e responsabilità;
- il software non può essere aggiornato;
- l'azienda non controlla account o dati essenziali;
- ogni intervento dipende da una sola persona;
- il rapporto non consente più di pianificare l'evoluzione;
- il livello di rischio è diventato incompatibile con l'importanza del sistema.
Prima di comunicare il passaggio
Prima di avviare la transizione è opportuno verificare:
- chi è titolare dei contratti;
- chi controlla dominio e hosting;
- dove si trova il codice;
- chi gestisce il database;
- quali servizi esterni sono utilizzati;
- quali obblighi contrattuali esistono;
- quali attività sono ancora aperte;
- quali scadenze tecniche devono essere rispettate;
- quali persone interne conoscono i processi coperti dal software.
Proprietà e disponibilità del codice
La disponibilità del codice sorgente è uno degli elementi principali, ma non è l'unico.
Occorre distinguere:
- possesso di una copia del codice;
- possibilità legale di modificarlo;
- presenza dello storico delle modifiche;
- disponibilità delle dipendenze;
- conoscenza delle configurazioni;
- possibilità di eseguire il software in un ambiente diverso dalla produzione.
In caso di dubbi contrattuali o sui diritti di utilizzo è opportuno ottenere una verifica professionale specifica. Restauro Software può analizzare la disponibilità tecnica degli asset, ma non sostituisce una consulenza legale.
Continuità operativa durante la transizione
Il passaggio deve evitare che il software resti senza presidio in un momento critico.
È utile definire:
- data di conclusione del rapporto;
- disponibilità del precedente fornitore durante il passaggio;
- canale per emergenze;
- freeze temporaneo delle modifiche;
- backup prima delle attività;
- responsabilità su server e account;
- modalità di comunicazione agli utenti;
- priorità da mantenere operative.
Cosa deve ricevere il nuovo sviluppatore
Il nuovo sviluppatore dovrebbe ricevere almeno:
- descrizione delle funzioni essenziali;
- accessi disponibili;
- codice sorgente;
- database o procedure per accedervi;
- configurazioni;
- elenco dei servizi esterni;
- procedure di backup;
- modalità di rilascio;
- problemi noti;
- attività in corso;
- riferimenti delle persone interne;
- vincoli temporali o normativi.
Usate la checklist completa per il passaggio di consegne per organizzare questi elementi.
Se il precedente fornitore collabora
Un passaggio collaborativo può ridurre tempi e rischi.
È utile richiedere una consegna strutturata, verificare che i materiali siano utilizzabili e organizzare un confronto tecnico mirato sui punti che non possono essere ricostruiti rapidamente dal codice.
Se il precedente fornitore non collabora
Quando la collaborazione non è possibile, occorre partire dagli asset controllati dall'azienda.
La ricostruzione può coinvolgere server, database, backup, dominio, configurazioni, log e comportamento dell'applicazione. Prima di intervenire bisogna distinguere ciò che può essere recuperato da ciò che manca in modo sostanziale.
Errori da evitare
Tra gli errori più frequenti:
- interrompere l'accesso al precedente fornitore prima di avere verificato gli asset;
- cambiare credenziali senza sapere quali servizi le utilizzino;
- consegnare al nuovo sviluppatore soltanto una copia incompleta del codice;
- iniziare subito nuove funzionalità;
- modificare direttamente la produzione senza backup;
- assumere che il software sia documentato perché esiste un manuale utente;
- affidare nuovamente tutto a una sola persona senza repository e procedure condivise.
Il ruolo del check-up
Il check-up iniziale serve a verificare se il passaggio sia tecnicamente sostenibile e quali attività siano necessarie prima di assumere la manutenzione ordinaria.
Non elimina ogni incertezza, ma consente di delimitare rischi, priorità e prerequisiti.
Quando gli asset sono sufficienti, il percorso può proseguire con il subentro su gestionali e applicazioni web esistenti.
Richiedere un confronto preliminare
Descrivete il software, le criticità note e gli accessi disponibili. Il primo confronto serve a comprendere il contesto e a verificare se esistono le condizioni per un intervento.