Cambiare partner di sviluppo: la checklist per il passaggio di consegne

Il passaggio a un nuovo partner di sviluppo funziona se fai quattro cose nell'ordine giusto. Prima metti per iscritto le questioni di proprietà e di trattamento dei dati. Poi sposta codice, account e conoscenza in una sequenza controllata. Lascia che il nuovo team lavori a fianco di quello uscente per un breve periodo. E dai il via libera solo quando il nuovo partner ha rilasciato in autonomia una modifica reale. Questa guida ripercorre ogni passo come checklist di cambio fornitore per un'azienda svizzera, con i punti legali su cui i team inciampano più spesso.

In breve

• Prima che qualcuno tocchi il codice, metti per iscritto chi detiene il diritto d'autore, dove vengono trattati i dati e a chi è intestato ogni account.
• Trasferisci il repository completo con tutta la cronologia, poi cambia ogni credenziale. Non affidarti a un file zip o a password condivise.
• Fai lavorare in parallelo partner vecchio e nuovo per un breve periodo, spostando le responsabilità passo dopo passo invece che in un giorno solo.
• Concorda perimetro, ritmo di comunicazione, tappe e criteri di accettazione prima del primo sprint, non durante.
• Considera concluso il passaggio quando il nuovo partner ha messo in produzione una modifica da solo, non quando una casella è spuntata.

Cosa chiarire prima che il nuovo partner inizi

Quasi tutti i passaggi di consegne falliti non falliscono per motivi tecnici. Falliscono per domande che nessuno ha fatto nella prima settimana. Trova le risposte prima dell'incontro di avvio.

Perché stai cambiando. Scrivi le due o tre ragioni: scadenze mancate, uno sviluppatore chiave che se n'è andato, una tecnologia che nessuno sa più mantenere, i costi. Al nuovo partner servono per non ripetere lo schema, e a te servono per valutare il risultato più avanti.

Che cosa esiste davvero. Elenca ogni prodotto, ambiente e servizio di terzi che compone il sistema: produzione, staging, il registrar del dominio, l'account di hosting, i fornitori di pagamenti e di posta, le statistiche, CI/CD, il monitoraggio. Di solito i team si stupiscono di quanti di questi siano intestati al vecchio fornitore o alla sua carta di credito.

Chi può decidere. Indica una persona dalla tua parte che può approvare il perimetro e una che può approvare le spese. Un nuovo partner con cinque fonti di istruzioni riprodurrà esattamente la confusione da cui vuoi uscire.

Che cosa dice il vecchio contratto. Controlla il termine di disdetta, gli obblighi di consegna del fornitore uscente, le clausole di riservatezza ed eventuali limiti alla condivisione del codice con un successore. Chi ti segue sul piano legale dovrebbe leggerlo prima che tu prometta una data di inizio al nuovo partner.

Verifica proprietà, protezione dei dati e clausole contrattuali

In Svizzera ci sono alcune regole che sorprendono i fondatori. Chiariscile subito, perché possono impedire al nuovo partner di lavorare legalmente sul tuo prodotto.

Chi è titolare del codice sorgente

Avere il codice sul tuo server non significa esserne titolare dei diritti. Secondo il diritto svizzero, copyright in software is not automatically transferred to the commissioning party al di fuori dei rapporti di lavoro dipendente, e la consegna di una copia del codice sorgente non comporta automaticamente il diritto di utilizzarlo. Un'azienda che possiede il codice senza una cessione esplicita potrebbe non avere il diritto di modificarlo, ridistribuirlo o ospitarlo altrove.

Il Tribunale federale si è espresso nello stesso senso. Secondo un'University of Geneva analysis of the ruling, un contratto di sviluppo software non implica automaticamente il trasferimento del diritto d'autore al cliente. Il cliente deve poter indicare una clausola esplicita, e l'obbligo di restituire il codice sorgente non basta di per sé a dimostrare il trasferimento.

In pratica: trova nel vecchio contratto la clausola che cede il diritto d'autore o concede i diritti d'uso. Se manca o è vaga, chiedi al tuo legale di far confermare i diritti per iscritto dal fornitore uscente prima che il nuovo partner inizi. Poi assicurati che il contratto con il nuovo partner indichi chiaramente la cessione o la licenza fin dal primo giorno. I componenti di terzi e open source meritano un elenco a parte, con le rispettive licenze.

Dati personali e contratto di trattamento dei dati

Se il sistema gestisce dati personali, il nuovo partner li toccherà durante test, assistenza o migrazione. Una checklist svizzera per gli acquisti informatici dello studio legale Wicki Partners indica le domande a cui rispondere:

• Vengono trattati dati personali e si applica anche il GDPR?
• I dati escono dalla Svizzera e, in tal caso, dove finiscono?
• Esiste un contratto di trattamento dei dati?
• A chi spettano i diritti sui dati archiviati?
• Il fornitore è in grado di documentare le proprie misure tecniche e organizzative?

Chiedi al nuovo partner di mettere le sue risposte nel contratto. Decidi anche come trattare i dati di produzione durante la transizione. Ambienti di staging con dati anonimizzati o sintetici sono più sicuri delle copie di dati reali dei clienti sul portatile di uno sviluppatore. Se i tuoi dati sono soggetti a obblighi di riservatezza particolari, come nel settore bancario o sanitario, coinvolgi il responsabile della protezione dei dati prima di fare qualsiasi copia.

Costruisci la checklist di transizione

Questo è il cuore del passaggio di consegne. Tratta ogni riga come un punto con un responsabile e una data di chiusura.

Ambito	Che cosa consegnare	Come verificare che sia fatto
Codice sorgente	Repository completi con cronologia, rami, tag e configurazione CI	Il nuovo partner compila e rilascia dal repository di tua proprietà
Account	Hosting, registrar del dominio, app store, pagamenti, posta, statistiche, monitoraggio	Ogni account è intestato alla tua azienda, con utenti amministratori nominativi
Credenziali	Chiavi API, password dei database, chiavi di rilascio, certificati di firma	Tutte sostituite; i vecchi valori non funzionano più
Infrastruttura	Schemi degli ambienti, infrastructure-as-code, procedure di backup e ripristino	Il nuovo partner esegue un test di ripristino
Documentazione	Note di architettura, modello dei dati, runbook, processo di rilascio, problemi noti	Il nuovo partner sa seguire il runbook senza chiamare il vecchio team
Conoscenza	Sessioni guidate, demo registrate, elenco dei ticket aperti con il contesto	L'elenco delle domande è chiuso o volutamente messo in pausa
Aspetti legali	Cessione del diritto d'autore, contratto di trattamento dei dati, elenco delle licenze	Firmati e archiviati

Consegna codice, account e credenziali in sicurezza

Fatti dare l'intero repository, non un'istantanea del ramo principale. I vecchi rami e i messaggi di commit spiegano perché le cose stanno così, e ti serviranno la prima volta che qualcosa si rompe. Se trasferisci un repository tra organizzazioni su una piattaforma come GitHub, controlla che cosa resta collegato, per esempio webhook, chiavi di rilascio e segreti, perché le integrazioni ereditate possono continuare a funzionare con le credenziali del vecchio fornitore. Una vendor handover checklist from Trio fa la stessa osservazione: i segreti sono la voce che viene saltata più spesso.

Un ordine che funziona:

1. Prima l'inventario. Un unico documento condiviso elenca ogni account e ogni segreto, con il titolare attuale.
2. Intesta gli account alla tua azienda. Il vecchio fornitore deve essere un utente nel tuo account, non il contrario.
3. Dai al nuovo partner accessi nominativi e individuali tramite il tuo gestore di password o il tuo sistema di identità. Mai condividere un unico accesso tra più persone.
4. Sostituisci i segreti quando il nuovo partner è operativo, poi revoca nella stessa seduta gli accessi del fornitore uscente.
5. Registra le modifiche così puoi dimostrare chi aveva accesso e quando.

Puoi annotare chi è titolare di che cosa, account per account e ambiente per ambiente, in un tuo foglio di consegna. Se cerchi un modello da adattare al perimetro del passaggio e ai livelli di servizio successivi, this checklist product è un punto di partenza.

Trasferisci la conoscenza, non solo i file

Il codice spiega che cosa fa un sistema. Raramente spiega perché. Programma tre tipi di sessione con il team uscente, anche se il rapporto è teso, e valuta di pagarle nelle condizioni di uscita:

• Panoramica dell'architettura: componenti, flusso dei dati, dipendenze da terzi.
• Panoramica operativa: come avvengono i rilasci, che cosa si rompe, chi riceve gli avvisi, quali sono le routine mensili.
• Panoramica del backlog: ogni ticket aperto, con il motivo per cui esiste e le eventuali promesse fatte ai clienti.

Registrale. I nuovi membri del team guarderanno quelle registrazioni mesi dopo. Lo stesso vale quando il sistema include componenti di intelligenza artificiale: prompt, configurazione dei modelli, dati di valutazione e impostazioni di rilascio vanno documentati come qualsiasi altro codice. Un articolo su knowledge transfer and operational continuity per i sistemi di intelligenza artificiale approfondisce questo aspetto.

Mettetevi d'accordo su come lavorerete insieme

Un passaggio tecnico pulito fallisce comunque se l'accordo di lavoro è vago. Definisci questi punti prima del primo sprint.

Perimetro. Descrivi il primo blocco di lavoro, non l'intera roadmap. Scegli qualcosa di piccolo e concreto, come correggere un bug noto o rilasciare una funzione minore, così entrambe le parti imparano le abitudini dell'altra a basso costo.

Responsabilità. Metti per iscritto chi si occupa degli incidenti in produzione, chi approva i rilasci, chi parla con gli utenti e chi gestisce le patch di sicurezza. Se mantieni anche una persona interna, definisci il confine con il partner.

Comunicazione. Scegli un canale per le domande quotidiane e un incontro settimanale per le decisioni. Concordate i tempi di risposta. Chiedi chi sarà il tuo referente per tutta la collaborazione e se quella persona è anche chi lavora al progetto. La continuità delle persone conta moltissimo nei primi mesi: chiedi quindi senza giri di parole come il partner compone il team e che cosa succede se qualcuno se ne va.

Tappe e criteri di accettazione. Per ogni tappa, scrivi che cosa significa "fatto" in termini osservabili: rilasciato in produzione, test superati, documentazione aggiornata, funzione dimostrabile. È proprio dalle formule di accettazione vaghe che nascono le discussioni sul perimetro.

Livelli di servizio dopo il lancio. Se il partner gestirà il sistema, definisci che cosa viene monitorato, con quale rapidità risponde agli incidenti e che cosa è incluso ogni mese. Il nostro piano di monitoraggio, Run & monitor, costa CHF 750 al mese; chiedi a qualsiasi partner di esplicitare l'equivalente, così confronti cose comparabili.

Riduci i fermi con un subentro a tappe

L'approccio più rischioso è il fine settimana del cambio: il vecchio fornitore esce il venerdì e il nuovo inizia il lunedì. Un piano a tappe, grosso modo in tre fasi, è più sicuro. Questa struttura segue un 90-day transition plan published by Howdy, qui adattato come schema generale. La durata dipende dalla dimensione del sistema: considera i 90 giorni come limite massimo per un prodotto complesso e prevedi tempi più brevi per un sito semplice.

Fase 1: stabilizzare gli accessi e leggere

Il nuovo partner ottiene accesso in sola lettura, esamina il codice, prepara i propri ambienti locali e di staging e legge i runbook. In produzione non cambia nulla. L'obiettivo è che il nuovo partner sappia indicare le tre parti più rischiose del sistema.

Fase 2: lavoro in parallelo

Il nuovo partner inizia a fare piccole modifiche, riviste dal team uscente dove possibile. Le responsabilità si spostano gradualmente: prima lo staging, poi i rilasci, poi la gestione degli incidenti. Tieni un elenco breve di tutto ciò che il nuovo partner segnala come poco chiaro e chiudilo con il vecchio team finché è ancora raggiungibile.

Fase 3: passaggio definitivo

Il nuovo partner gestisce rilasci e incidenti. Sostituisci i segreti rimasti, revoca gli accessi del fornitore uscente e passa ai nuovi livelli di servizio per l'assistenza. Mantieni il vecchio fornitore raggiungibile per un periodo definito di domande, messo per iscritto nell'accordo di uscita.

Proteggi l'attività durante il cambio

• Blocca i rilasci non essenziali nei giorni attorno al passaggio.
• Fai un backup completo e verifica di saperlo ripristinare prima di modificare gli accessi.
• Di' al tuo team di assistenza chi contattare durante la transizione.
• Pianifica il passaggio lontano dai giorni di maggior lavoro.

Verifica che il nuovo partner sia pronto a prendersi il prodotto

Una checklist firmata dimostra che i documenti sono passati di mano. Non dimostra che il nuovo team sa far funzionare il prodotto. Usa invece prove sui risultati:

1. Prova di rilascio: il nuovo partner porta in produzione una piccola modifica senza l'aiuto del vecchio fornitore.
2. Prova di ripristino: rimette in piedi il sistema da backup in un ambiente pulito.
3. Esercitazione su incidente: spiega come reagirebbe a un'integrazione di pagamento non funzionante o a un database fuori servizio, usando il runbook.
4. Verifica degli accessi: sai elencare ogni persona con accesso, e il fornitore uscente non compare da nessuna parte.
5. Controllo della documentazione: una pagina sbagliata o mancante è stata corretta dal nuovo partner durante il processo.

Dopo il via libera, fai una revisione a 30 e a 90 giorni. Confronta i risultati con i motivi iniziali del cambio: velocità di consegna, difetti, comunicazione, costi. Risolvi i problemi finché il rapporto è ancora giovane.

Come lavoriamo quando siamo noi il nuovo partner

Ampersand è un piccolo studio di Zurigo e i nostri ingegneri senior restano coinvolti dal primo colloquio alla consegna. È un modo per evitare requisiti riscritti e cambi di persone a progetto in corso, e per lasciarti in grado di gestire il tuo prodotto invece che legato a noi. Se stai spostando un prodotto da un altro fornitore, possiamo aiutarti con audit, migrazione di sistemi legacy, consulenza e assistenza continuativa. Il nostro piano Guidance per la consulenza tecnica senior costa CHF 799 al mese. Trovi le opzioni sulla nostra pagina dei prezzi oppure parti dalla nostra homepage.

Domande frequenti

Quanto dura l'inserimento di un nuovo partner di sviluppo?

Dipende dalla dimensione del sistema. Un sito semplice può richiedere un paio di settimane, mentre una piattaforma complessa con molte integrazioni può arrivare a circa tre mesi di transizione a tappe. Prevedi un periodo in parallelo invece di un cambio secco, e definisci la fine con prove sui risultati, per esempio un rilascio in produzione fatto in autonomia.

Che cosa deve contenere una checklist di cambio fornitore?

Come minimo: repository completi con cronologia, intestazione degli account, credenziali sostituite, documentazione di infrastruttura e backup, runbook, una panoramica del backlog aperto e i documenti legali firmati su diritto d'autore e trattamento dei dati. Ogni voce deve avere un responsabile e un modo per verificare che sia conclusa.

Il codice scritto dalla vecchia agenzia è mio?

Non automaticamente. Secondo il diritto svizzero, il diritto d'autore su un software su misura non passa a te solo perché l'hai pagato o perché hai ricevuto il codice sorgente. Controlla se nel contratto c'è una cessione esplicita o una licenza d'uso, e fai confermare la situazione da un avvocato prima che il nuovo partner inizi.

E se il vecchio fornitore non collabora?

Parti da quello che impone il contratto: obblighi di consegna, termini di disdetta e consegna del codice. Metti in sicurezza gli account di cui sei direttamente titolare, come dominio e hosting, e lascia le questioni contestate al tuo avvocato. Chiedi al nuovo partner di fare prima un audit del codice, così sai che cosa manca prima di trattare.

Fonti

• Wicki Partners
• copyright in software is not automatically transferred to the commissioning party
• University of Geneva analysis of the ruling
• vendor handover checklist from Trio
• 90-day transition plan published by Howdy