Las tareas olvidadas no son un problema de personas
Por qué las tareas olvidadas en la gestión de proyectos no son cuestión de disciplina – y cuándo tu equipo necesita un sistema que las detecte.
By Ellis Keane · 2026-03-17
Si tu equipo es lo suficientemente pequeño como para que todos coman juntos (o al menos pudieran, hipotéticamente, si alguna vez estuvieran en la misma ciudad al mismo tiempo), probablemente no necesitas leer esto. Cierra la pestaña. Ve a construir algo. El problema de las tareas olvidadas a tu escala está a un recordatorio de Slack un miércoles por la tarde de estar resuelto – y lo digo en serio.
¿Sigues aquí? Bien. Hablemos entonces de las tareas olvidadas en la gestión de proyectos – y, más concretamente, de por qué el consejo estándar deja de funcionar cuando el equipo alcanza cierto tamaño.
Antes de continuar
Desarrollamos una herramienta que aborda este problema (Sugarbug – mentiría si fingiera lo contrario), pero la respuesta honesta es que la mayoría de los equipos que leen esto aún no necesitan lo que estamos construyendo. Quizás nunca. Lo que necesitan es entender por qué se olvidan las tareas en primer lugar, porque la solución depende de la causa, y la causa casi nunca es lo que la gente cree.
Por qué se olvidan las tareas
Pregunta a la mayoría de los managers por qué se olvidan tareas y escucharás una lista familiar: alguien olvidó, alguien no prestó atención, alguien no siguió el proceso. La solución, por tanto, son mejores procesos, más recordatorios, quizás un bot de standup que avisa a todos cada mañana.
Y sí, a veces ese es genuinamente el problema. Si tu desarrollador olvidó actualizar el ticket de Linear y tu PM no lo verificó antes de la revisión del sprint, eso es un fallo humano y una brecha de proceso. Añade una lista de verificación. Sigue adelante.
Pero ese no es el tipo de tarea olvidada que desvela a los engineering managers. El que realmente duele es aquel en el que todo el mundo hizo su trabajo, siguió su proceso, actualizó sus herramientas – y algo cayó igualmente por la brecha. Porque la brecha no está entre una persona y su tarea. Está entre una herramienta y otra.
Aquí está lo que quiero decir. Un desarrollador envía un PR que cierra un issue de GitHub. El issue estaba vinculado a un ticket de Linear, y el ticket pasa a "Hecho". Genial. Excepto que la solicitud original vino de una conversación en Slack hace tres semanas en la que el PM también mencionó un requisito de seguimiento que nadie registró nunca como tarea separada. Ese seguimiento vive en un hilo de Slack de febrero. No está en Linear. No está en GitHub. No está en el sprint de nadie. Es técnicamente una tarea olvidada, pero ninguna persona en particular la dejó caer – cayó a través de la brecha estructural entre Slack y el rastreador de tareas.
Este patrón aparece en todas partes una vez que empiezas a buscarlo. Un diseñador deja un comentario en Figma señalando que un caso límite contradice el spec de Notion, pero el desarrollador que trabaja en la funcionalidad nunca revisa Figma y el PM nunca ve el comentario porque vive en Linear. Un responsable de customer success promete una funcionalidad en una llamada, la resume en un correo, y nunca llega al backlog de ingeniería porque nadie cubre esa brecha en particular. Un post-mortem de incidente identifica tres puntos de seguimiento, el documento se comparte en Slack, y dos de los tres nunca se convierten en tareas rastreadas porque la persona que normalmente hace eso estaba de baja esa semana.
Las tareas olvidadas más dañinas en la gestión de proyectos ocurren en las brechas entre herramientas, no en las brechas entre las personas y sus listas de tareas.
La solución de proceso (y dónde deja de funcionar)
Creo genuinamente que los buenos procesos resuelven la mayoría de estos problemas para la mayoría de los equipos. Aquí está lo que funciona, y lo comparto sin ningún interés oculto porque (para ser honesto) estamos en pre-lanzamiento y lo mejor que podemos hacer ahora es generar confianza siendo útiles.
La revisión semanal. Una persona – idealmente el PM o el engineering lead – pasa 30 minutos cada viernes revisando hilos de Slack, notas de reuniones y correos para capturar todo lo que se discutió pero nunca se registró. ¿Tedioso? Absolutamente. ¿Efectivo? Sorprendentemente sí, hasta cierto punto.
El registro de decisiones. Cada decisión que sale de un hilo de Slack o una reunión se pega en un documento compartido (Notion, Google Docs, lo que sea) con la fecha, quién decidió y cuál es el seguimiento. Esto suena sencillo, y lo es, hasta que estás tomando quince decisiones a la semana en cuatro canales y nadie recuerda cuáles se registraron.
La disciplina de vinculación. Cada PR referencia su ticket de Linear. Cada ticket de Linear enlaza al hilo de Slack donde se discutió el requisito. Cada spec de Notion enlaza a su epic de Linear. Si alguien rompe la cadena – y alguien lo hará, no es cuestión de si sucede sino de cuándo –, la visibilidad se rompe con ella.
Estas son todas buenas prácticas. Nosotros mismos usamos versiones de las tres. Pero tienen un modo de fallo común: dependen de que los humanos hagan de manera consistente una pequeña tarea aburrida cada vez, para siempre. Y la evidencia sobre eso no es alentadora – no necesito citar investigaciones. Si has gestionado un equipo de más de cinco personas, ya lo sabes.
Cuándo la solución de proceso deja de escalar
Hay un umbral, y ojalá pudiera darte un número exacto, pero aún no lo hemos determinado (honestamente, probablemente varía según el equipo y la disciplina de sus miembros). Nuestra heurística de trabajo – y quiero dejar claro que es una heurística, no datos contrastados – es que las cosas empiezan a fallar en algún punto alrededor de cuatro o cinco herramientas, más de diez personas y múltiples flujos de trabajo paralelos.
No porque nadie se volviera perezoso. No porque el proceso fuera malo. Sino porque el volumen de conexiones entre herramientas supera la capacidad de cualquier persona para rastrearlas manualmente. La revisión semanal tarda 90 minutos en lugar de 30, y el PM empieza a leerla por encima. El registro de decisiones queda obsoleto porque la persona que lo mantenía se fue de vacaciones y nadie lo retomó. La disciplina de vinculación se mantiene para Linear y GitHub pero se desmorona para Slack y Figma porque esas herramientas no tienen el mismo tipo de referencias estructuradas.
Esto es – y quiero ser claro – un problema de escala, no un problema de disciplina. He visto a PMs y engineering leads genuinamente excelentes luchar con esto – personas que llevan un barco bien organizado y se preocupan profundamente de que nada se pierda. A cierta escala, el problema supera la solución. No es un fallo de la persona – es un fallo del ecosistema de herramientas para conectarse entre sí.
"La recompensa por ser sofisticado con tus herramientas es una superficie de fallo más compleja para las tareas olvidadas. Lo encuentro profundamente irónico." – Ellis Keane
Y aquí está la parte que creo que es genuinamente injusta: cuanto mejor es tu equipo en el uso de sus herramientas, mayor es la superficie para las brechas entre herramientas. Un equipo que usa Linear de forma religiosa, mantiene los specs de Notion actualizados, tiene revisiones activas en Figma y se comunica en canales de Slack bien organizados tiene más puntos de transferencia que un equipo que solo usa correo electrónico y una hoja de cálculo.
Por qué tus herramientas no pueden ayudar
Aquí está lo que encuentro genuinamente interesante de todo este problema, y que creo que no se discute lo suficiente: tus herramientas están haciendo exactamente para lo que fueron diseñadas. Linear es excelente rastreando issues de Linear. GitHub es excelente rastreando cambios de código. Notion es excelente organizando documentos. Slack es excelente siendo... Slack (para bien o para mal).
Pero ninguna de ellas fue diseñada para rastrear las conexiones entre sí. Y el trabajo, el trabajo real, no ocurre dentro de una sola herramienta – fluye a través de todas. Los puntos de transferencia entre herramientas son donde las cosas desaparecen, y ninguna mejora de ninguna herramienta individual lo soluciona. Puedes hacer que Linear sea mejor rastreando issues, pero eso no ayuda cuando el issue debería haberse creado en primer lugar basándose en una conversación de Slack que ocurrió en un canal que el engineering lead no monitorea.
Qué lo solucionaría realmente
He sido deliberadamente vago sobre los aspectos del producto en este artículo, y eso es intencional – quería que fuera útil independientemente de si alguna vez usas algo de lo que construimos. Pero ya que has llegado hasta aquí (y lo aprecio), déjame ser honesto sobre cómo creo que se ve la solución real.
No es un mejor rastreador de tareas. No es un mejor proceso. No es un bot de standup ni una revisión semanal ni una hoja de cálculo compartida. Todo eso ayuda, y a pequeña escala es suficiente, pero todos tratan el síntoma.
La solución real es algo que observe las conexiones entre tus herramientas y señale cuando algo no cuadra. Cuando una decisión de Slack no se convierte en un ticket. Cuando un PR de GitHub cierra un issue pero hay comentarios sin resolver. Cuando un spec de Notion hace referencia a un requisito que fue deprioritizado en una conversación que el autor del spec nunca vio.
Para hacerlo concreto: imagina que tu sistema observa tanto Slack como Linear. Ve una conversación en #engineering donde alguien dice "también deberíamos manejar el caso en que el usuario no ha verificado su correo" – ese es un nuevo requisito. Si ese requisito no aparece como ticket de Linear en, digamos, 48 horas, el sistema lo señala. No con una notificación que te grita (nadie necesita más de esas), sino como entrada en una vista de "decisiones aún no rastreadas" que el PM puede revisar durante su revisión del viernes. Lo mismo para PRs de GitHub que cierran tickets de Linear pero todavía tienen comentarios de revisión abiertos, o specs de Notion que hacen referencia a funcionalidades que han sido depriorizadas desde que se escribió el spec.
Si lo construyes internamente (algunos equipos lo hacen, con webhooks, una cola de mensajes y algo de código de pegamento), usas algo ya disponible, o simplemente aceptas las tareas olvidadas como un coste operativo – esa es tu decisión. Estamos construyendo una versión de esta respuesta, pero no es la única versión, y para muchos equipos todavía no es la correcta.
Si quieres saber cuándo podría ser la correcta para ti, aquí está mi heurística honesta: si tu revisión semanal tarda más de 30 minutos y las cosas siguen cayendo, has superado el enfoque manual.
---
Cuando la revisión semanal tarda más de 30 minutos y las cosas siguen cayendo, has superado el enfoque manual. Sugarbug vigila las brechas automáticamente.
Q: ¿Cómo previene Sugarbug las tareas olvidadas en la gestión de proyectos? A: Sugarbug construye un grafo de conocimiento a través de tus herramientas – Linear, GitHub, Slack, Figma, Notion – y rastrea tareas, conversaciones y decisiones mientras se mueven entre ellas. Cuando algo se detiene o pierde la conexión con la solicitud original, Sugarbug lo hace visible antes de que se pierda. No es un sistema de recordatorios – comprende las relaciones entre elementos en todas las herramientas y señala cuando esas relaciones se rompen.
Q: ¿Puede Sugarbug detectar tareas que se discuten en Slack pero nunca se registran? A: Sí. Sugarbug monitorea las conversaciones de Slack e identifica cuando se discute una decisión o un punto de acción pero nunca aparece como tarea en Linear o ticket en GitHub. Señala el vacío para que alguien pueda actuar. Todavía estamos refinando cuán agresivamente debe señalar (nadie quiere fatiga de herramientas encima de todo lo demás), pero la detección central funciona.
Q: ¿Necesito una herramienta para solucionar las tareas olvidadas, o es un problema de proceso? A: Honestamente, depende de la escala. Los equipos pequeños con dos o tres herramientas generalmente pueden solucionarlo con mejores hábitos – una revisión semanal, un documento compartido, una disciplina de vinculación. Pero cuando superas las cuatro o cinco herramientas y más de diez personas, el enfoque manual deja de escalar y necesitas algo que rastree las conexiones automáticamente. El umbral varía según el equipo, pero lo sabrás cuando lo alcances.
Q: ¿Cuál es la diferencia entre un rastreador de tareas y un sistema de inteligencia de señales para la gestión de proyectos? A: Un rastreador de tareas registra lo que le dices. Un sistema de inteligencia de señales observa lo que realmente está ocurriendo en todas tus herramientas y señala cuando algo no cuadra – una tarea marcada como completada pero con comentarios sin resolver, una decisión tomada en Slack pero nunca reflejada en el spec. Captura las cosas que los humanos olvidan registrar, que, en nuestra experiencia, es donde se originan la mayoría de estas brechas.