Trovare vecchie decisioni in Slack – oltre la ricerca
Perché la ricerca Slack fallisce per le decisioni e come un grafo della conoscenza collega la traccia decisionale in automatico.
By Ellis Keane · 2026-03-14
Veloce: dove ha deciso il tuo team di usare i webhook invece del polling? Non cosa avete deciso – dove è scritta quella decisione adesso, in un posto che qualcuno che si unisce il mese prossimo possa trovare?
Se siete come noi, la risposta onesta è da qualche parte tra "un thread Slack, probabilmente" e "credo fosse in #eng-backend, forse tre settimane fa, e sono abbastanza sicuro che coinvolgesse due o tre persone ma sinceramente non ricordo quali." Il che è un affascinante stato di cose se ci si pensa, perché la decisione in sé era abbastanza importante da cambiare il funzionamento dell'intero sistema, ma evidentemente non abbastanza importante perché qualcuno la scrivesse in un posto che non fosse un flusso di coscienza organizzato per timestamp. E questo, in breve, è il problema nel cercare di trovare vecchie decisioni in Slack – l'informazione è tutta lì, è solo che non è organizzata in un modo che ti permetta di recuperarla come decisione.
Ho passato un po' di tempo a indagare su come trovare vecchie decisioni in Slack, e più vado a fondo, più penso che il problema centrale non sia la disciplina, né l'abitudine, né nessuna delle altre cose che la gente incolpa. È architetturale. La ricerca di Slack è stata costruita per trovare messaggi, e le decisioni non sono messaggi – sono significato che capita di essere espresso attraverso messaggi, una distinzione che sembra pedante fino a quando non hai passato venti minuti a scorrere i risultati di ricerca cercando di capire quale delle diciassette menzioni di "webhook" fosse quella in cui il tuo team si era effettivamente impegnato a usarli.
Come funziona davvero la ricerca di Slack (e dove si rompe)
Siamo precisi su questo, perché "la ricerca di Slack è pessima" non è la diagnosi giusta – la ricerca di Slack è in realtà abbastanza buona in quello che fa. Il problema è che quello che fa e quello di cui hai bisogno che faccia quando stai cercando una decisione sono due cose fondamentalmente diverse.
Slack indicizza i messaggi come testo con metadati: timestamp, mittente, canale e (se hai un piano a pagamento) il contesto completo del thread. Quando cerchi "webhook," Slack restituisce fedelmente ogni messaggio contenente quella parola, classificato in base a una combinazione di recenza e rilevanza. Puoi restringere le cose con gli operatori di ricerca – in:#eng-backend from:@sarah before:2026-02-15 – ma quello che stai facendo è solo filtrare la stessa lista piatta di messaggi per metadati. Questo è recupero per parole chiave, e per trovare un messaggio specifico di cui ti ricordi a metà, funziona bene.
Ma una decisione non è una parola chiave. Una decisione è una relazione tra una domanda, un insieme di opzioni, un insieme di persone e un momento in cui il gruppo ha convergito su un'opzione. Il testo effettivo della decisione potrebbe essere "sì, facciamo con i webhook, l'approccio al polling sta consumando il nostro limite di frequenza" – che è colloquiale, contestuale e ha senso solo se conosci già il thread in cui è apparso. Oppure potrebbe essere "funziona, lasciami fare un prototipo," che non contiene nessuna parola chiave relativa alla decisione tecnica che rappresenta.
Questa è l'incompatibilità architetturale: Slack archivia i messaggi cronologicamente e li recupera per parole chiave. Le decisioni sono semantiche (riguardano il significato) e relazionali (si collegano a task, persone e risultati). Stai chiedendo a un sistema di archiviazione cronologica di eseguire il recupero semantico, e non può, perché non è mai stato progettato per farlo. Il divario tra "ricercabile" e "trovabile" si rivela enorme – ogni messaggio nella tua cronologia Slack è tecnicamente ricercabile, ma questo non significa che la decisione di cui hai bisogno sia trovabile in alcun senso pratico.
"Slack ha creato uno dei più grandi archivi di processo decisionale organizzativo della storia, e quasi niente di tutto questo è recuperabile come decisioni – ogni parola perfettamente conservata e quasi del tutto introvabile." – Ellis Keane
Cosa succede quando cerchi di trovare vecchie decisioni in Slack
Ecco come appare l'incompatibilità in pratica. Diciamo che il tuo team ha deciso tre settimane fa di passare dal polling ai webhook per un'integrazione GitHub. Ricordi che la discussione è avvenuta in #eng-backend e coinvolgeva alcuni ingegneri. Quindi cerchi "webhook" in quel canale.
Quello che torna: ogni messaggio che abbia mai menzionato i webhook in #eng-backend. Segnalazioni di bug di sei mesi fa. Qualcuno che fa una domanda sulla logica di nuovo tentativo dei webhook in un contesto completamente diverso. Un link che qualcuno ha condiviso a un post del blog sulle migliori pratiche dei webhook (che, in una bella ironia, probabilmente si posiziona più in alto nei risultati di ricerca rispetto alla decisione effettiva vicino alla quale si trova). La decisione stessa – una risposta in un thread dove qualcuno ha detto che l'approccio al polling stava raggiungendo i limiti di frequenza – è sepolta da qualche parte a pagina tre, sembrando esattamente come ogni altro messaggio attorno ad essa.
E questo è lo scenario in cui ti ricordi più o meno quali parole sono state usate. La metà delle volte, le decisioni usano un linguaggio così contestuale che potrebbe anche essere cifrato. "Andiamo con l'opzione B" non contiene affatto la parola "webhook," anche se l'opzione B erano i webhook. "Funziona, lasciami fare un prototipo" non contiene nemmeno la parola "opzione." Il momento effettivo della decisione è spesso il messaggio più corto e con meno parole chiave dell'intero thread, perché a quel punto tutti nella conversazione hanno già il contesto e stanno solo confermando l'allineamento.
Trovo questo genuinamente interessante come problema di architettura dell'informazione (beh, interessante e anche un po' frustrante quando sei tu quello che cerca). Slack ha creato uno dei più grandi archivi di processo decisionale organizzativo della storia, e quasi niente di tutto questo è recuperabile come decisioni – ogni parola perfettamente conservata, e quasi del tutto introvabile.
Perché i log di decisioni sono un cimitero con una segnaletica migliore
Il consiglio standard, se vai a cercare soluzioni, è tenere un log di decisioni. Un database Notion, un canale Slack dedicato (la cui ironia sembra sfuggire alle persone che lo raccomandano), una pagina wiki – un unico posto dove le decisioni vengono registrate man mano che avvengono.
Lo abbiamo provato. È durato circa sei settimane. Le prime due settimane erano ottime – tutti erano coinvolti, le voci erano dettagliate, il log era genuinamente utile. Alla settimana tre, le voci hanno iniziato a diventare sporadiche. Alla settimana cinque, una persona stava ancora aggiornandolo, scrivendo cose come "decisione su auth" senza link, senza contesto e senza indicazione di chi fosse coinvolto o quali fossero le alternative. Alla settimana sei, abbiamo silenziosamente smesso di far finta.
Il problema non è che al nostro team manchi disciplina (voglio dire, forse, ma non è il problema rilevante qui). Il problema è che la tenuta di un log di decisioni impone una tassa esattamente nel momento sbagliato. Hai appena avuto una discussione produttiva, hai raggiunto un accordo, qualcuno è pronto a iniziare a costruire – e ora devi fermarti, aprire uno strumento diverso, scrivere un riassunto, taggare le persone pertinenti e ricollegarti alla conversazione originale. Sono da tre a cinque minuti per decisione, e per un team che prende da cinque a dieci decisioni significative al giorno tra canali e thread, il sovraccarico si accumula in qualcosa che nessuno vuole gestire.
E il sistema funziona solo con il 100% di conformità. Un log di decisioni con il 70% delle decisioni è in alcuni modi peggio di nessun log, perché ora stai controllando due posti e non fidandoti di nessuno. Guardi nel log, la decisione non c'è, quindi cerchi ugualmente in Slack – e sei tornato al punto di partenza, tranne che ora hai anche sprecato due minuti a controllare prima il log.
Le decisioni non sono eventi – sono gradienti
Parte del motivo per cui la registrazione manuale fallisce è che presuppone che le decisioni siano momenti discreti e identificabili. In realtà, la maggior parte delle decisioni emerge gradualmente attraverso la conversazione, e il "momento della decisione" è spesso genuinamente ambiguo.
Considera come si svolge davvero una tipica decisione ingegneristica. Qualcuno solleva una preoccupazione in un commento Figma: "questo schema di interazione potrebbe non funzionare su mobile." Un ingegnere risponde in un thread Slack, facendo riferimento al commento originale: "sì, ho guardato – la libreria di componenti non lo supporta." Un designer suggerisce un approccio alternativo nello stesso thread. L'ingegnere dice "funziona, lasciami fare un prototipo." Due giorni dopo, una PR viene aperta per implementare l'alternativa, e il ticket Linear viene aggiornato.
Dove è stata presa la decisione? Era il commento Figma che ha identificato il problema? Il thread Slack dove è stata proposta l'alternativa? Il momento in cui l'ingegnere ha detto "funziona"? La PR che l'ha implementata? In pratica, la decisione era distribuita in tutti e quattro quei momenti, spanning due strumenti e tre giorni. Non era un evento che potevi registrare – era un gradiente che si è risolto in un risultato, e l'unico motivo per cui sappiamo che è stata presa una decisione è che il codice è cambiato.
Questo è (credo) la parte che la maggior parte dei consigli sul "tracciamento delle decisioni" sbaglia. Tratta le decisioni come cose che catturi, come scrivere un numero di telefono. Ma la maggior parte delle decisioni reali sono cose che ricostruisci – guardi cosa è cambiato, risali alle conversazioni che hanno portato lì, e metti insieme il ragionamento dopo il fatto. Il che significa che il sistema di cui hai bisogno non è un log. È un grafo.
Cosa ti dà un grafo che un log non può
Un grafo collega segnali attraverso strumenti e tempo. Invece che qualcuno scriva manualmente "abbiamo deciso di usare i webhook per i limiti di frequenza," il grafo collega il thread Slack dove i limiti di frequenza erano stati discussi, il ticket Linear che tracciava il lavoro di integrazione, la PR che ha implementato i webhook e le persone che erano coinvolte nella conversazione. La decisione non viene registrata – è ricostruibile dalle connessioni tra cose che stavano già accadendo.
La differenza pratica emerge in uno scenario specifico. Tre settimane dopo la decisione sui webhook, un nuovo ingegnere si unisce e chiede: "perché stiamo usando i webhook invece del polling per GitHub? Il polling sembra più semplice." Senza un sistema connesso, qualcuno dice "oh, l'abbiamo deciso un po' di tempo fa," nessuno ricorda quale canale, qualcuno trascorre quindici minuti a cercare in Slack, e o lo trovano o (più probabilmente) ricostruiscono il ragionamento a memoria, il che è rischioso perché la memoria è inaffidabile e il ragionamento originale era quasi certamente più sfumato di quanto chiunque ricordi tre settimane dopo.
Con un grafo, l'ingegnere guarda il task di integrazione GitHub. Ogni segnale che ha toccato quel task è collegato: la discussione originale sui limiti di frequenza, il thread dove polling vs. webhook era stato valutato, la PR che ha implementato il cambiamento. L'intera traccia decisionale, dall'inizio alla fine, senza che nessuno abbia cercato nulla e senza che nessuno abbia registrato nulla.
Il divario non è tra "buona ricerca" e "cattiva ricerca" – è tra il recupero per parola chiave e il recupero per relazione. Le decisioni sono definite dalle loro connessioni a task, persone e risultati, non dalle parole usate per esprimerle.
I costi che non appaiono in nessun pannello di controllo
Sono onestamente scettico verso chiunque affermi numeri precisi per costi intangibili come questi (il genere di statistiche "i team sprecano X ore a settimana" sembra sempre essere stato ottenuto ripartendo da una conclusione desiderata), ma ecco quello che abbiamo osservato nel nostro team.
Il costo più ovvio è la ri-litigazione – quando nessuno riesce a trovare la decisione originale, i team la riaprono semplicemente, a volte perché le persone non ricordano davvero e a volte perché un nuovo membro del team ha domande legittime a cui nessuno riesce a rispondere con precisione. Stavamo riaprendo regolarmente questioni già risolte prima di avere un modo per rintracciare le decisioni alla loro fonte, e ogni ri-litigazione porta il suo sovraccarico: il tempo della riunione, la stanchezza emotiva di discutere di qualcosa di cui sei abbastanza sicuro fosse già stato risolto, il sospetto persistente che il ragionamento originale fosse più sfumato di quanto chiunque ricordi.
Il costo più sottile è quello che succede durante l'inserimento. Ogni domanda "perché è stato fatto così?" di un nuovo membro del team interrompe qualcuno che era presente alla decisione originale, e la risposta viene ricostruita a memoria ogni volta che qualcuno la chiede, allontanandosi leggermente dal ragionamento originale a ogni racconto – come un telefono senza fili, tranne che il telefono è software aziendale e il messaggio è "perché l'architettura funziona così." E c'è un deficit di credibilità che si accumula nel tempo: "siamo andati con i webhook" ha meno peso di "siamo andati con i webhook perché il polling consumava il 40% del nostro limite di frequenza dell'API GitHub e stavamo subendo throttling durante le ore di punta." Il ragionamento è ciò che consente ai futuri ingegneri di valutare se una decisione regge ancora in circostanze cambiate, e quel ragionamento è seduto da qualche parte in un thread Slack, perfettamente conservato e praticamente invisibile.
Smetti di perdere decisioni nello scroll di Slack. Sugarbug traccia l'intera traccia decisionale – dal thread Slack al ticket Linear fino alla PR – automaticamente.
Q: Perché è così difficile trovare vecchie decisioni in Slack? A: Slack archivia i messaggi cronologicamente, non per significato. Una decisione sepolta in un thread sembra uguale a qualsiasi altra risposta – la ricerca di Slack può abbinare parole chiave, ma non può distinguere "abbiamo deciso di usare Redis" da "dovremmo usare Redis?" senza leggere il contesto conversazionale completo. Più passa il tempo, più diventa difficile, perché si perdono gli indizi contestuali (chi era coinvolto, quale canale, quale settimana) che rendono la ricerca praticabile in primo luogo.
Q: Sugarbug traccia automaticamente le decisioni prese in Slack? A: Sì. Sugarbug classifica i segnali in entrata da Slack e da altri strumenti connessi, identificando schemi simili a decisioni – thread che fanno riferimento a task, coinvolgono persone assegnate e risultano in cambiamenti di stato o PR. Questi vengono collegati al task pertinente nel grafo della conoscenza, così puoi tracciare la traccia decisionale dal task anziché cercare nella cronologia Slack.
Q: Qual è la differenza tra un log decisioni e un grafo della conoscenza per le decisioni? A: Un log decisioni richiede che qualcuno registri manualmente ogni decisione man mano che avviene – notarla, fermarsi, riassumerla, taggarla, collegarla. Un grafo della conoscenza deduce le decisioni dai segnali che scorrono attraverso i tuoi strumenti e le collega automaticamente a task, persone e conversazioni. Uno dipende dalla disciplina costante di ogni membro del team; l'altro gira in background a partire dall'attività già in corso.
Q: Sugarbug può recuperare decisioni da strumenti diversi da Slack? A: Sugarbug si connette a Slack, GitHub, Figma, Linear, Notion, email e calendari. Le decisioni spesso si estendono su più strumenti (un commento Figma porta a un thread Slack che porta a una PR), e il grafo della conoscenza collega i segnali su tutte le superfici connesse. Vedi l'intera traccia indipendentemente da quale strumento abbia avviato la conversazione.
Q: Come si differenzia dall'uso della ricerca integrata di Slack? A: La ricerca Slack trova messaggi che contengono parole chiave specifiche. Un grafo della conoscenza trova le relazioni tra messaggi, task e persone. Quando stai cercando una decisione, raramente stai cercando una parola – stai cercando il momento in cui un team ha scelto un approccio rispetto a un altro, e quel momento è definito dalle sue connessioni ad altri segnali, non dalle parole usate per esprimerlo.
---
Se le decisioni continuano a sparire nella tua cronologia Slack, il problema non è Slack – è che nessun sistema sta osservando i momenti che contano e collegandoli al lavoro che hanno plasmato. Questo è il divario che stiamo costruendo Sugarbug per colmare.