Spec-Driven Development y el reto real de la transición organizacional
Este artículo no es una crítica a Spec-Driven Development. Es una reflexión sobre un problema que he visto repetirse en proyectos empresariales reales: la mayoría de los equipos que intentan adoptar SDD no fracasan por escribir malas especificaciones. Fracasan porque nadie definió qué pasa con Jira.
Trabajando con equipos reales, no en proyectos personales de laboratorio, he observado un patrón consistente. Las organizaciones empiezan a explorar herramientas de IA para desarrollo, descubren el valor de trabajar guiadas por especificaciones y comienzan a mantener archivos Markdown en el repositorio. Al mismo tiempo, Jira o Azure DevOps siguen siendo el centro operativo del equipo: épicas, historias, prioridades, sprints. En pocos meses aparece el problema que nadie anticipó: dos sistemas que describen el mismo trabajo, evolucionando por separado.
El problema no es SDD. Es la gobernanza de la información
Cuando las especificaciones del repositorio no están sincronizadas con las historias de Jira, los documentos de Confluence y lo que el cliente envió por correo, no tienes un problema de metodología. Tienes un problema de gobernanza.
La proliferación de fuentes de la verdad no es exclusiva de SDD. Existe en cualquier organización que crece sin definir quién tiene autoridad sobre cada artefacto. Lo que SDD hace es visibilizar ese problema más rápido, porque propone mover una fuente relevante de información al repositorio, donde antes no vivía.
Vale la pena aclarar un punto técnico: Spec-Driven Development no obliga a que las especificaciones existan como archivos Markdown dentro del código. Esa es la implementación que popularizaron muchas herramientas actuales porque resulta conveniente para trabajar con Git y con modelos de IA. El principio es trabajar guiados por especificaciones. Dónde viven esas especificaciones es una decisión de arquitectura de información, no un dogma del enfoque.
La discusión equivocada
He escuchado muchas veces el debate planteado como “¿Jira o Markdown?”. Creo que esa pregunta está mal formulada.
No es una competencia entre herramientas. Es una pregunta de gobernanza: ¿cuál es la fuente oficial de la verdad dentro de esta organización, y cómo evitamos mantener dos sistemas sincronizados a mano?
Defender una herramienta específica sin responder esa pregunta es decorar el problema, no resolverlo.
Definir un único System of Record
La recomendación que he visto funcionar con mayor consistencia es esta: define un único System of Record y automatiza la generación o sincronización del resto de los artefactos.
Si la organización decide que Jira es la fuente de verdad, las especificaciones para la IA deberían generarse automáticamente desde allí. Si la organización adoptó completamente SDD y el repositorio es el centro, entonces Jira debería reflejar el estado del trabajo derivado de esas especificaciones, no duplicarlo.
Lo que no funciona es dejar que ambos sistemas evolucionen manualmente en paralelo. Eso no es una estrategia de transición; es deuda de información acumulándose.
El factor humano
Los desarrolladores tendemos a pensar desde lo técnico. Cuando aparece una solución mejor, asumimos que la organización debería adoptarla de inmediato. Esa asunción subestima cómo funcionan realmente las empresas.
Las organizaciones no cambian solo por razones técnicas. Cambian cuando hay cultura, personas, procesos, tolerancia al riesgo y gestión del cambio alineados. Una transición que ignora esas variables puede ser técnicamente correcta y organizacionalmente desastrosa.
En ese contexto también está ocurriendo algo relevante en los perfiles profesionales. Con la IA aparecen roles más orientados al producto, capaces de combinar conocimiento técnico, negocio y especificaciones. La frontera entre desarrollador, analista funcional y product manager empieza a difuminarse en algunos equipos. Eso es real y vale la pena seguirlo de cerca.
Pero no significa que todas las organizaciones vayan a transformarse de forma inmediata. Existen estructuras que llevan muchos años funcionando de una manera determinada, con personas que tienen expertise real en esos procesos. Cualquier transición que no considere esa realidad generará resistencia antes que adopción.
No voy a afirmar que Scrum, Jira o los roles tradicionales van a desaparecer, porque eso sería una predicción sin respaldo. Lo que sí puedo decir es que la industria está evolucionando y que el trabajo del ingeniero incluye diseñar transiciones ordenadas, no solo construir el estado futuro.
Por qué OpenSpec intenta ser un puente
Esta reflexión influyó directamente en cómo se diseñó OpenSpec. Una de las decisiones explícitas fue mantenerlo simple para reducir la fricción de adopción. No buscaba construir el framework de SDD más completo ni más estricto posible.
Herramientas como GitHub Spec Kit proponen un proceso muy estructurado y disciplinado. Para organizaciones que ya adoptaron completamente SDD, ese nivel de formalidad puede ser exactamente lo que necesitan. Pero en equipos que están comenzando esa transición, el mismo nivel de estructura puede convertirse en una barrera de entrada.
No porque el enfoque sea incorrecto, sino porque el grado de estructura debe corresponder al nivel de madurez de la organización. Un proceso demasiado exigente para el momento equivocado produce abandono, no adopción.
OpenSpec intenta funcionar como un puente entre ambos mundos: suficientemente simple para equipos en transición, suficientemente útil para seguir aportando valor a medida que la organización madura.
La pregunta que vale la pena hacerse
El éxito de Spec-Driven Development no dependerá únicamente de escribir mejores especificaciones. Dependerá de cómo los equipos integren ese paradigma con los procesos que ya tienen, sin perder alineación, trazabilidad ni colaboración.
La pregunta correcta no es si Jira, Azure DevOps o Markdown es la mejor herramienta. La pregunta correcta es: ¿cuál es el System of Record de tu organización, y qué se genera automáticamente desde allí?
Mientras esa pregunta no tenga respuesta clara, la adopción de SDD genera más fricción de la que elimina.
Si quieres seguir aprendiendo sobre estos temas te invito a ver mis otras publicaciones.
