Perdido en Slack: buscable no significa encontrable
Tu equipo tiene demasiados canales de Slack y no encuentra nada. Por qué la búsqueda sola no es suficiente – y qué funciona de verdad.
By Ellis Keane · 2026-03-17
¿Cuántos canales de Slack tiene tu equipo ahora mismo? No el número en la barra lateral, porque has silenciado la mayoría. El número real, incluidos los que alguien creó para un proyecto que terminó hace seis meses, los que tienen nombres tan parecidos que nunca sabes cuál es el correcto, y ese puñado de canales donde ocurren cosas genuinamente importantes que nunca volverás a encontrar porque no sabías que estaban ocurriendo en ese momento.
Supongo que no conoces el número. Nosotros tampoco, sinceramente. Y ese es más o menos el punto.
El consejo habitual ante la sobrecarga de canales de Slack es reorganizar, crear convenciones de nombres, archivar lo que no necesitas, quizás hacer una limpieza trimestral (el tipo de ritual que se siente productivo durante aproximadamente una tarde y luego se deshace lentamente a lo largo de las siguientes seis semanas). Ese consejo está bien, hasta donde llega, pero trata el síntoma en lugar del mecanismo. La razón por la que tu equipo tiene demasiados canales de Slack y no puede encontrar nada no es que seáis malos en organización (bueno, quizás un poco), sino que Slack fue construido para conversaciones, no para el conocimiento, y la brecha entre esas dos cosas es donde todo tu contexto importante va a morir.
Buscable no significa encontrable
Esto es lo que hace tropezar a la mayoría de los equipos. La búsqueda de Slack es en realidad bastante buena en lo que hace. Escribes una palabra, encuentra los mensajes que contienen esa palabra, incluso los clasifica por relevancia y te permite filtrar por canal, persona y rango de fechas. Si sabes lo que buscas y aproximadamente cuándo ocurrió, la búsqueda de Slack te llevará allí.
El problema es que «encontrable» y «buscable» describen capacidades fundamentalmente diferentes – y Slack solo ofrece una de ellas.
«Buscable y encontrable describen capacidades fundamentalmente diferentes – y Slack solo ofrece una de ellas.» – Ellis Keane
Buscable significa: tengo una palabra clave concreta y quiero ver todos los mensajes que la contienen. Encontrable significa: recuerdo que ocurrió una conversación, sé aproximadamente de qué trataba, pero no recuerdo las palabras exactas que usó alguien, en qué canal fue, ni exactamente cuándo tuvo lugar. Ese segundo caso representa, según nuestra experiencia, aproximadamente el 80 % de las veces que la gente intenta recuperar información de Slack.
Piensa en la última vez que intentaste encontrar algo en Slack. ¿Escribiste una palabra clave exacta, o probaste distintas variaciones, navegaste por canales, revisaste DMs y al final le preguntaste a alguien: «oye, ¿recuerdas dónde hablamos sobre…?» Si fue lo segundo (y apostaría dinero real a que suele serlo), la búsqueda de Slack no está rota. Simplemente está resolviendo un problema distinto al que tú tienes.
Cómo se multiplican los canales y el contexto se fragmenta
Esto es lo que ocurre en la mayoría de los equipos que hemos observado. Comienza de forma inocente: creas canales para equipos (#engineering, #design, #product), canales para proyectos (#project-atlas, #project-beacon), canales para funciones (#standup, #deployments, #incidents) y quizás algunos sociales (#random, #watercooler). Son tal vez 15–20 canales y funciona a las mil maravillas durante unos tres meses.
Luego los límites empiezan a difuminarse. Alguien inicia en #engineering una conversación sobre un problema de despliegue que realmente debería estar en #incidents. Una conversación de revisión de diseño se extiende por #design, #project-atlas y un hilo de DM. Alguien crea #project-atlas-design porque quiere un espacio específico para el feedback de diseño de ese proyecto, y ahora hay dos lugares donde podrían vivir las decisiones de diseño de Atlas, y más vale que compruebes ambos si quieres el panorama completo.
El número de canales no es realmente el problema, aunque lo parezca (no puedo demostrarlo en todos los equipos, pero ha sido cierto en cada equipo con el que he hablado de esto). El problema es que cada canal se convierte en un compartimento aislado de contexto sin conexiones con los demás compartimentos. Una conversación en #project-atlas referencia un doc de Notion que referencia un issue de Linear que se discutió en #engineering, y ninguna de esas referencias es un enlace legible por máquinas. Son abreviaturas humanas: «como hablamos», «según el doc», «como seguimiento de ese hilo». Una persona que estuvo en todas esas conversaciones puede seguir el rastro. Una persona que no estuvo (o una persona que sí estuvo, seis meses después) simplemente no puede.
Lo que las convenciones de nombres realmente resuelven (y lo que no)
No quiero descartar las convenciones de nombres por completo, porque sí ayudan con una cosa concreta: te ayudan a encontrar el canal correcto donde buscar. Un patrón consistente como team-engineering, proj-atlas, func-deploys hace que la barra lateral sea navegable. Eso tiene valor real, aunque la convención sobreviva aproximadamente hasta que la tercera persona que no leyó la wiki crea atlas-design-feedback en lugar de proj-atlas-design.
Pero las convenciones de nombres no resuelven el problema de encontrabilidad, porque la encontrabilidad no se trata de saber en qué canal buscar. Se trata de que la conversación que necesitas esté repartida entre tres canales y un DM, y ninguna convención de nombres del mundo te dirá eso. La arquitectura de información de Slack es plana por diseño, y esa planitud es en realidad una de sus fortalezas para la conversación en tiempo real (no quieres jerarquía cuando necesitas enviarle un mensaje rápido a alguien sobre un despliegue), pero es un desastre para la recuperación de información.
El problema de «demasiados canales» es en realidad un problema de «contexto atrapado en los canales». Reducir el número de canales ayuda con la navegación, pero no resuelve la fragmentación subyacente.
Por qué tienes demasiados canales de Slack y no puedes encontrar nada
Imagina que intentas encontrar la conversación donde tu equipo decidió pasar de REST a GraphQL para la API interna. Así es como ocurre en la práctica:
- Buscas «GraphQL» en Slack. Obtienes alrededor de 250 resultados en una docena de canales. La mayoría son de #engineering, algunos de #random (alguien compartiendo una entrada de blog), unos pocos de #project-beacon donde alguien preguntó si el cambio les afectaría.
- Acotes a #engineering. Aún hay decenas de resultados. La decisión en sí no está en ninguno de ellos porque cuando tu ingeniero principal dijo «hagámoslo», simplemente escribió «suena bien, vamos con eso» en respuesta a un mensaje de dos días antes.
- Buscas «REST API» esperando encontrar la discusión de comparación. Diferente conjunto de resultados, solo parcialmente solapados. Algunos de los mensajes más importantes en el hilo de la decisión no contienen ni «REST» ni «GraphQL» porque estaban debatiendo la experiencia del desarrollador y la seguridad de tipos en términos generales.
- Te rindes y preguntas en #engineering: «¿alguien recuerda cuándo decidimos pasarnos a GraphQL?» Alguien responde con un enlace a un issue de Linear. El issue de Linear enlaza a un RFC de Notion. El RFC de Notion referencia un hilo de Slack (pero el enlace está roto porque el canal fue archivado). Y el momento real de la decisión fue en un huddle sin ningún registro escrito.
Eso no es un problema de búsqueda. Es un problema de grafo de conocimiento. Y es la razón real por la que los equipos con demasiados canales de Slack no pueden encontrar nada, no importa cuánto mejore la búsqueda de Slack.
Lo que realmente funciona
Tras observar este patrón en nuestro propio equipo (y escuchar historias notablemente similares de otros ingenieros de gestión), hemos llegado a unas pocas cosas que genuinamente ayudan:
Acepta que Slack es una bandeja de entrada, no un archivo. El cambio de modelo mental más útil con diferencia. Slack es donde las conversaciones ocurren en tiempo real, no donde se almacenan las decisiones. Si algo importante se decidió en Slack, debe capturarse en algún lugar duradero: un issue de Linear, un doc de Notion, un ADR, incluso un mensaje de commit. Slack es la conversación; esas otras herramientas son el registro.
Usa los hilos de forma sistemática. Los hilos son la mejor funcionalidad de Slack para la encontrabilidad porque mantienen una conversación completa en una unidad direccionable. Un hilo tiene un enlace permanente. Una conversación dispersa por la línea de tiempo principal de un canal no. Si la cultura de tu equipo tiende a responder en el canal principal (y muchos lo hacen, porque se siente más inmediato), estás dificultando enormemente la recuperación de información.
Crea canales de decisiones, no canales de proyectos. Esto es contraintuitivo, pero escúchame. En lugar de (o además de) #project-atlas, prueba con #decisions o #decisions-engineering. Un canal cuyo único propósito sea registrar decisiones con contexto breve. No contendrá la discusión completa (esa puede vivir donde ocurra de forma natural), pero te dará un registro cronológico y buscable de lo que se decidió y un enlace a donde ocurrió la discusión. Piénsalo como un log de commits para el pensamiento de tu equipo. El mecanismo de aplicación que realmente funciona (según nuestra experiencia): conviértelo en parte de tu plantilla de PR. Antes de hacer merge, enlaza el post de decisión relevante. Es ligero, se puede verificar en revisión y crea un rastro que no depende de la memoria ni la disciplina de nadie.
Conecta los puntos automáticamente. Esta es la parte donde mencionaré lo que estamos construyendo, porque es directamente relevante. Sugarbug ingiere mensajes de Slack junto a tus issues de Linear, PRs de GitHub, docs de Notion y comentarios de Figma, y construye un grafo de conocimiento de cómo se relacionan entre sí. Cuando esas conexiones existen, no necesitas recordar en qué canal ocurrió una conversación, porque puedes empezar desde la tarea o el documento y seguir el rastro hasta cada conversación relevante, independientemente de dónde viviera. Todavía estamos resolviendo la mejor manera de presentar todo esto (honestamente, la UX para la recuperación entre herramientas es más difícil que la ingestión), pero el enfoque central – conectar el contexto en lugar de reorganizarlo – es lo que creemos que realmente mueve la aguja.
Deja de buscar en cinco canales y salir con las manos vacías. Sugarbug conecta Slack con el resto de tus herramientas para que las decisiones sigan siendo encontrables.
Q: ¿Cuántos canales de Slack son demasiados? A: No hay un número mágico, pero si tu equipo habitualmente no puede encontrar dónde ocurrió una conversación, o si la gente recurre a los DMs porque los canales se sienten abrumadores, probablemente hayas cruzado la línea. Los equipos de 10–20 personas con más de 80–100 canales activos tienden a chocar con esta pared, aunque depende mucho de cuán disciplinado es tu equipo respecto al propósito de los canales y el archivado.
Q: ¿Ayuda Sugarbug a gestionar la sobrecarga de canales de Slack? A: Sugarbug no gestiona tus canales directamente, pero resuelve el problema de encontrabilidad que crea la sobrecarga de canales. Ingiere los mensajes de Slack junto a tus issues de Linear, PRs de GitHub, docs de Notion y comentarios de Figma en un grafo de conocimiento, de modo que cuando busques una decisión o conversación, busques una sola vez y la encuentres sin importar en qué canal (o en qué herramienta) ocurrió.
Q: ¿Por qué no puedo encontrar nada en Slack aunque use la búsqueda? A: La búsqueda de Slack encuentra mensajes que contienen tus palabras clave exactas, pero la mayoría de las decisiones en el trabajo usan palabras diferentes en distintas etapas. Alguien podría decir «la opción Redis» en un hilo y «BullMQ» en otro, refiriéndose a la misma decisión, y esos hilos nunca se referencian entre sí. La búsqueda encuentra coincidencias de texto. Encontrar un rastro de decisión requiere comprender las conexiones entre conversaciones, lo cual es una capacidad fundamentalmente diferente.
Q: ¿Puede Sugarbug reemplazar los canales de Slack con algo mejor? A: No, y no debería intentarlo. Slack es excelente en la conversación en tiempo real, y eso tiene un valor genuino. El problema no es Slack en sí, sino el hecho de que el contexto importante queda atrapado dentro de las conversaciones sin forma de conectarlo con las tareas, documentos y código relacionados. Sugarbug construye esas conexiones automáticamente para que no tengas que recordar dónde se discutieron las cosas.