¿Qué es la regla del noventa-noventa?
Cultura de ingeniería y práctica de software
La regla del noventa-noventa es un famoso chiste del mundo del software sobre los plazos. Dice que la primera parte visible de un proyecto consume una gran porción del tiempo, y que la supuesta etapa final, aparentemente pequeña, acaba llevando casi otro tanto. Los ingenieros la usan para describir la persistente cola de integración, pruebas, casos extremos, documentación, trabajo de lanzamiento y pulido, que suele aparecer cuando todo el mundo ya ha empezado a decir que la funcionalidad está básicamente lista.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
La regla tiene gracia precisamente porque la aritmética es imposible. Eso es lo que la hace memorable. Captura la sensación de que un equipo puede avanzar casi hasta tener una funcionalidad operativa y luego pasar una eternidad en ese último tramo incómodo.
En el software, ese "último tramo incómodo" rara vez es una sola cosa. Es la acumulación de detalles que siempre fueron reales pero fáciles de ignorar al principio: migración de datos, controles de seguridad, monitorización, empaquetado, permisos, reintentos, mensajes y soporte para todos los casos extraños que los usuarios reales encuentran de inmediato.
Por qué importa
Esta pieza de cultura ingenieril importa porque explica una fuente perenne de frustración entre los equipos y quienes los rodean. Desde fuera, una funcionalidad puede parecer casi terminada en cuanto funciona una demo. Desde dentro, esa demo puede seguir careciendo del endurecimiento que convierte una versión prometedora en algo que se puede lanzar y mantener con seguridad.
La regla también enseña una lección útil sobre planificación. El trabajo de software no se distribuye de forma uniforme a lo largo de la vida de una tarea. El final acumula mucho peso oculto. Si quienes lideran no tienen eso en cuenta, generan un ciclo de informes de progreso optimistas seguidos de decepciones dolorosas. Entender la regla ayuda a los equipos a hablar con más honestidad sobre qué incluye realmente el "hecho".
Cómo funciona
El origen de la regla
La regla se atribuye habitualmente a Tom Cargill, de Bell Labs. La aparición impresa más conocida y temprana está en la columna Programming Pearls de Jon Bentley de 1985, "Bumper-Sticker Computer Science", en Communications of the ACM, donde aparece bajo la etiqueta "Rule of Credibility". Esto importa porque sitúa la frase en el mundo de las máximas de ingeniería concisas, no en la teoría formal de gestión de proyectos.
También apunta al espíritu con el que la gente la ha usado desde entonces. La frase no es un cálculo. Es un ingeniero experimentado poniendo los ojos en blanco ante la forma en que el trabajo de software se expande en el tramo final.
Por qué crece el último tramo
El progreso inicial en software suele ser muy visible. Se puede esbozar la interfaz, conectar el camino feliz, mostrar un flujo funcional y hacer que el sistema parezca casi completo. El problema es que el software solo se vuelve verdaderamente real cuando se enfrenta a todo el entorno que lo rodea.
Ese entorno incluye datos reales, usuarios reales, tiempos reales y fallos reales. Una funcionalidad que funciona para una entrada puede fallar con otras veinte. Un servicio que corre sin problemas en un portátil puede tener dificultades en producción. Un flujo de trabajo que parece correcto en una demo puede ser inutilizable sin los permisos adecuados, registros de auditoría, notificaciones, reversión y guías de soporte. No ha ocurrido nada mágico. El equipo simplemente ha llegado a la parte del trabajo en la que el sistema tiene que dejar de ser plausible y empezar a ser fiable.
Por eso el final del calendario parece desproporcionado. Cerrar la brecha entre "funciona en principio" y "funciona en la práctica" obliga al equipo a descubrir todos los supuestos que faltaban.
Cómo usan los ingenieros la regla en la práctica
Cuando los ingenieros invocan la regla del noventa-noventa, suelen advertir contra uno de tres hábitos. El primero es confundir una demo con un lanzamiento. El segundo es tratar el trabajo de pruebas, operaciones y documentación como añadidos opcionales. El tercero es informar del porcentaje completado como si el progreso del software fuera fluido y lineal.
En los equipos sanos, la frase se usa con cierta ironía. Recuerda a las personas que no se dejen engañar por su propio impulso inicial. También fomenta una mejor definición del alcance. Si un equipo quiere un calendario genuinamente corto, a menudo tiene que reducir el trabajo de forma más significativa, no simplemente fingir que el último tramo será rápido.
Lo que la frase no significa
La regla no significa que las estimaciones de software sean inútiles. Significa que las estimaciones mejoran cuando los equipos definen correctamente qué es completar algo. Si "hecho" incluye integración, pruebas, despliegue, permisos, observabilidad y traspaso al soporte, la trampa se vuelve más fácil de ver.
Tampoco significa que el tramo final de cada proyecto vaya a desbordarse. Algunos trabajos están bien acotados. La regla es memorable porque el caso contrario es frecuente, especialmente en trabajo de producto, cambios de plataforma, integraciones y todo lo que tiene cara al usuario.
Ejemplos
Un equipo construye un nuevo flujo de pago y muestra con orgullo que el cobro funciona. Entonces llega el verdadero tramo final. La gestión de reembolsos, los reintentos por tarjeta fallida, los casos extremos de impuestos, el momento del recibo, las comprobaciones antifraude, los análisis, los guiones de atención al cliente y las correcciones de accesibilidad requieren atención. El sistema no estaba engañosamente incompleto. Estaba incompletamente definido.
Un equipo de plataforma interna dice que una migración está casi lista porque el nuevo servicio está en marcha. Lo que queda parece pequeño: desactivar el camino antiguo. En la práctica, eso implica rellenos de datos, paneles de control, guías de guardia, cambios de acceso, rotación de secretos, comprobaciones de consistencia de datos y un plan de reversión. El movimiento visible era solo una parte del trabajo.
Una funcionalidad de informes parece completa en el entorno de pruebas. Una vez que llega a producción, los usuarios quieren formatos de exportación, coherencia de zonas horarias, filtros de permisos, nombres de columnas que coincidan con el lenguaje del negocio y cifras que cuadren con finanzas. El "último diez por ciento" resulta ser la parte que decide si alguien confía en él.
Malentendidos frecuentes
Un error habitual es tratar la regla como una autorización para inflar drásticamente todas las estimaciones. Eso pasa por alto la cuestión. El objetivo no es la inflación, sino la honestidad sobre qué incluye completar algo.
Otro malentendido es que la regla solo afecta a equipos débiles. Los equipos fuertes también pueden sufrirla, especialmente cuando el límite entre el trabajo de funcionalidad y el trabajo de lanzamiento es difuso.
También se usa como si fuera principalmente sobre programación. En realidad, el doloroso tramo final suele vivir en las pruebas, la integración, las operaciones, el soporte y los detalles de producto.
Por último, hay quienes escuchan el chiste y concluyen que el porcentaje completado es inútil. Puede ser útil, pero solo si el equipo comparte una definición real de cada hito en lugar de ofrecer números redondos optimistas.
Riesgos y límites
La versión negativa de esta regla se convierte en cinismo. Los equipos se encogen de hombros, asumen que todo proyecto se descontrolará y dejan de aprender de sus errores. Eso no es sabiduría. Es rendición.
La versión positiva es diagnóstica. Si el final del trabajo siempre se expande, conviene preguntarse qué se sigue omitiendo del plan. ¿Es la integración? ¿La preparación para el lanzamiento? ¿La calidad de los datos? ¿Las aprobaciones? ¿La monitorización? La regla tiene más valor cuando revela un punto ciego que el equipo puede corregir.
También tiene un límite natural. Si un trabajo está bien acotado y el equipo ha hecho lo mismo muchas veces antes, el tramo final puede ser corto. El folclore debe agudizar el juicio, no sustituirlo.
Qué hacer a continuación
Si este patrón resulta familiar, conviene empezar por reforzar la definición de "hecho". Hay que dejar claro que el progreso no es solo código escrito. Incluye pruebas, instrumentación, preparación para el despliegue, documentación y todo lo que la organización necesite antes de que un cambio esté genuinamente completo.
Divide los proyectos grandes en hitos que cada uno termine de verdad, no de forma teatral. Pide evidencias de preparación, no solo porcentajes. Cuando un equipo diga que algo está casi listo, pregunta qué queda en integración, casos extremos, reversión, soporte y seguridad en producción.
Sobre todo, deja de recompensar el optimismo temprano más que la precisión tardía. Los equipos producen mejores estimaciones cuando decir la verdad es más seguro que hacer teatro.
¿Tienes alguna pregunta o sugerencia, o quieres saber cómo investigamos y revisamos estas guías? Lee sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es la regla del noventa-noventa matemáticamente seria?
No. La aritmética rota es el chiste. Es una forma de hacer que el tramo final del calendario sea inolvidable.
¿Por qué el final del trabajo de software suele ser más difícil que el inicio?
Porque es donde el sistema se enfrenta a la realidad. Los casos extremos, la integración, la gestión de fallos y los detalles del lanzamiento se vuelven inevitables.
¿Es lo mismo que la Ley de Brooks?
No. La Ley de Brooks trata sobre añadir personas a un proyecto retrasado. La regla del noventa-noventa trata sobre cómo el supuesto pequeño tramo final no deja de crecer.
¿El trabajo ágil hace desaparecer la regla?
No automáticamente. La entrega iterativa puede exponer el tramo final antes, pero solo si el equipo trata cada fragmento como algo cercano a lo genuinamente publicable.
¿Cómo se puede evitar la trampa?
Usando una definición de "hecho" más sólida, dividiendo el trabajo con más cuidado e incluyendo las tareas de integración y lanzamiento en el plan desde el principio.
¿Esto solo aplica a productos de cara al cliente?
No. Las herramientas internas, los cambios de infraestructura, las migraciones y el trabajo con datos pueden mostrar exactamente el mismo patrón.
Fuentes
September 1985 issue (Communications of the ACM). publication context for Jon Bentley's column and the period in which the rule entered print
Bumper-Sticker Computer Science (IIT Chicago mirror of Communications of the ACM article). early printed appearance of the rule, attribution to Tom Cargill, and "Rule of Credibility" label