Presa in carico del software: la checklist prima di accettare

Prima di accettare la responsabilità di un sistema costruito da altri, ispezionatelo. Questa è la checklist che AL+ usa per la presa in carico di un software. È scritta in modo che un fondatore, un CTO o un team in arrivo possano usarla anche senza di noi. Seguitela in ordine: le prime sezioni vi proteggono dai guasti che non si possono annullare.

La checklist ha otto parti. Ogni voce è una domanda con risposta sì o no. Un «no» non è un motivo per rifiutare il sistema. È una riga del piano.

1. Accessi e proprietà

Il guaio più comune nelle prese in carico è scoprire, dopo settimane, che un account critico appartiene a qualcuno che se n’è andato.

Il codice sorgente è in un repository di proprietà della vostra azienda, con i diritti di amministratore in mano alla vostra azienda?
Avete accesso da proprietari a hosting, DNS, registrar del dominio, database, object storage e CDN?
L’invio delle email, i fornitori di pagamento, le API di terze parti, gli account degli app store e il monitoraggio sono registrati con indirizzi aziendali, non personali?
Dove sono conservati i segreti, e potete ruotare ogni credenziale in mano al precedente sviluppatore senza interruzioni del servizio?
Quali account sono a pagamento, su quale carta, e quando scade o si rinnova ciascuno?
Ci sono licenze (font, librerie, postazioni SaaS, mappe) che scadranno quando verranno chiusi gli account del team precedente?

Se anche una sola risposta è «non lo sappiamo», fermatevi e scoprite la risposta prima di cambiare qualsiasi cosa.

2. La realtà della produzione

Il repository dice cosa era previsto. La produzione dice cosa è vero.

Cosa è in produzione adesso, da quale commit, e corrisponde al ramo principale?
Come viene rilasciato? A mano, con uno script, con una pipeline? Potete ripeterlo?
Cosa gira a intervalli programmati: cron job, code, funzioni pianificate, webhook? Dove sono configurati?
Quali servizi esterni chiama il sistema, e quali lo chiamano?
Cosa dicono i log e gli strumenti di tracciamento degli errori su ciò che fallisce in silenzio?
Quali ambienti esistono oltre alla produzione? C’è un ambiente di staging che le somiglia?

3. Dati

I dati sono la parte di un sistema che non si può rigenerare.

Dove vivono i dati: database, file, servizi di terze parti, fogli di calcolo?
Quanto sono grandi e quanto velocemente crescono?
Quando è stato fatto l’ultimo backup, e un backup è mai stato ripristinato altrove e verificato?
Quali dati personali sono conservati, con quale base giuridica, e dove è documentato?
Ci sono migrazioni in sospeso, applicate a metà o applicate a mano?
Potete esportare i dati in una forma che consenta di spostarli su un altro sistema?

Durante la revisione ripristinate un backup in un luogo sicuro. Un backup che non è mai stato ripristinato è una speranza, non un backup.

4. Sicurezza delle modifiche

Dovrete modificare il sistema. Scoprite quanto è pericoloso farlo.

Potete far girare il sistema su un computer di sviluppo usando solo il repository?
Ci sono test? Passano? Cosa coprono?
C’è una fase di revisione prima che il codice arrivi in produzione?
Un rilascio sbagliato si può annullare, ed è già successo?
Una modifica banale (un refuso nel footer) percorre l’intero percorso in meno di un giorno?

Se l’ultima risposta è no, sistemare quel percorso è il primo compito tecnico, prima di qualsiasi funzionalità.

5. Dipendenze e piattaforma

Quali sono le versioni di runtime, framework e database, e quando arriva a fine vita ciascuna?
Quante dipendenze ci sono, quanto sono vecchie e quali non sono più mantenute?
Qualcuna ha vulnerabilità note?
Quando è stato fatto l’ultimo aggiornamento, e cosa si è rotto?
C’è qualcosa bloccato a una versione per un motivo che nessuno ricorda?

6. Sicurezza di base

Non è un penetration test. È il minimo che dovete sapere prima di diventare proprietari del sistema.

L’autorizzazione è applicata sul server, o solo nell’interfaccia?
Ci sono segreti nel codice o nella cronologia del repository?
L’input dell’utente viene validato prima di arrivare al database o alla shell?
Chi ha accesso alla produzione, e l’accesso è individuale e revocabile?
Ci sono endpoint amministrativi, modalità di debug o credenziali predefinite ancora attivi?
Le comunicazioni sono cifrate ovunque, anche tra i servizi?

7. Conoscenza

Lo sviluppatore precedente è raggiungibile e disposto a rispondere alle domande, a pagamento?
Esiste una descrizione scritta dell’architettura, del deploy o dei motivi delle decisioni principali?
Quali parti del sistema non capisce nessuno, oggi?
Quali parti evitano tutti di toccare, e perché?
Quali incidenti ci sono stati nell’ultimo anno, e come sono stati risolti?

Fate domande sulle decisioni, non sul codice: perché questo database, perché questo hosting, cosa cambierebbero, di cosa avevano paura. Registrate le risposte.

8. Costi e adeguatezza

Quanto costa il sistema ogni mese in hosting, licenze e servizi di terze parti?
Quanto costa oggi in tempo di sviluppo per tenerlo in funzione?
Cosa richiede l’azienda da questo sistema nei prossimi dodici mesi?
Una parte rilevante serve un caso d’uso che non esiste più?
È un sistema da tenere, da modernizzare sul posto o da sostituire? La risposta viene dalle sette sezioni precedenti, non dal primo incontro.

Come usare il risultato

Scrivete le risposte in un unico documento, con un elenco dei «no» ordinato per rischio. L’ordine diventa le prime settimane di lavoro: prima accessi e fatturazione, poi backup e deploy, poi le parti fragili, poi quelle desiderate. Una presa in carico fatta in questo ordine mostra all’azienda una nuova funzionalità più tardi di quanto sperasse e un’interruzione del servizio mai.

Se preferite che siamo noi a eseguire questa revisione e a prendere in carico il sistema in seguito, è proprio ciò che fa il nostro servizio di presa in carico del software. Se volete eseguirla da soli, la checklist è vostra.