Crear un Plan de Proyecto

Objetivo

Convertir una idea en fases, decisiones y tareas verificables. Un plan evita que OPS se convierta en una lista de tareas sueltas sin direccion.

El plan debe responder: que queremos conseguir, en que orden, con que limites, como sabremos que esta bien y que decisiones humanas quedan pendientes.

Cuando crear un plan

Crea o revisa un plan cuando:

arranca un proyecto;
cambia el alcance;
una tarea se vuelve demasiado grande;
hay varias fases dependientes;
necesitas coordinar humano, IA y despliegue;
una automatizacion recurrente necesita contexto estable;
otra persona podria incorporarse y necesitar entender el trabajo.

Antes de escribir el plan

Comprueba:

proyecto correcto;
objetivo claro;
usuario o responsable que revisa;
restricciones tecnicas o comerciales;
estado actual del sistema;
riesgos conocidos;
criterios de terminado;
si hay tareas antiguas que ya cubren parte del trabajo.

Por que importa:

Si el plan se crea en el proyecto equivocado, las tareas y horas se desordenan.
Si no hay criterio de terminado, cada fase acaba siendo interpretativa.
Si no se registran riesgos, la IA puede optimizar por velocidad y romper simplicidad.

Estructura recomendada

Un plan util deberia tener:

Contexto: por que existe el trabajo.
Objetivo: resultado que se busca.
No objetivos: cosas que no se haran ahora.
Fases: bloques pequenos y ejecutables.
Entregables: que queda visible al final de cada fase.
Validacion: como se comprueba.
Riesgos: que se puede romper.
Decisiones pendientes: que requiere humano.
Documentacion: que hay que actualizar si cambia el sistema.

Estructura completa de plan

Para proyectos pequenos, la estructura recomendada puede ser suficiente. Para proyectos de producto, cliente, automatizacion o runner local, usa una estructura mas completa.

1. Resumen ejecutivo

Debe poder leerse en menos de un minuto:

que se va a conseguir;
por que importa ahora;
que resultado visible quedara;
que no se va a hacer todavia;
quien revisa o aprueba.

Ejemplo:

> Preparar un ciclo de 30 dias para estabilizar la conversion entre builders, con tareas ejecutables por runner local, specs aprobadas y validacion por fase. El objetivo es poder probar el flujo sin lanzar automatizacion ciega.

2. Contexto y problema

Explica el origen del trabajo:

problema observado;
usuario o cliente afectado;
estado actual;
deuda o riesgo acumulado;
que pasa si no se hace.

No escribas solo "mejorar el sistema". Explica la friccion concreta.

3. Objetivo medible

Un objetivo medible combina resultado y criterio:

"Reducir warnings de quality gate a cero";
"Conseguir que 21 tareas tengan spec aprobada antes de entrar en cola";
"Publicar documentacion manual para reproducir el procedimiento";
"Validar dos proyectos piloto con checklist completo".

Si el objetivo no puede verificarse, probablemente no esta listo para convertirse en plan.

4. Alcance

Define que entra:

modulos;
pantallas;
datos;
proyectos;
integraciones;
documentos;
entornos;
tipos de usuario.

Ejemplo:

Entra: plan, tareas, specs, target local, perfil Codex y verificacion.
No entra: instalar daemon final, ejecutar todas las tareas, publicar cambios de cliente.

5. No alcance

El no alcance evita que el plan crezca sin control.

Incluye:

mejoras deseables para despues;
decisiones comerciales no tomadas;
automatizaciones futuras;
migraciones no necesarias;
refactors que no bloquean el resultado.

El no alcance no es una renuncia. Es una forma de proteger el foco del ciclo.

6. Supuestos

Lista lo que creemos cierto:

el workspace existe;
el proyecto esta en el departamento correcto;
el runner local podra acceder a la ruta;
el modelo operativo existe;
el usuario revisara antes de ejecutar.

Cada supuesto importante debe tener una verificacion o una tarea de bloqueo.

7. Fases

Cada fase debe tener:

nombre;
objetivo;
entregables;
tareas;
dependencias;
validacion;
estimacion;
riesgo;
criterio de salida;
si requiere deploy.

Formato recomendado:


## Fase 1 - Base operativa



Objetivo:

- Dejar preparado el proyecto para ejecutar sin improvisar.



Entregables:

- Plan activo.

- Tareas con spec.

- Target local.

- Perfil/agente asignado.



Validacion:

- El plan tiene una sola version activa.

- Todas las tareas estan en next.

- Ninguna tarea queda en queued.



Criterio de salida:

- El proyecto esta preparado para emparejar runner local.



Riesgos:

- Que una tarea entre en cola antes de tiempo.



Mitigacion:

- Mantener tareas en next hasta heartbeat fresco.

8. Dependencias

Las dependencias deben ser explicitas:

tarea B depende de tarea A;
fase 2 depende de que fase 1 este en review o done;
una tarea depende de credencial;
una tarea depende de decision humana.

No uses prioridad como dependencia. Prioridad decide orden deseable; dependencia decide si se puede ejecutar.

9. Criterios de calidad

Define que evidencia basta para aceptar:

comando ejecutado;
captura;
enlace publicado;
smoke o test;
diff revisado;
registro de tiempo;
comentario de decision;
resultado del runner.

Para tareas automaticas, incluye tambien que debe pasar si falla.

10. Plan de comunicacion

En trabajos vendibles o de cliente, define:

quien debe ser informado;
cuando se avisa;
que se puede publicar;
que no debe aparecer en docs publicas;
que decisiones necesitan aprobacion.

11. Cierre y aprendizaje

Un plan no termina cuando "parece hecho". Termina cuando:

tareas cerradas o diferidas con razon;
tiempo registrado;
docs actualizadas;
riesgos pendientes visibles;
siguiente ciclo propuesto;
plan archivado si ya no es activo.

Paso 1: definir objetivo

Escribe el objetivo en una frase concreta.

Ejemplo malo:

"Mejorar automatizaciones".

Ejemplo bueno:

"Hacer que las tareas recurrentes editoriales creen una propuesta de temas, queden bloqueadas para decision humana y registren fecha de ejecucion."

Por que importa:

Un objetivo concreto permite crear tareas cerrables.
Un objetivo generico genera trabajo interminable.

Paso 2: definir alcance y no alcance

Alcance:

que se va a tocar;
que modulos entran;
que comportamiento debe cambiar;
que documentacion debe actualizarse.

No alcance:

lo que no se va a resolver ahora;
mejoras deseables pero secundarias;
cambios que podrian romper estabilidad.

Por que importa:

El no alcance protege la simplicidad.
Evita que una fase pequena se convierta en redisenar todo el producto.

Paso 3: dividir en fases

Una buena fase:

tiene un objetivo corto;
puede verificarse;
no mezcla demasiados dominios;
deja el sistema usable al terminar;
permite parar sin dejar todo roto.

Ejemplo de fases:

Documentar comportamiento esperado.
Ajustar backend/API.
Ajustar UI.
Verificar flujo manual.
Verificar dispatch/recurrente.
Actualizar documentacion.
Registrar tiempo y cerrar tareas.

Paso 4: convertir fases en tareas

Cada tarea derivada debe tener:

proyecto;
titulo accionable;
descripcion suficiente;
responsable o perfil;
estado inicial;
criterio de terminado;
validacion esperada;
tiempo registrado al cerrarse.

Por que importa:

Las tareas son la unidad que OPS puede ejecutar, medir y cerrar.
Si una fase no se puede traducir a tareas, probablemente esta demasiado abstracta.

Paso 4.1: comprobar que las tareas son buenas

Antes de crear tareas en masa, revisa cada una con esta prueba:

Se entiende leyendo solo el titulo y la descripcion.
Tiene un unico resultado principal.
Cabe en una sesion razonable de trabajo.
Tiene criterio de terminado.
Tiene prueba o evidencia esperada.
Tiene estimacion de tiempo.
Tiene proyecto y fase.
Tiene dependencias explicitas si no puede empezar sola.
Dice cuando debe parar y pedir decision.
Dice si debe quedar en review, waiting o done.

Si una tarea falla varios puntos, no la crees todavia o creala como tarea de definicion.

Paso 4.2: tamano de tarea

Una tarea demasiado grande se convierte en un mini-proyecto invisible. Una tarea demasiado pequena genera ruido.

Tamanos practicos:

15-30 min: verificacion, nota, ajuste pequeno, decision.
30-90 min: tarea normal de docs, UI pequena, spec, auditoria acotada.
2-4 h: bloque tecnico con pruebas o varias pantallas relacionadas.
1 dia o mas: deberia ser fase, no tarea, salvo que sea trabajo manual claro.

Si una tarea tiene varias salidas independientes, dividela.

Ejemplo malo:

"Mejorar Kodavio".

Ejemplo mejor:

"Crear target local Kodavio".
"Importar tareas 30D desde backlog".
"Crear specs aprobadas para tareas 30D".
"Verificar que ninguna tarea queda en queued".

Paso 4.3: plantilla de tarea

Usa esta plantilla cuando una tarea pueda ejecutarla otra persona o un agente:


Titulo:

- Verbo + objeto + contexto.



Contexto:

- Por que existe esta tarea.



Objetivo:

- Resultado concreto.



Alcance:

- Que se puede tocar.



No alcance:

- Que no se debe tocar.



Criterios de aceptacion:

- Como sabremos que esta bien.



Pruebas/evidencia:

- Que comando, revision, captura o enlace lo demuestra.



Dependencias:

- Tareas, decisiones, credenciales o runners necesarios.



Salida esperada:

- Done, review o waiting.



Tiempo estimado:

- Minutos u horas.

Paso 5: marcar bloqueos y decisiones

No todo debe avanzar automaticamente.

Debe quedar en waiting cuando:

falta decision del usuario;
falta credencial;
falta input externo;
falta elegir tema, modelo, proveedor o alcance;
hay riesgo de tocar produccion sin confirmacion.

Debe quedar en review cuando:

la ejecucion termino pero necesita validacion;
hay output IA que debe ser revisado;
se genero documentacion, codigo o contenido que no debe darse por bueno automaticamente.

Por que importa:

Bloquear a tiempo es una medida de calidad, no un fallo.
Review evita que el sistema cierre trabajos sin evidencia.

Paso 6: validar el plan

Antes de ejecutar:

revisa si las fases estan en orden;
comprueba que no hay tareas duplicadas;
comprueba que las tareas criticas tienen proyecto;
verifica credenciales si hay IA;
revisa que el plan no dependa de supuestos no confirmados;
deja documentado que se actualizara si cambian reglas del sistema.

Ejemplo de plan minimo

Contexto:

"Queremos preparar OPS para que un piloto pueda entender y operar el sistema."

Objetivo:

"Crear guias how-to, mejorar configuracion de preferencias y preparar asistente como ayuda operativa controlada."

Fases:

"Documentar quickstart."
"Mover idioma/tema a perfil."
"Colocar asistente como burbuja configurable."
"Verificar build y help."
"Cerrar tareas con tiempo."

Criterio de terminado:

"La UI carga, la documentacion online contiene las guias, y las tareas cerradas tienen tiempo."

Ejemplo de plan completo

Contexto:

"El producto permite automatizar trabajo, pero necesitamos probar un ciclo real con runner local y documentar el modo manual equivalente."

Objetivo:

"Dejar un proyecto con plan activo, tareas con specs, target local, perfil asignado y guia publicada para reproducir el proceso."

No objetivos:

"No ejecutar todas las tareas."
"No instalar daemon final."
"No prometer ejecucion local sin runner autorizado."

Fases:

Preparacion de datos: revisar backlog, specs y proyecto destino.
Importacion segura: crear plan, tareas, specs y target local en next.
Verificacion: confirmar conteos, specs, target, perfil y ausencia de queued.
Documentacion: publicar procedimiento automatico y manual.
Piloto: emparejar runner y ejecutar una tarea pequena.

Criterios de salida:

Hay un solo plan activo.
Las tareas tienen spec aprobada.
No hay tareas automaticas en cola accidentalmente.
La doc publica explica el proceso manual.
El primer piloto tiene runner fresco y evidencia.

Riesgos:

Worker remoto reclama tarea local.
Modelo solicitado no existe con ese nombre.
Tarea grande entra en cola sin preflight.

Mitigacion:

Mantener next hasta heartbeat fresco.
Guardar etiqueta solicitada y modelo operativo separado.
Ejecutar primero tarea de preflight.

Errores comunes

Crear tareas sin plan y luego intentar reconstruir intencion.
Usar fases demasiado grandes.
No separar configuracion, ejecucion y revision.
No bloquear decisiones humanas.
Cerrar fase sin actualizar documentacion.
No registrar tiempo por proyecto.

Resultado esperado

Al terminar esta guia, deberias tener un plan que permita ejecutar trabajo sin improvisar y detenerse cuando haya decisiones o riesgos.