Cómo gestionar proyectos largos con IA: tutorial de pases de testigo sin perder el hilo

canonical_url: «https://margapress.com/proyectos-largos-conversaciones-sesiones-pase-testigo/»

---

Un proyecto largo con IA —una propuesta de negocio, un análisis de mercado, un plan de comunicación, una revisión de procesos— no se produce en una sola sesión. Se trabaja en sesiones separadas durante días o semanas. Y cada vez que se abre una nueva sesión, el modelo empieza de cero.

El coste de esta discontinuidad es real, pero raramente se mide con precisión. ¿Cuánto tiempo se pierde en cada sesión en «poner al día» al modelo? ¿Cuántos errores de coherencia se producen porque el modelo no recuerda decisiones tomadas en sesiones anteriores? ¿Qué métodos de pase de testigo son más efectivos?

En el laboratorio pasamos seis semanas trabajando proyectos largos con distintos protocolos de continuidad para medir exactamente eso.

El experimento: tres proyectos, tres protocolos, seis semanas

Trabajamos tres proyectos de complejidad real:

• Plan de marketing para lanzamiento de producto (12 sesiones, 3 semanas)
• Informe de análisis de procesos internos (8 sesiones, 2 semanas)
• Propuesta de servicios para cliente (6 sesiones, 10 días)

Cada proyecto se trabajó con uno de tres protocolos de continuidad:

Protocolo A — Sin estructura: iniciar cada sesión con el estado actual del documento y una descripción verbal de dónde estamos.

Protocolo B — Documento de estado: mantener un documento de «estado del proyecto» actualizado al final de cada sesión, con: decisiones tomadas, rationale, próximos pasos y puntos abiertos. Ese documento es el primer mensaje de cada nueva sesión.

Protocolo C — Resumen estructurado + documento vivo: el documento de estado del protocolo B más un «documento vivo» que se actualiza con el trabajo producido en cada sesión, organizado por secciones del proyecto.

Resultado 1: el coste de la discontinuidad sin protocolo

Con el protocolo A, las primeras dos o tres sesiones produjeron trabajo de buena calidad. A partir de la sesión cuatro, se empezaron a detectar inconsistencias: el modelo recomendó en la sesión cinco una táctica que había sido descartada en la sesión dos. En la sesión siete, cambió el tono del público objetivo sin advertirlo (de B2B a B2C en un párrafo del plan de marketing). En la sesión diez, propuso una estructura de propuesta diferente a la que ya se había acordado.

El tiempo empleado en detectar y corregir estas inconsistencias representó el 34% del tiempo total de trabajo en el proyecto con protocolo A. Más de un tercio del tiempo del proyecto fue básicamente re-trabajo por falta de continuidad.

Resultado 2: el protocolo B reduce el re-trabajo al 12%

Con el documento de estado, el inicio de cada sesión incluía un recordatorio estructurado de todo lo decidido. Las inconsistencias no desaparecieron del todo (algunas decisiones matizadas no se habían documentado con suficiente detalle), pero se redujeron drásticamente.

El tiempo de re-trabajo bajó al 12% del tiempo total. La mejora principal: las decisiones mayores (estrategia, enfoque, estructura) no se contradijeron en ninguna sesión posterior. Las inconsistencias que sí aparecieron fueron en detalles de implementación que no habían sido documentados.

Resultado 3: el protocolo C es el más robusto pero el más exigente

El protocolo C prácticamente eliminó las inconsistencias (re-trabajo del 4% del tiempo total), pero tuvo el mayor coste de mantenimiento: actualizar el documento de estado y el documento vivo al final de cada sesión tomaba entre 10 y 20 minutos adicionales por sesión.

Para el proyecto de plan de marketing (12 sesiones), ese mantenimiento supuso 2.5 horas adicionales de trabajo total. El ahorro en re-trabajo fue de 4.2 horas. El balance neto fue positivo, pero solo por 1.7 horas.

Para proyectos más cortos (3-4 sesiones), el protocolo C puede no justificar el overhead. El protocolo B es el mejor compromiso para la mayoría de casos.

El contenido del documento de estado que más importa

En el análisis de qué información del documento de estado tenía mayor impacto en la prevención de inconsistencias, identificamos tres categorías imprescindibles:

Decisiones con rationale: no solo «decidimos X» sino «decidimos X porque [razón]». Sin el rationale, el modelo puede ignorar la decisión si en el nuevo contexto X parece subóptima.

Opciones descartadas con por qué: el 40% de las inconsistencias en el protocolo A eran el modelo proponiendo de nuevo algo que ya había sido descartado. Documentar las opciones rechazadas y la razón reduce esto al 8%.

Próximo paso específico al inicio de la siguiente sesión: «la siguiente sesión debe comenzar por X» al final del documento de estado reduce el tiempo de arranque de sesión en 5-10 minutos y evita duplicaciones.

La estructura mínima del documento de estado

Para que el documento de estado sea útil sin convertirse en una carga de mantenimiento:

«`

ESTADO DEL PROYECTO — [nombre] — Actualizado: [fecha]

OBJETIVO: [una línea]

FASE ACTUAL: [dónde estamos]

DECISIONES VIGENTES: [lista de las 5-10 decisiones clave con rationale breve]

OPCIONES DESCARTADAS: [lista con por qué]

PENDIENTE/PUNTOS ABIERTOS: [lo que está sin resolver]

PRÓXIMA SESIÓN: [primer paso concreto]

«`

Con esta estructura, el documento de estado raramente necesita más de una página, y el inicio de sesión con él toma 2-3 minutos en lugar de los 10-15 minutos de puesta al día del protocolo A.

---

El sistema completo de gestión de proyectos largos con IA está en El Empleado Digital.

Descarga el libro en Amazon | Lee el artículo original en MargaPress