Gestire molti progetti attivi: il metodo di organizzazione di un consulente senior

Tenere molti progetti attivi contemporaneamente senza far cadere nulla è una delle competenze più sottovalutate di un consulente senior, e la cosa importante da capire è che è proprio una competenza, non un talento: non si tratta di avere una memoria prodigiosa, si tratta di avere un metodo. Nel mio lavoro alterno la delivery su un numero alto di codebase e clienti diversi, e ho imparato a mie spese che l'unico approccio che regge è smettere di affidarsi alla testa. La memoria umana è inaffidabile, non sopravvive a una settimana di stacco su un progetto e crolla sotto il cambio di contesto continuo: il dettaglio che "tanto mi ricordo" è esattamente quello che si perde. Il metodo che uso ribalta questo: lo stato dei progetti vive su file, non nella mia testa, il contesto si ricostruisce in fretta a ogni rientro, le priorità si rivedono con cadenza invece che a reazione, e gli strumenti AI reggono una parte del carico cognitivo. Vediamo come, in pratica, perché è un sistema replicabile da chiunque gestisca più cose insieme.

Lo stato va su file, non in testa

Il principio fondante è questo: lo stato di un progetto non si tiene a mente, si esternalizza su file. Per ogni progetto attivo tengo dei file che descrivono dove sono arrivato, cosa è in sospeso, quali decisioni ho preso e perché, quali sono le trappole note. Non è burocrazia, è la condizione per poter avere più di tre progetti in parallelo senza che il quarto inizi a sgretolarsi. Il filesystem diventa la fonte di verità, e la mia testa si libera dal compito impossibile di tenere tutto caricato insieme.

La memoria umana è una RAM volatile: veloce ma piccola, e si svuota a ogni riavvio, cioè a ogni notte di sonno o cambio di contesto. Lo stato di un progetto va scritto su disco, non tenuto in RAM, perché è l'unico modo perché sopravviva al fatto che tu, prima o poi, penserai ad altro.

La forma concreta è semplice e volutamente a bassa tecnologia: un file di stato per progetto, in testo o markdown, con l'attività in corso, i prossimi passi, i nodi aperti. La struttura più rigida, come i risultati dei test o lo stato di avanzamento, sta in file dedicati; le note libere e i pensieri di passaggio in un file di appunti. Il punto non è lo strumento, è la disciplina di scrivere lo stato fuori, ogni volta che lascio un progetto, così che ritrovarlo non dipenda dal mio ricordo. Un sistema che dipende dalla memoria di una persona è un sistema che fallisce il giorno in cui quella persona è stanca, malata o semplicemente concentrata su altro.

Il contesto ricostruibile in fretta a ogni rientro

Il vero costo del multi-progetto non è fare il lavoro, è il cold start: il tempo che ci metti a rientrare in un progetto che hai lasciato giorni o settimane fa, a ricaricare in testa dov'eri, cosa stavi facendo, perché avevi preso una certa strada. Senza un sistema, ogni rientro è mezz'ora persa a ricostruire il contesto rileggendo codice e diff; con un buon file di stato, la stessa ricostruzione richiede due minuti, perché il "me stesso del passato" ha lasciato al "me stesso del futuro" esattamente le informazioni che servono.

Per questo il file di stato non è scritto per documentare il progetto in generale, è scritto per il mio rientro: la prima riga risponde alla domanda "cosa stavo facendo e qual è il prossimo passo", non a "cos'è questo progetto". È una differenza sottile ma decisiva. Quando rientro, leggo quella riga e sono operativo, invece di dover ricostruire tutto da zero. Moltiplicato per molti progetti e molti rientri a settimana, questo è il margine che separa chi gestisce dieci cose con calma da chi ne gestisce tre nel panico.

Se gestisci un'attività di consulenza o un team che lavora su più fronti e vuoi capire come strutturare un metodo che regga il carico, nel mio profilo professionale trovi l'esperienza concreta di chi alterna delivery su molte codebase senza perdere il filo di nessuna.

Le priorità riviste con cadenza, non a reazione

Il terzo pilastro è la gestione delle priorità, ed è quello dove cade chi lavora "a chi grida più forte". Le priorità decadono: quella che era urgente lunedì può non esserlo giovedì, e nuove cose arrivano di continuo. Se le riordini solo quando qualcuno ti chiama, stai lasciando che sia il cliente più rumoroso, non quello più importante, a decidere la tua giornata. Il rimedio è una revisione a cadenza fissa, tipicamente settimanale, in cui guardo tutti i progetti insieme e decido, a freddo, l'ordine reale, distinguendo l'urgente dall'importante.

La pratica concreta è tenere una sola lista prioritizzata che attraversa tutti i progetti, non una lista per progetto che mi costringerebbe a fare il confronto a mente ogni volta. Una lista unica mi obbliga a rispondere alla domanda vera: tra tutte le cose che potrei fare ora, su tutti i clienti, qual è quella che conta di più? Decidere questo una volta a freddo, e poi seguirlo, è infinitamente più efficace che deciderlo cento volte al giorno sotto la pressione dell'ultima email arrivata.

Nella revisione settimanale faccio anche una cosa che sembra banale ma che evita la maggior parte delle palle perse: scorro ogni progetto e mi chiedo "c'è qualcosa che sta scadendo o che blocca qualcun altro?". Le cose che fanno arrabbiare i clienti raramente sono quelle complesse, sono quelle dimenticate: una risposta che aspettavano, un blocco che tenevano fermo loro, una scadenza scivolata via. Una passata settimanale con questa domanda in testa intercetta gli elementi a rischio mentre sono ancora gestibili, invece di scoprirli quando sono già diventati un problema. È un controllo di dieci minuti che vale, in serenità del rapporto con il cliente, molto più del tempo che costa.

Il carico cognitivo e il ruolo degli strumenti AI

Qui entra in gioco la tecnologia, e in particolare gli strumenti basati su LLM, che uso esattamente come una protesi cognitiva, non come un sostituto del metodo. Un assistente AI è bravissimo a riassumere dove un progetto si era fermato leggendo i file di stato e i diff recenti, a rileggere una decisione che avevo annotato, a darmi un riepilogo che accelera il cold start. Offload il contesto su file, e l'AI mi aiuta a riassorbirlo in fretta quando rientro. È una capacità che si lega direttamente a come imposto l'ambiente di lavoro, descritta parlando del setup di Claude Code in produzione per uno sviluppatore PHP senior.

Ma attenzione al rovescio, perché è dove molti si illudono: l'AI amplifica un buon sistema, non lo crea. Se lo stato non è scritto da nessuna parte, l'assistente non ha nulla da riassumere, e l'illusione di delegargli la memoria del progetto si infrange al primo dettaglio che non avevi annotato. C'è anche un rischio più sottile, quello di delegare la comprensione e non solo il ricordo, accumulando quello che ho chiamato il debito di comprensione nell'uso dell'AI sul codice: l'AI può ricostruirti il contesto, ma la responsabilità delle decisioni resta tua, e fidarti ciecamente del suo riassunto senza verificarlo è un modo per perdere il controllo dei tuoi stessi progetti. L'AI regge il carico cognitivo di basso livello; il giudizio resta umano.

I commit come stato, non solo come codice

Un'abitudine che integro nel metodo è trattare i commit git come marcatori di stato, non solo come salvataggi di codice. Una cronologia di commit piccoli e frequenti, con messaggi descrittivi, è di fatto un diario leggibile del progetto: rientrando, il git log mi racconta cosa è successo nelle ultime sessioni meglio di qualunque memoria. È una pratica che la documentazione ufficiale di Git tratta come igiene di base, e che nel multi-progetto diventa una rete di sicurezza: ogni commit è un checkpoint da cui posso ripartire, e una storia pulita è metà del contesto già pronto. Quando lavoro con assistenti AI, questo vale doppio, perché un commit frequente lascia una traccia da cui ricostruire lo stato anche dopo aver azzerato la sessione, e l'ho applicato anche progettando agenti che analizzano una codebase legacy.

Il rituale di chiusura: come lascio un progetto

Il pezzo del metodo che fa la differenza più grande, e che quasi nessuno applica, è il rituale di chiusura di una sessione di lavoro. Non lascio mai un progetto "così com'è" quando passo ad altro, perché interrompersi nel mezzo senza lasciare una traccia significa condannare il futuro me a ricostruire tutto da capo. Prima di chiudere, dedico due o tre minuti a un gesto preciso: aggiorno il file di stato con dove sono arrivato e qual è il prossimo passo concreto, faccio un commit anche del lavoro incompleto se serve a non perdere il filo, e scrivo, in una sola riga, la prima cosa che dovrò fare al rientro.

Quella riga finale è la cosa più preziosa del rituale, perché trasforma il rientro da una decisione in un'esecuzione. Quando torno, non devo chiedermi "e adesso cosa faccio qui?", il me stesso del passato me l'ha già detto: "rientra da qui, fai questo". È la differenza tra ripartire da fermo in salita e ripartire con la marcia già innestata. Il rituale costa pochi minuti alla fine di ogni sessione e ne fa risparmiare molti di più al rientro successivo, con un ritorno sull'investimento enorme e immediato.

C'è anche un beneficio psicologico che non va sottovalutato: chiudere bene una sessione mi permette di staccare davvero. Quando so che lo stato è scritto e che il prossimo passo è annotato, la mia testa smette di tenere in background quel progetto, perché non ha più paura di dimenticare qualcosa. La mente scarica non è solo più efficiente, è anche meno stanca, e in un lavoro che alterna molti fronti la stanchezza da contesto sempre acceso è uno dei costi nascosti più alti.

Si possono davvero gestire dieci progetti contemporaneamente?

La risposta onesta è: non in testa, mai; con un sistema, sì. Il limite reale non è il numero di progetti, è quanto provi a tenere in memoria. Chi tenta di gestire dieci progetti ricordandoseli ne gestisce bene due e fa cadere gli altri otto a rotazione; chi esternalizza lo stato, ricostruisce il contesto in fretta e prioritizza a freddo può tenerne molti senza panico, perché in ogni istante la mente lavora su uno solo, e gli altri nove aspettano pazienti nei loro file, esattamente dove li ha lasciati. Il segreto non è una mente più capiente, è una mente più scarica.

L'errore che fa cadere le cose: fidarsi della memoria

Vale la pena nominare il singolo punto di rottura, perché è sempre lo stesso. La palla cade quando ti fidi della tua testa, e la cosa che cade è sempre quella che "tanto ti ricordavi". Non è un problema di impegno o di intelligenza, è un problema di architettura: un sistema che dipende dalla memoria umana è progettato per fallire, perché la memoria umana non è fatta per quello. La soluzione non è "stare più attento" o "ricordarsi meglio", che sono rimedi eroici e quindi inaffidabili, è sistemica: scrivere lo stato fuori, sempre, così che ricordarsi non sia più necessario. La differenza tra un consulente che sembra avere tutto sotto controllo e uno che corre dietro alle emergenze non è la memoria, è il sistema che gli permette di non averne bisogno.

Tirando le somme, gestire molti progetti attivi senza far cadere nulla è un'abilità appresa, costruita su un'idea semplice e potente: non fidarsi della propria testa. Lo stato vive su file, così libera la mente e sopravvive al tempo; il contesto si scrive per il proprio rientro, così il cold start dura due minuti invece di trenta; le priorità si rivedono a cadenza e a freddo, così a comandare è l'importanza e non il rumore; gli strumenti AI reggono il carico cognitivo di basso livello, ma amplificano un buon sistema invece di crearlo; e i commit fanno da diario e da checkpoint. È un metodo poco spettacolare e molto efficace, e la sua forza è proprio nell'essere noioso e ripetibile, perché l'affidabilità nel multi-progetto non nasce dall'eroismo, nasce dal togliere all'eroismo ogni occasione di servire. Se gestisci più progetti o un team che lo fa, e ti accorgi di perdere contesto o di far cadere cose tra una priorità e l'altra, contattami per una consulenza diretta: nella mia esperienza, il problema non è quasi mai la quantità di lavoro in sé, è l'assenza di un sistema che lo regga al posto della memoria umana.