Liderando desarrollo en LATAM bajo presión real: comprimir ciclos de 6–8 meses a 7–8 semanas "apoyándonos fuerte" en IA generativa.
Estoy liderando desarrollo en LATAM bajo una presión concreta: comprimir ciclos de 6–8 meses a 7–8 semanas "apoyándonos fuerte" en IA generativa. La premisa tiene algo de verdad: en su investigación enterprise, GitHub y Accenture reportan evidencias de impacto (incluyendo resultados de laboratorio donde desarrolladores completaron tareas hasta 55% más rápido) y una metodología basada en experimento y telemetría para medir su impacto en entornos reales.
La ilusión nace en el demo. Un stakeholder muestra una UI con prompts, un flujo "que ya funciona", y la conversación salta directo a producción: "solo hay que montarlo". Me recordó un tema recurrente en Productoria: cuando el calendario gobierna el desarrollo, la calidad termina pagando, y la era del parche puede ser promesa… o peligro.
En paralelo, el equipo se entusiasma explorando y se decepciona rápido cuando el output está incompleto o sin contexto interno. Esa decepción es sensata: sin conocimiento organizacional, el modelo responde como generalista y la confianza se erosiona; y DORA documenta que la confianza en outputs de genAI se relaciona con la capacidad de capturar beneficios de productividad (sin confianza, no hay adopción sostenida).
Dejé de discutir si el demo "está bien" y empecé a usarlo como artefacto de descubrimiento. En una sesión, un líder de negocio llegó con un flujo montado en prompts y una pregunta que sonaba inocente: "si ya corre, ¿qué falta?". Bastaron 15 minutos para que el mismo demo revelara lo que no estaba en pantalla: datos, auditoría, usuarios reales, y quién se despierta cuando algo falla.
El patrón es estable: el negocio trae un prototipo y un expectation gap escondido (demo ≠ plataforma). Cuando explicamos que no es tan simple, aparece el juicio emocional ("no quieren subirse"), pero ahí está la oportunidad: el demo revela su modelo mental y permite negociar qué significa "funciona" con criterios explícitos.
Para bajar la conversación a tierra, usé Value Stream Mapping porque hace visible dónde se va el tiempo real. DORA describe VSM como una práctica para visualizar el flujo de trabajo de idea a producción, identificar cuellos de botella y facilitar conversaciones sobre fricción.
Demo + prompts + "dolor" en una frase.
Outcome medible, mapa VSM del flujo actual, y NFRs mínimos como criterios de aceptación.
Una hoja de outcome/KPIs, registro de supuestos, VSM con el cuello dominante, y un backlog de slice vertical (operable).
El prototipo suele "correr", pero falla donde no se ve en el demo:
Reglas de negocio, contratos de datos, integraciones, decisiones históricas.
Performance, disponibilidad, auditoría, costos, mantenibilidad.
NIST es explícito: muchos SDLC no abordan seguridad en detalle y hay que integrar prácticas de desarrollo seguro.
Observabilidad, runbooks, SLOs, rollback, ownership.
La promesa de 7–8 semanas fracasa cuando se intenta comprimir solo "teclado", no el flujo end-to-end.
DORA insiste en que velocidad y estabilidad no son trade‑offs en alta performance, pero eso exige reducir lotes, colas y retrabajo, y medir throughput e inestabilidad con métricas concretas (lead time, deployment frequency, failed deployment recovery, change fail rate, rework).
En vez de "migrar el demo", lo traté como una ruta por etapas:
Un slice vertical operable.
El estudio GitHub/Accenture es útil por su combinación de experimento y telemetría.
Adopción y aceptación/uso; PR cycle time; lead time a producción; frecuencia de despliegue; failed deployment recovery; change fail rate/rework; señales de seguridad (SAST/SCA/secrets); y costo por flujo.
IBM describe barreras típicas de adopción (precisión/sesgo, falta de datos propietarios para personalizar, falta de expertise, confidencialidad).
En mi experiencia, el punto de quiebre no está en la herramienta: está en el momento en que el negocio quiere tratar el demo como base técnica. Para evitarlo, cierro cada taller con dos acuerdos: qué se considera un "done" operable (incluyendo NFRs y seguridad) y cuál es el cuello de botella a atacar primero en el flujo. Eso transforma la presión en un plan de aprendizaje iterativo, no en una guerra de percepciones.
La ilusión del prompt mágico y la realidad de entregar en ocho semanas