Hay proyectos que parecen ir bien hasta que, de repente, hacen aguas. Es una situación que he visto repetirse muchas veces: equipos capaces, mucho esfuerzo invertido y, aun así, una pérdida progresiva de intención, trazabilidad y control. Con el tiempo, esos patrones me llevaron a buscar una forma más explícita de gobernar el ciclo de desarrollo de software antes de que la degradación llegase demasiado lejos.
El punto de partida
No siempre ocurre de forma espectacular. A veces el deterioro empieza con pequeñas señales: una duda que nadie resuelve, una historia que entra al backlog sin estar preparada, una decisión que se toma en una reunión y no queda registrada, una especificación que describe intención pero no permite implementar, una arquitectura vendida demasiado pronto, una estimación que empieza a quedarse pequeña sin que nadie lo diga en voz alta.
Durante bastante tiempo, mi trabajo acabó acercándome una y otra vez a ese tipo de situaciones. Proyectos tensionados, equipos con lecturas distintas del problema, clientes insatisfechos, entregas que no encajaban con lo esperado y funcionalidades implementadas con buena intención, pero sostenidas sobre una base demasiado débil. Contextos donde todos habían trabajado mucho y, aun así, nadie tenía una explicación clara y defendible de por qué el proyecto se estaba desviando.
En algunos contextos terminé participando cuando la situación ya venía torcida y hacía falta ordenar, entender, contener y volver a dar dirección. No lo cuento como una heroicidad, sino porque esas situaciones repetidas hicieron visible un patrón: muchos problemas no nacían de una falta de esfuerzo, sino de una pérdida progresiva de continuidad entre intención, conocimiento, ejecución y validación.
Lo cuento porque KEEL no nace de una reflexión abstracta sobre procesos. Nace de observar un patrón recurrente en proyectos de software: la intención inicial se degrada a medida que atraviesa fases, equipos, documentos, decisiones y herramientas.
KEEL es mi metodología para gobernar el ciclo de desarrollo de software mediante artefactos conectados, trazabilidad suficiente y validación contra una verdad vigente. No busca documentar más por inercia, sino conservar mejor la intención que justifica lo que se construye.
Antes de ser un marco, antes de tener nombre y antes de poder explicarlo como una forma de trabajar, KEEL nace de una pregunta bastante incómoda:
¿Por qué somos capaces de detectar el problema cuando ya duele, pero no somos capaces de gobernarlo antes de que deteriore el proyecto?
El caos no siempre parece caos al principio
Cuando pensamos en un proyecto caótico solemos imaginar una situación evidente: nadie sabe qué hacer, no hay prioridades, el equipo está bloqueado, las entregas fallan y el cliente está enfadado.
Pero muchas veces el caos empieza de una forma mucho más discreta.
Empieza cuando una especificación parece suficiente, pero no permite diseñar con seguridad, cuando una historia parece clara, pero no contiene criterios de aceptación útiles o incluso cuando una pantalla parece definir comportamiento, pero en realidad solo muestra una posibilidad visual. Empieza cuando una arquitectura se plantea demasiado pronto sobre un problema todavía poco detallado.
Desde fuera, el proyecto parece avanzar, desde dentro, el equipo empieza a compensar
El arquitecto rellena huecos para poder proponer una estructura. El analista interpreta lo que falta para poder cerrar documentación. El responsable de proyecto convierte incertidumbre en planificación porque necesita fechas. El desarrollador toma decisiones locales porque necesita implementar. QA prueba lo que puede porque no siempre existe una intención formal contra la que validar. El cliente corrige tarde porque hasta que ve algo funcionando no detecta que aquello no era exactamente lo que tenía en mente.
Nadie está actuando necesariamente mal. Ese es el punto importante.
La degradación no siempre nace de incompetencia. Muchas veces nace de una ausencia de estructura para conservar intención, transformar conocimiento y decidir cuándo algo está listo para pasar a la siguiente fase.
Tom DeMarco y Timothy Lister lo expresaron muy bien en Peopleware cuando recordaban que muchos problemas del trabajo en software no son tanto tecnológicos como sociológicos. La frase importa porque desplaza el foco: no basta con mirar herramientas, arquitecturas o metodologías; hay que mirar cómo las personas transfieren conocimiento, toman decisiones y coordinan responsabilidad.
Por eso este tema interesa tanto a arquitectos, managers, ingenieros, responsables de área y equipos que quieren ordenar su forma de trabajar. No porque necesiten más teoría, sino porque necesitan una forma de impedir que el proyecto dependa continuamente de heroicidades individuales.
Un proyecto no debería sostenerse porque una o dos personas tienen todo el mapa mental en la cabeza.
Esa situación puede funcionar durante un tiempo, pero no escala, no se audita bien, no protege al equipo y se rompe con facilidad cuando cambian personas, prioridades, alcance o contexto.
Cuando el patrón se repite demasiadas veces
Hay una secuencia que he visto repetirse en distintas formas: Una persona habla con cliente. Entiende una necesidad y plantea una solución, luego se define una arquitectura de alto nivel y se prepara una especificación inicial, también de alto nivel, porque todavía no hay detalle suficiente. Se cierra un acuerdo. Se comprometen expectativas, fechas, presupuesto y alcance.
Hasta aquí, nada extraño.
El nacimiento silencioso del problema
El problema empieza cuando esa información inicial se trata como si tuviera más madurez de la que realmente tiene.
Después entra un equipo funcional. Quizá ve parte de lo vendido, quizá no todo. Quizá recibe una presentación, una propuesta, un documento comercial o una idea general. Empieza a trabajar con cliente, plantea sesiones, extrae funcionalidad deseada, documenta flujos, pantallas, reglas y necesidades.
Pero esa documentación puede quedar desconectada de lo que se vendió originalmente.
No siempre por descuido. A veces porque el equipo funcional no tiene suficiente visibilidad sobre la arquitectura planteada, sobre los límites comerciales del acuerdo, sobre los compromisos cerrados o sobre las hipótesis que se asumieron en preventa. Otras veces porque cliente, al empezar a pensar en detalle, pide cosas razonables desde el punto de vista del producto, pero que no estaban realmente dentro del alcance comprometido.
Entonces esa documentación pasa al equipo técnico.
Un mal entendimiento de la documentación
Y ahí aparece otra fractura.
El equipo técnico descubre que lo recibido es más descriptivo que implementable. Hay intención, pero no siempre hay reglas completas. Puede que haya pantallas, pero no estados. Existen flujos felices (happy paths), pero no siempre excepciones. Vemos funcionalidades, pero no contratos. Hay entidades nombradas, pero no modelo. Hay decisiones aparentes, pero no trazabilidad.
A partir de ahí empieza el ajuste doloroso.
Encajando las piezas a martillazos
Hay que hacer cuadrar la arquitectura vendida, la especificación de alto nivel, la documentación funcional y las restricciones reales de implementación. Además, empiezan a aparecer dudas sobre posibles cambios de alcance. Algunas cosas que cliente pide parecen nuevas. Otras parecen implícitas. Algunas quizá estaban en la intención, pero no quedaron suficientemente descritas. Otras afectan técnicamente mucho más de lo que aparentan funcionalmente.
Y entonces la estimación empieza a cambiar en silencio.
Si en ese momento se reestimase con honestidad, es muy posible que las cuentas ya no salieran. Ni los plazos ni los números ni las expectativas. Pero el tiempo corre, el equipo siente presión, el cliente espera avances y el proyecto ya está en movimiento.
La dinámica peligrosa en la que nos encontramos sin entender muy bien por qué
Ahí aparece una dinámica muy peligrosa: ocultar toda la incertidumbre que se pueda ocultar.
No necesariamente con mala intención. De hecho, casi siempre ocurre con la mejor intención. El equipo técnico quiere avanzar. No quiere bloquear ni parecer poco resolutivo. No quiere esperar una semana a que alguien tome una decisión cuando pasado mañana hay que enseñar algo. Así que tira con lo que hay.
Toma decisiones.
A veces buenas. Otras veces razonables y, en ocasiones, inevitables. Pero no siempre le correspondía tomarlas. Y, sobre todo, no siempre quedan registradas como lo que son: hipótesis operativas.
Ese matiz es clave.
Una hipótesis puede permitir avanzar. Pero si no queda trazada, cuando llegue la decisión real nadie sabrá qué afecta. Nadie sabrá si el cambio es meramente técnico, si modifica comportamiento funcional, si rompe un contrato, si invalida pruebas, si obliga a rehacer backlog o si deja obsoleta una parte de la documentación.
Estos problemas son demasiado habituales.
Y cuando los has visto varias veces, empiezas a dejar de tratarlos como accidentes independientes. Empiezas a ver el patrón.
El proyecto donde la causa raíz se volvió cristalina
En algunos contextos especialmente complejos, el patrón se vuelve difícil de ignorar.
A veces, desde fases muy tempranas, ya es posible intuir dónde van a aparecer los problemas. No porque exista una bola de cristal, sino porque las señales estaban ahí: información dispersa, arquitectura prematura, especificación de alto nivel insuficiente, dependencias entre áreas poco gobernadas, documentación funcional difícil de transformar en trabajo técnico, dudas de alcance y presión por avanzar.
Las señales aparecieron pronto y apuntaban en una dirección clara. Con el tiempo, varios de esos riesgos terminaron materializándose.
La revelación
Y cuando aparecieron, la causa raíz se veía con mucha nitidez: no era solo un problema de estimación, ni solo de análisis, ni solo de arquitectura, ni solo de gestión, ni solo de desarrollo. Era un problema de continuidad del conocimiento.
Cada fase había producido algo, pero no siempre estaba claro cómo ese algo conectaba con la fase anterior ni cómo debía habilitar la siguiente.
Lo vendido no quedaba suficientemente conectado con lo funcional. Luego lo funcional no quedaba suficientemente conectado con lo técnico. Finalmente lo técnico tenía que inferir demasiadas cosas. El backlog absorbía dudas que no debería absorber. La ejecución resolvía preguntas que deberían haberse resuelto antes. La validación llegaba tarde, cuando ya había demasiado construido sobre decisiones poco visibles.
Ese día la pregunta cambió.
Ya no era: “¿cómo rescatamos este proyecto?”
La pregunta pasó a ser:
Si este patrón explica buena parte del deterioro, ¿podemos mitigarlo antes de que el proyecto llegue a ese punto?
No de eliminarla por completo. Eso sería ingenuo.
Frederick Brooks ya había advertido en No Silver Bullet que en software no hay una única técnica de gestión o tecnología capaz de producir mejoras milagrosas. También señalaba que la complejidad del software es una propiedad esencial, no accidental. Para mí, esa idea aterriza muy bien aquí: no se trata de encontrar una bala de plata, sino de construir mecanismos que nos ayuden a tratar mejor la complejidad que no podemos hacer desaparecer.
La pregunta, por tanto, no era cómo inventar una solución mágica.
La pregunta era cómo hacer visible antes la degradación. Cómo obligar a que ciertas preguntas aparezcan cuando todavía estamos a tiempo y evitar que la incertidumbre viaje escondida hasta implementación. Cómo impedir que cada fase entregue algo que parece correcto en su propio lenguaje, pero que no encaja con el conjunto.
Ahí empezó a tomar forma la necesidad real.
Primera idea: tener información no significa tener conocimiento operativo
Durante mucho tiempo asumí que el problema principal era la falta de información.
Si un proyecto iba mal, parecía lógico pensar que faltaban requisitos, faltaban reuniones, faltaban documentos o faltaba involucración de negocio. Y, en parte, puede ser cierto.
Pero con el tiempo he visto otra variante más peligrosa: proyectos donde información hay de sobra.
Hay documentos funcionales, actas, correos, diagramas, hojas de cálculo, diseños de pantallas, contratos provisionales, notas de preventa, decisiones comerciales, conversaciones con usuarios, tickets antiguos, documentación heredada e incluso presentaciones y explicaciones dispersas.
Documentación y especificación son cosas diferentes
El problema es que todo eso no forma automáticamente una base gobernable. Una fuente no es todavía conocimiento operativo.
Una frase en una reunión no es todavía una regla. Una maqueta no es todavía una especificación. Un documento comercial no es todavía alcance ejecutable. Una respuesta de un stakeholder no es todavía una decisión consolidada si no se sabe a qué afecta. Un comportamiento de un sistema heredado no es todavía un requisito, aunque pueda ser una pista importante.
Este matiz cambia mucho la forma de trabajar.
Cuando un equipo no distingue entre fuente, observación, decisión, especificación, modelo y trabajo ejecutable, todo acaba mezclado. Y cuando todo se mezcla, el backlog se convierte en una especie de zona de sedimentación donde caen ideas, tareas, dudas, compromisos, soluciones parciales y decisiones no trazadas.
El backlog no se ordena por arte de magía
Después pedimos al backlog que ordene el proyecto. Pero el backlog no puede ordenar aquello que no ha sido gobernado antes.
Esta es la primera idea que precede a KEEL: antes de ejecutar trabajo, el equipo necesita transformar información dispersa en conocimiento operativo.
No hace falta hacerlo con solemnidad ni con documentos interminables. Pero sí hace falta hacerlo de alguna forma explícita.
Hay que poder responder preguntas muy básicas:
- qué sabemos con certeza;
- qué estamos suponiendo;
- qué falta por decidir;
- qué contradicciones existen;
- qué parte del alcance está dentro;
- qué parte queda fuera;
- qué parte sigue en zona gris;
- qué decisiones habilitan trabajo;
- qué incertidumbres bloquean ejecución;
- qué evidencias necesitaremos para validar después.
Esto no es burocracia. Es higiene de ingeniería.
No buscamos pureza. Buscamos sostenibilidad.
La diferencia entre ambas cosas es importante. La pureza intenta diseñar un proceso perfecto. La sostenibilidad intenta evitar que el equipo pague una y otra vez el coste de haber avanzado con conocimiento débil.
Aquí la literatura no viene a adornar el argumento. Viene a recordarnos algo incómodo: los errores de requisitos descubiertos tarde suelen costar mucho más que los detectados al principio. Un estudio publicado por NASA sobre escalada de costes en el ciclo de vida recoge esa idea y referencia los trabajos tempranos de Barry Boehm sobre factores de coste por fase del ciclo de vida. No necesito convertir esa curva en dogma para aceptar la lección práctica: cuanto más tarde hacemos visible una mala interpretación, más partes del sistema tenemos que revisar.
Segunda idea: las fases existen, pero las transiciones no están gobernadas
En muchos proyectos las fases del ciclo de desarrollo están nominalmente presentes. Hay análisis, diseño, planificación, desarrollo, pruebas, validación, gestión del cambio y hasta reporting. El problema no siempre está dentro de cada fase. Muchas veces está en el salto entre fases.
Pasar de una conversación con negocio a una regla verificable no es trivial. Derivar una regla a un escenario no es trivial. Pasar de un escenario a un contrato no es trivial. Definir estados, permisos, errores y excepciones partiendo de una pantalla tampoco es trivial. Modelar técnicamente desde una especificación muchas veces es complejo. Pasar de un modelo a backlog ejecutable no es trivial. Pasar de una tarea implementada a una validación real tampoco es trivial.
Y, sin embargo, en muchos equipos esos saltos ocurren de forma implícita.
Dependen del criterio de quien está en medio.
Si la persona tiene experiencia, contexto y buena intuición, el proyecto aguanta durante un tiempo. Si no, se introducen desviaciones que no siempre se detectan pronto.
Esto explica por qué dos equipos pueden partir de una misma especificación y producir soluciones muy distintas. También explica por qué una implementación puede ser técnicamente correcta y, aun así, no responder a la intención del producto.
No basta con tener fases. Hay que gobernar las transiciones entre fases.
Esta es la segunda idea que precede a KEEL: el desarrollo de software no falla solo por falta de actividades, sino por falta de condiciones claras para pasar de una actividad a la siguiente.
Un equipo que quiere trabajar con más orden necesita saber cuándo una pieza está lista para especificarse, cuándo está lista para modelarse, cuándo está lista para convertirse en backlog y cuándo está lista para ejecutarse.
Y también necesita saber cuándo no lo está.
Ese “no lo está” es fundamental. En muchos proyectos se vive como una molestia, cuando en realidad es una señal de control. Detectar que algo no está listo para ejecución no frena el proyecto; puede estar evitando que el proyecto se endeude de una forma que después será mucho más cara.
La presión por avanzar siempre existe. La entiendo. Hay fechas, contratos, dependencias, expectativas y equipos esperando. Pero avanzar no siempre significa programar. A veces avanzar significa cerrar una duda crítica o delimitar una unidad funcional. Otras veces significa separar una decisión de una hipótesis. En ocasiones significa bloquear una historia hasta que exista una regla clara. A veces significa cambiar un compromiso porque la información nueva contradice la verdad vigente.
El problema aparece cuando todo se traduce automáticamente en ejecución.
“Haz este endpoint.”
“Cambia esta pantalla.”
“Añade este campo.”
“Adapta este flujo.”
“Crea esta integración.”
Cada una de esas frases puede esconder tipos de trabajo muy distintos. Puede haber una decisión de producto, un cambio de contrato, una duda de dominio, una dependencia externa, una modificación de alcance, una deuda técnica o una simple tarea ya preparada.
Si todo entra por el mismo carril, el equipo pierde capacidad de diagnóstico.
Y cuando se pierde diagnóstico, se pierde gobierno.
Parnas, en su trabajo sobre modularización, proponía empezar por las decisiones difíciles o propensas al cambio, no por una simple descomposición del flujo. Esa idea es muy potente fuera incluso del diseño modular: si no identificamos dónde viven las decisiones difíciles, terminan dispersas entre documentos, tickets, código y memoria oral. (Effective Software Design)
Tercera idea: validar no es comprobar que algo se ha hecho
La tercera idea aparece al final del flujo, aunque en realidad nace al principio.
Muchos proyectos cierran trabajo cuando la implementación existe. El código está hecho, la tarea se mueve de columna, los tests básicos pasan, la pantalla se ve, el endpoint responde o la funcionalidad está desplegada en un entorno.
Eso puede ser avance técnico. Pero no necesariamente es cierre de producto.
La pregunta que debería preocuparnos es otra:
Para responder a eso no basta con mirar el resultado. Hay que saber contra qué se valida.
Si la intención estaba dispersa, si las reglas no estaban claras, si los criterios de aceptación eran genéricos, si las decisiones vivían en conversaciones y si el backlog no derivaba de conocimiento estable, entonces la validación llega tarde y llega débil.
En ese escenario, validar se convierte en opinar sobre una entrega.
“Esto no era lo que quería.”
“Yo entendí otra cosa.”
“Eso se habló en una reunión.”
“Ese caso no estaba contemplado.”
“Ese comportamiento no tiene sentido para el usuario.”
“Esto técnicamente funciona, pero no sirve.”
Todas esas frases suelen aparecer cuando el proyecto no ha conservado bien la intención.
Esta es la tercera idea que precede a KEEL: implementar no es terminar; terminar exige evidencia y contraste contra una verdad vigente.
Una prueba técnica puede decir que una parte del sistema funciona. Pero solo una validación bien conectada con la intención puede decir que funciona como debía funcionar.
Esta diferencia es especialmente relevante para arquitectos y responsables técnicos, porque muchas decisiones de arquitectura se evalúan tarde desde síntomas equivocados. Un problema puede parecer de diseño, rendimiento, acoplamiento o integración, cuando en realidad nace de una especificación ambigua o de una transición mal gobernada.
También es relevante para managers y responsables de entrega, porque un tablero lleno de tareas cerradas puede ocultar un producto que todavía no está alineado con lo que se necesitaba construir.
Y es crítica para organizaciones que quieren implantar buenas prácticas, porque no basta con exigir más documentación, más ceremonias o más revisiones. Hay que conectar esas prácticas con una cadena de verdad, trabajo y validación.
Si no, solo añadimos más actividad alrededor del mismo problema.
Brooks decía que la parte difícil de construir software está en especificar, diseñar y probar la estructura conceptual, no solo en representarla en código. Esa frase refuerza exactamente este punto: cerrar una tarea no debería significar únicamente que existe una representación técnica, sino que esa representación respeta la estructura conceptual que necesitábamos construir.
La pregunta que empezó a ordenar la respuesta
La cuestión de fondo era sencilla de formular y difícil de llevar a la práctica.
No hablo de crear un documento enorme que pretenda contenerlo todo. Hablo de diseñar artefactos con propósito claro, conectados entre sí, de forma que cada fase produzca salidas que sirvan realmente como entradas de la siguiente.
En KEEL, un artefacto no es simplemente un documento. Es una pieza con propósito, entradas, salidas, responsabilidades y condiciones mínimas de validez. Esa forma estable es lo que permite conectar fases, revisar decisiones y mantener compatibilidad aunque cambien las herramientas.
Por ejemplo, que el trabajo funcional no se limite a describir lo que cliente quiere, sino que obligue a completar plantillas de especificación que hagan aflorar lo que no se sabe. Plantillas que fuercen preguntas sobre reglas, actores, escenarios, excepciones, límites, datos, permisos, errores, contratos, criterios de aceptación y dependencias.
No para molestar a funcional.
Precisamente para protegerlo.
Porque un equipo funcional no debería cargar solo con la presión de traducir intención difusa en documentación útil sin disponer de una estructura que le ayude a detectar huecos, levantar incertidumbre y preservar conexión con lo vendido.
La misma lógica aplica al equipo técnico.
¿Y si el equipo técnico tuviese reglas claras para levantar bloqueos inmediatamente, en lugar de verse empujado a inventar comportamiento o tomar decisiones silenciosas? ¿Y si pudiera registrar una hipótesis operativa cuando necesita avanzar, dejando trazado qué ha decidido, por qué, sobre qué parte impacta y qué debería revisarse cuando llegue la decisión definitiva?
Eso permitiría algo muy importante: avanzar sin fingir certeza.
En proyectos reales, a veces hay que tomar decisiones provisionales. Lo peligroso no es reconocerlo. Lo peligroso es que esas decisiones se mezclen con la verdad del sistema y nadie pueda distinguirlas después.
Una hipótesis registrada tiene gobierno.
Una hipótesis escondida se convierte en deuda.
La idea empezó a tomar forma así: cada fase del ciclo debería trabajar con artefactos de entrada, aplicar reglas explícitas y producir artefactos de salida que dejen el sistema en mejor estado de conocimiento que antes.
No perfecto. Mejor.
Ese matiz importa.
No estoy inventando el problema, y eso es precisamente lo interesante
Cualquier persona con suficiente recorrido en ingeniería del software podría decir que todo esto ya está inventado.
Y tendría razón. La ingeniería de requisitos lleva décadas trabajando sobre especificación, trazabilidad, validación, gestión del cambio, criterios de aceptación, casos de uso, historias de usuario, arquitectura, pruebas, contratos, modelos de dominio y gobierno del ciclo de vida. Hay literatura, prácticas, técnicas y marcos para abordar casi cada uno de los problemas que acabo de describir.
No pretendo presentar estas ideas como si hubieran aparecido de la nada. Sería absurdo.
La fragmentación del ciclo y la especialización como raíz del problema
El problema que he visto en la práctica no es que falte conocimiento disponible. El problema es que ese conocimiento suele vivir fragmentado.
Un libro resuelve muy bien una parte. Un paper profundiza en otra. Un artículo explica una técnica concreta. Una organización adopta una práctica de requisitos. Otra mejora su gestión de backlog. Otra introduce mejores revisiones técnicas. Otra refuerza pruebas. Otra define procesos de cambio.
Todo eso puede ser valioso.
Pero muchas veces cada pieza vive aislada.
Y ahí está la clave.
Puedo tener el mejor motor del mundo, pero si no se acopla al chasis, si no transmite potencia a las ruedas, si no dialoga con la dirección, los frenos, la suspensión y el resto del sistema, seguirá siendo solo un motor. Muy bueno, quizá. Pero no formará parte del todo para el que fue concebido.
Con las prácticas de ingeniería ocurre algo parecido.
Puedo tener buenas plantillas de requisitos, buenos criterios de aceptación, buen diseño técnico, buenas historias de usuario, buenos protocolos de pruebas y buena gestión del cambio. Pero si cada elemento no sabe de dónde viene ni hacia dónde conecta, el conocimiento se pierde en las costuras.
La clave no está solo en conocer cada práctica.
La clave está en modularlas como artefactos conectados.
- Que una observación pueda transformarse en conocimiento consolidado.
- Que ese conocimiento pueda derivar especificación.
- Que la especificación pueda habilitar modelado.
- Que el modelado pueda alimentar backlog.
- Que el backlog pueda producir ejecución trazable.
- Que la ejecución genere evidencia.
- Que la validación pueda volver sobre la cadena y decir: esto funciona así por esta razón, que viene de esta decisión, que responde a esta regla, que cubre este escenario.
Eso es lo que me interesaba construir.
No una colección de documentos.
Una cadena de transformación.
Hacer el flujo casi algorítmico
Uso “casi” con intención.
No creo que el desarrollo de software pueda reducirse a una receta mecánica. Hay criterio, contexto, negociación, diseño, incertidumbre y experiencia profesional. Siempre los habrá.
Pero sí creo que muchas transiciones pueden hacerse más disciplinadas.
Si una fase recibe ciertos artefactos de entrada, debería poder aplicar reglas razonablemente repetibles para producir artefactos de salida. Si falta información, no debería inventarla. Debería abrir una duda. Si hay conflicto, no debería resolverlo silenciosamente. Debería señalarlo. Si una decisión es provisional, no debería camuflarla como definitiva. Debería registrarla como hipótesis. Si una historia no tiene criterios suficientes, no debería pasar a ejecución como si estuviera preparada.
Esto es lo que quiero decir cuando hablo de hacer el flujo pseudo-algorítmico.
No es automatizar el juicio profesional. Más bien es protegerlo.
Se trata de reducir la cantidad de interpretación silenciosa que ocurre entre fases y hacer que cada paso deje rastro. Es obligar al proyecto a responder lo que necesita responder antes de seguir. Es conseguir que, llegado el final, podamos volver sobre nuestros pasos y entender por qué algo funciona como funciona.
Ese retorno es fundamental.
Cuando un sistema ya está construido y alguien pregunta por qué se comporta de una manera, no deberíamos depender de la memoria de quien estuvo allí. Deberíamos poder recorrer la cadena: requisito, regla, escenario, decisión, modelo, historia, tarea, implementación, prueba y validación.
No siempre con un nivel de detalle extremo.
Pero sí con suficiente continuidad para defender el producto.
Por qué esto importa a quien está intentando ordenar un proyecto
Si eres arquitecto…
Si eres arquitecto, esto te importa porque no puedes diseñar bien sobre una intención inestable sin pagar un coste. Puedes proponer una arquitectura limpia, patrones adecuados y buenas fronteras técnicas, pero si el dominio está mal delimitado o las reglas cambian sin gobierno, tu diseño terminará absorbiendo ambigüedad.
Si eres manager…
Si eres manager, esto te importa porque gran parte del riesgo del proyecto no está solo en la capacidad del equipo, sino en la calidad del flujo que convierte necesidad en trabajo ejecutable. Un backlog lleno no significa que el proyecto esté preparado. Una planificación detallada no significa que el alcance esté claro. Una fecha comprometida no significa que la incertidumbre haya desaparecido.
Si eres ingeniero…
Si eres ingeniero de software, esto te importa porque muchas malas implementaciones nacen de buenas personas trabajando con malas entradas. Cuando una tarea llega sin contexto, sin reglas, sin contratos claros y sin criterios de aceptación, el desarrollador tiene que elegir entre bloquearse, preguntar indefinidamente o inventar. Ninguna de las tres opciones debería ser la base normal de un sistema profesional.
Si eres responsable…
Si eres responsable de un área, esto te importa porque implantar buenas prácticas no consiste en acumular ceremonias. Consiste en crear mecanismos para que las decisiones se conserven, la incertidumbre sea visible, el trabajo tenga sentido y la validación no dependa de memoria informal.
Si tienes una idea de producto o un cliente…
Si tienes una idea de producto o un cliente que te pide construir algo, esto te importa porque hacer las cosas bien desde el principio no significa sobrediseñar ni retrasar artificialmente. Significa evitar que la urgencia inicial te obligue después a reconstruir intención a base de retrabajo.
En todos los casos, la pregunta de fondo es la misma:
¿cómo facilitamos la gobernanza del flujo de desarrollo sin convertir el proceso en una losa?
Mi respuesta, al menos la que me llevó a construir KEEL, es que hay que gobernar el conocimiento antes de gobernar la ejecución. Porque la ejecución sin conocimiento estable es velocidad aparente.
Y la velocidad aparente suele convertirse en coste diferido.
La curiosidad del nombre: por qué una quilla
Cuando una forma de trabajo empieza a repetirse, necesita nombre.
No por marketing ni porque haya que envolverlo todo en siglas. No porque cada práctica personal necesite convertirse en marca. Necesita nombre porque, si no lo tiene, cuesta hablar de ella, evolucionarla, explicarla, criticarla y aplicarla con otros.
El nombre acabó siendo KEEL: Knowledge Engineering Execution Layer.
La parte conceptual es relativamente directa: una capa que conecta ingeniería del conocimiento con ejecución. Una forma de hacer que lo que el proyecto sabe, decide y valida no quede separado de lo que el equipo construye.
Pero la imagen que realmente me interesaba era la de la quilla.
La quilla no es la parte más visible de un barco. No es la vela ni el timón. No es la cubierta. Tampoco es el motor. Pero cumple una función silenciosa y fundamental: aporta estabilidad, ayuda a mantener dirección y evita que el barco derive o se incline con demasiada facilidad ante cualquier cambio de viento o corriente.
Esa analogía encajaba muy bien con el problema.
En un proyecto de software, lo visible suele ser el código, las pantallas, las demos, los tickets, los informes y las entregas. Pero debajo de todo eso debería existir una estructura que estabilice el movimiento.
Esa estructura es el conocimiento gobernado del producto.
Cuando existe, el equipo puede absorber cambios sin perder completamente la orientación.
- Puede discutir con más precisión.
- Puede saber qué se rompe si una decisión cambia.
- Puede distinguir entre avanzar y precipitarse.
- Puede cerrar trabajo con más confianza.
- Puede explicar por qué algo está bloqueado sin que parezca una excusa.
- Puede validar con más criterio.
Cuando no existe, el proyecto navega igualmente, pero lo hace más expuesto a cada cambio de viento.
La quilla no evita el mar. No elimina la incertidumbre. No garantiza que el viaje sea fácil. Pero ayuda a que el barco no dependa solo del entusiasmo de la tripulación o de la suerte del día.
Esa era la imagen.
Y por eso el nombre encajaba.
Un ejemplo mínimo: cuando “añadir una fecha” no es solo añadir una fecha
Pensemos en algo pequeño para no escondernos detrás de abstracciones.
Imaginemos una aplicación de organización personal basada en proyectos, acciones siguientes, contextos y revisión semanal. En una reunión, alguien dice:
Parece simple. De hecho, parece una tarea pequeña. Añadir un campo, mostrarlo en pantalla, permitir editarlo y quizá ordenar por fecha.
Pero si queremos gobernar bien el flujo, esa frase todavía no debería entrar directamente como implementación.
Primero habría que entender qué representa esa fecha.
¿Es una fecha límite real o una fecha deseada? ¿Aplica a todas las acciones o solo a algunas? ¿Puede existir una acción sin fecha? ¿Qué ocurre si la fecha vence? ¿Se notifica? ¿Afecta a la revisión semanal? ¿Cambia la forma de priorizar? ¿Debe aparecer en los filtros? ¿Se relaciona con contextos o energía? ¿Hay diferencia entre fecha de inicio y fecha límite? ¿Qué pasa con acciones completadas fuera de plazo?
Ninguna de estas preguntas es especialmente sofisticada. Pero si no se hacen en el carril adecuado, aparecerán después en código, pruebas, soporte, cambios de alcance o conversaciones con el cliente.
La diferencia entre hacerlo mal y hacerlo bien no está en escribir veinte páginas.
Está en no confundir una frase de intención con una unidad de trabajo ejecutable.
Esa es la clase de problema que KEEL intenta ordenar.
No porque el ejemplo sea complejo, sino porque incluso lo simple se degrada cuando el flujo no distingue entre idea, decisión, regla, diseño, backlog, ejecución y validación.
Decisiones tomadas y pendiente por madurar
A día de hoy, hay algunas decisiones que tengo bastante claras.
La primera es aceptar que la incertidumbre no es un fallo del proceso. Es parte del proceso. Lo inmaduro no es tener dudas; lo inmaduro es ocultarlas o empujarlas hacia ejecución como si no existieran.
La segunda es separar responsabilidades. Observar no es especificar. Especificar no es modelar. Modelar no es programar. Programar no es validar. Reportar no es crear verdad. Cambiar no es simplemente ordenar una modificación.
La tercera es exigir trazabilidad suficiente entre intención y resultado. No una trazabilidad pesada para satisfacer una auditoría artificial, sino una trazabilidad útil para responder: por qué estamos haciendo esto, de dónde viene, qué regla respeta, qué afecta, cómo sabremos que está bien y qué ocurre si cambia.
Estas tres decisiones marcan el carácter del marco.
No buscan ralentizar. Buscan evitar avance ilegítimo.
Y conviene matizar esto porque puede malinterpretarse. Hay proyectos donde el nivel de formalidad debe ser bajo. No tiene sentido aplicar la misma intensidad a una prueba interna, una herramienta departamental sencilla, un sistema regulado o una plataforma crítica con múltiples integraciones.
La hipótesis que manejo es que el nivel de gobierno debe crecer con el riesgo, la complejidad, el coste del error, el número de actores y la dificultad de revertir decisiones.
No todos los equipos necesitan el mismo peso metodológico.
Pero todos necesitan saber qué están tratando como verdad.
Lo que sigue en evolución es cómo graduar esa intensidad sin que el marco se convierta en carga. Qué artefactos son imprescindibles siempre, cuáles dependen del contexto, qué nivel de detalle exige cada fase y cómo evitar que la buena intención metodológica acabe generando documentación que nadie usa.
Ese equilibrio es delicado.
Pero prefiero enfrentar ese problema a seguir aceptando el contrario: proyectos que avanzan deprisa porque han escondido la incertidumbre debajo de la alfombra.
Qué hacer ahora si tu proyecto ya está en marcha
Si tu proyecto ya está en marcha y reconoces parte de este problema, no empezaría por rediseñarlo todo.
Empezaría por localizar dónde se está perdiendo más intención.
Puede estar en la entrada de información, porque todo llega mezclado y nadie distingue fuentes de decisiones. O podría estar en la especificación, porque los documentos describen deseos pero no reglas operativas. Investiga si está en el backlog, porque las historias no representan trabajo ejecutable. Podría estar en la ejecución, porque los desarrolladores tienen que inventar contexto. Puede estar en la validación, porque no existe una verdad clara contra la que comprobar. Puede estar en los cambios, porque cualquier decisión nueva atraviesa el sistema sin dejar rastro.
Para empezar, haría algo muy concreto:
- separar fuentes recibidas de decisiones vigentes;
- registrar las incertidumbres que hoy están escondidas dentro del backlog;
- revisar si las historias principales pueden validarse sin interpretación adicional;
- identificar qué cambios recientes han dejado artefactos obsoletos;
- definir qué evidencia mínima exige el cierre de trabajo relevante.
Eso ya cambia la conversación.
No resuelve todo, pero empieza a desplazar el proyecto desde “vamos haciendo” hacia “sabemos por qué podemos hacer esto ahora”.
Ese cambio es pequeño en apariencia, pero profundo en la práctica.
No nace para presentar una metodología, nace para justificar una necesidad
KEEL no nace porque faltasen metodologías en el mundo del software.
Nace porque, en la práctica, muchos proyectos siguen teniendo una fractura entre intención, conocimiento, trabajo y validación.
Nace al ver que una especificación puede existir y no gobernar. Un backlog puede estar lleno y no representar trabajo preparado. Una implementación puede estar terminada y no estar validada contra la intención. Un cambio puede parecer pequeño y romper silenciosamente varias capas del proyecto. Un reporte puede tranquilizar sin reflejar una verdad operativa.
Nace, sobre todo, de una preocupación: no perder el producto por el camino.
Porque eso ocurre.
- El producto que se imaginó no siempre es el producto que se vendió.
- El producto vendido no siempre es el que se especificó.
- El producto especificado no siempre es el que se modeló.
- El producto modelado no siempre es el que llegó al backlog.
- El producto del backlog no siempre es el que se implementó.
- Y el producto implementado no siempre es el que se necesitaba validar.
Cada salto puede introducir pérdida.
La intención de KEEL es construir una quilla para esos saltos.
Una estructura que no se vea siempre, que no compita con lo visible, que no pretenda sustituir el criterio profesional, pero que ayude a que el proyecto mantenga dirección cuando aparecen presión, cambios, ruido e incertidumbre.
No se trata de documentar más.
Se trata de perder menos.
Y para muchos equipos, ahora mismo, esa diferencia puede ser la frontera entre un proyecto que simplemente avanza y un proyecto que realmente se gobierna.