> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2024/essay-collection-informal-talks.md).

# Colección de notas: conversaciones abiertas

Antes del Año Nuevo investigué el desarrollo de plataformas de pruebas A/B. Los detalles están reunidos en [El ámbito de las pruebas A/B](https://km.sankuai.com/collabpage/2103469706).

1. Cómo situar nuestra etapa actual. Según el modelo de madurez de la experimentación, Jingwan está aproximadamente en la fase de caminar, y los demás negocios, en la de gatear. Gatear es la primera fase del modelo. A la etapa anterior yo la llamaría despertar o iniciación. El objetivo de la fase de gatear es crear las condiciones básicas para experimentar, sobre todo herramientas y capacidades elementales de ciencia de datos.
2. Las plataformas A/B más avanzadas de la empresa. Hablé en profundidad con los equipos de Horizon, de la plataforma del grupo, y de la plataforma A/B de operaciones de entrega a domicilio. Están aproximadamente en la fase de correr. Ambas evolucionan hacia reducir a gran escala las barreras para experimentar y asegurar la confianza en los experimentos. Buscan evitar que quienes experimentan dediquen demasiada energía a justificar sus diseños y que los factores humanos comprometan la confianza en los resultados. Han incorporado puestos de ciencia de datos. Sus indicadores ya muestran una visión integral de la integración, la asignación de tráfico, la ejecución y la toma de decisiones. Por ejemplo, miden la proporción de nuevos experimentos cuya objetividad puede evaluarse y la proporción de resultados objetivos entre los experimentos importantes.
3. **Lecciones del desarrollo de la plataforma A/B de operaciones de entrega a domicilio. Esta información procede de una conversación con uno de sus miembros principales. Para mí, es un ejemplo representativo de cómo la tecnología presta servicio al negocio. Se trata de ajustar continuamente la relación concreta entre ambos. Lo más valioso son la forma de pensar y las personas capaces de integrar negocio y tecnología.** En ámbitos tan especializados, el negocio no sabe describir con claridad sus problemas; a veces ni siquiera es consciente de ellos. Para servirle bien, hay que salir del propio campo, acercarse a la primera línea, entender el negocio y cambiar de perspectiva. La ejecución de las entregas es el núcleo del negocio a domicilio, por lo que mejorar su eficiencia resulta esencial. El modelo de múltiples partes de los servicios basados en ubicación, LBS, requiere muchos experimentos con algoritmos y estrategias. Por eso necesita con más intensidad una plataforma A/B de alto nivel. Al principio, plataforma y negocio funcionaban con un acoplamiento débil, con la agilidad propia de una plataforma. En 2022, el equipo pasó a centrarse en las operaciones de entrega y a ofrecer un servicio totalmente gestionado. El negocio solo tiene que plantear sus necesidades; el equipo de datos se encarga de todo el ciclo de diseño, ejecución y análisis del experimento. No ofrece únicamente capacidades, sino soluciones que incluyen capacidades, herramientas y métodos. En los ámbitos más complejos, donde los retos del negocio son suficientemente grandes, el equipo de entregas también empezó pronto a explorar la colaboración con la investigación científica. En cuanto a apertura, su plataforma A/B ofrece tres niveles: gestión completa, gestión parcial y acceso al motor de análisis. Corresponden, respectivamente, a la gestión centralizada por la plataforma, al acceso a las capacidades de diseño y evaluación de experimentos, y al acceso a métodos de análisis individuales.

***

Hace poco revisé la iniciativa de la biblioteca de componentes e intenté responder a una pregunta bastante difusa: ¿cómo crear una biblioteca de componentes con mucha vitalidad? Las bibliotecas de componentes son tan comunes que solemos considerar el asunto claro, sencillo y fácil de entender. Pero son muy pocas las que logran ser populares, útiles y duraderas, especialmente duraderas. Intentaré responder desde dos ángulos.

**Resolver problemas reales dentro de un ámbito definido y mantener una relación positiva entre inversión y retorno.**

Identificar los problemas reales desde el valor que se pretende aportar, investigarlos con detalle y resolverlos de verdad. Prestar atención al ámbito en el que se resuelve el problema: los costos y las soluciones disponibles cambian según su alcance. Una biblioteca para todo Meituan, para servicios financieros o para un equipo puede perseguir valores distintos.

En proyectos cuyo alcance de valor ya es limitado, hay que vigilar siempre la relación entre inversión y retorno. El costo de mantenimiento puede superar el valor real sin que lo advirtamos, y a medio o largo plazo eso acaba corrigiéndose. Hace poco varios comentaban con pesar que YAPI, una herramienta de simulación de API con una mejor experiencia de uso, había dejado de mantenerse, mientras PAPI seguía siendo la principal recomendación oficial. Dejando de lado las diferencias organizativas entre ambas herramientas, sospecho que el costo de mantener YAPI ya superaba la mejora de experiencia que aportaba a los desarrolladores. No tengo datos para demostrarlo. Pero que la mayoría de los proyectos no optara por migrar a YAPI respalda la idea de que esa mejora era pequeña, quizá insuficiente incluso para compensar el costo de migración.

**Resolver los problemas en el nivel de abstracción adecuado.**

La esencia del problema más el ámbito en que aparece definen el problema real. Una biblioteca de componentes ya es una solución. En ámbitos de mayor nivel, puede no ser la mejor. A medida que aumenta la abstracción, podemos dividir las soluciones, a grandes rasgos, en implementación, biblioteca, framework y estándar. Una biblioteca de componentes corresponde al segundo nivel. Creo que esta es la razón por la que MTD no llegó a funcionar. En la comunidad existe un proyecto llamado [A Global Design System](https://component-odyssey.com/articles), cuya visión es ofrecer componentes universales a diseñadores y desarrolladores de todo el mundo. En realidad, no es una biblioteca de componentes: es un sistema, aunque tampoco un sistema de diseño como Material Design. En un proyecto así no hace falta centrarse en si tendrá éxito. Lo importante es aprender a explorar una cuestión planteada en un nivel alto de abstracción.

***

El trabajo técnico de los equipos de negocio puede dividirse en dos grandes tipos. Uno consiste en resolver los problemas más importantes de la etapa actual, concentrando esfuerzos para abordarlos uno a uno, normalmente mediante iniciativas técnicas específicas. El otro exige desarrollo y operación a largo plazo: bibliotecas de componentes, Infras y otras infraestructuras de ingeniería. Es un trabajo continuo, de muchos detalles, que requiere perseverancia y para el que nos falta un mecanismo de funcionamiento adecuado. De hecho, ese mecanismo también puede responder en parte a una cuestión importante: cómo mantener activa y viva la infraestructura.

A medida que crecen el equipo y la solidez de sus bases de ingeniería, nuestro trabajo también debe pasar gradualmente de campañas puntuales a mecanismos duraderos.

Nuestra infraestructura ya ha recorrido el camino de 0 a 1. Ahora necesitamos explorar cómo pasar de 1 a ∞. El funcionamiento actual tiende a ser cerrado, y lo cerrado acaba dependiendo de personas concretas. Hay poca iniciativa para contribuir dentro del equipo y se depende de instrucciones jerárquicas. Mi idea es aprender de proyectos de código abierto maduros, establecer una forma de trabajo abierta y sostenible, y estimular la creatividad del equipo.

He preparado un borrador, [Mecanismo de grupos de trabajo: Working Group](https://km.sankuai.com/collabpage/2610619313). Utiliza el concepto de Working Group e incorpora mecanismos como RFC y Membership. A la vez, los adapta y simplifica según el tamaño del equipo para equilibrar eficiencia y apertura. Quienes tengan ideas al respecto son bienvenidos a compartirlas.

***

Con los últimos ajustes del negocio relacionados con el libro de cuentas, tanto el frontend como el backend se enfrentan a dudas sobre la idoneidad de su arquitectura. Esta se refleja directamente en la calidad; la refactorización de la tarjeta de negocio partió de ahí. Quiero compartir algunas ideas sobre la arquitectura de negocio en el frontend.

1. La arquitectura ocupa lugares distintos en frontend y backend. En el frontend todavía no hay suficiente consenso sobre el diseño de la arquitectura de negocio. Se habla más de elegir frameworks y cadenas de herramientas. Una posible razón principal es que el frontend se ha enfrentado a menos desafíos arquitectónicos. En muchos proyectos, los cuellos de botella derivados de esas decisiones nunca llegan a aparecer durante su vida útil. Un proyecto genérico creado con una plantilla basta para satisfacer el máximo de las necesidades del negocio.
2. ¿Qué es una decisión de arquitectura y qué no lo es? La arquitectura es el resultado de la comunicación, el análisis y el razonamiento, no de una simple selección de herramientas. Centrarse solo en la estructura de directorios y los documentos que se entregan puede hacer que pasemos por alto conceptos importantes como aislamiento y reutilización, gestión del estado e inversión de dependencias. Estos influyen más en la calidad real y en la capacidad de atender las necesidades del negocio. Por ejemplo, la arquitectura ECS en videojuegos resuelve un problema de mantenibilidad propio de ese ámbito.
3. ¿Es necesario separar la arquitectura de frontend y backend, o bastaría con un equipo de arquitectura común? La pregunta es muy amplia. La estructura de los sistemas refleja de forma natural cómo se comunican los equipos; no desarrollaré aquí la parte de la ley de Conway. Sí quiero comentar dos ideas. Primero, el diseño global de arquitectura irá incorporando al frontend. Aún estamos en el proceso de conseguir que un lenguaje minoritario haga entender su trabajo al lenguaje dominante. Ya se empieza a tener en cuenta el frontend en calidad y eficiencia, aunque el examen de prevención de riesgos técnicos siga pareciendo una prueba de certificación desconectada del trabajo real. Quizá la arquitectura no esté tan lejos. Segundo, frontend y backend pueden aprender uno del otro. El frontend puede beneficiarse de ideas del backend, como DDD, para entender mejor los problemas de negocio. El backend puede aprender los métodos eficientes de prototipado del frontend y su forma de pensar en los componentes como servicios.
4. Para entender la arquitectura del frontend, es imprescindible leer [¿Qué es la arquitectura del frontend?](https://ducin.dev/what-is-frontend-architecture). Vale la pena seguir a su autor, Tomasz Ducin, en este campo.

***

Límites físicos, límites de ingeniería y límites de la experiencia. Intento responder a una pregunta que surgió la semana pasada: cuando hablamos de optimizar, ¿en qué nivel lo hacemos y dentro de qué límites?

Comprender los límites físicos permite reconocer restricciones fundamentales, mantener la claridad en procesos complejos de innovación e invertir los recursos con más criterio. Todavía hay inventores aficionados que intentan construir máquinas de movimiento perpetuo. Ya en el siglo XIX, Carnot demostró que existe un límite teórico para la eficiencia de las máquinas térmicas, así que ese empeño está condenado a ser inútil. Hoy también hay quienes creen que el desarrollo de la IA resolverá todos los problemas y sustituirá a los seres humanos. Turing ya podía dar una respuesta clara a esta cuestión en el siglo XX. En el mundo hay muchos problemas; solo una pequeña parte son problemas matemáticos; de estos, solo una pequeña parte tiene solución; de esos, solo algunos son computables por una máquina de Turing; y de esos, solo algunos pueden ejecutarse en las computadoras actuales. Los problemas que puede resolver la IA son un subconjunto de todo lo anterior. Los límites de la física son casi imposibles de refutar. Los matemáticos son completamente imposibles, porque las matemáticas se basan de forma estricta en la lógica, no en observaciones experimentales.

Entender los límites de ingeniería sirve para dar dirección y eficiencia a la práctica. Dentro de los límites físicos conocidos, optimizar en varias dimensiones permite mejorar el rendimiento y encontrar la mejor solución de ingeniería. Por ejemplo, un DVD que utiliza luz azul en lugar de roja aprovecha una longitud de onda menor para aumentar la capacidad. La evolución de 2G a 6G tampoco ha superado el límite teórico de capacidad de un canal que Shannon estableció para un ancho de banda y una relación señal-ruido dados. Cada generación optimiza la ingeniería del espectro, la codificación y modulación, y la arquitectura de red. La ley de Moore sigue cumpliéndose hoy. A medida que nos acercamos a los límites físicos del silicio, seguimos viendo mejoras de rendimiento mediante técnicas de encapsulado, como el apilamiento 3D, y optimizaciones de arquitectura, como los SoC y la computación heterogénea.

Entender los límites de la experiencia implica reconocer que se trata de un juego infinito: la experiencia juega con los límites. Las necesidades, expectativas e imaginación humanas evolucionan constantemente. Por mucho que avance la tecnología, nunca terminaremos de mejorar la experiencia en torno a los momentos de la verdad, MOT, y los factores humanos. Por tanto, no existe un nivel de desarrollo tecnológico a partir del cual ya no sea necesario optimizar algún aspecto.

***

Leí *El efectivo es el rey*. Los ingresos son vanidad, los beneficios son sensatez y el efectivo es el rey. Esto resulta especialmente pertinente en la actual etapa de mercados con poco crecimiento, donde manda la eficiencia. Competir ya no consiste solo en ampliar la escala y perseguir el crecimiento, sino en profundizar en la eficiencia.

El libro utiliza el control del peso como analogía para explicar la lógica de «el efectivo es el rey».

1. Usar platos más pequeños. Ser frugal y mantener los costos operativos dentro de un volumen razonable y limitado de recursos. Una regla empírica, la ley de Parkinson, dice que la demanda de algo aumenta a medida que crece su oferta. Por eso ampliar las carreteras para reducir la congestión nunca funciona: siempre aparecen más conductores que llenan los nuevos carriles.
2. Comer primero las verduras y después los carbohidratos. Reescribir la fórmula contable clásica «ingresos de operación − costos y gastos = beneficios» como «ingresos de operación − beneficios = costos y gastos». Separar primero el beneficio y decidir después cómo gastar el dinero restante. La base es el efecto de primacía.
3. Eliminar la tentación y esconder lo que no se debe comer. Depositar los beneficios reservados, la remuneración de los propietarios y los impuestos en una cuenta separada, preferiblemente con cierta dificultad para retirar el dinero.
4. Comer menos, más veces, y suavizar los picos y valles. Revisar el saldo bancario dos veces al mes e inferir la situación del negocio a partir del efectivo disponible: el método más sencillo de llevar las cuentas mediante el saldo bancario.

Esto me recuerda al rediseño de la alarma que Apple hizo dentro de su gestión del sueño; no recuerdo en qué versión de iOS empezó. Normalmente, al poner una alarma nos centramos en la hora a la que debe despertarnos. La alarma de sueño de Apple hace que el usuario se fije primero en cuántas horas quiere dormir y ajuste, a partir de ese objetivo, cuándo acostarse y cuándo levantarse. Es la proyección de un cambio de enfoque en el diseño del producto. La idea de poner primero los beneficios debería tener una expresión similar en el pequeño libro de cuentas.

***

El aumento de tráfico tras la refactorización de la pantalla de pago en panel parcial lleva tiempo pendiente. Ahora toca afrontarlo de lleno. Ante un asunto que ha desgastado la voluntad del equipo durante casi un año, tengo dos opciones: resolverlo yo o dirigir a otras personas para resolverlo. Desde la perspectiva de ejercer bien la gestión, creo que la organización espera lo segundo. Para dirigir ese esfuerzo, necesito aclarar, en este orden, la disposición mental, las personas, el objetivo y la estrategia. Lo primero es reconstruir la disposición mental. Con qué actitud y estado de ánimo afrontar el mismo reto, producir una respuesta nueva y transmitirla al equipo.

Justo vi un libro nuevo, *Reframe Your Brain*. «Reframe» significa replantear el marco: interpretar activamente la realidad como una historia nueva que nos resulte más útil. Es reprogramar el cerebro, como un chip FPGA. En psicología hay un concepto parecido, la reestructuración cognitiva. Ante una situación, una experiencia, un pensamiento o una emoción, se trata de reconocer cómo la vemos, cuestionar esa visión y adoptar otra. Por ejemplo, podemos ver una dificultad como un reto, el reto como una aventura y la aventura, al final, como un juego.

El libro presenta muchas técnicas para replantear las cosas. Una de las más importantes consiste en pasar de una actitud pasiva a una activa. Recuerdo que Jerry me dijo algo parecido hace unos años: pasar de qué quieren que haga a qué quiero hacer yo. Y dar un paso más: pasar de lo que quiero hacer, *want to*, a lo que decido hacer, *decide to*. Decidir es asumir una iniciativa absoluta y un compromiso con uno mismo. Si quiero hacer algo, puedo dejar de quererlo cuando cambien las condiciones. Si decido hacerlo, buscaré todos los medios para conseguirlo y nada podrá detenerme.

¿Esta reconstrucción mental es una dosis de autoayuda basada en declararse vencedor por puro consuelo? Es como el marketing y las estafas piramidales: en apariencia, ambos venden algo; la diferencia esencial está en quién produce valor final. Lo que importa de la nueva interpretación no es si es correcta, sino si funciona. Algunas interpretaciones pueden no ser ciertas, pero basta con que nos resulten útiles.

***

La semana pasada, en un caso de integración con la pantalla de pago, las limitaciones del contenedor de la plataforma obligaron al equipo de negocio a cambiar de tipo de producto de pago. Eso exigió un costo considerable de comunicación. Aprovechamos para revisar cómo habían afectado al negocio los cambios históricos de contenedores. Al ordenarlos cronológicamente, los problemas principales salieron a la luz. Como dice la firma de tiange: «Hacer todo lo posible por evitar que, al estandarizar, los destinatarios se vuelvan abstractos, las normas se simplifiquen en exceso y las acciones se mecanicen». Creo que el problema más destacado es perder de vista a los destinatarios concretos. Servicios financieros puede ser el mayor cliente de los contenedores estandarizados. Sin embargo, en tantas decisiones técnicas históricas, nunca he visto que acudieran por iniciativa propia a investigar y entrevistar a nuestros compañeros de primera línea. El diseño pragmático nace de adentrarse y trabajar dentro del negocio.

Los productos técnicos o estándares que impulsa una plataforma suelen cubrir bien el 90 % de los casos. Lo más frustrante es que el 10 % restante, los casos menos frecuentes, suele fallar por desconocimiento. El negocio tiene que compensar los defectos de diseño con una peor experiencia o con más costos. Precisamente ese último 10 % determina cómo percibimos y valoramos el trabajo de la plataforma: en un recorrido de cien pasos, llegar a noventa es haber hecho solo la mitad del esfuerzo. Me recuerda a Six Sigma, en control de calidad. Para alcanzar resultados de alto nivel, la capacidad del proceso debe llegar a seis desviaciones estándar. Hay que centrarse en eliminar los últimos defectos de diseño, los difíciles de detectar. Atender y resolver los casos marginales y poco frecuentes es lo que puede aportar mejoras significativas de calidad o ventajas competitivas.

Es una lección que también debemos tener muy presente cuando hacemos trabajos de estandarización y gobernanza.