¿Hace falta adoptar un framework SDD formal si el equipo ya sigue los mismos pasos sin él?
Un equipo puede llevar meses aplicando de facto planificación funcional, planificación técnica e implementación de forma consistente, sin haber adoptado nunca un framework SDD con nombre propio. ¿Compensa formalizarlo?
La pregunta real
Es habitual encontrar equipos que, sin haber leído nunca la documentación de un framework SDD con nombre propio, ya siguen un procedimiento interno bastante parecido: definen la necesidad de forma estructurada, la traducen a un diseño técnico, y solo entonces implementan. Surge entonces una duda legítima: si el equipo ya aplica esos mismos pasos de forma consistente, ¿aporta algo real adoptar formalmente un framework como OpenSpec o Spec Kit, o es simplemente ponerle una etiqueta a algo que ya funciona?
Y hay un matiz adicional frecuente: el proceso informal suele abordar cada cambio "de una vez", mientras que la promesa de un framework formal es permitir sumar cambios de forma incremental.
Un proceso "pseudo-SDD" habitual
Planificación funcional
Un prompt ya definido guía la conversación hacia un formato uniforme: qué necesidad de negocio se cubre, quién la pide, qué casos de borde importan.
Planificación técnica
A partir de la planificación funcional aprobada, se genera el diseño técnico: qué capas se tocan, qué contrato de datos, qué dependencias existen.
Implementación y testing
Solo entonces se escribe código, guiado por lo ya acordado en los dos pasos anteriores — sin tener que reinterpretar la necesidad sobre la marcha.
Lo relevante de este patrón no es que le falte una marca reconocible, sino que todo el equipo aplique los mismos tres pasos de forma consistente, sin excepciones caso a caso. Eso es, en la práctica, lo que un framework SDD formal intenta garantizar — solo que aquí ya ocurre de forma orgánica.
Lo que sí cambia con un framework formal
La diferencia principal no está en los pasos en sí, sino en la granularidad del cambio. Un proceso informal tiende a tratar cada nueva funcionalidad como un bloque monolítico: se planifica, se diseña y se implementa de una sola vez. Un framework formal como OpenSpec está pensado para cambios incrementales — permite que una propuesta pequeña se apruebe, se aplique y quede archivada como historial reutilizable, en vez de reabrir todo el documento de especificación cada vez que aparece un ajuste menor. Esa capacidad de versionar cambios pequeños es lo que realmente se gana al formalizar, no la existencia de los tres pasos en sí.
Cuándo merece la pena formalizar
Si el equipo ya aplica los mismos pasos de forma consistente y el dolor real es la falta de trazabilidad de cambios pequeños e incrementales, formalizar hacia un framework tiene sentido: da vocabulario común, herramientas de línea de comandos y un historial de propuestas reutilizable entre proyectos.
Si, en cambio, el equipo es pequeño y el proceso informal ya resuelve bien las necesidades actuales, adoptar toda la burocracia de un framework puede añadir fricción sin un beneficio proporcional. En ese caso, "ya hay mucho avanzado" — consolidar el hábito importa más que adoptar una herramienta concreta.
Resumen rápido
- Aplicar los mismos pasos de forma consistente (planificar, diseñar, implementar) ya captura la esencia de SDD, con o sin framework con nombre propio.
- Lo que aporta un framework formal es sobre todo granularidad incremental: poder versionar cambios pequeños en vez de reabrir todo el diseño cada vez.
- Formalizar compensa más cuanto mayor es el equipo y más frecuentes los cambios incrementales; en equipos pequeños, consolidar el hábito puede ser suficiente.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.