←
Más deprisa que nunca: los fundamentos científicos del agile en la era de la IA

11 · Ritmo sostenible y aprender del fallo14 min read

Teoría — Ritmo sostenible y el arte de aprender del fallo

La noche del despliegue no fue mala suerte: fue la ejecución puntual de varias leyes bien documentadas — sobre lo que las horas hacen al rendimiento, lo que la vigilia hace al juicio, lo que la presión hace a los márgenes de seguridad, y lo que el miedo hace a la información. Esta sección reúne esa evidencia, que es de las más duras del curso en ambos sentidos de la palabra: metodológicamente sólida, y difícil de mirar. Incluye datos de salud cardiovascular, dos transbordadores espaciales y una fábrica de municiones de 1915. Termina, como terminó Aurelia, en el postmortem sin culpa — la práctica donde todo el curso converge.

1. Horas y producción: la curva que la industria conoce desde 1917 y olvida cada lunes

El octavo principio del Manifiesto Ágil pide «desarrollo sostenible: un ritmo constante indefinidamente». Suena a valor blando; es economía empírica. La mejor evidencia cuantitativa procede de un contexto brutalmente motivado para exprimir horas: las fábricas británicas de munición de la Primera Guerra Mundial, cuyos datos (del Health of Munition Workers Committee, 1915-1917) reanalizó el economista de Stanford John Pencavel ("The Productivity of Working Hours", 2014/2015). Los resultados, con sus números exactos:

  • Por debajo de 49 horas semanales, la producción es proporcional a las horas: trabajas más, produces más.
  • A partir de 49, la producción crece a ritmo decreciente; el máximo absoluto de producción se alcanza hacia las 63 horas; y —

"Output at 70 hours differs little from output at 56 hours." [traducción propia] «La producción a 70 horas difiere poco de la producción a 56.»

Catorce horas semanales extra — dos jornadas — para producir prácticamente lo mismo. Y el hallazgo del descanso: «el trabajo de siete días produce solo la producción de seis, y las reducciones del trabajo dominical no supusieron pérdida de producción». Los domingos no sumaban. En 1917. Con torneras de municiones, trabajo físico medible al kilo. Henry Ford — nadie lo acusará de filántropo laboral — llegó a la misma cuenta por la vía contable: jornada de 8 horas en 1914, semana de 5 días en 1926, con el argumento explícito de que producían al menos lo mismo en cinco días que en seis.

Cautelas honestas: es un contexto concreto (trabajo manual, 1915), y la generalización exacta de los umbrales al trabajo cognitivo no está establecida — lo que converge entre dominios es la forma de la curva: rendimientos decrecientes, luego nulos o negativos. Para trabajo del conocimiento hay además una asimetría que empeora el cuadro: la producción de una tornera cansada se mide al momento; el código de un programador exhausto se mide semanas después, en producción, con intereses. La industria del videojuego lo documenta como forma de vida: las encuestas de la IGDA (Developer Satisfaction Survey 2019) sitúan el crunch en la experiencia del ~41-42% de los desarrolladores, con otro tanto reportando que «se espera» en su empresa — y su literatura de casos (desde el célebre «EA: The Human Story» de 2004) describe el ciclo exacto de Aurelia: la excepción que se institucionaliza.

2. El sueño: programar legalmente ebrio

La pieza más contundente de esta sección cabe en una cita. Williamson y Feyer (2000, Occupational and Environmental Medicine), comparando experimentalmente privación de sueño y alcohol:

"After 17-19 hours without sleep… performance on some tests was equivalent or worse than that at a BAC of 0.05%." [traducción propia] «Tras 17-19 horas sin dormir, el rendimiento en varias pruebas fue equivalente o peor que con una alcoholemia del 0,05%.»

El 0,05% de alcohol en sangre es el límite legal de conducción en España. Con privación mayor, la equivalencia sube al 0,1% — el doble del límite. (Convergente con Dawson y Reid, 1997, en Nature; y con el meta-análisis de Lim y Dinges, 2010, sobre privación aguda y atención.) Marc a la 1:40, con diecisiete horas de vigilia y una semana a seis horas: la organización había puesto a aprobar cambios clínicos a alguien en el estado cognitivo en el que la ley le prohibía conducir un coche. Ninguna política escrita de Aurelia lo permitía; toda la cadena de decisiones de la quincena lo produjo.

Complementos con evidencia: la investigación de recuperación de Sabine Sonnentag muestra que recuperarse del estrés laboral exige desconexión psicológica — dejar de pensar en el trabajo fuera de él; la disponibilidad permanente (el canal de despliegues en el móvil de madrugada) degrada la recuperación aunque no se responda. Y el meta-análisis de vacaciones (de Bloom et al., 2009): el bienestar mejora al irse y el efecto se disipa en la primera semana de vuelta — la recuperación no se almacena: o es recurrente (noches, fines de semana, el fin de sprint de verdad) o no es.

3. Control y salud: la autonomía como variable cardiovascular

La sección 1 prometió esta pieza y aquí está, porque merece asombro: el diseño del trabajo predice enfermedad coronaria. El estudio Whitehall II (cohorte prospectiva de funcionarios británicos, dirigida por Michael Marmot) encontró — Bosma et al., 1997, BMJ, texto completo libre — que el bajo control sobre el propio trabajo predecía nuevos eventos coronarios con una odds ratio de 1,93 (IC 95%: 1,34-2,77), ajustando por grado de empleo, personalidad y factores de riesgo clásicos. Casi el doble de riesgo, por la variable «cuánto decides sobre tu propio trabajo». El marco teórico es el modelo demanda-control de Karasek (1979): la combinación tóxica no es la exigencia alta — es exigencia alta con baja latitud de decisión; y el modelo esfuerzo-recompensa de Siegrist añade el tercer eje (esfuerzo alto con recompensa baja — dinero, estima, seguridad — también enferma). Los meta-análisis posteriores (Kivimäki et al., 2012, Lancet) confirman el efecto del job strain sobre el infarto, algo más modesto que en los estudios pioneros, pero real.

Júntalo todo y el «ritmo sostenible» deja de ser un principio simpático: los equipos autoorganizados con carga gestionada no son solo más eficaces (secciones 1, 4, 5) — son literalmente más sanos, con gradiente medible en arterias. Y la advertencia de esta década se formula sola: un sistema donde la IA asigna, mide y acelera el trabajo mientras reduce la latitud de decisión de las personas es una máquina de job strain con interfaz moderna.

4. Normalización de la desviación: el Challenger como espejo

El 28 de enero de 1986, el transbordador Challenger explotó a los 73 segundos por el fallo de las juntas tóricas de un propulsor, heladas la madrugada anterior. El análisis sociológico definitivo es de Diane Vaughan (The Challenger Launch Decision, 1996), que acuñó el concepto que Nadia usó en la pared: normalización de la desviación. Las juntas venían erosionándose en vuelos anteriores — cada erosión era una anomalía fuera de especificación — y cada vez que se volaba «sin pasar nada», la anomalía se reclasificaba como riesgo aceptable. El margen violado se convertía en el margen nuevo. Sin villanos: ingenieros y gestores razonables, con presión de calendario, decidiendo localmente sobre precedentes que ellos mismos habían ido creando. La cadena de Aurelia — del «bajo riesgo con una aprobación» del lunes 6 al deploy ok de la 1:40 — es el mismo mecanismo a escala de startup.

El físico Richard Feynman, en su apéndice personal al informe de la comisión Rogers (Apéndice F, 1986 — dominio público, en la web de la NASA), documentó el síntoma cuantitativo:

"The estimates range from roughly 1 in 100 to 1 in 100,000. The higher figures come from the working engineers, and the very low figures from management." [traducción propia] «Las estimaciones [de probabilidad de fallo] van de aproximadamente 1 entre 100 a 1 entre 100.000. Las cifras altas vienen de los ingenieros de a pie; las bajísimas, de la dirección.»

Un factor mil de diferencia en la percepción del riesgo dentro de la misma organización — el gradiente que produce toda cadena de mando donde las malas noticias se atenúan en cada escalón (Westrum, sección 11, le pondrá tipología). Y la frase final del apéndice, que Bruno le recomendó a Nadia: "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled" — «para que una tecnología tenga éxito, la realidad debe prevalecer sobre las relaciones públicas, porque a la naturaleza no se la puede engañar». Diecisiete años después, el transbordador Columbia se desintegró en la reentrada, y el informe de investigación (CAIB, 2003 — dominio público) dedicó capítulos enteros a demostrar, con Vaughan colaborando, que las causas organizativas pesaron tanto como la espuma que golpeó el ala: la NASA había normalizado también los impactos de espuma. El mecanismo sobrevivió a su propio descubrimiento. Eso es lo que lo hace temible: no se arregla sabiéndolo — se arregla con estructura que lo busque activamente (los working agreements revisados en retro son, exactamente, detectores de deriva: «¿llevamos tres sprints saltándonos la definición de hecho?»).

5. Cultura justa: el sistema que puede mirar sus fallos

¿Y qué hace una organización cuando lo grave ocurre? La ciencia de seguridad — aviación, sanidad, nuclear — lleva décadas destilando la respuesta, y el software la importó con nombres propios.

El modelo mental de partida es el queso suizo de James Reason (2000, BMJ, texto libre): las defensas de un sistema son lonchas con agujeros que se abren, cierran y desplazan; el accidente ocurre cuando los agujeros de muchas lonchas se alinean momentáneamente. Corolario: el «error humano» de la última loncha (Marc a la 1:40) es el final de la explicación, nunca la explicación — la pregunta es qué agujeros estaban abiertos en todas las lonchas anteriores (la cronología de la pared: nueve agujeros alineándose). Reason contrapone el enfoque persona (culpar, formar, amonestar — y no cambiar nada del sistema, garantizando la repetición con otro nombre) al enfoque sistema (rediseñar las lonchas).

Sobre esa base, Sidney Dekker (Just Culture) construyó la distinción entre cultura retributiva (¿quién lo hizo? ¿qué se merece?) y restaurativa (¿quién ha resultado dañado — usuarios, el propio Marc —, qué necesita, y qué debe cambiar el sistema?); su síntesis célebre: el error humano no es la causa de los problemas — es el síntoma de problemas más profundos del sistema. Y Hollnagel (whitepaper From Safety-I to Safety-II, EUROCONTROL, 2013, gratuito) añadió el giro complementario: la seguridad no es solo que salgan mal pocas cosas (Safety-I: estudiar el fallo) sino que salgan bien muchas (Safety-II: estudiar el trabajo cotidiano que sale bien — porque éxito y fallo nacen de la misma variabilidad). El protocolo de papel de Rosa es puro Safety-II: una adaptación humana que llevaba años produciendo éxito silencioso y que ningún análisis de fallos habría inventariado. Los buenos sistemas — Rosa dixit — aguantan que una vieja desconfíe de ellos: la desconfianza experta es una capa de defensa.

La versión software de todo esto es el postmortem sin culpa, y su texto canónico es el capítulo 15 del Site Reliability Engineering de Google (libro completo gratuito, CC BY-NC-ND):

"For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior." [traducción propia] «Para que un postmortem sea verdaderamente sin culpa, debe centrarse en identificar las causas contribuyentes del incidente sin acusar a ningún individuo o equipo de conducta mala o inapropiada.»

El post fundacional de la cultura en la industria web es de John Allspaw (Etsy, 2012): los ingenieros deben poder relatar qué hicieron, qué observaron, qué esperaban y qué asumieron, «sin miedo a castigo o represalia» — no por bondad, sino por ingeniería de la información: si el error se castiga, el error se oculta, y el sistema pierde exactamente los datos que necesita para no repetirlo (el bucle de Edmondson de la sección 5, en su versión de alto voltaje). De la misma tradición: los presupuestos de error de SRE — el fusible automático de Aurelia: si la tasa de fallos supera el umbral, el ritmo baja sin negociación — que despersonalizan el conflicto velocidad-contra-estabilidad convirtiéndolo en una regla acordada de antemano; y la miniatura imprescindible de Richard Cook, How Complex Systems Fail (1998, dieciocho puntos, gratuito): los sistemas complejos funcionan siempre en modo degradado, contienen el accidente en potencia, y la seguridad la fabrican, cada día, las adaptaciones humanas.

Estado de la evidencia del bloque: los marcos (Reason, Dekker, Hollnagel) son ingeniería de seguridad basada en décadas de casos, no hipótesis falsables puntuales — así se citan; la relación castigo→ocultación sí tiene respaldo empírico directo (Edmondson 1996); y Vaughan/CAIB constituyen el caso de estudio más documentado de la historia organizativa, con «réplica» trágica incluida.

6. Deuda técnica: el ritmo sostenible del código

Cierra la sección el pariente técnico del crunch. La metáfora original es de Ward Cunningham (OOPSLA 1992): embarcar código no-del-todo-correcto es como endeudarse — «un poco de deuda acelera el desarrollo siempre que se devuelva pronto»; el peligro es la deuda no devuelta, donde cada cambio paga intereses. La formalización académica (Kruchten, Nord y Ozkaya, 2012, IEEE Software) organiza el paisaje — deuda de código, de arquitectura, de tests, de documentación — y la evidencia de encuestas y diarios (Besker et al., 2019) estima que los desarrolladores desperdician en torno a una cuarta parte de su tiempo por deuda técnica existente. La formulación moderna más útil es la del libro Software Engineering at Google (gratuito, CC BY-NC-ND): "Software engineering is programming integrated over time" — la ingeniería es lo que pasa cuando el código debe vivir y cambiar durante años; sostenibilidad es poder reaccionar al cambio durante toda esa vida.

El noveno principio del manifiesto («la atención continua a la excelencia técnica y al buen diseño mejora la agilidad») es esta cuenta: la única forma de ir rápido mucho tiempo es mantener sano aquello sobre lo que se corre. Y la conexión con esta era es la advertencia central del curso entero, que la sección 13 documentará con datos de campo: los agentes generan código a un ritmo que convierte la gestión de deuda de tarea de higiene en cuello de botella estratégico — el crunch de Aurelia produjo en dos semanas la deuda de un trimestre, y la pagó un domingo a las 7:12.

Para llevar

  • La curva de horas es conocida desde 1917: proporcional hasta ~49h, máximo hacia 63h, y a 70h produces lo de 56 (Pencavel); los domingos no suman. El crunch compra velocidad con sueño y la devuelve con intereses — y en trabajo cognitivo la factura llega tarde y en producción.
  • 17-19 horas despierto ≈ 0,05% de alcoholemia; más vigilia, 0,1% (Williamson y Feyer). Aprobar cambios críticos exhausto es conducir ebrio con permiso de la organización. La recuperación exige desconexión real y es recurrente o no es (el efecto vacaciones se disipa en una semana).
  • El bajo control sobre el propio trabajo casi duplica el riesgo coronario (Whitehall II, OR 1,93): la autonomía es una variable de salud, no un estilo de gestión.
  • Normalización de la desviación (Vaughan): cada margen violado «sin pasar nada» se convierte en el margen nuevo; el Challenger y el Columbia son el mismo mecanismo con 17 años entre medias. Se combate con estructura que busque la deriva (working agreements auditados), no con memoria.
  • Cultura justa: el error humano es síntoma, no causa (Dekker); el accidente es alineación de agujeros en muchas lonchas (Reason); castigar el error destruye la información que evita el siguiente (Allspaw). El postmortem sin culpa, con cronología de sistema y cambios escritos, es la práctica donde convergen la seguridad psicológica, el feedback de tarea y el doble bucle. Y estudiar también lo que sale bien (Safety-II): el cuaderno de Rosa era una defensa que ningún análisis de fallos habría encontrado.
  • Las defensas parecen fricción porque funcionan: la lista de lo que se suspende «solo durante el crunch» es la lista de lo que te estaba salvando. Toda excepción a una defensa exige decisión escrita con caducidad — y un presupuesto de error que baje el ritmo por fusible, no por heroísmo.

Para profundizar