Il costo reale di lavorare su più progetti in parallelo

La domanda più comune quando racconto come lavoro è questa: come riesci a tenere in testa sette progetti in parallelo?

La risposta onesta è che non li tengo in testa. Li tengo su file.

Schedy, ISPCore, MARCØ, QTF, WheelBot, diet-manager, Relink. Più il ruolo di COO in una telco satellitare, un account di trading attivo su CopyFX, e mio figlio di un anno. Non è un vanto. È il contesto in cui ho dovuto trovare un sistema che funzionasse, perché quelli che avevo usato fino a quel momento non bastavano più.

Per anni ho creduto al focus profondo come soluzione. Un progetto al giorno, blocchi di tre ore senza interruzioni, calendario blindato. Funziona bene quando hai un solo problema complesso. Scala male quando ne hai sette.

Il problema concreto è questo: un progetto fermo una settimana perde contesto. Rientrare su un codebase che non tocchi da dieci giorni richiede venti minuti se sei fortunato, due ore se non lo sei. In una settimana hai sei o sette rientri del genere. Hai bruciato mezza giornata solo a ricostruire stato mentale.

Quella non è produttività. È perdita di tempo con uno strato di disciplina sopra.

La distinzione che cambia tutto

C’è una distinzione che la maggior parte delle guide sulla produttività non fa mai, e che per me ha cambiato tutto.

Context switching e context rebuilding non sono la stessa cosa.

Context switching è passare dal progetto A al progetto B. Se i materiali sono già lì davanti, un minuto, forse due. Il cervello umano gestisce bene la commutazione quando non deve ricostruire niente.

Context rebuilding è tornare al progetto A dopo due settimane. Rileggere il codice per capire perché quella decisione architetturale sembrava sensata. Cercare nei file di note una scelta che ricordi vagamente di aver preso ma non sai dove hai documentato. Ricostruire lo stato del sistema nella testa prima di poter fare qualcosa di utile.

Questo è quello che costa. Non lo switch in sé.

Ho smesso di ottimizzare per evitare lo switch. Ho iniziato a ottimizzare per rendere il rientro il più veloce possibile.

I quattro file

La soluzione pratica sono quattro file presenti in ogni repo, con lo stesso nome e la stessa struttura in tutti i miei progetti.

CLAUDE.md contiene l’identità del progetto. Cosa sto costruendo, perché, qual è lo stack, quali sono i vincoli architetturali non negoziabili, qual è il prossimo obiettivo. È il file che apro io e che apre l’AI di coding quando entro in una sessione. Senza leggerlo non si tocca niente.

DEPS.yaml è la mappa delle dipendenze interne. Ogni modulo dichiara cosa possiede, cosa impatta se cambia, e quali eventi costituiscono un breaking change. Quando faccio l’impact analysis prima di una modifica, leggo questo file. Se un modulo è marcato come frozen, devo esplicitamente confermare prima di toccarlo.

STATUS.md è lo stato attuale del progetto. Cosa funziona, cosa è in lavorazione, dove sono fermo, quali sono i rischi aperti. Aggiornato a fine di ogni sessione di lavoro. È il file che leggo per prima cosa quando riapro un progetto. Se è aggiornato correttamente, mi serve cinque minuti per rientrare operativo.

FROZEN.md elenca i moduli che non si toccano. Ogni codebase maturo ha parti che funzionano bene e vanno lasciate in pace. Senza questa documentazione esplicita, ogni nuova sessione rischia di entrare in zone stabili per curiosità o per errore, introducendo regressioni.

Insieme questi quattro file sono la memoria esterna di un progetto. Non vivono nella mia testa. Vivono nel repo, disponibili in ogni momento, sia per me sia per gli strumenti di coding che uso.

Il protocollo a sei gate

Sopra ai file ho un protocollo che applico in modo identico a ogni progetto, indipendentemente dalla tecnologia o dallo stato di avanzamento.

Gate 0 — Impact analysis. Prima di toccare qualunque cosa, dichiaro cosa voglio fare e leggo DEPS.yaml per capire cosa potrebbe essere impattato. Se un modulo è frozen, mi fermo e chiedo conferma a me stesso se vale davvero la pena toccarlo.

Gate 1 — Lettura. Leggo STATUS.md, leggo le ultime decisioni prese, leggo il codice rilevante. Non si scrive niente prima di aver letto.

Gate 2 — Piano. Definisco in modo esplicito cosa cambierà e in quale ordine. Il piano va dichiarato prima di iniziare, non mentre si è già a metà.

Gate 3 — Implementazione. Solo qui si scrive codice. E si scrive solo quello che il piano prevede. Se durante l’implementazione emerge qualcosa di inatteso che non era nel piano, ci si ferma, si torna al Gate 2, si aggiorna il piano.

Gate 4 — Verifica. Test, build, smoke check. Niente deploy senza Gate 4.

Gate 5 — Handoff. Si aggiorna STATUS.md, si controllano DEPS.yaml e FROZEN.md, si lascia il progetto in uno stato leggibile per la prossima sessione. Il Gate 5 saltato è la principale causa di rientri lenti.

Questo protocollo dura più di qualunque singolo progetto. Lo ho raffinato in diciotto mesi di lavoro su sistemi diversi. Adesso è la cosa più stabile di come lavoro.

Stesso metodo, codice diverso

C’è un errore che ho quasi fatto e che mi è stato tentante a lungo.

Costruire una piattaforma comune sotto i miei progetti. Una sorta di “sistema operativo interno” che condividesse librerie, componenti, servizi di base tra tutti i miei prodotti. Sulla carta sembrava efficiente. Meno duplicazione, meno manutenzione.

Non funziona. L’ho tentato parzialmente e ho capito subito perché.

Aggiunge una dimensione di manutenzione in più — la piattaforma comune diventa un progetto a sé, con i suoi bug e le sue breaking change. Blocca la sperimentazione — se Schedy vuole provare una libreria nuova, non può farlo senza rischiare di impattare ISPCore o MARCØ. Crea accoppiamento che non si vede — due progetti sembrano indipendenti, ma sotto usano la stessa funzione, e quando modifichi la funzione per le esigenze di uno, l’altro si rompe in modo sottile.

Il principio che funziona è il contrario:

Stesso metodo, codice diverso, deploy isolati. La condivisione avviene a livello di processo e di file di scheletro, non di artefatti tecnici.

Ogni progetto può usare lo stack che ha senso per quel dominio. Schedy usa whatsapp-web.js e Baileys. ISPCore usa Bun e Hono. QTF è Python puro. Non condividono una riga di codice tra loro. Ma condividono lo stesso modo di documentarsi, lo stesso protocollo di sessione, gli stessi quattro file.

Tre cose che ne derivano

Investi nel ritorno, non nella disciplina dello switch. Il vero costo non è passare da un progetto all’altro. Il vero costo è rientrare su un progetto che non hai documentato bene. Ogni minuto investito nel Gate 5 finale di una sessione si ripaga nella prossima sessione di quel progetto.

Standardizza il metodo, lascia libero il codice. La condivisione che funziona è quella di processo. Il codice deve restare libero di divergere perché ogni dominio ha vincoli diversi.

Una nuova sessione di coding deve poter iniziare in cinque minuti. Se ci vuole mezz’ora per orientarsi, il problema non è la tua concentrazione. È che il sistema non ha la memoria che dovrebbe avere.