¡Sólo es un pequeño cambio! ¿Cuántas veces oímos que necesitamos arreglar algo? Necesitamos añadir una pequeña característica. Necesitamos ajustar algo. Code-wise o publicando, sólo se dio cuenta de que necesitaban esto para la conservación, o tal vez un analista trajo los datos más recientes, así que ahora tenemos que añadir solo unas pocas líneas al código. No afectan al rendimiento o a ningún otro departamento, prometo. Y es como 3 minutos de trabajo de codificación - ¿por qué no? Avanza rápidamente: rompieron el botón "Comprar" en la página principal de la tienda en el lanzamiento. ¿Por qué esto siempre sucede con pequeños cambios? Bueno, si pensamos en ello, generalmente no pensamos en ello. Los diseñadores piensan en las características y la experiencia del usuario. Los ingenieros piensan en sistemas enteros. Los productores piensan en tareas. Los interesados piensan en los resultados de los negocios. Y un pequeño cambio es siempre percibido como algo aislado y generalmente sin la conciencia de todos. Por lo tanto, es básicamente un recorrido cognitivo. Y eso no sucede porque todo el mundo está equivocado o poco profesional. Es porque los sistemas de producción modernos están altamente interconectados, por lo que es imposible saber qué podría ser potencialmente afectado por cualquier cosa - especialmente si no ha trabajado en este proyecto durante 15 años. ¿Qué es la producción moderna? me alegro de que te preguntes! No importa si construyes juegos o una aplicación bancaria - no solo tienes una pila de características y activos. Tienes un ecosistema para cada bit de trabajo: Arte, Código, Diseño, UI, Marketing, Publishing (quizás incluso Gestión de Proyectos - wow, eres un desarrollador rico), etc. Y cada uno de ellos tiene su propia infraestructura, pipelines, flujos de trabajo y activos compartidos. Para simplificar, puede ser esquemas de datos compartidos, construcciones, procesos de automatización, vínculos de UI y muchas otras cosas. ¿Qué está mal si sólo hago un pequeño cambio de color a uno de los iconos? Bueno, eso significa que pasas 3 segundos cambiando un código de color. Luego tienes que montar una construcción. Luego QA tiene que comprobar tu pequeño cambio para confirmar que realmente cambiaste el color. Luego tienes que montar la construcción de nuevo, que debería estar en cola con otras construcciones en la lista de espera. Entonces tenemos que actualizar el servidor con tus cambios - oh espera, ¿has contado a alguien sobre eso? ¿No? Oh, eso es genial, porque acaba de enviar tus cambios durante el congelamiento del compromiso, y ahora los ingenieros de despliegue tienen que arreglar el tubo CI / CD, y tenemos que posponer el lanzamiento por 4 días porque es viernes. Y por cierto - tenemos que comunicar eso a los usuarios porque estaban esperando esta nueva versión, y algunos de ellos decidieron no esperar tanto y eliminaron su app. Déjame presentarte a Change Propagation Surface (CPS) - el número de sistemas, tuberías, activos y flujos de trabajo que un cambio debe pasar antes de llegar al jugador. Su cambio no debe estimarse por su tamaño de tareas, como “1 hora de trabajo”. su cambio equivale a CPS × Densidad de acoplamiento (la cantidad de trabajo que otros departamentos deben hacer para que este cambio pase). Piensa en ello de esta manera: 
 
 
 Un pequeño ajuste de la interfaz de usuario no toca datos compartidos - bajo CPS. Un cambio de reglas de juego tocando el código, el equilibrio, el diseño, el análisis, la experiencia del jugador - alto CPS. Volvamos a la situación en la que desea cambiar el color del icono. Aquellos 3 segundos de trabajo afectarían a la interfaz de usuario, las ediciones, la percepción del jugador, la experiencia y el diseño. También podría afectar a la codificación de colores para las reglas de accesibilidad, además de la montaje de la edificación y, finalmente, las actualizaciones del servidor. Lo mismo se aplica a los intercambios de activos o al cambio de un valor de estado: afecta a la memoria, al ajuste de la IA, a la lógica de destrucción, etc. No lo hagas a menos que alguien de la dirección superior diga que es bajo CPS, entonces simplemente hazlo y vea cómo va. Puede aplicar este enfoque básicamente en cualquier lugar en la producción porque no es una cosa abstracta en absoluto y se puede estimar. Por ejemplo: 
 
 
 
 
 
 
 
 
 
 
 
 UI Atrás Código Cliente Diseño de juegos Economía analítico que Construcción / CI / CD El marketing Apoyo al Cliente Operaciones en vivo Cada uno de estos elementos cuenta como un factor CPS más 1.Después, cuanto más de los mismos “elementos” toques, mayor será el número de CPS que obtendrás.Y con esa información, puedes crear una pequeña matriz de estimación como: CPS 1-2 - Cambio local CPS 3-5 - Cambio interfuncional CPS 6+ - Cambio sistémico Una vez más, la fórmula es: Impact = CPS × Coupling Density. Veamos cómo funciona en un ejemplo real: Así que tu desarrollador se fue de vacaciones y completó un curso de matemáticas en LinkedIn. Y cuando volvió, dijo que hay una forma más eficiente de calcular EXP. Este cambio es “una línea de código”. 
 
 
 
 
 
 
 
 
 Juego de equilibrio Juegos de progresión pacing La inflación económica Batalla de la progresión Metrología de retención Análisis de Dashboards Promesas de marketing Apoyo al Cliente Load Eso significa que el CPS es más de 7. Así que ahora se ve que aunque el código difiera es pequeño, la superficie de propagación es sistémica y tiene un resultado potencial masivo. En otras palabras, si la progresión XP acelera cosas como la economía, la disponibilidad del contenido, el valor del pase de batalla, las curvas de retención, etc., debe saber que incluso si la implementación tarda alrededor de 10 minutos, el efecto de ripple puede tomar semanas de trabajo. ¿Por qué la producción de servicios en vivo lo hace peor?Porque es amplificado por el contenido que se reutiliza en múltiples funciones, por la telemetría y la economía que están estrechamente unidas, y por los sistemas que son persistentes y a menudo requieren compatibilidad retroactiva. Por lo tanto, el verdadero coste que pagas por la propagación se encuentra en plazos prolongados, reemplazo oculto, fricción entre equipos, deuda técnica, agotamiento y, finalmente, personas que renuncian directa o indirectamente. En lugar de pensar, “Oh, este es un pequeño cambio”, probablemente deberíamos pensar, “¿Qué sistemas toca este cambio?”Piensa en esto como infraestructura, no como una característica, y siempre intenta traer eso a la conciencia de los equipos. **Todo el punto de mi introducción demasiado larga es que no hay tal cosa como un pequeño cambio en los sistemas de producción.Sólo hay cambios en las áreas afectadas mal entendidas.Y cuanto más viejo se vuelve, más su visión se desplaza hacia comprender cómo este cambio viajará en lugar de tratar de evitar el cambio en su totalidad.

Read My Stories

Este audio es producido en el idioma original de la historia!

Por qué los "pequeños cambios" no existen en los sistemas de juegos de producción

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps