Perso in Slack: cercabile non significa trovabile
Il tuo team ha troppi canali Slack e non trova nulla. Perché la ricerca da sola non basta – e cosa funziona davvero.
By Ellis Keane · 2026-03-17
Quanti canali Slack ha il tuo team in questo momento? Non il numero nella barra laterale, perché ne hai silenziato la maggior parte. Il numero reale, compresi quelli che qualcuno ha creato per un progetto terminato sei mesi fa, quelli con nomi così simili da non sapere mai quale sia quello giusto, e la manciata di canali in cui accadono cose genuinamente importanti che non ritroverai mai più perché non sapevi che stessero accadendo in quel momento.
Immagino che tu non conosca il numero. Nemmeno noi, onestamente. Ed è un po' questo il punto.
Il consiglio standard per il sovraccarico di canali Slack è: riorganizzare, creare convenzioni di denominazione, archiviare ciò di cui non si ha bisogno, magari fare una pulizia trimestrale (il tipo di rituale che sembra produttivo per circa un pomeriggio, poi si sgretola lentamente nelle sei settimane successive). Quel consiglio va bene, fin dove arriva, ma tratta il sintomo piuttosto che il meccanismo. La ragione per cui il tuo team ha troppi canali Slack e non riesce a trovare nulla non è che siete cattivi nell'organizzazione (beh, forse un po') – è che Slack è stato costruito per le conversazioni, non per la conoscenza, e il divario tra queste due cose è dove tutto il vostro contesto importante va a morire.
Cercabile non significa trovabile
Questo è il punto in cui la maggior parte dei team inciampa. La ricerca di Slack è in realtà piuttosto buona in quello che fa. Digiti una parola, trova i messaggi che contengono quella parola, li classifica anche per rilevanza e ti permette di filtrare per canale, persona e intervallo di date. Se sai cosa stai cercando e approssimativamente quando è successo, la ricerca di Slack ti porterà lì.
Il problema è che "trovabile" e "cercabile" descrivono capacità fondamentalmente diverse – e Slack ne offre solo una.
"Cercabile e trovabile descrivono capacità fondamentalmente diverse – e Slack ne offre solo una." – Ellis Keane
Cercabile significa: ho una parola chiave specifica e voglio vedere ogni messaggio che la contiene. Trovabile significa: ricordo che è avvenuta una conversazione, so approssimativamente di cosa trattava, ma non ricordo le parole esatte che ha usato qualcuno, in quale canale è avvenuta, o precisamente quando è successo. Questo secondo caso rappresenta, nella nostra esperienza, circa l'80% di come le persone tentano effettivamente di recuperare informazioni da Slack.
Pensa all'ultima volta che hai cercato qualcosa in Slack. Stavi digitando una parola chiave esatta, o stavi provando varianti diverse, scorrendo canali, controllando i DM, e alla fine chiedendo a qualcuno: «ehi, ricordi dove abbiamo parlato di...?» Se era il secondo caso (e scommetterei denaro vero che di solito è così), la ricerca di Slack non è rotta. Sta semplicemente risolvendo un problema diverso da quello che hai davvero.
Come i canali si moltiplicano e il contesto si frammenta
Ecco cosa accade davvero nella maggior parte dei team che abbiamo osservato. Inizia in modo abbastanza innocuo: crei canali per i team (#engineering, #design, #product), canali per i progetti (#project-atlas, #project-beacon), canali per le funzioni (#standup, #deployments, #incidents), e forse qualcuno social (#random, #watercooler). Sono forse 15–20 canali e funzionano magnificamente per circa tre mesi.
Poi i confini cominciano a sfumare. Qualcuno avvia in #engineering una conversazione su un problema di deployment che dovrebbe davvero essere in #incidents. Una conversazione di revisione del design si estende su #design, #project-atlas e un thread di DM. Qualcuno crea #project-atlas-design perché vuole uno spazio specifico per il feedback di design su quel progetto, e ora ci sono due posti in cui le decisioni di design di Atlas potrebbero vivere – è meglio controllare entrambi se vuoi il quadro completo.
Il numero di canali non è davvero il problema, anche se sembra esserlo (non posso dimostrarlo per ogni team, ma è stato vero per ogni team con cui ho parlato di questo). Il problema è che ogni canale diventa una sacca isolata di contesto senza connessioni con le altre sacche. Una conversazione in #project-atlas fa riferimento a un doc di Notion che fa riferimento a una issue di Linear che è stata discussa in #engineering, e nessuno di quei riferimenti è un link leggibile da una macchina. Sono abbreviazioni umane: «come discusso», «secondo il doc», «in seguito a quel thread». Una persona che era in tutte quelle conversazioni può seguire la pista. Una persona che non c'era (o una persona che c'era, sei mesi dopo) semplicemente non può.
Cosa risolvono davvero le convenzioni di denominazione (e cosa non risolvono)
Non voglio scartare del tutto le convenzioni di denominazione, perché aiutano con una cosa specifica: aiutano a trovare il canale giusto in cui cercare. Un pattern coerente come team-engineering, proj-atlas, func-deploys rende la barra laterale navigabile. Questo è un valore reale, anche se la convenzione sopravvive approssimativamente fino alla terza persona che non ha letto il wiki e crea atlas-design-feedback invece di proj-atlas-design.
Ma le convenzioni di denominazione non risolvono il problema della trovabilità, perché la trovabilità non riguarda sapere in quale canale cercare. Riguarda il fatto che la conversazione di cui hai bisogno è distribuita su tre canali e un DM, e nessuna convenzione di denominazione al mondo te lo dirà. L'architettura delle informazioni di Slack è piatta per design, e quella piattezza è in realtà uno dei suoi punti di forza per la conversazione in tempo reale (non vuoi gerarchia quando devi contattare rapidamente qualcuno riguardo a un deployment), ma è un disastro per il recupero delle informazioni.
Il problema dei "troppi canali" è in realtà un problema di "contesto intrappolato nei canali". Ridurre il numero di canali aiuta con la navigazione ma non risolve la frammentazione di fondo.
Perché hai troppi canali Slack e non riesci a trovare nulla
Supponiamo che tu stia cercando la conversazione in cui il tuo team ha deciso di passare da REST a GraphQL per l'API interna. Ecco come appare nella pratica:
- Cerchi "GraphQL" in Slack. Ottieni circa 250 risultati su una dozzina di canali. La maggior parte viene da #engineering, alcuni da #random (qualcuno che condivide un post del blog), qualcuno da #project-beacon dove qualcuno ha chiesto se il cambiamento li avrebbe influenzati.
- Restringi a #engineering. Ci sono ancora decine di risultati. La decisione stessa non si trova in nessuno di essi perché quando il tuo ingegnere principale ha detto «facciamolo», ha semplicemente scritto «sembra buono, andiamo con quello» in risposta a un messaggio di due giorni prima.
- Cerchi "REST API" sperando di trovare la discussione di confronto. Set di risultati diverso, solo parziale sovrapposizione. Alcuni dei messaggi più importanti nel thread della decisione non contengono né "REST" né "GraphQL" perché stavano discutendo l'esperienza dello sviluppatore e la sicurezza dei tipi in termini generali.
- Ti arrendi e chiedi in #engineering: «qualcuno ricorda quando abbiamo deciso di passare a GraphQL?» Qualcuno risponde con un link a una issue di Linear. La issue di Linear si collega a un RFC di Notion. Il RFC di Notion fa riferimento a un thread Slack (ma il link è morto perché il canale è stato archiviato). E il momento reale della decisione era in un huddle senza alcuna documentazione scritta.
Non è un problema di ricerca. È un problema di grafo della conoscenza. Ed è la vera ragione per cui i team con troppi canali Slack non riescono a trovare nulla, non importa quanto migliori la ricerca di Slack.
Cosa funziona davvero
Dopo aver osservato questo schema nel nostro team (e aver sentito storie notevolmente simili da altri responsabili tecnici), siamo arrivati a un paio di cose che aiutano davvero:
Accetta che Slack è una posta in arrivo, non un archivio. Il cambio di modello mentale più utile in assoluto. Slack è il luogo in cui le conversazioni avvengono in tempo reale, non dove le decisioni vengono archiviate. Se qualcosa di importante è stato deciso in Slack, deve essere catturato da qualche parte di duraturo: una issue di Linear, un doc di Notion, un ADR, anche un messaggio di commit. Slack è la conversazione; quegli altri strumenti sono il registro.
Usa i thread in modo sistematico. I thread sono la funzionalità migliore di Slack per la trovabilità perché mantengono una conversazione completa in un'unica unità indirizzabile. Un thread ha un permalink. Una conversazione dispersa sulla timeline principale di un canale non ce l'ha. Se la cultura del tuo team porta a rispondere nel canale principale (e molti lo fanno, perché sembra più immediato), stai rendendo il recupero enormemente più difficile.
Crea canali per le decisioni, non canali per i progetti. Questo è controintuitivo, ma ascoltami. Invece di (o oltre a) #project-atlas, prova #decisions o #decisions-engineering. Un canale il cui unico scopo è registrare le decisioni con contesto breve. Non conterrà la discussione completa (quella può vivere dove avviene naturalmente), ma ti darà un registro cronologico e ricercabile di ciò che è stato deciso e un link a dove è avvenuta la discussione. Consideralo come un commit log per il pensiero del tuo team. Il meccanismo di applicazione che funziona davvero (secondo la nostra esperienza): rendilo parte del tuo template di PR. Prima del merge, collega il post della decisione pertinente. È leggero, verificabile in revisione, e crea una pista che non dipende dalla memoria o dalla disciplina di nessuno.
Collega i punti automaticamente. Questa è la parte in cui menzionerò cosa stiamo costruendo, perché è direttamente rilevante. Sugarbug acquisisce i messaggi Slack insieme alle tue issue di Linear, PR di GitHub, doc di Notion e commenti di Figma, e costruisce un grafo della conoscenza di come si relazionano tutti tra loro. Quando quelle connessioni esistono, non hai bisogno di ricordare in quale canale è avvenuta una conversazione, perché puoi partire dal compito o dal documento e seguire la pista verso ogni conversazione pertinente, indipendentemente da dove si trovava. Stiamo ancora capendo il modo migliore per presentare tutto questo (onestamente, la UX per il recupero tra strumenti è più difficile dell'acquisizione), ma l'approccio centrale – connettere il contesto invece di riorganizzarlo – è ciò che pensiamo faccia davvero la differenza.
Smetti di cercare in cinque canali e tornare a mani vuote. Sugarbug collega Slack al resto dei tuoi strumenti così le decisioni restano trovabili.
Q: Quanti canali Slack sono troppi? A: Non esiste un numero magico, ma se il tuo team non riesce regolarmente a trovare dove è avvenuta una conversazione, o se le persone ricorrono ai DM perché i canali sembrano opprimenti, hai probabilmente superato il limite. I team da 10–20 persone con più di 80–100 canali attivi tendono a scontrarsi con questo muro, anche se dipende molto da quanto il tuo team è disciplinato riguardo allo scopo dei canali e all'archiviazione.
Q: Sugarbug aiuta a gestire il sovraccarico di canali Slack? A: Sugarbug non gestisce i tuoi canali direttamente, ma risolve il problema di trovabilità che il sovraccarico di canali crea. Acquisisce i messaggi Slack insieme alle tue issue di Linear, PR di GitHub, doc di Notion e commenti di Figma in un grafo della conoscenza, così quando cerchi una decisione o una conversazione, cerchi una sola volta e la trovi indipendentemente dal canale (o dallo strumento) in cui è avvenuta.
Q: Perché non riesco a trovare nulla in Slack anche con la ricerca? A: La ricerca di Slack trova i messaggi che contengono le tue parole chiave esatte, ma la maggior parte delle decisioni lavorative usa parole diverse in fasi diverse. Qualcuno potrebbe dire «l'opzione Redis» in un thread e «BullMQ» in un altro, riferendosi alla stessa decisione, e quei thread non si riferiscono mai l'uno all'altro. La ricerca trova corrispondenze di testo. Trovare una pista decisionale richiede la comprensione delle connessioni tra le conversazioni, il che è una capacità fondamentalmente diversa.
Q: Sugarbug può sostituire i canali Slack con qualcosa di meglio? A: No, e non dovrebbe provare. Slack è eccellente nella conversazione in tempo reale, ed è un valore genuino. Il problema non è Slack stesso, ma il fatto che il contesto importante rimane intrappolato nelle conversazioni senza modo di collegarlo ai compiti, documenti e codice correlati. Sugarbug costruisce quelle connessioni automaticamente in modo che tu non debba ricordare dove le cose sono state discusse.