Organizar un proyecto.

• Tiempo: tres cuartos de hora para montarlo, y diez minutos a la semana.
• Plan: cualquiera. Hay proyectos en todos los planes; en Free, cinco como mucho.
• Necesitas: el brief o lo que hay escrito del proyecto, las fechas que ya están comprometidas, quién hace qué y tus notas.

Un proyecto en Claude por cada cosa a la que vuelves: un cliente, un lanzamiento, el informe de cada mes. Dentro van los archivos que hacen falta siempre (el brief, los acuerdos, las plantillas, las cifras de referencia) y unas instrucciones que valen para todas sus conversaciones. Cómo funcionan por dentro está en el capítulo 4.

Cuándo sí y cuándo no

Úsala cuando un trabajo dura semanas, tiene fechas y depende de más gente: un lanzamiento, una cuenta, una implantación. Para la tarea de una tarde, sobra.

No lleva el proyecto por ti. Ordena, resume y redacta con lo que le das; las decisiones, las fechas y quién hace qué siguen saliendo de las personas.

Los textos

El 01 y el 02, en una conversación; el 03 va en las instrucciones del proyecto; el 04, cada semana dentro del proyecto, y el 05, en una conversación nueva. Lo que va entre corchetes lo cambias tú.

01 · La ficha

Con tus notas adjuntas:

Te paso lo que tengo de [el proyecto]. Antes de planificar nada, escribe una ficha de una página:
- el problema que resuelve y por qué importa ahora;
- cómo sabremos que ha salido bien, con algo que se pueda medir;
- qué queda fuera;
- lo que sabemos y lo que todavía no sabemos.
Si te falta algo para escribirla, pregúntame, de una en una.

Es lo que Atlassian llama el póster del proyecto, y se hace antes del plan: hay proyectos que van en verde durante semanas y saltan a rojo de golpe, y muchas veces es porque nadie escribió lo que se estaba dando por hecho.

02 · Lo que puede salir mal

Imagina que es [la fecha de fin] y el proyecto ha fracasado. Dame las ocho o diez razones más probables, pensando en este proyecto y no en proyectos en general.

Con eso, haz el registro del proyecto en una tabla con cuatro partes:
- Riesgos: lo que puede pasar, con su impacto, quién lo vigila y qué haremos.
- Supuestos: lo que damos por cierto, y cómo y cuándo lo comprobamos.
- Incidencias: lo que ya está pasando.
- Dependencias: qué tiene que entregarnos quién, y para cuándo.
No confundas un riesgo (puede pasar) con una incidencia (ya pasa). Si no sabes quién es el responsable de algo, márcalo; no lo rellenes.

Lo primero es el pre-mortem que propuso Gary Klein en Harvard Business Review en 2007: imaginar que ya ha fracasado saca lo que nadie se atreve a decir en voz alta en una reunión de arranque. Lo segundo, el registro que en gestión de proyectos se llama RAID por sus iniciales en inglés. Guarda la ficha y el registro como archivos del proyecto, para que los vean todas sus conversaciones.

03 · Las instrucciones del proyecto

Esto va en las instrucciones del proyecto, no en una conversación:

Este proyecto es [qué: la cuenta de un cliente, el lanzamiento de un producto, el informe mensual].
Yo soy [tu papel] y lo que escribas aquí lo van a leer [quién].
En los archivos tienes la ficha, el registro y [el brief, los acuerdos, las plantillas]. Si algo no está en ellos ni en lo que te diga, pregúntame antes de suponerlo.
El estado va con este semáforo: verde, si cumplir plazo, coste y calidad es muy probable; ámbar, si es factible pero hay problemas serios; rojo, si tal como va no se llega.
Por defecto, entrégame [el formato: resúmenes de media página, tablas, viñetas cortas].

Los colores del semáforo son los del Gobierno británico para sus grandes proyectos, que los pone según la confianza en entregar y no según lo que se esfuerza el equipo.

04 · El informe de cada semana

En una conversación dentro del proyecto:

Con lo que hay en el proyecto y estas notas de la semana, prepárame el informe de estado: el color del semáforo y por qué; qué se ha hecho; qué está bloqueado y por qué; qué viene la semana que viene, con su responsable; y qué decisiones necesito, de quién y para cuándo. Actualiza el registro con lo que haya cambiado. Si no encuentras quién es el responsable de algo, márcalo; no lo rellenes.

La última frase viene de un ejemplo de Anthropic para informes de estado: que marque lo que no encuentra en vez de rellenar el hueco. Es lo que separa un informe útil de uno que parece completo.

05 · La lectura de quien aprueba

En una conversación nueva, fuera del proyecto, pega la ficha y el registro:

Te paso la ficha y el registro de riesgos de un proyecto que no conoces. Eres [quien tiene que aprobarlo: la dirección, el cliente]. Dime qué supuesto no te crees, qué riesgo falta y qué fecha te parece optimista. Clasifica cada punto en «hay que arreglarlo» o «a considerar».

Antes de dar el proyecto por montado

• Lo importante, en las instrucciones. Claude no ve el nombre ni la descripción del proyecto.
• Los archivos, al día. Si cambia el brief, cambia el archivo; si no, seguirá trabajando con el viejo.
• Archivos de hasta 30 MB cada uno. Si un PDF pesa más, pártelo.
• Lo que tiene que saber cualquier conversación, en los archivos. Una conversación del proyecto no tiene delante lo que se habló en las otras, salvo lo que guarde su memoria o lo que le pidas que busque.

Vas bien si el informe del lunes te lleva diez minutos y el semáforo se pone en ámbar antes de que el problema te pille por sorpresa.

Si sale mal

Si pasa esto	Dile esto
Todo está en verde	«Aplica las reglas del semáforo, no el ánimo del equipo. ¿Qué tendría que pasar para que esto esté en ámbar?»
Confunde riesgos con incidencias	«Un riesgo puede pasar; una incidencia ya está pasando. Muévelas a su sitio.»
El informe repite lo de la semana pasada	«Compáralo con el informe anterior y dime solo qué ha cambiado.»
El pre-mortem es genérico	«Esas razones valen para cualquier proyecto. Dame las de este, con nombres, fechas y dependencias concretas.»

Sube de nivel

• Si las tareas viven en Asana o en ClickUp, conéctalo. Los dos tienen conector hecho por ellos mismos, y así el informe sale del estado real de las tareas y no de lo que tú le cuentes.
• El informe de cada semana puede prepararse solo. En los planes de pago, como tarea programada: en el capítulo 6 está montado con una skill de informe semanal, para que salga siempre con tu formato.
• Para escribir el plan entre varios, está Claude Docs, en beta y de pago: Claude escribe delante de ti, deja comentarios explicando lo que ha decidido y el equipo edita a la vez.