Saltar el Ciclo de Frameworks: Un Caso por la Capacidad Técnica

22 min de lectura

La Alternativa que Nadie le Vende

Antes de mapear el ciclo de vida de la adopción de frameworks, dejemos claro lo que realmente funciona: enseñar a las personas que construyen software cómo construirlo mejor.

Desarrollo guiado por pruebas. Integración continua que realmente encuentra problemas. Desarrollo basado en trunk en lugar del infierno de branches. Especificaciones que puedes ejecutar. Lotes pequeños. Feedback rápido. Estas prácticas — enseñadas por personas que las han practicado, integradas en el trabajo diario — arreglan los problemas que hacen que la entrega sea dolorosa. Crean la visibilidad, calidad y previsibilidad que los frameworks prometen pero nunca entregan.

Ningún proveedor vende esto porque no hay nada que vender. Sin certificaciones que renovar. Sin hojas de ruta de transformación para facturar. Sin tarifas de licencia recurrentes. Solo trabajo paciente que se acumula con el tiempo.

El ciclo de vida de frameworks que sigue no es inevitable. Es lo que sucede cuando alguien decide “necesitamos un proceso” en lugar de “necesitamos mejorar en esto”. Entender el patrón te ayuda a ver dónde estás — y encontrar la salida antes de haber perdido años.

Unas Palabras para los Gerentes

Si eres un líder no técnico leyendo esto, no estoy aquí para hacerte sentir estúpido. No eres el villano.

Tienes una junta directiva preguntando por qué los proyectos se retrasan. Competidores entregando más rápido. Desarrolladores hablando un idioma que no entiendes completamente. Cuando un proveedor aparece con casos de estudio y una hoja de ruta de transformación — por supuesto que escuchas. ¿Qué más se supone que hagas?

Nadie te enseñó qué hace que los equipos de software realmente funcionen. La escuela de negocios no lo cubrió. Los consultores tenían certificaciones que vender. Así que buscas lo que está disponible: estructura, proceso, supervisión. El problema es que el software no responde a esas herramientas como lo hace otro trabajo. El control en software viene de la capacidad, no del proceso.

El patrón que estoy a punto de describir no pretende avergonzarte. Pretende mostrarte lo que realmente está pasando — para que puedas tomar decisiones diferentes. Cada fase tiene una salida. Las salidas no requieren que te vuelvas técnico. Requieren que inviertas diferente.

El Patrón que Sigue Repitiéndose

Conferencias, cenas de ponentes, bares de hotel a altas horas. Los momentos honestos cuando los practicantes comparan notas. El framework específico cambia — cascada cede paso a Scrum, Scrum escala a SAFe, SAFe se complementa con OKRs — pero las historias siguen los mismos ritmos.

(Cascada nunca debía ser una cosa. El paper de Winston Royce de 1970 lo presentó como defectuoso. La industria leyó el diagrama y se saltó la advertencia. Llevamos haciendo eso con las metodologías desde entonces.)

Cuando cientos de relatos independientes pintan la misma trayectoria, estás mirando un patrón. Entender dónde te encuentras ayuda a encontrar la salida.

Fase 1: Dolor y Búsqueda de Salvación

Toda adopción de framework comienza con dolor genuino. Los proyectos se atrasan. La calidad es inconsistente. Los stakeholders se sienten desconectados de la ingeniería. Nadie sabe qué se entregará o cuándo.

El dolor es real. El diagnóstico que sigue es donde las cosas se desvían.

El liderazgo enmarca el problema como una brecha de proceso en lugar de una brecha de ingeniería. La búsqueda comienza por un “framework probado” — algo con casos de estudio, certificaciones y soporte del proveedor. Aparecen modelos de madurez. Los planes de implementación masiva toman forma. Los consultores presentan presentaciones impresionantes con hojas de ruta de transformación.

El lenguaje cambia sutilmente. “Nos falta alineación.” “Necesitamos prácticas comunes.” “Necesitamos escalar lo que funciona.” Estas frases señalan que la solución será organizacional, no técnica.

La selección del framework procede con altas expectativas. Las historias de éxito del proveedor suenan convincentes. El pipeline de certificación promete practicantes entrenados. La metodología parece lo suficientemente completa para abordar cada preocupación.

La trampa ya está puesta. Como exploré en Frameworks de Gestión y la Proximidad al Aceite de Serpiente, los incentivos estructurales favorecen la venta de modelos de proceso sobre resultados verificables.

Una cosa más que vale la pena saber: algunos frameworks socavan activamente las buenas prácticas técnicas. Están construidos sobre la suposición de que el desarrollo de software es manufactura — predecible, repetible, controlable a través de procesos. Tratan la complejidad como un fallo de gestión en lugar de una propiedad inherente del trabajo. Cuando los equipos adoptan prácticas diseñadas para manejar la complejidad — testing exploratorio, diseño evolutivo, refactoring continuo — estos frameworks empujan hacia atrás. “Eso no está en el proceso.” “No están siguiendo la metodología.” “Necesitamos previsibilidad, no experimentación.”

Los frameworks no dicen esto en voz alta. Pero observa lo que pasa cuando un equipo quiere hacer pair programming en lugar de asistir a reuniones de estado. Observa lo que pasa cuando alguien sugiere mob programming. Observa lo que pasa cuando los desarrolladores quieren refactorizar antes de agregar funcionalidades. Los defensores del framework encontrarán razones por las que esas prácticas no encajan en el modelo.

Algunos de estos enfoques van más lejos. Imponen una división dura entre “descubrir qué construir” y “construirlo” — como si el descubrimiento terminara cuando comienza la programación. Esto contradice directamente el ciclo exploratorio en el corazón del desarrollo guiado por pruebas, donde escribir tests es cómo descubres lo que el código debería hacer. TDD no es solo una técnica de testing; es un proceso de descubrimiento de diseño. Los frameworks que tratan la implementación como una fase separada de la especificación resucitan la suposición de 1968 de que los programadores son la fuente de complejidad — que si pudiéramos especificar las cosas con suficiente claridad, la programación sería mecánica. Esa suposición estaba equivocada en 1968. Sigue estando equivocada.

Y ahora la IA le da nueva vida a esta vieja fantasía. “Desarrollo guiado por especificación” — la idea de que escribes especificaciones detalladas y la IA genera el código — suena revolucionario hasta que reconoces el patrón. Es la misma creencia: que la parte difícil es decidir qué construir, y construirlo es solo transcripción. La IA programará exactamente según la especificación, prometen. Igual que el equipo offshore programaría exactamente según la especificación. Igual que los desarrolladores junior programarían exactamente según la especificación. La especificación nunca está tan completa como crees. Los casos límite viven en la implementación. El aprendizaje sucede cuando el código se encuentra con la realidad. La IA es una herramienta poderosa para desarrolladores que entienden esto. Es una trampa para organizaciones que siguen persiguiendo el sueño de programar sin programadores.

Esto no es accidental. Si el desarrollo de software es complejo — si requiere juicio, habilidad y adaptación constante — entonces no puedes escalarlo a través de estandarización de procesos. Necesitas capacidad. Y la capacidad toma más tiempo para construir y es más difícil de vender.

Fase 2: Teatro de Adopción del Framework

El despliegue comienza con optimismo genuino. Aparecen nuevos roles — mira el recuadro a la derecha para ver una muestra. Eso no es una parodia. Son títulos de trabajo reales de iniciativas de transformación reales, y la mayoría de las organizaciones adoptan una docena o más de ellos. Las ceremonias llenan los calendarios. Las personas obtienen nuevos títulos, nuevas responsabilidades, nuevas razones para sentirse importantes.

Esto importa psicológicamente. El framework crea ganadores. El Scrum Master recién certificado que estaba atrapado en un rol de QA sin salida ahora tiene un camino de carrera. El gerente de proyecto que temía la obsolescencia ahora es Release Train Engineer. El consultor que pasó años aprendiendo la metodología finalmente tiene clientes que pagan. Estas personas tienen intereses reales en el éxito del framework — sus hipotecas dependen de ello.

Los equipos renombran cosas obedientemente. Las historias de usuario reemplazan los requisitos. Los sprints reemplazan los hitos. Los story points reemplazan las estimaciones de tiempo. El vocabulario cambia comprehensivamente.

Pero debajo de la nueva terminología, la ingeniería permanece en gran parte sin cambios. El mismo código se escribe de la misma manera. El mismo dolor de integración ocurre. Los mismos defectos escapan a producción. Los mismos descubrimientos tardíos explotan los cronogramas.

La actividad aumenta visiblemente. Los resultados no cambian mensurablemente.

Esta brecha entre ceremonia y capacidad es donde los frameworks de gestión divergen de lo que realmente arregla los equipos de software. El framework proporciona estructura para la coordinación — coordinación que quizás ni siquiera se necesita. Muchas organizaciones que adoptan frameworks pesados son demasiado pequeñas para requerirlos. Los equipos que construyen herramientas internas únicas o mantienen productos estables rara vez necesitan ceremonias de sincronización entre equipos. Pero el framework no pregunta si la coordinación es tu cuello de botella. Asume que la coordinación es el cuello de botella de todos, porque coordinación es lo que vende. Mientras tanto, el framework no enseña desarrollo guiado por pruebas, no establece disciplina de integración continua, no refactoriza arquitectura legacy, no construye automatización de despliegue.

Fase 3: Presión de Métricas y Modo de Cumplimiento

Cuando los resultados no se materializan, el liderazgo intensifica el enfoque en el cumplimiento. Si el framework no está funcionando, la gente debe no estar siguiéndolo correctamente.

Las métricas proliferan. La velocidad se convierte en un indicador de rendimiento. Los compromisos de sprint se convierten en contratos. Los dashboards se multiplican — no para proporcionar insight, sino para identificar quién no está cumpliendo.

Los equipos responden racionalmente. Los story points se inflan. Las definiciones de hecho se suavizan. Los dashboards verdes proliferan mientras la capacidad real de entrega permanece sin cambios. Nadie está mintiendo, exactamente. Están sobreviviendo.

Aparece más gobernanza. Change Advisory Boards. Comités de revisión de arquitectura. Cadenas de aprobación. Cada capa añade fricción mientras proporciona la ilusión de control. La organización está ahora buscando proceso cuando necesita visibilidad.

Fase 4: Colisión con la Realidad

Eventualmente, las restricciones que el framework no pudo abordar se vuelven inevitables. Un release importante falla. Una fecha límite crítica se incumple catastróficamente. Un cliente clave escala. La junta directiva hace preguntas incómodas.

Cuando la presión se vuelve aguda, los problemas reales salen a la superficie: monolitos que requieren releases coordinados, datos de prueba que toman semanas en prepararse, procesos de build que toman días en lugar de horas. El framework los tapó con actividad. Ahora son visibles — descritos como “dependencias”, “cuellos de botella de QA”, “deuda técnica”. Lenguaje seguro que culpa a los sistemas, no a las decisiones.

Este es un punto de decisión. La organización puede reconocer que el trabajo real — construir capacidad de ingeniería — permanece sin hacer. O puede duplicar la apuesta en el framework.

Aquí hay una alternativa que salva las apariencias: deje que una herramienta cuente la historia. Cuando Caimito Navigator muestra que la frecuencia de despliegue cayó mientras la sobrecarga de ceremonias se duplicó, o que los equipos que ignoran el framework entregan tres veces más rápido que los que cumplen — los datos se convierten en el mensajero. Nadie tiene que confesar fracaso personal. La evidencia simplemente hace obvio el siguiente paso. Los líderes que no podían decir “me equivoqué” pueden decir “los datos muestran que necesitamos ajustar.” Mismo pivote, dignidad preservada.

Fase 5A: Duplicar la Apuesta (Camino Común)

Duplicar se siente lógico. El framework debe funcionar — ¡mira los casos de estudio! — así que el problema debe ser la implementación. Lo que se necesita es más disciplina, más coordinación, más supervisión.

Las capas de proceso se multiplican. Aparece una oficina de transformación. La planificación centralizada aumenta. Los requisitos de aprobación crecen. Nuevos roles intermedios emergen para coordinar la coordinación.

Los equipos pierden autonomía. Los ciclos de decisión se alargan. La organización se vuelve más lenta incluso cuando añade más personas explícitamente encargadas de hacerla más rápida.

La fatiga se instala. Los mejores ingenieros empiezan a irse. Los que permanecen aprenden indefensión. Eventualmente, alguien sugiere que quizás un framework diferente funcionaría mejor.

El ciclo se prepara para reiniciar.

Fase 5B: Rebelión Local (También Común)

Mientras los procesos oficiales se multiplican, algunos equipos silenciosamente hacen lo necesario para realmente entregar software.

Establecen automatización de pruebas que el framework no requiere. Adoptan desarrollo basado en trunk a pesar de las políticas oficiales de branching. Endurecen sus pipelines de CI. Cortan el trabajo más pequeño que los formatos de historias prescritos. Trabajan en parejas y en mob para compartir conocimiento que el framework no transfiere.

Estos equipos tienen éxito a pesar del framework, no gracias a él. Se convierten en los “de alto rendimiento” que el liderazgo estudia e intenta replicar.

Los esfuerzos de replicación típicamente se enfocan en los artefactos visibles — la estructura del equipo, la cadencia de reuniones, las herramientas — mientras pasan por alto la disciplina de ingeniería invisible que realmente impulsa los resultados.

Fase 6: La Organización de Dos Velocidades

Las organizaciones a menudo se estabilizan en este estado de dos velocidades. Unos pocos equipos entregan confiablemente. La mayoría de los equipos permanecen orientados al cumplimiento. Y la política se pone fea.

Los equipos de alto rendimiento se convierten en héroes y villanos al mismo tiempo. Héroes porque entregan. Villanos porque su éxito plantea una pregunta incómoda: si ellos pueden, ¿por qué no pueden los demás?

La presión se construye para “estandarizar” — típicamente imponiendo las prácticas de los equipos que cumplen a los de alto rendimiento. Esto usualmente destruye el alto rendimiento sin elevar a los equipos que luchan. Todos se vuelven igualmente mediocres.

La alternativa — entender por qué los ganadores ganan e invertir en esa capacidad ampliamente — requiere reconocer que el framework nunca fue el diferenciador. Pocos ejecutivos pueden hacer esa admisión.

Fase 7A: El Punto de Inflexión

Algunas organizaciones alcanzan un punto de inflexión genuino. El liderazgo reconoce que lo que importa no es el framework sino la capacidad subyacente de ingeniería y aprendizaje de producto.

La inversión cambia explícitamente a prácticas que realmente cambian los resultados: adopción de TDD con soporte de coaching real. Pairing y mobbing como modos de trabajo por defecto. Pipelines de CI/CD que permiten múltiples despliegues por día. Refactoring como disciplina continua en lugar de evento periódico. Lotes pequeños medidos en horas, no semanas. Ciclos de feedback de clientes directos que evitan el pipeline de ceremonias.

El framework no desaparece. Se convierte en andamiaje opcional — útil para algunos propósitos de coordinación, ignorado donde añade fricción sin valor.

Esta fase es reconocible por sus síntomas: menos reuniones, más trabajo técnico visible, ciclos de integración más rápidos, menos defectos escapando a producción. Los equipos hablan de prácticas, no de procesos.

Fase 7B: Ciclo de Reemplazo de Framework (También Común)

La alternativa a construir capacidad genuina es simplemente empezar de nuevo con un framework diferente.

Nuevo vocabulario reemplaza al viejo vocabulario. Nuevos consultores reemplazan a viejos consultores. Nuevo entrenamiento reemplaza al viejo entrenamiento. Nuevas métricas reemplazan a las viejas métricas.

Los problemas del código base permanecen. El dolor de integración persiste. Las brechas de testing perduran. Las restricciones de arquitectura continúan.

El ciclo reinicia desde la Fase 1, a menudo con el liderazgo convencido de que “esta vez es diferente”. Después de todo, aprendieron de sus errores con el framework anterior.

Lo que típicamente aprendieron es a evitar los modos de fallo específicos del viejo framework. Lo que no aprendieron es que el framework nunca iba a arreglar lo que les aqueja.

Fase 8: El Estado Maduro

Algunas organizaciones alcanzan un estado maduro estable. Han aprendido a seleccionar prácticas basándose en restricciones — requisitos de flujo, necesidades de calidad, desafíos de descubrimiento, realidades arquitectónicas — en lugar de lealtad al framework.

La gobernanza existe pero permanece ligera. La disciplina de ingeniería es fuerte y autosostenible. La mejora continua ocurre a través de feedback directo y experimentación, no ciclos de ceremonias.

Estas organizaciones no discuten qué framework siguen. Discuten qué resultados están persiguiendo y qué prácticas sirven mejor esos resultados.

Han internalizado que el desarrollo de software es trabajo de diseño, no un proceso de manufactura para ser optimizado a través de mejor gestión de flujo de trabajo.

Reconociendo Dónde Estás

El ciclo de vida no es destino. Las organizaciones pueden salir en múltiples puntos. Pero salir requiere reconocer dónde estás.

Si estás en Fase 1: Cuestiona el diagnóstico. ¿Es esto realmente un problema de proceso? ¿Qué capacidades específicas de ingeniería faltan? ¿Qué cambiaría si invirtieras en prácticas técnicas en lugar de estructura organizacional?

Si estás en Fase 2 o 3: Mide lo que importa. No velocidad o finalización de sprint — sino tiempo de ciclo desde la idea hasta producción, tasa de escape de defectos, frecuencia de despliegue, y si los clientes realmente usan lo que entregas.

Si estás en Fase 4: Esta es la oportunidad. Los problemas reales son visibles ahora. Resiste la tentación de añadir más proceso. Pregunta en cambio: ¿qué capacidades técnicas abordarían realmente estas restricciones?

Si estás en Fase 5A: Duplicar la apuesta está fallando. Busca a los rebeldes silenciosos en 5B. Ellos saben qué realmente funciona.

Si estás en Fase 6: Estudia a los de alto rendimiento honestamente. No sus ceremonias o herramientas — sus prácticas de ingeniería. Invierte en difundir esa capacidad, no en estandarizar la disfunción.

Incluso la IA Conoce Esta Historia

Pregúntale a cualquier asistente de IA que describa “el ciclo de vida típico de la adopción de frameworks en organizaciones de software.” La respuesta reflejará lo que he descrito aquí — porque este patrón aparece tan frecuentemente en los datos de entrenamiento que cualquier modelo de lenguaje grande lo ha absorbido. El ciclo es así de predecible.

Las Historias Detrás del Patrón

Todo esto suena pesado. Es pesado. Carreras descarriladas. Confianza destruida. Buenas personas atrapadas en malos sistemas. Años perdidos.

Pero aquí está la cosa: también hace gran drama. Y el drama, a veces, es más fácil de absorber que el análisis.

Algunos de nosotros hemos estado convirtiendo estos patrones en ficción — historias estilo telenovela ambientadas en empresas de software. Si has llegado hasta aquí y sientes que necesitas un trago, las historias podrían ser mejor opción. Te harán reír. Podrían hacerte enojar. Y en algún lugar entre la tensión romántica y las traiciones de directorio, las lecciones calan diferente.

La Startup transcurre en Bogotá. Una empresa fintech que comenzó con innovación genuina ahora se ahoga en disfunción. El desarrollador líder ha desaparecido. Un consultor ágil italiano está vendiendo aceite de serpiente a quien lo escuche. Don Hernando, el ganadero que apostó su legado en esta startup, trae a un Developer Advocate alemán para descubrir qué está pasando realmente. La pregunta no es si la empresa sobrevivirá. La pregunta es si alguien dirá la verdad antes de que sea demasiado tarde.

Código del Destino está ambientada en Ciudad de México. LogiMex Systems construyó un imperio sobre sistemas legacy AS/400 — durante 25 años, su software de logística impulsó empresas de transporte en toda América Latina. Ahora deben modernizarse a SaaS o morir. El mismo Developer Advocate alemán llega para guiar la transformación. Pero el sobrino ambicioso del patriarca tiene otros planes. Entra Bruno Cavalcanti: un consultor brasileño con un framework seductor y un rastro de empresas destruidas tras de sí. Hay amor prohibido en un club ecuestre, desarrolladores veteranos aterrados de la obsolescencia, y un legado familiar que quizás no sobreviva la transformación. El ciclo de vida del framework se desarrolla en tiempo real, pero te importarán los personajes primero.

Ambas historias muestran lo que el análisis solo puede describir. El miedo en los ojos de un desarrollador cuando se da cuenta de que su experiencia está siendo descartada por la metodología de otro. El momento silencioso cuando un líder finalmente admite que cometió un error. El costo del silencio. La posibilidad de redención.

Si el patrón en este artículo se siente familiar, las historias podrían impactar diferente. A veces la ficción es solo la verdad con mejores diálogos.

El Camino Alternativo

El ciclo de vida no es una prisión. En cualquier fase, las organizaciones pueden salir haciendo algo radical: volver a lo básico.

Esto significa invertir en capacidad real de ingeniería. Desarrollo guiado por pruebas. Integración continua con pruebas automatizadas reales. Desarrollo basado en trunk. Especificaciones ejecutables. Las prácticas que los equipos de alto rendimiento han usado durante décadas — las que los frameworks de gestión ni siquiera tocan.

La IA es ahora un acelerador para este camino. Los desarrolladores que entienden los fundamentos encuentran las herramientas de IA extraordinariamente poderosas. La IA maneja el boilerplate y el código de infraestructura. Esto libera a los desarrolladores para enfocarse en lo que importa: entender el problema, diseñar soluciones elegantes, asegurar la calidad.

Un desarrollador que entiende HTTP, HTML y CSS puede usar IA para generar exactamente el código frontend que necesita — sin el framework JavaScript que trae infierno de actualizaciones, vulnerabilidades en la cadena de suministro y miles de líneas de código desconocido. Un desarrollador que entiende SQL puede usar IA para escribir precisamente las consultas que necesita — sin el ORM que oculta lo que realmente está pasando.

El camino existe. Las herramientas son mejores que nunca. Lo que se requiere es el coraje de admitir que los frameworks nunca fueron la respuesta. La respuesta siempre fue la habilidad. El oficio. La comprensión.

Un Rol de Compañero, No de Crítico

Comparto este patrón no para burlarme de las organizaciones atrapadas en él. Las presiones son reales. Pero entender el ciclo de vida ayuda. Cuando reconoces que la Fase 3 está emergiendo, puedes elegir diferente. Cuando la Fase 4 llega, puedes aprovechar la oportunidad en lugar de retirarte a la Fase 5A.

Los ciclos de framework eventualmente terminan. No porque las organizaciones se rindan, sino porque finalmente construyen la capacidad de ingeniería que hace al framework opcional.

Hay un chiste cínico en nuestra industria: “Las organizaciones están más listas para aprender cuando tienen una experiencia cercana a la muerte.” No seas como ellas. No tienes que esperar la catástrofe. Los puntos de salida están marcados. El camino es claro. Empieza a caminar.