Decisiones antiguas en Slack – cuando la búsqueda falla
Cómo encontrar decisiones en Slack cuando la búsqueda falla. Por qué desaparecen, por qué los registros fallan y cómo un sistema las rastrea.
By Ellis Keane · 2026-03-14
Rápido: ¿dónde decidió tu equipo usar webhooks en lugar de polling? No qué decidisteis – ¿dónde está escrita esa decisión ahora mismo, en un lugar donde alguien que se incorpore el mes que viene pueda encontrarla?
Si sois como nosotros, la respuesta honesta está en algún punto entre "un hilo de Slack, probablemente" y "creo que fue en #eng-backend, hace quizás tres semanas, y estoy bastante seguro de que involucraba a dos o tres personas, pero sinceramente no recuerdo cuáles." Lo cual es un estado de cosas fascinante si lo piensas, porque la decisión en sí misma fue lo suficientemente importante como para cambiar el funcionamiento de todo el sistema, pero aparentemente no lo suficientemente importante como para que nadie la anotara en un lugar que no fuera una corriente de conciencia organizada por marca de tiempo. Y eso, en pocas palabras, es el problema de intentar encontrar decisiones antiguas en Slack – la información está toda ahí, simplemente no está organizada de manera que permita recuperarla como una decisión.
Llevo un tiempo investigando cómo encontrar decisiones antiguas en Slack, y cuanto más profundizo en ello, más pienso que el problema central no es la disciplina ni el hábito ni ninguna de las otras cosas que la gente culpa. Es arquitectónico. La búsqueda de Slack fue diseñada para encontrar mensajes, y las decisiones no son mensajes – son significado que resulta expresarse a través de mensajes, una distinción que suena pedante hasta que has pasado veinte minutos desplazándote por los resultados de búsqueda intentando averiguar cuál de las diecisiete menciones de "webhooks" fue aquella en la que tu equipo realmente se comprometió a usarlos.
Cómo funciona realmente la búsqueda de Slack (y dónde falla)
Seamos precisos sobre esto, porque "la búsqueda de Slack es mala" no es el diagnóstico correcto – la búsqueda de Slack es en realidad bastante buena en lo que hace. El problema es que lo que hace y lo que necesitas que haga cuando buscas una decisión son dos cosas fundamentalmente diferentes.
Slack indexa los mensajes como texto con metadatos: marca de tiempo, remitente, canal y (si tienes un plan de pago) el contexto completo del hilo. Cuando buscas "webhook", Slack devuelve fielmente cada mensaje que contiene esa palabra, ordenado por alguna combinación de relevancia y actualidad. Puedes acotar las cosas con operadores de búsqueda – in:#eng-backend from:@sarah before:2026-02-15 – pero lo único que haces es filtrar la misma lista plana de mensajes por metadatos. Esto es recuperación por palabras clave, y para encontrar un mensaje específico que recuerdas a medias, funciona bien.
Pero una decisión no es una palabra clave. Una decisión es una relación entre una pregunta, un conjunto de opciones, un conjunto de personas y un momento en el que el grupo convergió en una opción. El texto real de la decisión podría ser "sí, usemos webhooks, el enfoque de polling está consumiendo nuestro límite de velocidad" – lo cual es conversacional, contextual y solo tiene sentido si ya conoces el hilo en el que apareció. O podría ser "eso funciona, déjame hacer un prototipo", que no contiene ninguna palabra clave relacionada con la decisión técnica que representa.
Esta es la incompatibilidad arquitectónica: Slack almacena mensajes cronológicamente y los recupera por palabras clave. Las decisiones son semánticas (tratan sobre el significado) y relacionales (se conectan con tareas, personas y resultados). Estás pidiendo a un sistema de almacenamiento cronológico que realice recuperación semántica, y no puede, porque nunca fue diseñado para ello. La brecha entre "buscable" y "encontrable" resulta ser enorme – cada mensaje en tu historial de Slack es técnicamente buscable, pero eso no significa que la decisión que necesitas sea encontrable en ningún sentido práctico.
"Slack ha creado uno de los mayores repositorios de toma de decisiones organizacionales en la historia, y casi nada de ello es recuperable como decisiones – cada palabra perfectamente conservada y casi completamente imposible de encontrar." – Ellis Keane
Qué ocurre cuando intentas encontrar decisiones antiguas en Slack
Así es como se ve la incompatibilidad en la práctica. Supón que tu equipo decidió hace tres semanas cambiar de polling a webhooks para una integración de GitHub. Recuerdas que la discusión ocurrió en #eng-backend e involucró a algunos ingenieros. Así que buscas "webhook" en ese canal.
Lo que vuelve: cada mensaje que alguna vez ha mencionado webhooks en #eng-backend. Informes de errores de hace seis meses. Alguien haciendo una pregunta sobre la lógica de reintentos de webhook en un contexto completamente diferente. Un enlace que alguien compartió a una entrada de blog sobre las mejores prácticas de webhooks (que, en una hermosa ironía, probablemente tiene un rango más alto en los resultados de búsqueda que la decisión real junto a la que está). La decisión en sí – una respuesta en un hilo donde alguien dijo que el enfoque de polling estaba alcanzando límites de velocidad – está enterrada en algún lugar de la página tres, con exactamente el mismo aspecto que todos los demás mensajes a su alrededor.
Y eso es el escenario en el que recuerdas más o menos qué palabras se usaron. La mitad de las veces, las decisiones usan un lenguaje tan contextual que podría estar cifrado. "Vamos con la opción B" no contiene la palabra "webhook" en absoluto, aunque la opción B eran los webhooks. "Eso funciona, déjame hacer un prototipo" ni siquiera contiene la palabra "opción". El momento real de la decisión es a menudo el mensaje más corto y con menos palabras clave de todo el hilo, porque en ese punto todos en la conversación ya tienen el contexto y solo están confirmando la alineación.
Encuentro esto genuinamente interesante como problema de arquitectura de la información (bueno, interesante y también levemente frustrante cuando eres quien busca). Slack ha creado uno de los mayores repositorios de toma de decisiones organizacionales en la historia, y casi nada de ello es recuperable como decisiones – cada palabra perfectamente conservada, y casi completamente imposible de encontrar.
Por qué los registros de decisiones son un cementerio con mejores señales
El consejo estándar, si buscas soluciones, es mantener un registro de decisiones. Una base de datos de Notion, un canal dedicado de Slack (cuya ironía aparentemente escapa a quienes lo recomiendan), una página wiki – algún lugar único donde las decisiones se registran a medida que ocurren.
Lo intentamos. Duró unas seis semanas. Las primeras dos semanas fueron geniales – todos estaban comprometidos, las entradas eran detalladas, el registro era genuinamente útil. Para la tercera semana, las entradas empezaron a ser irregulares. Para la quinta semana, una persona todavía lo actualizaba, escribiendo cosas como "decisión sobre autenticación" sin enlaces, sin contexto y sin indicación de quién estuvo involucrado o cuáles eran las alternativas. Para la sexta semana, dejamos de fingir en silencio.
El problema no es que a nuestro equipo le falte disciplina (quiero decir, quizás, pero ese no es el problema relevante aquí). El problema es que el registro de decisiones impone una carga exactamente en el momento equivocado. Acabas de tener una discusión productiva, habéis alcanzado un acuerdo, alguien está listo para empezar a construir – y ahora tienes que pausar, abrir una herramienta diferente, escribir un resumen, etiquetar a las personas relevantes y volver a enlazar a la conversación original. Son de tres a cinco minutos por decisión, y para un equipo que toma de cinco a diez decisiones significativas al día entre canales e hilos, el esfuerzo se acumula en algo que nadie quiere gestionar.
Y el sistema solo funciona con el 100 % de cumplimiento. Un registro de decisiones con el 70 % de las decisiones es en cierto modo peor que ningún registro, porque ahora estás revisando dos lugares y no confías en ninguno. Miras en el registro, la decisión no está, así que buscas en Slack de todos modos – y estás de vuelta al punto de partida, salvo que ahora también has perdido dos minutos revisando primero el registro.
Las decisiones no son eventos – son gradientes
Parte del motivo por el que el registro manual falla es que asume que las decisiones son momentos discretos e identificables. En realidad, la mayoría de las decisiones emergen gradualmente a través de la conversación, y el "momento de la decisión" es a menudo genuinamente ambiguo.
Considera cómo se desarrolla realmente una decisión típica de ingeniería. Alguien plantea una preocupación en un comentario de Figma: "este patrón de interacción puede no funcionar en móvil." Un ingeniero responde en un hilo de Slack, haciendo referencia al comentario original: "sí, lo investigué – la biblioteca de componentes no lo admite." Un diseñador sugiere un enfoque alternativo en el mismo hilo. El ingeniero dice "eso funciona, déjame hacer un prototipo." Dos días después, se abre una PR implementando la alternativa, y la incidencia de Linear se actualiza.
¿Dónde se tomó la decisión? ¿Fue el comentario de Figma que identificó el problema? ¿El hilo de Slack donde se propuso la alternativa? ¿El momento en que el ingeniero dijo "eso funciona"? ¿La PR que lo implementó? En la práctica, la decisión se distribuyó entre esos cuatro momentos, abarcando dos herramientas y tres días. No fue un evento que pudieras registrar – fue un gradiente que se resolvió en un resultado, y la única razón por la que sabemos que se tomó una decisión es que el código cambió.
Este es (creo) el punto que la mayoría de los consejos de "seguimiento de decisiones" se equivoca. Trata las decisiones como cosas que capturas, como anotar un número de teléfono. Pero la mayoría de las decisiones reales son cosas que reconstruyes – miras lo que cambió, trazas hacia atrás las conversaciones que llevaron a ello, y reúnes el razonamiento a posteriori. Lo que significa que el sistema que necesitas no es un registro. Es un grafo.
Lo que un grafo te da que un registro no puede
Un grafo conecta señales entre herramientas y tiempo. En lugar de que alguien escriba manualmente "decidimos usar webhooks por los límites de velocidad", el grafo vincula el hilo de Slack donde se discutieron los límites de velocidad, la incidencia de Linear que rastreó el trabajo de integración, la PR que implementó los webhooks, y las personas que participaron en la conversación. La decisión no se registra – es reconstruible a partir de las conexiones entre cosas que ya estaban ocurriendo.
La diferencia práctica aparece en un escenario concreto. Tres semanas después de la decisión sobre webhooks, un nuevo ingeniero se une y pregunta: "¿por qué estamos usando webhooks en lugar de polling para GitHub? El polling parece más simple." Sin un sistema conectado, alguien dice "ah, eso lo decidimos hace un tiempo", nadie recuerda qué canal, alguien pasa quince minutos buscando en Slack, y o lo encuentra o (más probablemente) reconstruye el razonamiento de memoria, lo cual es arriesgado porque la memoria es poco fiable y el razonamiento original casi con certeza era más matizado de lo que alguien recuerda tres semanas después.
Con un grafo, el ingeniero mira la tarea de integración de GitHub. Cada señal que tocó esa tarea está vinculada: la discusión original sobre los límites de velocidad, el hilo donde se evaluó polling vs. webhooks, la PR que implementó el cambio. El rastro completo de la decisión, de principio a fin, sin que nadie haya buscado nada y sin que nadie haya registrado nada.
La brecha no está entre "buena búsqueda" y "mala búsqueda" – está entre la recuperación por palabras clave y la recuperación por relación. Las decisiones se definen por sus conexiones con tareas, personas y resultados, no por las palabras usadas para expresarlas.
Los costes que no aparecen en ningún panel de control
Sinceramente soy escéptico de cualquiera que afirme cifras precisas para costes intangibles como estos (el género de estadísticas "los equipos pierden X horas a la semana" siempre parece haber sido elaborado a la inversa desde una conclusión deseada), pero esto es lo que hemos observado en nuestro propio equipo.
El coste más obvio es la re-litigación – cuando nadie puede encontrar la decisión original, los equipos simplemente la reabren, a veces porque la gente genuinamente no recuerda y a veces porque un nuevo miembro del equipo tiene preguntas legítimas que nadie puede responder con detalles. Estábamos reabriendo preguntas ya resueltas con regularidad antes de tener una forma de rastrear las decisiones hasta su origen, y cada re-litigación lleva su propio esfuerzo: el tiempo de la reunión, el agotamiento emocional de discutir algo de lo que estás bastante seguro ya se había resuelto, la sospecha persistente de que el razonamiento original era más matizado de lo que nadie recuerda.
El coste más sutil es lo que ocurre durante la incorporación. Cada pregunta "¿por qué se hizo así?" de un nuevo miembro del equipo interrumpe a alguien que estuvo en la decisión original, y la respuesta se reconstruye de memoria cada vez que alguien pregunta, alejándose ligeramente del razonamiento original con cada repetición – como un juego de teléfono roto, excepto que el teléfono es software empresarial y el mensaje es "por qué funciona así la arquitectura." Y hay una brecha de credibilidad que se acumula con el tiempo: "fuimos con webhooks" tiene menos peso que "fuimos con webhooks porque el polling consumía el 40 % de nuestro límite de velocidad de la API de GitHub y teníamos throttling durante las horas pico." El razonamiento es lo que permite a los futuros ingenieros evaluar si una decisión sigue siendo válida en circunstancias cambiadas, y ese razonamiento está en algún hilo de Slack, perfectamente conservado y prácticamente invisible.
Deja de perder decisiones en el scroll de Slack. Sugarbug rastrea el rastro completo de la decisión – desde el hilo de Slack hasta la incidencia de Linear hasta la PR – automáticamente.
Q: ¿Por qué es tan difícil encontrar decisiones antiguas en Slack? A: Slack almacena mensajes cronológicamente, no por significado. Una decisión enterrada en un hilo tiene el mismo aspecto que cualquier otra respuesta – la búsqueda de Slack puede coincidir con palabras clave, pero no puede distinguir "decidimos usar Redis" de "¿deberíamos usar Redis?" sin leer el contexto conversacional completo. Cuanto más tiempo pasa, más difícil se vuelve, porque pierdes las pistas contextuales (quién estuvo involucrado, qué canal, qué semana) que hacen viable la búsqueda en primer lugar.
Q: ¿Sugarbug rastrea automáticamente las decisiones tomadas en Slack? A: Sí. Sugarbug clasifica las señales entrantes de Slack y otras herramientas conectadas, identificando patrones similares a decisiones – hilos que hacen referencia a tareas, involucran a personas asignadas y resultan en cambios de estado o PRs. Estos se vinculan a la tarea relevante en el grafo de conocimiento, para que puedas rastrear el rastro de la decisión desde la tarea en lugar de buscar en el historial de Slack.
Q: ¿Cuál es la diferencia entre un registro de decisiones y un grafo de conocimiento para decisiones? A: Un registro de decisiones requiere que alguien registre manualmente cada decisión a medida que ocurre – notarla, pausar, resumirla, etiquetarla, vincularla. Un grafo de conocimiento infiere las decisiones a partir de las señales que fluyen por tus herramientas y las vincula automáticamente a tareas, personas y conversaciones. Uno depende de la disciplina constante de cada miembro del equipo; el otro se ejecuta en segundo plano a partir de la actividad que ya está ocurriendo.
Q: ¿Puede Sugarbug obtener decisiones de herramientas distintas de Slack? A: Sugarbug se conecta a Slack, GitHub, Figma, Linear, Notion, correo electrónico y calendarios. Las decisiones a menudo abarcan múltiples herramientas (un comentario de Figma lleva a un hilo de Slack que lleva a una PR), y el grafo de conocimiento vincula señales de todas las superficies conectadas. Ves el rastro completo independientemente de en qué herramienta comenzó la conversación.
Q: ¿En qué se diferencia esto de usar la búsqueda integrada de Slack? A: La búsqueda de Slack encuentra mensajes que contienen palabras clave específicas. Un grafo de conocimiento encuentra las relaciones entre mensajes, tareas y personas. Cuando buscas una decisión, raramente buscas una palabra – buscas el momento en que un equipo eligió un enfoque sobre otro, y ese momento está definido por sus conexiones con otras señales, no por las palabras usadas para expresarlo.
---
Si las decisiones siguen desapareciendo en tu historial de Slack, el problema no es Slack – es que ningún sistema está vigilando los momentos que importan y conectándolos con el trabajo que moldearon. Esa es la brecha que estamos construyendo Sugarbug para llenar.