Cómo rastrear decisiones en 5 herramientas de equipo
Cómo rastrear decisiones entre herramientas dispersas en Slack, Notion, Linear y PRs – y por qué los registros de decisiones no te salvarán.
By Chris Calo · 2026-03-13
«¿No habíamos decidido esto ya?»
Cinco personas en la llamada. Nadie responde. Alguien se desactiva el silencio para decir que cree que surgió en un hilo de Slack, quizás hace tres semanas, posiblemente en #engineering aunque podría haber sido en #backend. Nuestra diseñadora recuerda vagamente un comentario de Notion. Uno de nuestros ingenieros ya está desplazándose por Linear, buscando un comentario en el issue que puede haber sido cerrado. O archivado. O movido a un proyecto diferente.
La decisión en cuestión: qué esquema de versionado de API usaríamos en adelante. No es una elección que ponga en juego la empresa. No es un precipicio arquitectónico. Solo una decisión sencilla sobre cómo rastrear decisiones entre herramientas – o, más precisamente, cómo encontrar una decisión concreta que, definitiva y probablemente, ya se había tomado, y que ahora había evaporado en el espacio entre cinco herramientas que no se hablan entre sí.
Déjame reconstruir la escena del crimen.
La línea de tiempo forense de una decisión perdida
Esto es lo que ocurrió realmente, reconstituido a posteriori (porque al final lo encontré todo – me llevó casi una hora, lo que me pareció un uso productivo de una tarde de miércoles).
Día 1, 10:14 – Uno de nuestros ingenieros comparte un documento de Notion titulado «Opciones de versionado de API» en #engineering. Tres opciones desarrolladas, pros y contras de cada una. Formato limpio. Buen razonamiento. El tipo de documento que te hace sentir que tu equipo tiene las cosas bajo control.
Día 1, 10:22 – La discusión comienza en el hilo de Slack bajo el enlace compartido. Seis respuestas en los primeros veinte minutos. Una conversación genuina y útil sobre compatibilidad hacia atrás, implicaciones del SDK del cliente y si el versionado por cabeceras merece el dolor de depuración. También, en algún punto alrededor de la cuarta respuesta, una breve digresión sobre dónde comer – que, sinceramente, generó consenso más rápido que el debate sobre el versionado.
Día 1, 11:47 – Nuestra diseñadora, que había estado observando, deja una línea: «el versionado por ruta mantiene el explorador de API legible, hagamos simplemente /v2/.» Dos reacciones de pulgar arriba. Sin disidencia. Decisión tomada.
Día 1, 14:30 – Un compañero de equipo resume el resultado en un comentario de Linear sobre el issue de refactorización de la API. Buen instinto. Pésima visibilidad, resulta, porque los comentarios de Linear se vuelven funcionalmente invisibles una vez que se cierra un issue.
Día 8 – Llega el PR que implementa /v2/. La descripción del PR hace referencia al issue de Linear por número, pero no dice nada sobre la propia decisión de versionado ni sobre el hilo de Slack donde realmente ocurrió. Completamente normal. Nadie escribe «por cierto, aquí está la genealogía completa de esta decisión» en la descripción de un PR, porque nadie es un psicópata.
Día 43 – Alguien nuevo recoge un ticket relacionado y pregunta: «¿Estamos haciendo versionado por ruta o por cabecera?» ¿El documento de Notion? Nunca actualizado con el resultado. ¿El hilo de Slack? Enterrado bajo seis semanas de mensajes. ¿El comentario de Linear? En un issue cerrado que nadie piensa en buscar. ¿El PR? Tendrías que saber que existe para encontrarlo.
Y así cinco personas se sientan en una llamada, mirándose entre sí, redescubriendo una decisión que ya se había resuelto seis semanas antes. Progreso.
title: "Una decisión, seis semanas, cinco herramientas" Día 1, 10:14|ok|Notion doc "Opciones de versionado de API" compartido en #engineering; tres opciones Día 1, 10:22|ok|Comienza debate en Slack; conversación sobre compatibilidad hacia atrás y SDK Día 1, 11:47|ok|Decisión tomada: versionado de ruta, /v2/ Día 1, 14:30|amber|Resultado resumido en un comentario de Linear; issue cerrado = poca visibilidad Día 8|amber|PR con /v2/ fusionado; descripción referencia el issue pero no la decisión Día 43|missed|Nuevo desarrollador pregunta: "¿ruta o cabecera?" – la respuesta existe; nadie la encuentra
Dónde van a morir las decisiones
La cuestión es que ninguna de estas herramientas falló. Slack hizo exactamente lo que hace Slack. Notion guardó el documento a la perfección. Linear rastreó el issue. GitHub fusionó el código. Cada herramienta funcionó impecablemente de forma aislada – el tipo de observación que suena como un elogio hasta que te das cuenta de que en realidad es el diagnóstico.
| Dónde ocurrió | Por qué no se puede encontrar después | |---|---| | Hilo de Slack | Necesitas recordar las palabras exactas que alguien usó hace seis semanas. Buena suerte. | | Comentario de Linear | Los comentarios en issues cerrados bien podrían estar grabados en el fondo del océano | | Documento de Notion | El documento existe, pero nadie lo actualizó con el resultado, porque somos humanos | | PR de GitHub | Las conversaciones se colapsan tras el merge – tendrías que saber qué PR excavar | | Reunión (verbal) | Desaparecido del todo a menos que alguien tomara notas Y las pusiera en algún lugar accesible | | Hilo de email | Búsqueda decente, pero solo si estabas en la cadena correcta |
Seis herramientas. Seis motores de búsqueda. Cero memoria compartida.
Cada herramienta funcionó impecablemente de forma aislada – el tipo de observación que suena como un elogio hasta que te das cuenta de que en realidad es el diagnóstico. attribution: Chris Calo
El registro de decisiones: un cadáver hermoso
Si has estado asintiendo, probablemente ya hayas tenido El Instinto. Ese en el que piensas: «Bien, crearé un Registro de Decisiones.» Con mayúsculas. Una magnífica base de datos de Notion con columnas para Fecha, Decisión, Contexto, Interesados y Estado. Lo anuncias en el canal del equipo. Añades tú mismo las primeras tres entradas, con detalle meticuloso, y se siente genuinamente bien.
He construido este mismo artefacto en tres empresas (y sí, soy consciente de que repetir el mismo experimento fallido y esperar resultados diferentes tiene un nombre clínico). Cada vez, estaba absolutamente convencido de que funcionaría. «¡Esta vez seremos disciplinados!» No lo fuimos. Tú tampoco lo serás. No lo digo para ser cruel – lo digo porque el modo de fallo está integrado en el diseño.
Esto es lo que pasa. Semana uno: hermoso. Semana dos: mayormente poblado. Semana tres: alguien toma una decisión rápida en un DM de Slack, y el registro no se entera. Semana cuatro: se fusiona un PR con una decisión arquitectónica implícita enterrada en un comentario de revisión, y nadie piensa en transcribirla. Semana cinco: alguien está de vacaciones, el equipo restante decide algo en el almuerzo (el cambio de contexto del almuerzo golpea de nuevo), y el registro enmudece.
En la semana seis tu Registro de Decisiones es un memorial. Un monumento elegante a las buenas intenciones, sentado en tu barra lateral de Notion, intacto, acumulando el equivalente digital del polvo. Tengo tres. Son hermosos. También son completamente inútiles.
Los registros de decisiones no fallan porque los equipos no tengan disciplina, sino porque piden a los humanos que reconozcan un momento como importante mientras está sucediendo, que hagan una pausa, que hagan un cambio de contexto a una herramienta de documentación y que lo escriban con suficiente detalle para que sea útil seis semanas después. Es una cosa absurda de pedir a personas que están ocupadas haciendo trabajo real.
Cómo rastrear decisiones entre herramientas de verdad
Los registros manuales fallan por la naturaleza humana. La búsqueda por herramienta falla por la fragmentación. Lo que realmente funciona es algo que vigila toda la superficie de tus herramientas y conecta los puntos sin que nadie tenga que pausar lo que está haciendo.
En la práctica, eso significa cuatro cosas:
Ingesta automática. Cada señal de tus herramientas – mensajes de Slack, comentarios de Linear, revisiones de PR, actualizaciones de Notion, transcripciones de reuniones – se captura sin que nadie mueva un dedo. Sigues trabajando. El sistema sigue observando. Nadie tiene que interrumpir su hilo de pensamiento para abrir una hoja de cálculo y anotar lo que acaba de ocurrir (lo que, como hemos establecido, nadie hace de todas formas).
Clasificación. No todo mensaje es una decisión. La mayoría son actualizaciones de estado, preguntas o ruido. El sistema tiene que distinguir entre «¿usamos versionado por ruta o por cabecera?» (una pregunta), «hagamos simplemente /v2/» (una decisión) y «el endpoint /v2/ está desplegado» (una actualización de estado). Aquí es donde un clasificador LLM se gana su lugar – aunque no es infalible. Tuvimos un tramo memorable en el que «sí, hagamos eso» se marcaba repetidamente como una decisión importante cuando en realidad alguien aceptaba ir a por un café. Resulta que necesitas contexto temporal y ponderación del rol del remitente para calibrar bien la puntuación de confianza.
Vinculación. Esta es la parte que separa «mejor búsqueda» del rastreo de decisiones real. Cuando una decisión en un hilo de Slack se relaciona con un issue de Linear que produjo un PR de GitHub – esas conexiones deben existir porque el sistema rastreó las referencias (IDs de issue, números de PR, URLs de hilo, proximidad temporal), no porque alguien las dibujara diligentemente a mano. El documento de Notion, el hilo de Slack, el comentario de Linear y el PR deberían apuntarse entre sí automáticamente, porque eso es lo que ocurrió.
Recuperación. Cuando buscas «decisión de versionado de API», obtienes toda la cadena – no solo la herramienta que buscaste primero. El documento de Notion con las opciones, el hilo de Slack donde se tomó la decisión, el comentario de Linear que la resumió y el PR que la implementó. Todo conectado. Todo sin que nadie haya rellenado una sola entrada en ningún registro.
Dos cosas que puedes probar ahora mismo (de verdad, sin trampa):
- El canal
#decisions. Crea uno en Slack y pide a tu equipo que deje una línea cada vez que se decida algo en otro lugar. Es manual y decaerá en un mes (he establecido mis credenciales en este punto), pero incluso un registro parcial y en decadencia hace que el patrón de comunicación fragmentada sea dolorosamente visible.
- El hábito de la descripción del PR. Cuando abras un PR que implemente una decisión, añade una línea a la descripción: «Decisión: [qué se decidió] – ver [enlace al hilo/documento].» Cuesta diez segundos, sobrevive a la revisión de código y le da a tu yo futuro algo real que buscar. No capturará las decisiones que ocurren en DMs de Slack o en el almuerzo, pero las que sí captura son las más importantes – las que cambian el código base.
Qué cambia realmente el rastreo de decisiones conectado
La arqueología se convierte en una consulta. ¿Aquella búsqueda de versionado del principio? Con indexación entre herramientas, se convierte en una búsqueda de cinco segundos que devuelve cada artefacto de la cadena, vinculado. Lo que me habría ahorrado una vergonzosa tarde de miércoles. This is what visibility across your engineering tools actually means in practice. It’s closely related to a semantic approach to finding past Slack decisions and a connected view of tasks that span three or more tools – all three problems stem from the same fragmented-tools root cause.
Contexto de incorporación que no se pudre. Los nuevos miembros del equipo obtienen la cadena conectada del porqué las cosas son como son, en lugar de una página de wiki actualizada por última vez hace tres meses que todos saben vagamente que está mal pero que nadie se molesta en corregir. (Tienes una de esas. Todo el mundo tiene una de esas.)
Menos repeticiones del mismo debate. Esto me sorprendió. Una vez que las decisiones son localizables, «¿no habíamos decidido esto ya?» tiene respuesta en segundos en lugar de disolverse en una alucinación grupal de diez minutos en la que todos recuerdan haberlo discutido pero nadie puede confirmar qué se concluyó realmente.
Patrones que antes no podías ver. Cuando las decisiones son visibles en conjunto, empiezas a notar qué temas generan los debates más largos y dónde se estancan las decisiones. Inteligencia operativa que ninguna herramienta individual puede darte, porque ninguna herramienta individual tiene el panorama completo.
Cómo aborda esto Sugarbug
La búsqueda de versionado fue más o menos la gota que colmó el vaso y me empujó a empezar a construir Sugarbug (bueno, eso y los tres Registros de Decisiones muertos pesando sobre mi conciencia). Es el sistema que describí antes – se conecta a tus herramientas existentes a través de la API, alimenta cada señal en un grafo de conocimiento, clasifica y vincula automáticamente. El grafo se construye solo mientras tu equipo trabaja. Nadie documenta nada, porque la captura es un efecto secundario del trabajo en sí.
Todavía somos tempranos (en producción, antes del lanzamiento), y hay problemas difíciles que no hemos resuelto – decisiones que ocurren verbalmente en reuniones donde nadie tomó notas, o distinguir «sí, hagamos eso» de un compromiso genuino (el incidente del café nos enseñó mucho sobre los umbrales de confianza). Pero el tiempo que paso buscando decisiones pasadas ha bajado de «regularmente frustrante» a «ocasionalmente leve», lo que parece una trayectoria razonable.
Recibe inteligencia de señales en tu bandeja de entrada.
Preguntas frecuentes
¿Cómo encuentro una decisión que se tomó en un hilo de Slack hace semanas?
Sin un índice entre herramientas, estás haciendo lo que yo hice – desplazándote, probando diferentes palabras clave, esperando recordar más o menos cuándo ocurrió la conversación. Sugarbug incorpora los mensajes de Slack junto con tus otras fuentes en un grafo de conocimiento, para que puedas buscar por concepto en lugar de por palabras clave exactas. No es magia – la conversación todavía tiene que haber ocurrido en texto – pero es mejor que la excavación arqueológica.
¿Sugarbug rastrea automáticamente las decisiones entre herramientas?
Lo hace. Cada señal de tus herramientas conectadas se clasifica – decisiones, actualizaciones de estado, preguntas, bloqueos – y se vincula con las personas y tareas relevantes. Cuando una decisión aparece en un hilo de Slack relacionado con un issue de Linear, el grafo los conecta sin que nadie tenga que copiar y pegar un enlace o actualizar un registro.
¿Cuál es la diferencia entre un registro de decisiones y un grafo de conocimiento?
Un registro de decisiones requiere que alguien escriba qué se decidió, cuándo y por quién. Un grafo de conocimiento construye esas conexiones automáticamente a partir de las señales que tus herramientas ya están produciendo – el hilo de Slack, el issue de Linear, el PR que lo implementó. Uno requiere disciplina (en la que, como he establecido exhaustivamente, somos pésimos); el otro requiere un sistema.
¿Por qué los registros de decisiones siempre fallan?
Porque la carga cae exactamente en el momento equivocado. Tendrías que reconocer una decisión como importante mientras ocurre, pausar, cambiar a otra herramienta, escribirla con suficiente contexto para que sea útil semanas después, y luego volver al trabajo sin perder el hilo. Todos los equipos que he visto intentarlo lo abandonan en seis semanas – no por pereza, sino porque el proceso lucha contra la forma en que las personas realmente trabajan.
¿Pueden beneficiarse los equipos pequeños, o esto solo es para grandes organizaciones?
Los equipos pequeños lo sufren más, en mi experiencia. No hay un gestor de proyectos dedicado que mantenga la documentación, y la «memoria institucional» son una o dos personas que resultan tener buena memoria. Una startup de cinco personas que toma docenas de micro-decisiones a la semana a través de Slack, GitHub y Notion tiene el mismo problema de fragmentación que una organización de cincuenta personas – solo con menos gente para absorber el coste cuando algo se pierde.
---
Si alguna vez has estado en una llamada mientras cinco personas intentan reconstruir una decisión que ya se había resuelto semanas antes, ese es exactamente el problema que construimos Sugarbug para eliminar. Únete a la lista de espera.