Plantilla de actualización semanal asíncrona: avances, planes, problemas y quién la publica

La plantilla de actualización semanal

Cópiala en la herramienta que use tu equipo. Los corchetes son lo único que cambias.

**[Producto o área] — semana del [fecha]**

**Estado:** En plazo / En riesgo / Retrasado
**Responsable:** [nombre]

**Avances**
- [Elemento entregado o terminado, con enlace]
- [Elemento entregado o terminado, con enlace]
- [Decisión tomada, y dónde quedó registrada]

**Planes**
- [Qué estará terminado para la próxima actualización]
- [Qué estará terminado para la próxima actualización]
- [Qué va a empezar]

**Problemas**
- [Bloqueo, quién puede desbloquearlo, para cuándo]
- [Riesgo que puede retrasar la fecha, y qué lo cambiaría]
- Ninguno, si es cierto

**Cifras**
- [Métrica]: [valor] (semana pasada [valor])
- [Métrica]: [valor] (semana pasada [valor])

**Necesita una decisión**
- [Pregunta], de [nombre], antes del [fecha]

Seis apartados, unas doce líneas y ningún párrafo de más de una frase. Cualquiera puede leerla en el móvil dentro de un ascensor.

Por qué funciona el formato avances, planes, problemas

El formato lleva décadas en uso porque cada sección responde a una pregunta que el lector se hace.

Avances responde a "¿pasó algo?". Debe listar cosas terminadas, no cosas en las que se trabajó. "Trabajamos en el checkout" es actividad; "Checkout activo para el 40 % del tráfico" es avance. Enlaza cada elemento para que quien quiera el detalle pueda ir a buscarlo sin preguntar.

Planes responde a "¿qué puedo esperar la semana que viene?". Es un compromiso, así que limítalo a tres puntos. La sección de Avances de la semana próxima se leerá contra los Planes de esta, y de esa comparación nace la honestidad. Si el mismo plan aparece tres semanas seguidas, la actualización ha sacado a la luz un problema sin que nadie tenga que decirlo.

Problemas responde a "¿dónde me necesitas?". Es la sección que los responsables leen primero y la que quien escribe omite con más frecuencia. Una buena línea de problema nombra el bloqueo, la persona que puede resolverlo y una fecha. "Esperando a legal" es una queja. "Necesito la firma del contrato de Dana antes del jueves o el piloto se retrasa una semana" es una petición.

Las dos secciones adicionales, Cifras y Necesita una decisión, son opcionales, pero son las que hacen que la actualización valga más que una reunión. Las cifras dan forma a la semana a lo largo del tiempo. Las decisiones dan a los lectores un motivo para responder.

Quién publica la actualización semanal

Un responsable por producto o área, no uno por persona. Un equipo de ocho con tres productos publica tres actualizaciones, no ocho. Las actualizaciones personales se convierten en listas de tareas, y nadie lee la lista de tareas de otro.

El responsable es la persona a la que preguntarían "¿cómo va?" en una reunión. Normalmente es quien lidera el producto, el ingeniero que lleva más carga o el fundador para todo lo que no tenga un líder definido. Rotar el puesto no funciona bien; el valor de la actualización viene de una sola voz siguiendo una sola cosa semana tras semana.

Publícala aunque no haya pasado nada. Una semana con "Avances: ninguno, el equipo estuvo en la conferencia" es una actualización útil. Una semana que falta es un hueco que el lector rellena con preocupación.

Cuándo se publica

Elige un día y una hora y no los muevas. La mayoría de los equipos que conocemos publican el viernes por la tarde, que cierra la semana mientras está fresca, o el lunes antes de las 10:00, que la pone en marcha. Las actualizaciones del viernes se leen el lunes de todos modos, así que la elección depende sobre todo de cuándo prefiere escribir quien las redacta.

Fija un plazo de unas dos horas después de la hora de publicación para los comentarios. Pasado ese plazo, todo lo que no se haya resuelto en el hilo pasa a la sección de Problemas de la semana siguiente o a una llamada programada entre las dos personas que no están de acuerdo. Sin un corte, el hilo queda abierto toda la semana y la actualización se convierte en una reunión que nunca termina.

Qué sustituye a la reunión de estado

Una reunión de estado hace cuatro cosas: informa de los avances, saca a la luz los bloqueos, fuerza decisiones y permite que la gente se escuche. La actualización escrita cubre las dos primeras mejor que una reunión, porque el registro se conserva y nadie tiene que asistir. Las otras dos necesitan su propio espacio.

El patrón que funciona es este: cancela la reunión de estado, mantén una llamada semanal de 20 minutos que da por hecho que todos han leído las actualizaciones y dedícala solo a decisiones abiertas y a conversar. Si no hay nada que tratar, termínala en cinco minutos. La gente notará que ahora la llamada merece la pena.

Dónde publicarla

El lugar correcto es donde la gente que la necesita ya mira, con tres pruebas: debe poder buscarse más adelante, debe admitir comentarios debajo y no debe desaparecer bajo el chat del día.

Los canales de chat fallan la tercera prueba. Una actualización semanal en un canal con movimiento queda enterrada antes de la hora de comer. Si el chat es la única herramienta que tienes, fija la actualización o publícala en un canal que no lleve nada más.

Los canvases de Slack son documentos dentro de Slack que se pueden fijar como pestaña de un canal y comentar. Según el centro de ayuda de Slack, los canvases están disponibles en los planes de pago; el plan Pro cuesta 8,75 $ por usuario al mes con facturación mensual, o 7,25 $ con facturación anual, a octubre de 2026. Un canvas por producto, actualizado cada semana, mantiene el historial en un solo sitio y queda junto a la conversación.

Los check-ins automáticos de Basecamp resuelven el problema desde el otro lado. Defines una pregunta, como "¿En qué trabajaste esta semana?", con una frecuencia diaria, semanal o mensual, y Basecamp se la hace a cada persona y reúne las respuestas. El plan Freelancer de Basecamp cuesta 29 $ al mes para hasta 5 usuarios, Pro 79 $ para hasta 10 y Pro Plus 99 $ para hasta 15, a octubre de 2026; el plan gratuito está limitado a 3 usuarios. El modelo de check-in funciona mejor para actualizaciones personales; para una actualización a nivel de producto con cifras sigues queriendo un documento. La comparativa con Basecamp cubre el resto del producto.

Una herramienta de proyectos con feed es lo que usamos nosotros. En Atrix, cada producto tiene una página con su propio flujo de actualizaciones, y publicar una allí también la coloca en el feed del espacio de trabajo. Escribir el nombre de alguien en una actualización le envía una notificación, incluida una notificación push al móvil, así que solo nombramos a una persona cuando la actualización realmente la necesita, lo que en la práctica significa las secciones de Problemas y Necesita una decisión y nada más. Una actualización que nombra a seis personas es una convocatoria de reunión disfrazada. Nuestro chat de equipo queda para la conversación que sigue.

Para la sección de Cifras, los datos deberían salir del gestor de trabajo y no de la memoria. El servidor MCP de Atrix tiene una herramienta project_status que devuelve las cifras de estado de un producto: porcentaje completado, trabajo por estado, qué está vencido, qué lleva más de una semana atascado en progreso o en revisión, qué vence en los próximos siete días y qué se terminó esta semana. Pedir a un asistente que "redacte la actualización de esta semana de Checkout a partir de project_status" produce las secciones de Avances y Cifras en aproximadamente un minuto, y el responsable edita en lugar de escribir. No te escribirá la sección de Problemas; el gestor no sabe que Dana está de vacaciones.

Cómo implantarla en cinco pasos

1. Elige a los responsables y el día. Déjalos por escrito en un sitio público. Si un producto no tiene un responsable claro, ese es el primer problema que la actualización sacará a la luz.
2. Publica la primera tú mismo. El fundador o líder escribe la primera actualización con la plantilla de arriba, incluida una sección de Problemas real. El equipo copia el tono de la primera, así que hazla honesta y corta.
3. Cancela la reunión de estado desde la segunda semana. No la "acortes". Una reunión que sigue existiendo es el sitio al que las actualizaciones volverán en silencio.
4. Lee y responde dentro del plazo. En la segunda semana, el responsable comprueba si alguien comentó. Si nadie lo hizo, el líder responde a cada actualización con una pregunta. Las actualizaciones mueren por silencio, no por esfuerzo.
5. Revisa tras seis semanas. Compara las secciones de Planes con los Avances que vinieron después. Si los planes rara vez se cumplieron, la plantilla está haciendo su trabajo y lo que hay que arreglar es la planificación.

Errores habituales

• Demasiado larga. Si hay que desplazarse en el móvil para leerla, es un informe, no una actualización. Lleva el detalle a páginas enlazadas.
• Sin problemas durante un mes. Ningún equipo tiene cero problemas durante cuatro semanas. Una sección de Problemas vacía suele significar que el responsable tiene reparos en escribirlos. Pide un problema por semana hasta que resulte normal.
• Actividad en lugar de resultados. "Tuvimos tres llamadas con el proveedor" es actividad. "El proveedor confirmó la entrega para el 12 de noviembre" es avance.
• Nombrar a todo el mundo. Si una herramienta notifica a las personas que mencionas, cada nombre es una interrupción. Nombra a quien debe actuar, no a quienes podrían estar interesados.
• Cifras sin las de la semana pasada. Una métrica sola es un dato; la misma métrica junto a la de la semana pasada es una tendencia.

Preguntas frecuentes

¿Qué debe incluir una actualización semanal?

Tres secciones como mínimo: avances desde la semana pasada (cosas terminadas, con enlaces), planes para la próxima (como máximo tres compromisos) y problemas (cada uno con una persona y una fecha). Añade una sección de cifras con los valores de la semana anterior al lado y una lista corta de decisiones que necesitas de los lectores.

¿Cuánto debe ocupar una actualización semanal de equipo?

Lo bastante corta para leerla en el móvil sin apenas desplazarse: entre 150 y 300 palabras, o unas doce líneas de viñetas. Todo lo que necesite más espacio debería ser una página enlazada, no una actualización más larga.

¿Quién debe escribir la actualización de estado semanal?

Un responsable por producto o área, normalmente quien lo lidera o quien lleva más carga de trabajo. Las actualizaciones personales de cada miembro del equipo se convierten en listas de tareas que nadie lee. Un equipo de ocho con tres productos debería publicar tres actualizaciones.

¿Una actualización escrita puede sustituir de verdad la reunión de estado?

Sustituye la mitad de informar. Mantén una llamada corta y opcional para decisiones abiertas y para hablar entre vosotros, sin estado en la agenda. Los equipos que cancelan la reunión por completo y conservan la llamada ven que la llamada se acorta cada semana.

¿Qué herramientas sirven para actualizaciones semanales asíncronas?

Cualquiera en la que la actualización pueda buscarse después, admita comentarios y no desaparezca bajo el chat. Los canvases de Slack fijados a un canal, los check-ins automáticos de Basecamp o una herramienta de proyectos con un feed de actualizaciones por producto como Atrix cumplen. Un canal de chat normal no.

¿Cuál es la diferencia entre una actualización semanal y un standup diario?

Un standup diario trata de la coordinación de las próximas 24 horas y suele ser por persona. Una actualización semanal trata del estado de un producto a lo largo de la semana y es por producto o área. Los equipos pequeños suelen poder dejar el diario una vez que el semanal es fiable.

Siguiente paso

Si tus actualizaciones viven junto al trabajo, la sección de Avances casi se escribe sola. Mira cómo encajan productos, ciclos y feeds de actualizaciones en la gestión de proyectos de Atrix, o empieza con la plantilla de arriba en lo que ya uses.