I compiti dimenticati non sono un problema umano
Perché i compiti dimenticati nella gestione dei progetti non riguardano la disciplina – e quando il tuo team ha davvero bisogno di un sistema per gestirli.
By Ellis Keane · 2026-03-17
Se il tuo team è abbastanza piccolo da pranzare insieme (o almeno potrebbe farlo, ipoteticamente, se si trovasse mai nella stessa città nello stesso momento), probabilmente non hai bisogno di leggere questo. Chiudi la scheda. Vai a costruire qualcosa. Il problema dei compiti dimenticati alla tua scala è a un messaggio di Slack il mercoledì pomeriggio dall'essere risolto – e lo dico sinceramente.
Sei ancora qui? Bene. Parliamo allora dei compiti dimenticati nella gestione dei progetti – e più precisamente di perché il consiglio standard smette di funzionare quando il team raggiunge una certa dimensione.
Prima di andare avanti
Stiamo costruendo uno strumento che affronta questo problema (Sugarbug – mentirei se fingessi il contrario), ma la risposta onesta è che la maggior parte dei team che legge questo non ha ancora bisogno di ciò che stiamo costruendo. Forse mai. Ciò di cui ha bisogno è capire perché i compiti vengono dimenticati in primo luogo, perché la soluzione dipende dalla causa – e la causa non è quasi mai quella che le persone pensano.
Perché i compiti vengono dimenticati
Chiedi alla maggior parte dei manager perché i compiti vengono dimenticati e sentirai una lista familiare: qualcuno ha dimenticato, qualcuno non ha prestato attenzione, qualcuno non ha seguito il processo. La soluzione, quindi, sono processi migliori, più promemoria, forse un bot standup che punge le persone ogni mattina.
E sì, a volte è genuinamente questo il problema. Se il tuo sviluppatore ha dimenticato di aggiornare il ticket Linear e il PM non ha verificato prima della sprint review, è una svista umana e un vuoto di processo. Aggiungi una checklist. Vai avanti.
Ma non è questo il tipo di compito dimenticato che tiene svegli gli engineering manager. Quello che fa davvero male è quello in cui tutti hanno fatto il loro lavoro, hanno seguito il loro processo, aggiornato i loro strumenti – e qualcosa è comunque caduto nel vuoto. Perché il vuoto non è tra una persona e il suo compito. È tra uno strumento e un altro.
Ecco cosa intendo. Uno sviluppatore invia una PR che chiude un issue di GitHub. L'issue era collegato a un ticket Linear, e il ticket passa a "Done". Bene. Solo che la richiesta originale proveniva da una conversazione Slack tre settimane fa in cui il PM aveva anche menzionato un requisito di follow-up che nessuno ha mai registrato come attività separata. Quel follow-up vive in un thread Slack di febbraio. Non è in Linear. Non è in GitHub. Non è nello sprint di nessuno. Tecnicamente è un compito dimenticato, ma nessuna singola persona lo ha lasciato cadere – è caduto attraverso il vuoto strutturale tra Slack e il task tracker.
Questo schema appare ovunque una volta che inizi a notarlo. Un designer lascia un commento su Figma segnalando che un edge case contraddice il spec su Notion, ma lo sviluppatore che lavora sulla funzionalità non controlla mai Figma e il PM non vede mai il commento perché vive in Linear. Un responsabile customer success promette una funzionalità in una chiamata, la riassume in un'email, e non arriva mai al backlog di engineering perché nessuno fa il ponte su quel particolare vuoto. Un post-mortem di incidente identifica tre punti di follow-up, il documento viene condiviso su Slack, e due dei tre non diventano mai attività tracciate perché la persona che di solito lo fa era malata quella settimana.
I compiti dimenticati più dannosi nella gestione dei progetti avvengono nei vuoti tra gli strumenti, non nei vuoti tra le persone e le loro liste di attività.
La soluzione di processo (e dove smette di funzionare)
Credo sinceramente che i buoni processi risolvano la maggior parte di questi problemi per la maggior parte dei team. Ecco cosa funziona, e lo condivido senza secondi fini perché (per essere onesti) siamo in pre-lancio e la cosa migliore che possiamo fare ora è costruire fiducia essendo utili.
La revisione settimanale. Una persona – idealmente il PM o l'engineering lead – trascorre 30 minuti ogni venerdì a passare in rassegna thread Slack, note delle riunioni ed email per intercettare tutto ciò che è stato discusso ma mai tracciato. Noioso? Assolutamente. Efficace? Sorprendentemente sì, fino a un certo punto.
Il registro delle decisioni. Ogni decisione che emerge da un thread Slack o da una riunione viene incollata in un documento condiviso (Notion, Google Docs, non importa) con la data, chi ha deciso e qual è il follow-up. Sembra semplice, e lo è – finché non stai prendendo quindici decisioni a settimana su quattro canali e nessuno ricorda quali siano state registrate.
La disciplina dei collegamenti. Ogni PR referenzia il suo ticket Linear. Ogni ticket Linear collega al thread Slack dove il requisito è stato discusso. Ogni spec Notion collega al suo epic Linear. Se qualcuno rompe la catena – e qualcuno lo farà, non è questione di se ma di quando –, la visibilità si rompe con essa.
Sono tutte buone pratiche. Noi stessi ne usiamo versioni di tutte e tre. Ma hanno una modalità di fallimento comune: dipendono dal fatto che gli esseri umani facciano in modo costante una piccola, noiosa cosa ogni volta, per sempre. E la ricerca su questo non è incoraggiante – non ho nemmeno bisogno di citarla. Se hai gestito un team di più di cinque persone, lo sai già.
Quando la soluzione di processo smette di scalare
Esiste una soglia, e vorrei poter darti un numero esatto, ma non l'abbiamo ancora determinato (onestamente, varia probabilmente per team e per quanto disciplinati siano i suoi membri). La nostra euristica di lavoro – e voglio essere chiaro che è un'euristica, non dati di riferimento – è che le cose iniziano a rompersi da qualche parte intorno a quattro o cinque strumenti, più di dieci persone e più flussi di lavoro paralleli.
Non perché qualcuno sia diventato pigro. Non perché il processo fosse sbagliato. Ma perché il volume di connessioni tra strumenti supera la capacità di qualsiasi singola persona di tracciarle manualmente. La revisione settimanale richiede 90 minuti anziché 30, e il PM inizia a scorrere velocemente. Il registro delle decisioni diventa obsoleto perché la persona che lo manteneva era in vacanza e nessuno l'ha raccolto. La disciplina dei collegamenti regge per Linear e GitHub ma si sgretola per Slack e Figma perché quegli strumenti non hanno lo stesso tipo di riferimenti strutturati.
Questo è – e voglio essere chiaro – un problema di scala, non un problema di disciplina. Ho visto PM ed engineering lead genuinamente eccellenti lottare con questo – persone che gestiscono operazioni precise e si preoccupano profondamente che nulla cada nelle crepe. A una certa scala, il problema supera la soluzione. Non è un fallimento della persona – è un fallimento dell'ecosistema di strumenti nel fornire connessioni tra sé stesso.
"La ricompensa per essere sofisticato nell'uso degli strumenti è una superficie di guasto più complessa per i compiti dimenticati. Lo trovo profondamente ironico." – Ellis Keane
E qui sta la parte che ritengo genuinamente ingiusta: più il tuo team è bravo nell'uso dei propri strumenti, maggiore è la superficie esposta ai vuoti tra strumenti. Un team che usa Linear religiosamente, mantiene aggiornati gli spec su Notion, ha revisioni attive su Figma e comunica in canali Slack ben organizzati ha più punti di passaggio di un team che usa solo email e un foglio di calcolo.
Perché i tuoi strumenti non possono aiutare
Ecco ciò che trovo genuinamente interessante in tutto questo problema, e che credo non venga discusso abbastanza: i tuoi strumenti stanno facendo esattamente ciò per cui sono stati progettati. Linear è eccellente nel tracciare issue Linear. GitHub è eccellente nel tracciare modifiche al codice. Notion è eccellente nell'organizzare documenti. Slack è eccellente nell'essere... Slack (nel bene e nel male).
Ma nessuno di essi è stato progettato per tracciare le connessioni tra di loro. E il lavoro, il lavoro vero, non avviene all'interno di un singolo strumento – fluisce attraverso tutti. I punti di passaggio tra gli strumenti sono dove le cose scompaiono, e nessuna quantità di miglioramento di un singolo strumento risolve questo. Puoi rendere Linear migliore nel tracciare issue, ma questo non aiuta quando l'issue avrebbe dovuto essere creato in primo luogo sulla base di una conversazione Slack avvenuta in un canale che l'engineering lead non monitora.
Cosa risolverebbe davvero il problema
Sono stato deliberatamente vago sulle questioni di prodotto in questo articolo, e questo è intenzionale – volevo che fosse utile che tu usi o meno qualcosa di ciò che costruiamo. Ma dal momento che sei arrivato fin qui (e lo apprezzo), lasciami essere onesto su come penso che sia la vera soluzione.
Non è un task tracker migliore. Non è un processo migliore. Non è un bot standup, una revisione settimanale o un foglio di calcolo condiviso. Tutto questo aiuta, e su piccola scala è sufficiente – ma tutti trattano il sintomo.
La vera soluzione è qualcosa che osserva le connessioni tra i tuoi strumenti e segnala quando qualcosa non torna. Quando una decisione Slack non diventa un ticket. Quando una PR GitHub chiude un issue ma ci sono commenti irrisolti. Quando un spec Notion fa riferimento a un requisito che è stato deprioritizzato in una conversazione che l'autore del spec non ha mai visto.
Per renderlo concreto: diciamo che il tuo sistema monitora sia Slack che Linear. Vede una conversazione in #engineering dove qualcuno dice "dovremmo anche gestire il caso in cui l'utente non ha verificato la sua email" – è un nuovo requisito. Se quel requisito non compare come ticket Linear entro, diciamo, 48 ore, il sistema lo segnala. Non con una notifica che ti urla addosso (nessuno ne ha bisogno di altre), ma come voce in una vista "decisioni non ancora tracciate" che il PM può consultare durante la sua revisione del venerdì. Stesso principio per le PR GitHub che chiudono ticket Linear ma hanno ancora commenti di revisione aperti, o per spec Notion che fanno riferimento a funzionalità che sono state deprioritizzate da quando il spec è stato scritto.
Che tu lo costruisca internamente (alcuni team lo fanno, con webhook, una coda di messaggi e un po' di codice collante), usi qualcosa di già disponibile, o accetti semplicemente i compiti dimenticati come costo operativo – questa è la tua decisione. Stiamo costruendo una versione di questa risposta, ma non è l'unica versione, e per molti team non è ancora quella giusta.
Se vuoi sapere quando potrebbe esserlo per te, ecco la mia euristica onesta: se la tua revisione settimanale richiede più di 30 minuti e le cose continuano a cadere nel vuoto, hai superato l'approccio manuale.
---
Quando la revisione settimanale richiede più di 30 minuti e le cose continuano a cadere nel vuoto, hai superato l'approccio manuale. Sugarbug monitora i vuoti automaticamente.
Q: Come previene Sugarbug i compiti dimenticati nella gestione dei progetti? A: Sugarbug costruisce un grafo della conoscenza attraverso i tuoi strumenti – Linear, GitHub, Slack, Figma, Notion – e traccia attività, conversazioni e decisioni mentre si spostano tra di essi. Quando qualcosa si blocca o perde il collegamento con la richiesta originale, Sugarbug lo porta in superficie prima che cada nel vuoto. Non è un sistema di promemoria – comprende le relazioni tra gli elementi nei vari strumenti e segnala quando tali relazioni si spezzano.
Q: Sugarbug riesce a intercettare le attività discusse su Slack ma mai registrate? A: Sì. Sugarbug monitora le conversazioni Slack e identifica quando una decisione o un punto d'azione viene discusso ma non appare mai come attività in Linear o ticket in GitHub. Segnala il vuoto affinché qualcuno possa intervenire. Stiamo ancora affinando quanto aggressivamente debba segnalare (nessuno vuole affaticamento da strumenti sopra tutto il resto), ma il rilevamento di base funziona.
Q: Ho bisogno di uno strumento per risolvere i compiti dimenticati, o è un problema di processo? A: Onestamente, dipende dalla scala. I team piccoli con due o tre strumenti di solito riescono a risolvere il problema con abitudini migliori – una revisione settimanale, un documento condiviso, una disciplina dei collegamenti. Ma una volta superati quattro o cinque strumenti e dieci o più persone, l'approccio manuale smette di scalare e serve qualcosa che tracci le connessioni automaticamente. La soglia varia per team, ma saprai quando l'hai raggiunta.
Q: Qual è la differenza tra un task tracker e un sistema di intelligence dei segnali per la gestione dei progetti? A: Un task tracker registra ciò che gli dici. Un sistema di intelligence dei segnali osserva ciò che sta accadendo davvero in tutti i tuoi strumenti e segnala quando qualcosa non torna – un'attività contrassegnata come completata ma con commenti irrisolti, una decisione presa su Slack ma mai riflessa nel spec. Intercetta le cose che gli esseri umani dimenticano di registrare, che, nella nostra esperienza, è dove la maggior parte di questi vuoti ha effettivamente origine.