La cultura de rendimiento en un equipo

El patrón es tan repetido que se puede predecir con fecha. Un equipo hace un trimestre de rendimiento, baja el pintado del elemento más grande de 4,2 a 2,1 segundos, lo celebra, y cinco meses después está en 3,8 sin que nadie haya hecho nada obviamente malo: una fuente, un script de marketing, un carrusel, un banner de consentimiento. La degradación es por acumulación de decisiones individualmente razonables —es el mito de que el rendimiento es un proyecto—, y por eso no se defiende con concienciación. Se defiende con seis mecanismos, todos aburridos, todos baratos, y todos con la misma propiedad: hacen que el coste sea visible en el momento en que se genera y no cinco meses después.

Uno: el dueño de la métrica

“El rendimiento es responsabilidad de todos” es funcionalmente idéntico a que no sea de nadie, y se reconoce porque nadie mira los números salvo cuando alguien se queja. El arreglo es una tabla con nombres propios.

Cuatro reglas que hacen que esa tabla funcione en lugar de decorar un documento:

Una persona, no un equipo. Un equipo dueño de una métrica es un equipo donde la métrica no se mira. El nombre tiene que ser de alguien que pueda notarlo, no necesariamente de quien vaya a arreglarlo. Y la métrica que se le asigna es siempre un percentil de un segmento, nunca un agregado.

Ser dueño significa notar, no arreglar. La obligación del dueño es exactamente una: darse cuenta de que el número se ha movido y abrir la conversación con quien corresponda. Si la obligación fuera arreglarlo, nadie querría el puesto y la tabla se quedaría vacía en dos meses.

Rota cada trimestre. Por dos motivos: reparte el conocimiento y evita el efecto de que el dueño se acostumbre a su propio número, que es real y ocurre alrededor de la sexta semana.

Hay un suplente nombrado. Sin él, la métrica deja de mirarse durante las vacaciones de agosto, que es precisamente cuando se despliegan cosas con menos revisión.

Una superficie del sitio puede tener dueño de una métrica y no de las otras dos. Es correcto y es deseable: el carrito no necesita a nadie vigilando su LCP, y la portada no necesita a nadie vigilando su consumo de memoria. Repartir la propiedad por dónde duele en lugar de por completitud es lo que mantiene la tabla corta y viva.

Dos: el presupuesto como contrato

La mecánica técnica del presupuesto está resuelta en fijar un presupuesto y defenderlo y su implantación en la integración continua en presupuestos que hacen fallar el build. Lo que decide si sobrevive no es esa mecánica sino cuatro propiedades que lo distinguen de una aspiración.

Lo firma quien puede incumplirlo. Un límite acordado solo dentro de ingeniería no aguanta la primera fecha de lanzamiento comprometida. Tiene que estar aceptado explícitamente por quien aprueba las funciones nuevas y por quien mete etiquetas de terceros; si esas dos personas no lo han visto nunca, no hay contrato, hay una preferencia técnica.

Tiene el número derivado, no elegido. El número viene de la cadena que va del objetivo de métrica a los bytes que caben, y esa cadena es lo que se responde cuando alguien lo cuestiona. Un límite sin derivación se negocia; uno con derivación obliga a discutir el objetivo, que es una conversación mucho más difícil de ganar por cansancio.

Tiene procedimiento de incumplimiento escrito antes de necesitarlo. Un sistema sin válvula revienta por donde puede. La válvula es una entrada en un fichero versionado con nombre, motivo, incidencia y fecha de caducidad, y una comprobación que vuelve a romper el trabajo cuando esa fecha pasa. Sin caducidad, cada excepción es un agujero permanente; con caducidad, es una deuda que vuelve sola a la mesa.

Tiene fecha de renegociación. Una vez al trimestre se mira si el límite sigue describiendo la realidad. Doce excepciones activas que suman 140 KB no significan que la gente sea indisciplinada: significan que el límite ya no describe nada y hay que rehacer la derivación.

Tres: la revisión en la petición de cambios

Aquí está la mayor parte del valor de todo este nivel, porque es el único punto del proceso donde la decisión todavía se puede cambiar barato. El reparto entre máquina y persona no es arbitrario: la máquina se queda con todo lo determinista y la persona con todo lo que requiere conocer la intención.

La parte automática está desarrollada en qué medir en cada commit y el diff del bundle en el PR, y la auditoría reproducible en Lighthouse CI. El reparto no es negociable en un punto: lo estocástico no bloquea, porque cada falso positivo consume crédito y la desconfianza se contagia a las comprobaciones deterministas, que son las que de verdad protegen. El porqué, con la aritmética del ruido, está en la variabilidad de las medidas.

La parte humana cabe en tres preguntas, y conviene que estén escritas en la plantilla de revisión porque de memoria se hacen las tres primeras semanas y luego ninguna:

1. ¿Esto se ejecuta antes del primer pintado o después? Decide si el coste entra en el LCP o no, y en la mitad de los casos hay una respuesta barata que lo mueve a después.
2. ¿Puede coincidir con una interacción del usuario? Es la pregunta que captura las regresiones de INP, que no aparecen en ningún diferencial de bytes.
3. ¿Qué pasa si esto tarda cinco veces más de lo que tarda aquí? La pregunta del dispositivo real, y la que atrapa el trabajo que va bien en un portátil y bloquea medio segundo en un móvil.

Una nota sobre el formato que cambia mucho el resultado: el comentario automático tiene que ser corto y con la conclusión arriba. Un informe de cuarenta líneas se ignora a la tercera semana. Tres líneas con el diferencial por ruta y una lista de altas se lee siempre.

Cuatro: el panel visible

Un panel de rendimiento con veinte gráficas no lo mira nadie. Seis números, y cada uno con su dueño de la tabla del primer mecanismo:

Rendimiento - semana 32                        (rojo = fuera de umbral)

  LCP  p75 movil  portada          2,7 s   ->  2,9 s    rojo
  LCP  p75 movil  ficha            2,1 s   ->  2,1 s
  INP  p75 movil  carrito           180 ms ->  240 ms   rojo
  CLS  p75 movil  global            0,04   ->  0,04
  JS   ruta critica  portada       98,2 KB -> 103,7 KB  rojo
  Terceros activos                       7 ->  8

  Excepciones de presupuesto activas: 3  (suman 22 KB, la mas antigua caduca el 14/09)

Tres propiedades hacen que un panel se mire y su ausencia explica por qué la mayoría no se miran.

Está en una reunión que ya existe. No se crea una reunión de rendimiento: se añaden cinco minutos a una que ya está en el calendario y a la que ya va la gente que decide. Una reunión propia sobrevive dos meses. Y si además puedes poner al lado la comparación con la competencia sacada de los datos públicos de experiencia de usuario, la conversación cambia de tono, porque una posición relativa activa resortes que un valor absoluto no activa.

Tiene la comparación con la semana anterior en la misma línea. El valor absoluto no dice nada; la dirección lo dice todo. Un número aislado no genera ninguna conversación y una flecha sí.

Tiene el campo, no el laboratorio. Percentil 75 de usuarios reales, segmentado por clase de dispositivo, según instrumentar con la librería web-vitals y segmentar. Un panel de puntuaciones de auditoría produce discusiones sobre la herramienta en lugar de sobre los usuarios.

Cinco: cuando la regresión entra igualmente

Va a entrar. Ninguna combinación de mecanismos atrapa todo: los presupuestos son deterministas y las métricas de campo son estocásticas, los terceros cambian su propio código sin avisar, y algunas regresiones solo aparecen con datos reales. Lo que define a un equipo no es que no le entren, sino cuánto tarda en enterarse y qué hace después.

flowchart TB
A[Alerta o revision semanal] --> B{Confirmado en campo}
B -->|No| C[Ruido de medida y se anota sin actuar]
B -->|Si| D[Acotar la ventana entre dos despliegues]
D --> E{Hay un cambio candidato}
E -->|No| F[Revisar terceros y configuracion externa]
E -->|Si| G{Se puede revertir sin dano}
G -->|Si| H[Revertir primero y diagnosticar despues]
G -->|No| I{Cabe un arreglo en 48 horas}
I -->|Si| J[Arreglo hacia delante con fecha]
I -->|No| K[Excepcion con caducidad y responsable]
H --> L[Escribir por que no lo detecto el mecanismo]
J --> L
K --> L
F --> L
style B fill:#f9e2af,color:#11111b
style H fill:#a6e3a1,color:#11111b
style J fill:#89b4fa,color:#11111b
style K fill:#fab387,color:#11111b
style L fill:#cba6f7,color:#11111b

Cuatro decisiones de ese guion que conviene tener acordadas de antemano, porque discutirlas en caliente sale mal:

Revertir primero, diagnosticar después. La reversión es la única acción cuyo resultado se conoce de antemano. Diagnosticar con la regresión en producción cuesta lo mismo que diagnosticarla fuera, y en un caso los usuarios están pagando. El diagnóstico posterior empieza por la rama, con el árbol de decisión por síntoma, y no por el perfil.

Antes de acotar por despliegues, descarta lo que no viene del repositorio. Dos fuentes de regresión no aparecen en ningún diferencial: un tercero que ha cambiado su propio código sin avisar, que se caza con medir script a script, y un service worker que está sirviendo desde el disco del usuario una versión que tú creías retirada, que se caza con el despliegue seguro y la vía de escape.

La regla de las 48 horas. Si el arreglo hacia delante no cabe en dos días, no es un arreglo, es un proyecto, y mientras tanto la regresión se queda. Un arreglo con fecha y sin reversión es la forma más común de que una regresión se vuelva permanente.

La excepción es una decisión legítima. A veces la función nueva vale más que los 40 milisegundos. Aceptarlo explícitamente, con responsable y caducidad, es infinitamente mejor que aceptarlo callando, porque deja registro y vuelve solo.

El postmortem tiene una sola pregunta, y no es quién. Es por qué no lo detectó el mecanismo, que tiene siempre una de cuatro respuestas: no había comprobación, la había y era estocástica y no bloqueaba, la había y alguien pidió excepción, o la había y el cambio venía de fuera del repositorio. Cada respuesta lleva a una mejora concreta del mecanismo. La pregunta de quién lo introdujo no lleva a ninguna y garantiza que la próxima vez nadie avise.

Seis: quién decide cuando no cabe

Es el conflicto que define la cultura y el que casi nunca está resuelto por adelantado: una función nueva es importante y no cabe en el presupuesto. El reparto que funciona separa tres papeles y no los mezcla nunca.

La consecuencia que más cuesta aceptar, y la que más problemas ahorra: la decisión no es de ingeniería, y no debería serlo. Un ingeniero que decide unilateralmente que una función no entra acaba siendo el obstáculo del equipo y pierde la conversación siguiente aunque tenga razón. Lo que sí es suyo, en exclusiva, es la información: que el coste esté medido, traducido a la unidad de quien decide y presentado con su alternativa. Ese reparto es el mismo que se aplica a los terceros en presentar el coste a quien decide meterlos y a las peticiones de presupuesto en presentarlo a quien decide.

Y una regla de conducción que cambia el resultado más que cualquier argumento: ofrece siempre la alternativa antes de decir que no. Casi siempre hay tres, y las tres están desarrolladas en el track: cargarlo por interacción en lugar de en el arranque, usar una parte en vez de la librería entera —lo que exige haber hecho antes el trabajo de encontrar la dependencia gorda—, o sustituirla por veinte líneas propias. La conversación es distinta cuando la propuesta es “esto entra si se carga al abrir el diálogo” en lugar de “esto no entra”.

Para que el coste llegue traducido y no en milisegundos de hilo principal, el número que hay que llevar es el de negocio, y la correspondencia entre una y otra unidad está en qué métrica de negocio conectar con qué métrica técnica. El dispositivo sobre el que se calcula ese coste tiene que ser el de referencia acordado, no el de quien lo mide: el dispositivo real de tus usuarios.

El formato de tres líneas que hace que la decisión se pueda tomar en la misma reunión:

Peticion:  editor enriquecido en el formulario de alta
Coste:     +42 KB en la ruta critica, +130 ms de bloqueo en el
           dispositivo de referencia. El LCP p75 movil de /alta
           pasaria de 2,3 s a unos 2,6 s. Margen actual: 200 ms.
Opciones:  (a) entra tal cual, excepcion hasta el 15/11
           (b) entra cargado al pulsar "escribir descripcion", coste 0
           (c) no entra en este ciclo

Cómo se pierde una cultura de rendimiento

Siempre igual, y por eso se puede reconocer a tiempo. Primero hay una excepción razonable, con una fecha comprometida detrás y un motivo que cualquiera aceptaría. Después hay otra, y esta ya es más fácil porque existe el precedente. En la tercera, alguien observa que pedir la excepción es más trabajo que desactivar la comprobación. En la cuarta, la comprobación lleva un mes desactivada y nadie recuerda por qué. Y entonces el panel deja de mirarse, porque un panel cuyos números empeoran y no producen ninguna acción es una fuente semanal de incomodidad, y la gente deja de mirar las cosas que solo producen incomodidad.

Las cuatro señales tempranas, en el orden en que aparecen:

• La primera excepción sin fecha de caducidad. Es el punto exacto en que el mecanismo deja de tener memoria.
• Un comentario automático que nadie responde. Si tres peticiones de cambio seguidas superan el límite y nadie lo menciona en la revisión, el mecanismo ya es decorativo.
• El panel con dos números en rojo dos semanas seguidas. No es que los números estén mal: es que nadie ha abierto la conversación, que era la única obligación del dueño.
• “Ya lo miraremos en el sprint de rendimiento”. La frase que convierte el rendimiento en un proyecto episódico, cuando la degradación es continua. Las optimizaciones son episódicas y el crecimiento no: esa asimetría es la que garantiza que se pierda.

Ninguna de las cuatro requiere mala fe y las cuatro son reversibles el mismo día en que se detectan, que es la razón de enumerarlas.