De "move fast" a "ship crap": cuando la velocidad se come a la calidad

Publicado el 15 de febrero de 2026 • 9 minutos • 1723 palabras

Table of contents

Cuando “ir rápido” se convierte en “romperlo todo”
Grandes hostias por ir con prisas
El día a día: productos que “funcionan”, pero dan asco-pena
OKR, velocity y la ilusión de progreso
Estado actual del problema: más features, más ruido, misma miseria
¿Y ahora qué? De “move fast” a “move smart”
Glosario rápido para no perderse en las siglas
Fuentes y referencias

Estábamos al borde del abismo y hemos dado un gran paso adelante.

Durante años nos han vendido el “move fast” como si fuera una virtud absoluta. El problema es que, en demasiados equipos, se ha traducido en “ship crap”: entregar rápido, romper cosas… y luego vivir atrapado en la deuda técnica, los bugs, los cabreos de tus clientes y la frustración. En este artículo te voy a contar cómo las métricas mal planteadas (OKR, velocity, “features por trimestre”) están empujando a muchos productos al abismo, y a darte alguna solución, que no todo está (tan) mal.

Cuando “ir rápido” se convierte en “romperlo todo”

La idea original tenía sentido: entrega continua, feedback rápido, iterar con el usuario. El problema vino cuando la consigna se convirtió en KPI. De repente, lo único que importaba era:

Cuántas features salen al trimestre.
Cuántos tickets se cierran por sprint.
Cuántos OKR “verde fosforito” puedes enseñar en la slide del QBR.

Velocity, por ejemplo, es una métrica útil como herramienta de planificación interna. El desastre empieza cuando se convierte en objetivo de rendimiento: los equipos inflan estimaciones, priorizan tareas fáciles con muchos puntos y recortan pruebas para “cumplir el número”. Sobre el papel, todo mejora. En producción, todo empeora.

Stack Overflow lo resume muy bien: cuando mides el éxito de ingeniería solo por velocidad o volumen de trabajo, empujas a los equipos a cortar esquinas y sacrificar calidad, y la supuesta “productividad” se convierte en humo.

Grandes hostias por ir con prisas

No hace falta inventar ejemplos, hay un museo entero de “move fast, regret later”:

Cyberpunk 2077 : CD Projekt Red se precipitó al lanzamiento en 2020 con plazos irreales, promesas gigantes y plataformas (especialmente consolas) donde el juego estaba lleno de bugs y con un rendimiento desastroso. El resultado: retirado de la PlayStation Store durante meses, devoluciones masivas y años de trabajo posterior solo para volver a estar “aceptable”.
Healthcare.gov : el portal de seguros de salud se lanzó en 2013 por presión política y de fechas, con un sistema que se caía constantemente, problemas de seguridad y una experiencia de usuario lamentable. Hizo falta una reconstrucción casi completa tras el desastre inicial.
Knight Capital : 2012, una actualización apresurada de su software de trading introdujo un bug que generó operaciones erróneas durante 45 minutos. Pérdidas de unos 440 millones de dólares y la empresa prácticamente muerta.
Boeing 737 MAX : caso extremo, pero ilustrativo: un sistema de software (MCAS) desarrollado con prisas, mal diseñado y mal probado contribuyó a dos accidentes mortales, 346 fallecidos y un coste de reputación y dinero brutal.

En todos estos casos hay ingredientes comunes: presión para cumplir fechas, decisiones de gestión anteponiendo “salir ya” a “salir bien” y métricas que premiaban la entrega sobre la robustez.

El día a día: productos que “funcionan”, pero dan asco-pena

No hace falta irse a catástrofes mediáticas. Cualquiera que use software moderno vive rodeado de ejemplos donde la obsesión por añadir cosas rápido ha destrozado la experiencia:

Microsoft Teams: herramienta ubicua, útil y con un roadmap infinito de features e integraciones… pero con una fama bien ganada de pesado, tragón de RAM y a veces torpe .
- Usuarios reportan congelaciones frecuentes, tiempos de arranque muy lentos y consumos de memoria por encima de 1 GB incluso en tareas básicas de chat o videollamadas.
- Quejas recientes apuntan a picos de uso de GPU que afectan a otras aplicaciones y una sensación general de que cada nueva hornada de funciones hace la app más pesada sin mejorar realmente lo esencial.
Videojuegos modernos: lanzamientos a precio completo que llegan al mercado con parches “día 1” descomunales, bugs graves y rendimiento pobre en hardware perfectamente razonable. Cyberpunk 2077 es el ejemplo estrella, pero está lejos de ser el único.

A nivel menos visible, hay una ristra de proyectos empresariales (ERP, portales ciudadanos, sistemas internos) que han fracasado o se han enquistado por recortar en calidad, pruebas y diseño para “llegar al deadline”: decenas de millones tirados en implementaciones de ERP fallidas , sistemas nunca adoptados o rediseños completos a los pocos años.

OKR, velocity y la ilusión de progreso

No es que OKR y compañía sean malos en sí. El problema es cómo se usan:

OKR mal planteados:
- “Lanzar 20 features nuevas este trimestre.”
- “Incrementar un 30% el número de historias cerradas por sprint.” Ninguno de esos objetivos habla de calidad, estabilidad, reducción de incidencias o satisfacción de usuario. Así que nadie se sorprende cuando todo eso empeora.
Velocity como KPI:
- Si sube, “vamos bien”.
- Si baja, “hay que apretar”. Resultado: estimaciones infladas, trabajo fragmentado para que cuente más, menos tiempo para refactors y tests, más tiempo para apagar fuegos después.

Varios artículos recientes sobre métricas de agilidad coinciden en lo obvio: usar velocity como métrica de éxito es una receta casi garantizada para degradar la calidad y perder de vista el impacto real en negocio. Lo que aumenta no es tu productividad, es tu capacidad de autoengañarte.

Estado actual del problema: más features, más ruido, misma miseria

La foto general hoy es bastante triste:

Deuda técnica: empresas que han “acelerado” durante años se encuentran con sistemas difíciles de mantener, tiempos de entrega reales cada vez peores y equipos quemados. Hay casos documentados de productos donde la deuda técnica acumulada genera fallos de software catastróficos y pérdidas millonarias.
Métricas tóxicas: muchos equipos siguen midiendo éxito en base a output (tickets, puntos, releases) en lugar de outcomes (mejora en KPIs de usuario, reducción de incidencias, impacto en negocio).
Productos hinchados: herramientas que empezaron siendo relativamente ligeras y enfocadas, y hoy son monstruos llenos de features que casi nadie usa, consumen recursos excesivos y pierden la sencillez original.

Y lo mejor de todo: muchas organizaciones se sorprenden al descubrir que, a medio plazo, este modelo “rápido” es más caro. El coste de bugs, parches de urgencia, caídas, soporte y reescrituras supera con creces lo que habrías gastado en hacer las cosas bien de inicio.

¿Y ahora qué? De “move fast” a “move smart”

La alternativa no es volver a proyectos de cinco años con cascadas infinitas y documentos de 300 páginas. Es bastante más sencilla:

Cambiar OKR de “lanzar X features” a “mejorar Y métrica de usuario / negocio”, dejando espacio explícito para calidad y mantenimiento.
Medir algo más que velocidad : defectos en producción, tiempo dedicado a apagar incendios, satisfacción del usuario, estabilidad de la plataforma.
Proteger tiempo para refactors, pago de deuda técnica y mejoras estructurales como parte del plan, no como “si sobra sprint”.

La tesis es simple: puedes seguir moviéndote rápido, pero solo si dejas de premiar el “ship crap” y empiezas a premiar el impacto real y la calidad sostenible. Porque moverse rápido hacia el precipicio también es moverse rápido, pero no suele acabar bien.

Glosario rápido para no perderse en las siglas

OKR (Objectives and Key Results) Marco para definir objetivos (Objectives) y resultados clave medibles (Key Results). La idea original es alinear a toda la organización en pocas metas claras y medibles, no hacer listas infinitas de features. Bien usados, los OKR hablan de impacto (“aumentar retención un 10%”), no de output (“sacar 20 features”).

KPI (Key Performance Indicator) Indicador clave de rendimiento. Es una métrica que se usa para evaluar si se está cumpliendo un objetivo concreto (por ejemplo, tiempo medio de resolución de incidencias, NPS, tasa de errores). El problema viene cuando se escogen KPIs pobres (tickets cerrados, puntos por sprint) que no reflejan valor real.

Velocity (velocidad de equipo) En Scrum, es la suma de story points completados por un equipo en un sprint. Sirve para planificar cuánto trabajo cabe en el siguiente sprint, no para comparar equipos ni para medir “quién trabaja más”. Usarla como métrica de éxito fomenta inflar estimaciones y recortar calidad .

Story points Unidad relativa de esfuerzo/ complejidad que usa un equipo ágil para estimar tareas. No son horas ni días; son una escala comparativa interna. Dos equipos diferentes no son comparables en puntos, y convertirlos en objetivos numéricos suele acabar mal.

Output vs Outcome

Output: lo que produces (número de features, tickets cerrados, líneas de código).
Outcome: el efecto que eso tiene (más ventas, menos errores, más retención, mejor experiencia de usuario). Las críticas modernas a métricas tóxicas van justo de esto: se mide y se optimiza el output, ignorando el outcome .

Deuda técnica (Technical Debt) Metáfora para describir atajos y decisiones subóptimas en diseño, arquitectura o código que te permiten ir más rápido hoy, pero que tendrás que “pagar” más adelante en forma de mantenimiento, bugs y dificultad para cambiar el sistema. Cuando solo se optimiza por velocidad a corto plazo, la deuda técnica tiende a explotar en forma de fallos grandes y costes imprevistos.

MTTR (Mean Time To Recovery) Tiempo medio de recuperación. Mide cuánto tardas en recuperar el servicio tras un incidente (caída, degradación severa…). Es una de las métricas DORA para equipos de alto rendimiento; obsesionarse solo con “entregar rápido” sin mirar MTTR suele ser receta para el desastre.

SLO / SLA / SLI Relacionado pero distinto del tema central, ayuda a entender la parte de calidad:

SLI (Service Level Indicator): lo que mides (latencia, tasa de errores, uptime).
SLO (Service Level Objective): el objetivo interno (“99,9% de peticiones con éxito al mes”).
SLA (Service Level Agreement): lo que prometes por contrato al cliente, con consecuencias si no lo cumples.