La maggior parte delle guide parla di come scegliere un partner software. Poche parlano di come lasciarlo, anche se spesso è la decisione più difficile. Il sistema è già in produzione, le persone lo usano ogni giorno e l’unico team che lo conosce fino in fondo è proprio quello di cui non è più sicuro. Ereditiamo regolarmente progetti di questo tipo, e quelli che vanno bene hanno un punto in comune: il committente ha pianificato l’uscita prima di annunciarla.
I segnali che è ora di cambiare partner
Ogni collaborazione ha un mese difficile. Quello che conta è se i problemi vengono spiegati e risolti, oppure semplicemente si ripetono. Questi sono gli schemi che, nell’arco di due o tre trimestri, di solito indicano che il rapporto non si riprenderà:
Scadenze mancate senza motivazioni. Un ritardo con una causa chiara e un nuovo piano è normale. Ritardi che arrivano come sorprese, senza che cambi nulla nel modo in cui viene gestito il lavoro, sono un problema di gestione che il fornitore non sta risolvendo.
Solo il fornitore sa rilasciare. Se per mandare in produzione una modifica serve una persona precisa del fornitore, il suo sistema non è del tutto suo - e più a lungo dura questa situazione, più costoso diventa andarsene.
Ogni modifica costa più della precedente. Stime in crescita per lavori simili sono il segnale più chiaro di un codebase che diventa sempre più difficile da modificare, e di un team che non sta ripagando quel debito.
Il team continua a ruotare. Volti nuovi ogni trimestre e nessuna documentazione significano che la conoscenza se ne va con ogni persona. Chieda chi lavora ancora sul suo progetto dal primo mese.
Se due o più di questi segnali sono veri, applichi la checklist per scegliere un partner per lo sviluppo software al suo fornitore attuale, come se lo incontrasse per la prima volta. A volte una conversazione onesta e un’organizzazione diversa risolvono il problema. Spesso confermano quello che già sospettava.
Che cosa mettere al sicuro prima di dirlo a chiunque
L’ordine conta più del nuovo fornitore. Prima di annunciare il cambio - anche prima di avviare conversazioni serie con un sostituto - si assicuri che la sua azienda abbia in mano quanto segue, a proprio nome:
- Accesso amministrativo a ogni repository di codice, compresi quelli usati solo dalla CI del fornitore
- La titolarità degli account cloud, dei domini, del DNS e delle schede negli app store - intestati alla sua azienda
- Ogni segreto e credenziale: chiavi API, password dei database, certificati di firma, accessi a servizi di terzi
- Backup dei database che lei stesso ha ripristinato almeno una volta
- Tutta la documentazione esistente - note di architettura, runbook, procedure di deploy, per quanto scarna
- Un elenco di tutti i servizi di terzi da cui dipende il sistema, e di chi li paga
Gran parte di tutto questo dovrebbe già essere suo in base al contratto. Verifichi nell’accordo le clausole su proprietà intellettuale, obblighi di passaggio di consegne e periodi di preavviso, e mantenga un tono professionale: per settimane dopo la decisione avrà bisogno della collaborazione del team uscente.
Il momento più economico per assicurarsi l’accesso al proprio sistema è prima che qualcuno sappia che se ne sta andando.
Un passaggio di consegne per gradi
Il modo più rischioso di cambiare partner è un’unica data di passaggio. Un passaggio di consegne per gradi tiene in piedi il sistema e dà al nuovo team il tempo di impararlo mentre il vecchio team può ancora rispondere alle domande.
Settimane 1-2: affiancamento. Il nuovo team legge il codice, configura i propri ambienti e osserva il team uscente mentre rilascia e gestisce gli incidenti. L’obiettivo è una mappa scritta del sistema: componenti, flussi di dati, integrazioni e le parti che nessuno capisce.
Settimane 3-4: modifiche supervisionate. Il nuovo team apporta modifiche piccole ma reali e le rilascia, con la revisione del vecchio team. È qui che emergono la documentazione mancante e i passaggi di build fragili - meglio ora che durante un’interruzione del servizio.
Settimane 5-8: presa in carico per aree. La responsabilità passa un’area alla volta - prima le parti con la migliore copertura di test, per ultime quelle più rischiose. Il fornitore uscente resta reperibile, idealmente con un piccolo contratto di retainer, finché non è passata anche l’ultima area.
Resista alla tentazione di riscrivere tutto appena arriva il nuovo team. Un nuovo partner che propone di ricostruire ogni cosa prima ancora di aver capito il sistema sta ripetendo l’errore da cui lei sta cercando di uscire. Prima si stabilizza, poi si migliora un modulo alla volta - l’approccio che descriviamo in modernizzare i sistemi legacy senza la grande riscrittura.
Scegliere il partner successivo
La seconda scelta dovrebbe essere più rigorosa della prima. Chieda al candidato come ha preso in carico altri sistemi in passato, e chieda un piano di passaggio di consegne anonimizzato di un progetto reale. Concordi una fatturazione a milestone invece di un contratto a ore senza limiti, e faccia della documentazione un risultato consegnabile, non un favore. Soprattutto, verifichi che lasciare il nuovo partner sarebbe facile - perché la protezione migliore contro il dover rileggere questo articolo è un rapporto che potrebbe chiudere a basso costo.
Domande frequenti
Quando conviene cambiare partner per lo sviluppo software?
Quando i problemi smettono di essere spiegati e cominciano a ripetersi: scadenze mancate senza motivazioni, un sistema che solo il fornitore sa rilasciare, un costo per modifica in aumento e un team che ruota di continuo. Un mese difficile è normale; uno schema che dura due o tre trimestri è un segnale.
Come si cambia fornitore software senza perdere il progetto?
Si mettono al sicuro codice, infrastruttura, credenziali e backup prima di annunciare il cambio, poi si passa il testimone per gradi: il nuovo team affianca, poi rilascia sotto supervisione, poi prende in carico un'area alla volta mentre il vecchio fornitore resta reperibile.
Quanto dura un passaggio di consegne di un software?
Per un tipico sistema aziendale, da quattro a otto settimane di sovrapposizione tra il vecchio e il nuovo team. I sistemi senza documentazione o senza test richiedono più tempo, perché il nuovo team deve prima ricostruire quella conoscenza.
Quando si cambia partner bisogna riscrivere il software?
Quasi mai come primo passo. Un nuovo partner dovrebbe stabilizzare e capire il sistema prima di proporre modifiche. Si sostituiscono parti solo dove c'è una ragione chiara, un modulo alla volta.