Teoría de Cuellos de Botella
Por qué mejorar la restricción importa—y todo lo demás no.
1La Teoría de Restricciones
En la década de 1980, Eli Goldratt desarrolló la Teoría de Restricciones (TOC). La idea central es simple pero profunda:
Todo sistema tiene una restricción—un paso que limita el rendimiento del conjunto.
Piensa en una autopista: si un tramo está congestionado, toda la autopista se ralentiza. Ampliar los tramos despejados no ayuda. Tienes que arreglar el tramo congestionado.
Lo mismo aplica a los flujos de valor. Si la revisión de código es el cuello de botella, hacer el desarrollo más rápido solo crea una pila más grande en la revisión de código. Si las pruebas son la restricción, contratar más desarrolladores solo significa más trabajo esperando por QA.
El sistema solo puede moverse tan rápido como su restricción más lenta.
Esto tiene implicaciones poderosas para la mejora: mejorar cualquier cosa que no sea la restricción es teatro. Puede sentirse productivo pero no tiene efecto en el rendimiento general.
El Poder del Enfoque
TOC te dice exactamente dónde enfocarte: la restricción. Ignora todo lo demás hasta que la restricción se rompa. Luego encuentra la nueva restricción y repite. Esto previene la trampa común de optimizar en todas partes sin resultados.
2Encontrar la Restricción
¿Cómo encuentras la restricción? Busca dónde se acumula el inventario (trabajo).
La restricción tiene una pila de trabajo esperando frente a ella. Si la revisión de código siempre tiene un atraso, la revisión de código es probablemente la restricción. Si las pruebas tienen semanas de trabajo en cola, las pruebas son probablemente la restricción.
Otras señales de restricciones:
- Alta utilización: La restricción está al máximo
- Presión constante: Las personas en la etapa de restricción siempre están apuradas
- Inanición posterior: Las etapas después de la restricción están esperando trabajo
- Frustración anterior: "Terminamos, ¿por qué no avanza?"
Restricciones comunes de software:
- Revisión de código (muy pocos revisores, PRs grandes)
- Pruebas (QA manual, cobertura de pruebas limitada)
- Despliegue (lanzamientos complejos, ventanas de despliegue limitadas)
- Decisiones de arquitectura (esperando al arquitecto)
- Decisiones de producto (esperando al propietario del producto)
Nota: la restricción a menudo no es una etapa "productiva". Puede ser un tomador de decisiones. Puede ser un proceso de aprobación. Puede ser un recurso compartido.
Un equipo mide y encuentra trabajo acumulándose en el despliegue. Solo una persona sabe cómo desplegar. Tienen tiempo para un despliegue por semana. Todo lo demás espera. Solución: automatizar el despliegue y difundir el conocimiento. El rendimiento se duplica.
La gerencia ve a los desarrolladores 'subutilizados' (90% vs. 100%) y asigna más trabajo. Los desarrolladores aceleran. Pero el despliegue es la restricción—sigue siendo una vez por semana. El tiempo de entrega no mejora. El inventario frente al despliegue crece.
3Explotar y Elevar Restricciones
TOC prescribe un proceso de cinco pasos:
1. Identificar la restricción: Encuentra dónde se acumula el trabajo.
2. Explotar la restricción: Maximiza el rendimiento a través de la restricción sin agregar recursos. Si la revisión de código es la restricción, prioriza las revisiones sobre el nuevo desarrollo. Asegúrate de que los revisores no estén distraídos. Reduce el tamaño de los PR para que las revisiones sean más rápidas.
3. Subordinar todo lo demás: Las no restricciones deben servir a la restricción. Si QA es la restricción, no empujes más trabajo hacia QA—ajusta el ritmo del desarrollo para igualar la capacidad de QA.
4. Elevar la restricción: Si la explotación y la subordinación no son suficientes, agrega capacidad a la restricción. Capacita a más revisores. Automatiza las pruebas. Contrata más de la habilidad restringida.
5. Repetir: Una vez que rompes una restricción, emerge otra. La restricción se mueve. Encuéntrala y repite.
Esto es mejora continua e iterativa. Siempre estás enfocado en la restricción actual, no disperso en todas las etapas.
La metáfora del tambor-amortiguador-cuerda: La restricción es el "tambor" que marca el ritmo. El trabajo antes de la restricción es el "amortiguador". La "cuerda" jala el trabajo hacia el sistema al ritmo que la restricción puede manejar—no más rápido.
La Restricción Errante
Cuando rompes una restricción, otra etapa se convierte en la nueva restricción. Esto es normal. Pero si la restricción deambula aleatoriamente (a veces desarrollo, a veces QA, a veces despliegue), tu sistema es inestable. Estabiliza primero, luego optimiza.
- Todo sistema tiene una restricción que limita el rendimiento general
- Mejorar las no restricciones no ayuda al sistema
- Encuentra la restricción buscando dónde se acumula el trabajo
- Explota la restricción antes de agregar capacidad
- Cuando rompes una restricción, emerge otra—repite