Perché il codice deve restare tuo
Il vincolo con un fornitore non nasce dalla cattiveria: nasce da come è fatto il contratto e da dove stanno gli accessi.
Il momento in cui ci si accorge di essere legati a un fornitore non è quando le cose vanno male. È quando vanno bene e serve una modifica: si chiede un preventivo, il numero non torna, si pensa di chiedere a qualcun altro, e si scopre che non si può. Il codice sta su un account che non è tuo, il dominio è intestato a loro, e nessuno sa come è fatto il database.
Quasi mai è una trappola preparata a tavolino. È il risultato di scelte prese per comodità, una alla volta, senza che nessuno le mettesse per iscritto.
Le quattro cose da chiedere prima di cominciare
Il repository è tuo. Intestato alla tua azienda, con il fornitore invitato come collaboratore — non il contrario. Costa niente al primo giorno e diventa impossibile da sistemare al centesimo.
Gli accessi sono tuoi. Dominio, hosting, database, servizi esterni: registrati con email della tua azienda. Che poi le password le gestisca chi lavora al progetto va benissimo, purché il proprietario dell'account sia tu.
Le scelte sono documentate. Non serve un manuale: serve un file che spieghi come si avvia il progetto, dove stanno le variabili d'ambiente, perché è stato scelto quel database e cosa succede quando arriva un ordine. Mezza giornata di lavoro che vale mesi al primo cambio di fornitore.
Niente pezzi proprietari. Se il lavoro poggia su una libreria che esiste solo dentro l'azienda che te lo ha costruito, il codice è tuo solo sulla carta: nessun altro può metterci mano.
Il test da fare
Uno solo, e si può fare in qualunque momento: se il tuo fornitore sparisse domani, un altro sviluppatore riuscirebbe a prendere in mano il lavoro leggendo quello che c'è?
Se la risposta richiede una telefonata a chi l'ha scritto, il lavoro non è finito. La conoscenza che sta solo nella testa di una persona non è un vantaggio per quella persona: è un rischio per te e un peso per lui, perché sarà sempre l'unico a poterci lavorare.
Perché lo dico da fornitore
Sembra controintuitivo che chi scrive software ti spieghi come cambiarlo senza di lui. Il motivo è pratico: un cliente che resta perché non può andarsene non è un cliente contento, è un cliente che appena può se ne va — e nel frattempo tratta ogni preventivo come un abuso.
Preferisco che chi lavora con me lo faccia perché il lavoro è fatto bene. È anche l'unico modo per cui il passaparola funziona, e il passaparola è come arriva la maggior parte dei progetti seri.
Se ci sei già dentro
Non serve rifare tutto. Si comincia dagli accessi: si aprono account intestati all'azienda e si trasferiscono dominio e servizi, uno per volta. Poi si chiede una copia del codice e si mette in un repository tuo — anche solo come archivio. Poi la documentazione minima, che si può commissionare come lavoro a sé.
È il tipo di sistemazione che nessuno fa finché non serve. Farla mentre tutto funziona costa un decimo.