Por qué tu trabajo de rendimiento no es visible

Mi charla trata sobre por qué el trabajo de performance no se ve, así que esto es un poco de establecer expectativas. No será una charla técnica muy profunda, así que hablaremos sobre gobernanza, y hablaremos sobre cómo impulsar la gobernanza del performance.

Me llamo Vinicius, y sí, soy originalmente de Brasil y aún vivo en Suecia. Trabajo para Volvo Cars. Una cosa que tenemos en esta sala ahora, y me gustaría pensar que a todos nos importa el performance. Así que, con suerte, a todos nos importa el performance. Esto es algo que es muy, muy fácil de entender por qué nosotros, como ingenieros, nos preocupamos por el performance. Nuestras aplicaciones pueden usarse en muchos conjuntos de condiciones diferentes que no son muy predecibles, y el performance como tema tampoco es muy predecible. Nuestros usuarios pueden poner nuestra aplicación en condiciones que son muy difíciles para que nuestras aplicaciones funcionen.

En cuanto al performance que estamos tratando de medir, espero que todos conozcamos las herramientas de laboratorio, y si conocemos las herramientas de laboratorio, es muy probable que conozcamos Lighthouse. Cuando se trata de herramientas y monitoreo y métricas, tenemos el laboratorio, y también tenemos las herramientas de monitoreo de usuarios reales. Por lo tanto, es importante tener las dos facetas del ecosistema de herramientas, para que tenga sus datos de laboratorio y tenga esas primeras regresiones que se detectan, y tenga sus métricas de usuarios reales donde tendrá una representación real de cómo se ejecuta su aplicación en el mundo real.

Pero no sé cuántos de ustedes trabajan en equipos de producto, y todos conocemos la lista de tareas pendientes. La lista de tareas pendientes es esa entidad, esa presencia que siempre está acechando nuestro progreso, y en su mayoría es donde todas las buenas intenciones van a morir. La pregunta para la mayoría de nosotros que estamos tratando de poner algo de trabajo de performance ahí afuera en el mundo es ¿cómo haces que tu trabajo se priorice fuera de la lista de tareas pendientes? Si eres como yo, te has sorprendido, esto es, por cierto, una de nuestras oficinas en Suecia, pero todas son mías, y esto está dentro del salón principal de nuestra bonita oficina de Gotemburgo en Suecia. Si eres como yo, te has sorprendido, al igual que Jake, sentado y preguntándote cómo puedes asegurarte de sacar ese buen trabajo ahí afuera. ¿Cómo haces que el trabajo de performance mejore tus métricas y gritarle al mundo que mejoraste el performance del usuario? Al igual que todos los demás, también se convierte en un producto. La mayoría de las veces, las cosas a tu alrededor están en llamas. Y te preguntas cómo lograr hacer este trabajo. ¿Entonces, cómo lo hacemos? ¿Cómo haces que nuestra lista de tareas pendientes esté en llamas? Como un pequeño complemento, intenté sacar esta escena de nuestros modelos favoritos para generar una imagen, y esto es lo que se me ocurrió. Así que es bastante fiel a la vida, si me preguntas. Incluso los ojos de pez y cosas así. Pero, ya sabes, como equipo de producto, siempre estamos ocupados lanzando características. Al menos esa es la mentira que nos decimos, ¿verdad? Pero siempre nos vemos obligados a pensar en qué es lo siguiente que podemos lanzar y qué tan rápido podemos hacerlo. Si trabajas para una empresa abierta, tienes a tus interesados por encima de ti, o estás tratando de abrir tu empresa, y tienes a tus interesados por encima de ti. Siempre hay este tipo de restricción de tiempo al tratar de enfocarse en lanzar características. Y siempre estás luchando contra el reloj, por lo que es muy difícil priorizar el trabajo de performance porque siempre estás persiguiendo la siguiente cosa que debes lanzar. Entonces, la verdadera pregunta al tratar de impulsar el performance es ¿cómo demuestras valor? Entonces, demostrar valor en este tipo de entorno es cómo logras demostrar que los otros costos de trabajar en performance realmente beneficiarán tanto a tus ingenieros como a tus usuarios, ¿verdad? ¿Y cómo configuras este proceso de gobernanza? ¿Cómo justificas los costos adicionales? ¿Cómo manejas el flujo versus la fricción, tanto para tus ingenieros como para sacar el trabajo a tiempo? ¿Cómo obtienes mejores resultados del trabajo que estás realizando? Porque si estás trabajando en performance, algo que no está estrictamente relacionado con las características, ¿cómo puedes asegurarte de que lo que envíes se convierta en una mejor versión de tu producto? No solo desde la perspectiva de ingeniería. Y la respuesta siempre es data. Y aunque no este tipo, la respuesta siempre es data. Entonces, los datos de los que estamos tratando de hablar, nuevamente, volviendo al laboratorio y a los datos de ejecución.

Entonces, estás tratando de obtener perspectiva de tus herramientas automatizadas, tu CICD, pero también de tus usuarios. Pero cuando se trata de un entorno de producto, lo más importante es cómo enmarcas esos datos. ¿Cómo te aseguras de que... Porque todos podemos configurar alguna instrumentación alrededor de nuestro producto y recopilar muchos datos y ponerlos en un panel de control, pero ¿cómo te aseguras de que ese panel de control sea valioso, verdad? ¿Se utiliza? ¿Y cómo puedes aprovechar al máximo los datos que utilizas?

Entonces, hagamos un pequeño viaje rápido al laboratorio de herramientas. Echemos un vistazo a Lighthouse. Y dentro de tus herramientas de laboratorio, debes asegurarte de configurar tus datos en términos de buenas barreras de protección. ¿Cómo te aseguras de que tus datos tengan buenas barreras de protección? Para las herramientas de laboratorio, debes asegurarte de tener presupuestos significativos y metas realistas, y también metas alcanzables. Así que tus metas alcanzables son... Así que te aseguras de enviar mejoras progresivas. Así que tienes iteraciones rápidas de tu producto. Y a partir de esas iteraciones más rápidas, enviarás valor más rápido. Por lo tanto, enmarcar tus datos en un buen conjunto de restricciones, en presupuestos realistas que puedas alcanzar. Una vez que hayas configurado tus herramientas de laboratorio, una vez que hayas terminado esa parte, entonces llega el momento de mirar tus datos de usuarios reales.

Pero para los usuarios reales, debes asegurarte de comprender no solo desde la perspectiva de ingeniería, sino también desde la perspectiva del producto. Porque tu aplicación utiliza diferentes configuraciones de diferentes formas, y debes comprender que estás tratando de resolver cosas desde dos perspectivas. Tienes tu equipo de ingeniería y tu equipo de producto. Y puedes adivinar cuál es cuál por su foto, por cierto. Pero debes asegurarte de representar ambos lados de la historia. La ingeniería y tu producto. Con el fin de entregar la versión más impactante de tu producto. Entonces, ¿cómo obtienes más de tus datos redondos? Para darle forma a tus datos redondos, debes asegurarte de agrupar tus métricas de rendimiento y tus métricas del producto juntas. Porque si solo miras desde una perspectiva, dejarás de lado la otra. Y todos somos ingenieros y siempre nos importa la parte de ingeniería de las métricas. Pero debemos asegurarnos de que lo que intentamos enviar esté moviendo la aguja también en el lado del producto. Porque si estás tratando de obtener la aprobación para trabajar en el rendimiento, debes asegurarte de que ese sea el objetivo, el objetivo que estás tratando de lograr. Y obtener mejores atribuciones es una de las mejores cosas que puedes hacer si estás tratando de establecer un buen monitoreo del rendimiento. Así que tener las métricas por sí solas es solo una parte de la historia. Debes comprender a partir de esas métricas, de ese monitoreo, qué tipo de problemas están surgiendo. Porque si solo tienes números para las métricas y no tienes buenas atribuciones, ni siquiera sabes por dónde empezar. Solo tienes números.

Entonces, también configurar tus datos de una buena manera para que puedas lograr ese entregable. Entonces, ¿cómo enmarcas tus datos desde la perspectiva de tus usuarios? Pero lo más importante, ¿cómo cortas y agrupas tus datos de ejecución? Cortar y agrupar tus datos de ejecución desde una perspectiva de producto significa que tienes tus métricas observadas desde la perspectiva del producto. Obtendrás una segmentación basada en el mercado clave y la base de usuarios de tu producto, y te enfocarás en entregar valor para esos mercados clave y percentiles. Y tendrás un mayor impacto y te asegurarás de mejorar tu perspectiva, ¿verdad? Mejorar la experiencia de tus usuarios a partir de eso.

Mejorar el rendimiento para todos tus usuarios es un objetivo general muy bueno, pero no siempre una prioridad posible desde la perspectiva de un producto. Porque eso es un alcance muy, muy grande. Y trabajar en un alcance más grande es mucho más difícil para enviar mejoras valiosas. Porque normalmente los umbrales son demasiado altos. Y a veces, cuando comienzas a establecer una gobernanza de rendimiento, tienes un largo camino por recorrer hasta llegar a la parte verde de las métricas. Así que debes asegurarte de iterar rápidamente y enviar mejoras lo antes posible. Cuando se trata de datos, también debes asegurarte de evitar los puntos ciegos. Y evitar puntos ciegos en tus métricas significa que no estás segmentando tus datos en una sola dimensión. No solo estás observando tus datos desde la perspectiva del P75, porque eso puede llevarte a pasar por alto cualquier tipo de mejoras y regresiones que ocurran antes de eso. Porque cuando una regresión afecta al percentil P75, eso es prácticamente un incidente, ¿verdad? La mayoría de tus usuarios se ven afectados. Así que quieres asegurarte de capturar todos tus percentiles tanto para las regresiones como para las mejoras, y comprender cómo ocurren las diferentes segmentaciones. Porque todas las mejoras deben ser celebradas y las regresiones deben visualizarse en todo el espectro. Y la razón por la que haces eso es porque cuanto mayor sea tu contexto, más difícil será construir cualquier tipo de correlaciones y, por lo tanto, será muy difícil hacer atribuciones para mejoras o regresiones. Hay una muy buena charla de Tim Varicky de Performance Now del año pasado. Así que si estás interesado en este tipo de segmentación de percentiles, esta charla es realmente muy buena. Definitivamente la recomiendo.

Entonces, ahora mismo, ya comenzaste a pensar en percentiles y segmentación de datos, y estás tratando de asegurarte de que realmente estás limitando esa lista de tareas pendientes. Tienes una buena fortaleza para mantenerla. Estás fortaleciendo la gobernanza del rendimiento de tu código. Entonces, ¿cómo puedes asegurarte de que tu gobernanza del rendimiento sea sólida a lo largo del tiempo? Necesitas comprender y evaluar qué métricas representan mejor tu producto. Porque cuando se trata de web vitals, tienes un conjunto diferente de métricas, y eso es genial. Porque están muy bien estandarizadas y muy bien documentadas, pero no todas las páginas tienen la misma importancia y no todas las características tienen el mismo uso. Los productos no son unidimensionales. Así que debes comprender qué parte de ese subconjunto representa mejor tu proyecto y puedes construir KPIs en torno a eso y realmente proteger tus métricas y la perspectiva de tu producto en general. Construir KPIs y SLOs realmente sólidos significa que comprendes qué métricas representarán mejor tu producto y cómo rastrearlas a lo largo del tiempo. Y establecer tus propias métricas de rendimiento también es una muy buena idea si quieres establecer una gobernanza.

Porque tu historia se cuenta de manera diferente a cualquier otro producto. Por lo tanto, debes comprender qué partes de tu producto y del recorrido del usuario necesitas rastrear y cómo. Y obtener el respaldo de la dirección se vuelve una historia mucho, mucho más fácil si logras hacer bien esa parte de la historia.

Porque tienes tu segmentación, tienes tus métricas, sabes cómo dividir los data, sabes qué tipo de mercados estás observando, cómo observas a tus usuarios y comprendes cómo percibir cualquier tipo de regresión o mejora desde el principio. Y un mayor respaldo significa que debes obtener una buena correlación entre las mejoras de performance y las tasas de conversión. Pero las tasas de conversión también significan cosas diferentes para diferentes productos.

Así que asegúrate de documentar bien y tener todas tus mejoras bien documentadas también y comprende cómo informar eso. Porque a veces tienes que informar a dos conjuntos de habilidades diferentes. A veces tienes que informar para el producto y tienes que informar para la ingeniería. Y esos son dos tipos diferentes de informes. Algunas métricas importan más para unos que para otros. Entonces, al final, esto no solo debe importar para la ingeniería, sino que también debe importar para el producto si estás tratando de establecer un modelo sostenible de gobernanza. Y esto es realmente, realmente clave para establecer un buen modelo de gobernanza.

Y esta charla es parte de un artículo más extenso. Este código QR es el enlace para el artículo. Sí, las principales conclusiones de esta charla son medir, monitorear, informar, y repetir. Y eso fue todo.

APLAUSOS ¿Cuándo comenzó esta historia para ti? ¿Cuándo comenzaste a optimizar y ver dónde te quedaste atascado y avanzaste un poco?

Entonces, he estado estableciendo el trabajo de performance durante mucho tiempo. Ha sido parte de mi trabajo en Clona y también ha sido parte de mi trabajo en Spotify. Ha sido una parte importante de mi trabajo en Volvo. Y cada producto tiene diferentes características y debes comprender cómo vender mejor una iniciativa. Y eso implica comprender a las personas con las que estás tratando de hablar y comprender cómo funcionan las diferentes dinámicas de equipo y qué tipo de niveles necesitas trabajar.

Porque a veces necesitas establecer mucho más trabajo de ingeniería y a veces necesitas establecer mucho más trabajo de producto. Porque a veces la parte entenderá muy fácilmente que necesitas trabajar en el performance y a veces solo necesitas trabajar con ingeniería para mejorar el conocimiento, y este tipo de cosas, tooling. Hay mucho trabajo de tooling que es posible que necesites hacer. Así que cambia mucho.

Entonces, lo más importante realmente es qué tipo de producto estás tratando de vender. Se convierte en una posición de vendedor sobre cómo comprender la presentación de ventas y cómo construir una presentación de ventas para diferentes organizaciones. Diferentes audiencias. Exactamente. Entonces, cuando dices respaldo ejecutivo, ¿tienes un patrocinador ejecutivo que respalde tus esfuerzos en Perf, o quieres un respaldo ejecutivo más amplio? Entonces, más personas en tu equipo de liderazgo senior que se preocupen por el performance. El respaldo puede tener diferentes alcances. Normalmente, si estás tratando de trabajar en una organización que no tiene experiencia en performance, es posible que debas obtener el respaldo de tu gerente inmediato y tratar de establecer un trabajo para que puedas tener ese tipo de permiso para trabajar en la construcción de herramientas y comenzar a definir métricas. Y a partir de ese momento, trabajas para obtener el respaldo de la alta dirección, si es necesario. Así que depende del tipo de trabajo que estés tratando de establecer y qué tipo de ámbito.

Entonces, diferentes ingenieros tienen diferentes antecedentes, por supuesto, y diferentes esferas de influencia. A veces trabajas en una empresa muy grande donde tienes grupos técnicos de dirección a los que debes acudir y una plataforma a la que debes acudir y establecer un alcance más amplio para tooling e instrumentación. Así que realmente dependerá de la organización en la que estés tratando de trabajar. Pero diría que si estás tratando de comenzar a trabajar en el performance, comienza por tu gerente inmediato. Solo saca algo, obtén ese MVP, comienza a recopilar data de inmediato, porque los datos son el rey. El momento en que comienzas a tener datos es cuando puedes tener mejores atribuciones y correlaciones, y luego realmente puedes cambiar el rumbo del trabajo que estás tratando de hacer. Creo que eso responde algunas de las preguntas que estamos viendo, porque mucha gente está preguntando, aparentemente se están encontrando con un obstáculo y dicen, ¿qué pasa si las personas siguen siendo reacias, o cómo superas ese primer... Pero lo que estás diciendo es casi gradual, como convencer a una persona y luego a la siguiente. Sí, se convierte en un trabajo de vendedor donde realmente quieres trabajar para obtener ese permiso para tener más tiempo para trabajar en el performance.

Y eso significa construir mejores atribuciones a través de data desde el primer día. Entonces, si estás tratando de trabajar en mejoras de rendimiento, es muy tentador trabajar en mejoras de rendimiento de inmediato. Así que estás tratando de obtener esa mejora inmediata desde el principio, pero ni siquiera entiendes dónde están los cuellos de botella reales de tu aplicación, o en qué partes de tu aplicación los usuarios tienen más dificultades. Entonces, ¿cómo puedes asegurarte de que cierto trabajo de rendimiento afectará las tasas de conversión? Porque al final, si estás tratando de obtener respaldo del producto, realmente necesita intentar mover la aguja hacia mejores tasas de conversión, sea lo que sea que eso signifique para tu equipo de producto. Y debes entender, entonces, cuáles son los puntos problemáticos. Entonces, sin data, no puedes entender los puntos problemáticos. Por eso, la sugerencia siempre es comenzar primero con data. Perfecto, gracias. Otra pregunta aquí es, ¿tienes alguna recomendación sobre cómo evaluar el rendimiento de los scripts de terceros? Sí, los scripts de terceros... Y la advertencia es que la persona que pregunta está desarrollando un script de terceros. Yo también he trabajado con scripts de terceros, así que trabajé para Klana durante casi tres años, y dentro de Klana trabajé en su portal de comerciantes integrado que tenían, así que dentro del proceso de pago. Entonces, si estás familiarizado con el proceso de pago de PayPal o Stripe, pero eso está integrado dentro del sitio del comerciante, por lo que de alguna manera son un tercero. Entonces, como tercero, lo primero y más importante que quieres asegurarte es que no estás afectando los tiempos de carga de la página. Entonces, si estás tratando de establecer data a tu alrededor como un tercero, debes entender que no puedes afectar ese tiempo de carga para tu cliente. Pero también debes entender que como tercero deberías tener menos prioridad cuando se trata de los tiempos de ejecución. Entonces, si estás tratando de ejecutar tareas, también debes ser muy amigable con los tiempos de ejecución de las tareas. Entonces, IMP es una métrica muy importante para cualquier tercero, por lo que si estás tratando de establecer límites para eso, esos son dos lugares en los que debes ser realmente, realmente estricto. Genial, gracias. Todavía hay muchas preguntas, pero ¿qué pasa si siguen siendo reacios? Oh, me gusta este tipo de pregunta apocalíptica. ¿Cómo inicias la conversación sobre la medición y optimización antes de que sea demasiado tarde? Bueno, puedo decirte que muy difícilmente será demasiado tarde, porque nunca es demasiado tarde para comenzar a medir, pero cuando te encuentras en un escenario en el que tu rendimiento está muy por encima del presupuesto, ahí es donde la mejora progresiva y asegurarte de tener iteraciones cortas, entregas rápidas, y comenzar a mover la aguja hacia el buen espectro de las métricas lo antes posible es clave. Pero siempre comienza con data, por lo que quieres entender dónde te encuentras actualmente, y luego comienzas a proyectar entregables a lo largo del tiempo para poder rastrear ese progreso, pero siempre enviando en pequeñas iteraciones. Porque si estás tratando de pasar de un extremo muy malo a un extremo muy bueno, eso es un gran alcance para cubrir. La mayoría de las veces no tienes esa tolerancia de tiempo de inmediato, por lo que debes asegurarte de enviar mejoras incrementales y siempre mover constantemente la aguja hacia el umbral bueno. Excelente. Como persona de DevOps, aprecio mucho esa respuesta.

Muy bien, vamos a por esta. ¿Cuáles son tus herramientas favoritas para recopilar datos de rendimiento? Recopilando datos de rendimiento. Así que en cuanto a las partes de Roma, hay un montón de servicios realmente buenos de rendimiento por ahí. Tienes Speedcurve, tienes el Bugbear Sentry, también hacen rendimiento. Pero debes entender qué tipo de herramienta representará mejor tu uso. Porque la herramienta que uses solo será útil en la medida en que tu equipo esté dispuesto a utilizarla. Configurar una buena herramienta significa tener un buen flujo versus fricción. Por lo tanto, depende de las habilidades de tu equipo de desarrollo qué herramienta vas a utilizar. Bastante justo. Una respuesta muy neutral. Esa no era la que quería resaltar. Había una muy divertida. Muy bien. ¿Ralentizar intencionalmente el producto es una buena manera de demostrar el impacto en las métricas del producto? Supongo que si estás tratando de entender el impacto de qué tan lento puedes ir, sí. Quiero decir, definitivamente demostrarás un punto. Así que si vas a intentarlo, definitivamente avísame cómo te va. ¿De quién es esta pregunta? ¿Y hay algún gerente en la sala? Si eso sucede, definitivamente avísame cómo va, sinceramente. Me fascina esta pregunta. Es una buena pregunta. Es bastante, ya sabes, un tipo de rebelión. Déjame ver. Una última pregunta rápida. Espera. Espera, espera, espera.

Veamos. Hay una pregunta sobre un favorito. ¿Cuál es tu programa de capacitación? ¿Es para esta sala? No lo creo. ¿Programa de capacitación? ¿Cuál es mi programa de capacitación? Levanto pesas. Oh.

¿Sabes qué? Estaba pensando en educación. Pero sí, eso es. Estaba pensando en educación. Pero tú... ¿Dónde está mi cabeza? No lo sé.

Muy bien. Quiero agradecerles mucho. Demos otro aplauso a... Por favor. Gracias. Gracias. Gracias. Gracias. Gracias. Gracias.