Por qué existe Eidos

El problema

Pregúntale a un equipo qué está construyendo y obtendrás cuatro respuestas, ninguna escrita en un solo sitio. El ticket se cerró hace dieciocho meses. La página del wiki fue exacta la semana en que se escribió. La decisión de no cubrir un caso se tomó de palabra, y la persona que la recuerda se fue. El código dice qué hace la cosa hoy, no qué se supone que es.

Así que la respuesta honesta a «¿qué se supone que es esto?» es una reunión.

Por qué los tickets no pueden sostenerlo

Una tarea describe trabajo. Tiene una persona asignada, una estimación y un estado que va de abierto a cerrado. Su propósito es dejar de importar. Cuando el trabajo se entrega, todo lo que el ticket registraba sobre el producto caduca en ese mismo instante.

Un Blueprint (el plano) describe una pieza de tu producto. Se escribe antes de que empiece el trabajo, se corrige mientras el trabajo ocurre y sigue siendo exacto después. No tiene final.

Por eso Eidos prohíbe los campos de seguimiento de trabajo: nada de sprint, estimate ni assignee. Añádelos y un Blueprint se convierte en una tarea y se pudre en el mismo calendario. Enlaza con tu gestor de tareas en su lugar.

Qué hace Eidos al respecto

Guarda la respuesta a «qué es esta cosa» como markdown, en el repositorio, junto a tu producto, revisado en los mismos pull requests.

Junto a tu producto, así que está delante de la gente que si no adivinaría.
En git, así que cada cambio tiene autor, fecha y diff. Eidos se apoya en ese historial en lugar de inventarse su propio registro de auditoría.
Markdown plano, así que una persona y un agente de código leen el mismo archivo. Dos fuentes de verdad es como empieza la deriva.

Por qué tiene que escribirlo una persona

Una spec es un control sobre el código. Un control solo funciona si viene de otro sitio.

Deja que un agente escriba la spec, luego el código, y luego compruebe el código contra su propia spec. Todo cuadra. No se ha verificado nada: dos salidas de un mismo proceso que se corroboran entre sí no te dicen nada de ninguna de las dos.

Un Blueprint vale exactamente tanta intención humana como se puso en él. Uno sin ninguna es peor que ningún Blueprint, porque lleva la autoridad de estar escrito.

Cuándo no usar Eidos

Si vas a ir del todo en autónomo, sin revisión y con el agente eligiendo el rumbo, no escribas Blueprints. Añaden ceremonia, no corrección. Deja que el código sea la fuente de verdad, porque ya lo es. Para un prototipo o algo desechable, esa es la decisión correcta.

Eidos es para el caso en que alguien responde de lo que es la cosa: una persona que tiene que defender una decisión de alcance, o explicar dentro de un año por qué no cubre un caso que alguien dio por cubierto.

Qué no es

No es una herramienta de gestión de proyectos. Responde a «qué es esto», nunca a «cómo va».
No es un generador de documentación. Nada se deriva del código. Una persona decidió algo y lo escribió.
No es un formulario que rellenar. Si un Blueprint se lee como texto de relleno, remodélalo hasta que se lea como si lo hubiera escrito alguien.
No es una estructura rígida. El estándar no nombra ninguna colección, template (plantilla) ni sección. Tu Framework (el marco) lo nombra todo.

Quién lo sostiene

Las personas dueñas del producto: sostienen la intención, el alcance y las decisiones, sea cual sea el rol de cada una. Una raíz sin dueño se convierte en un wiki con mejor formato: todos editan, nadie decide, y los non-goals se vacían en silencio, porque decir que no exige autoridad.