Agenda del team di sviluppo

Il nostro team di sviluppo è piccolo: io e una collega che sviluppa con me, e due in direzione che hanno bisogno di vedere cosa sta succedendo. Quattro persone, ruoli profondamente diversi. Prima di questo strumento usavamo ClickUp.

Il problema non era ClickUp in sé. Il problema era che servivano due cose insieme, di norma in conflitto. Per chi scrive codice serve uno strumento granulare: progetti che si articolano in fasi, fasi in obiettivi, obiettivi in task, task in checklist, e ogni task con materiali, documenti, attori, scadenze, priorità, ore stimate. Per la direzione serve vedere tutto senza poter rompere niente — un report sempre aggiornato, leggibile, con la possibilità di commentare e proporre modifiche, senza il rischio che un click sbagliato cancelli ore di pianificazione.

In uno strumento generico queste due esigenze si pestano i piedi: o dai a tutti i permessi di scrivere (e prima o poi qualcosa si rompe), o tieni la direzione fuori (e perde visibilità su cosa sta facendo davvero il team).

Oggi il sistema traccia il lavoro su quattro livelli: progetti, fasi, obiettivi, task. Ogni task porta con sé checklist, materiali, documenti, attori e commenti. Una ventina di progetti aperti, dai bandi UE alle iniziative interne, dalle infrastrutture alle compliance — tutti dentro lo stesso modello.

I quattro ruoli vivono dentro lo stesso sistema, su un viewer-web condiviso, sempre aggiornato. Tutti leggono tutto: la lavagna dei progetti, l'impegno settimanale e mensile, il calendario, i task per persona, il briefing del giorno (cosa scade, cosa brucia). La direzione commenta su qualsiasi nodo dell'albero e, quando vuole spostare una scadenza o cambiare una priorità, lo propone da una pagina mobile-first: la proposta entra in una coda di richieste, noi la rivediamo, e l'approvazione o il rifiuto lascia un commento automatico sul task per chi vuole leggere la storia dopo.

Per il lavoro quotidiano l'app basta: focalizzo le priorità, chiudo task, leggo i grafici di capacità. Per i lavori grossi uso Claude Code in sessione: descrivo a voce o a tastiera un problema operativo intero ("organizza il montaggio dei tavoli per la cena di sabato, materiale dal magazzino C, delegato a un operaio, scadenza venerdì sera"), l'assistente costruisce la lista di modifiche, io confermo prima che tocchi il database, e una decina di task entrano nel sistema in un solo prompt — o in pochi. Esporto un PDF della lista task da consegnare a chi non ha accesso al sistema (un fornitore esterno, un consulente, un operaio). Rivedo lo stato di tutti i progetti in fine giornata con un solo comando, dalla stessa sessione in cui li ho creati la mattina. Mi permette di essere organizzato e preciso, e — soprattutto — è lo strumento di pianificazione con cui definiamo le priorità aziendali.

Tra i progetti del portfolio, questo è il più ricorsivo: l'IA è stata lo strumento con cui ho costruito il sistema, ed è anche lo strumento con cui ogni giorno lo uso. Il viewer-web Next.js, lo schema Postgres con sicurezza riga-per-riga, le sette skill di Claude Code che parlano col database — tutto scritto in sessione, decisione per decisione, commit per commit, ADR per ADR. Più di sessanta decisioni architetturali tracciate, ciascuna col suo perché scritto al momento.

Il metodo di lavoro è semplice e ripetitivo: a inizio sessione un breve brainstorming, un plan se la cosa è grossa, implementazione test-first sui pezzi che lo meritano, verifica visiva live nel browser, commit, e a fine sessione un log di cosa è successo. Le sette skill di Claude Code che parlano col database hanno un sistema di eval che si migliora da solo: se una skill scende sotto il 90% di qualità, un ciclo automatico la riscrive e la rivaluta fino a tre volte. L'IA non è una mano che esegue alla cieca: produce sostanza durevole solo se chi la usa le mette accanto un processo di lavoro disciplinato.

L'IA non scrive mai sul database senza una mia conferma. È la regola architetturale del progetto, applicata senza eccezioni.

Ogni modifica passa per la stessa pipeline. Descrivo a voce o a tastiera quello che voglio fare, l'IA legge lo stato attuale del sistema, costruisce la lista esatta di operazioni che applicherebbe, e me la mostra come una tabella di riepilogo: cosa cambia, su quale task, da quale stato a quale stato. Solo dopo un "sì" esplicito la lista viene applicata. Nessun automatismo che parta da una mia frase ambigua; nessun "applica direttamente" anche per modifiche piccole.

Il compromesso accettato è chiaro: ogni operazione mi costa una conferma in più. In cambio, in un mese di uso quotidiano sui dati aziendali reali del team, nessun dato è stato corrotto da un'interpretazione sbagliata dell'IA. E se ho confermato qualcosa che poi mi accorgo essere sbagliato, ogni batch viene salvato su file: un solo comando annulla l'ultima operazione e mi riporta allo stato precedente.

Oggi l'agenda è lo strumento operativo del team di sviluppo. Tutti e quattro vi entriamo ogni giorno, da telefono o da computer: i progetti aperti sono una ventina e ci girano dentro decine di task ogni settimana, fra creazioni nuove, scadenze che si spostano, deleghe che cambiano. ClickUp non si è più riaperto.

Il numero che racconta meglio il valore tecnico arriva da una singola migrazione del database. Prima della migrazione, le ore stimate di un task delegato a un collaboratore esterno (un fornitore, un consulente, un operaio) pesavano per intero sul carico del team che delegava — anche se l'esecuzione era altrove. Conseguenza: il mio backlog risultava 786,5 ore, gran parte delle quali erano in realtà sulle spalle di qualcun altro. Distinguere "ore mie" da "ore di supervisione" ha portato il backlog reale a 523,1 ore: −33,5% in una notte. Quelle 263 ore non sono sparite, sono tornate dove erano davvero. Il sistema non ha cambiato il lavoro: ha smesso di rappresentarlo male.

Lo stesso pattern in piccolo: in un controllo successivo, un indicatore di utilizzo della capacità gonfiato del 15-20% nel filtro per persona è stato corretto con la modifica di una sola riga, sostenuta da quattro nuovi test. Micro-eventi che raccontano il punto: i numeri veri permettono al team di prendere decisioni di priorità su una mappa fedele del lavoro.

Il prossimo passo è già a vista: l'agenda nasce per il team di sviluppo, ma il modello dati e la sicurezza riga-per-riga sono pronti a scalare. Verrà ampliata a tutto il team aziendale come strumento di gestione e affidamento dei compiti, con diversi livelli di scope — ciascuno vede e modifica solo quello che gli compete. Lo strumento che oggi pianifica il lavoro dello sviluppo, domani pianificherà il lavoro dell'azienda.