Det är bara en liten förändring! Hur ofta hör vi att vi behöver fixa något? Vi behöver lägga till en liten funktion. Vi behöver justera något. Code-wise eller publicering, bara insåg att de behöver detta för bevarande, eller kanske en analytiker tog de senaste uppgifterna, så nu måste vi lägga till bara några rader till koden. De påverkar inte prestanda eller andra avdelningar, jag lovar. Och det är precis som 3 minuter av kodningsarbete - varför inte? Snabbt framåt: de bröt "Köp" -knappen på framsidan av butiken vid release. Varför händer detta alltid med små förändringar?Jo, om vi tänker på det, tänker vi vanligtvis inte på det. Designers tänker på funktioner och användarupplevelse. Ingenjörer tänker i hela system. Producenterna tänker i uppgifter. Intressenterna tänker på affärsresultat. Och en liten förändring uppfattas alltid som något isolerat och vanligtvis utan allas medvetenhet. Så det är i grunden en kognitiv genväg. Och det händer inte för att alla är fel eller oprofessionella. Det beror på att moderna produktionssystem är mycket sammankopplade, så det är omöjligt att veta vad som potentiellt kan påverkas av något - speciellt om du inte har arbetat på detta projekt i 15 år. Vad är modern produktion? jag är glad att du frågade! Det spelar ingen roll om du bygger spel eller en bankapp - du har inte bara en massa funktioner och tillgångar. Du har ett ekosystem för varje bit av arbete: konst, kod, design, UI, marknadsföring, publicering (kanske till och med projektledning - wow, du är en rik utvecklare) etc. Och var och en av dem har sin egen infrastruktur, rörledningar, arbetsflöden och delade tillgångar. För att förenkla kan det vara delade data scheman, byggnader, automationsprocesser, UI-bindningar och många andra saker. Vad är fel om jag bara gör en liten färgförändring till en av ikonerna? Tja, det betyder att du spenderar 3 sekunder på att ändra en färgkod. Sedan måste du montera en build. Sedan måste QA kontrollera din lilla förändring för att bekräfta att du faktiskt har ändrat färgen. Sedan måste du montera builden igen, vilket bör vara i kö med andra builds i väntelistan. Då måste vi uppdatera servern med dina ändringar - o vänta, har du berättat för någon om det? nej, det är bra, för att du bara lämnade in dina ändringar under kommittéfrysningen, och nu måste utplaceringsingenjörerna fixa CI / CD-rörledningen, och vi måste skjuta upp utgivningen i 4 dagar eftersom det är fredag. Och förresten - vi måste kommunicera det till användare eftersom de väntade på den här nya versionen, och några av dem bestämde sig för att inte vänta så länge och tog bort din app. Låt mig presentera dig för Change Propagation Surface (CPS) - antalet system, rörledningar, tillgångar och arbetsflöden som en förändring måste passera innan den når spelaren. Din förändring bör inte uppskattas av dess uppgiftsstorlek, till exempel "1 timme arbete." Tänk på det så här: 
 
 
 En liten UI tweak berör inga delade data - låg CPS. En spelregler förändring beröring kod, balans, design, analys, spelarupplevelse - hög CPS. Låt oss gå tillbaka till situationen där du vill ändra färgen på ikonen. De 3 sekunderna av arbetet skulle påverka UI, byggnader, spelarens uppfattning, erfarenhet och design. Det kan också påverka färgkodning för tillgänglighetsregler, plus bygga montering, och slutligen serveruppdateringar. Det är hög CPS - naturligtvis, om du inte smyger in den förändringen utan allas medvetenhet (jag ser det - släpp det!). Detsamma gäller för tillgångsväxlingar eller ändring av ett statiskt värde: det påverkar minne, AI-stämning, destruktionslogik etc. Gör inte det om inte någon från ledningen säger att det är lågt CPS - sedan gör du det och se hur det går. Du kan tillämpa detta tillvägagångssätt i princip var som helst i produktionen eftersom det inte är en abstrakt sak alls och kan uppskattas. Till exempel: 
 
 
 
 
 
 
 
 
 
 
 
 UI Bakgrund Kundkoden Spel design ekonomin Analysera som Bygga / CI / CD Marknadsföring Kundsupport Levande operationer Var och en av dessa objekt räknas som en plus 1 CPS-faktor. Därefter, ju fler av samma "objekt" du rör vid, desto högre CPS-nummer du får. CPS 1-2 - Lokal förändring CPS 3-5 - Cross-funktionell förändring CPS 6+ - Systemisk förändring En gång till är formeln: Impact = CPS × Coupling Density. Låt oss se hur det fungerar i ett verkligt exempel: Så din utvecklare gick på semester och avslutade en matematikkurs på LinkedIn. Och när han kom tillbaka sa han att det finns ett mer effektivt sätt att beräkna EXP. Denna förändring är "en rad kod". 
 
 
 
 
 
 
 
 
 Spelbalans Spelare progression pacing ekonomisk inflation Battle Pass framsteg Retention Metrik Analytiska Dashboards Marknadsföring löften Kundtjänst Load Det betyder att CPS är mer än 7. Så nu ser du att även om koddiff är liten, är spridningsytan systemisk och har ett massivt potentiellt resultat. Med andra ord, om XP-progression accelererar saker som ekonomi, innehållets tillgänglighet, slagpassvärde, behållningskurvor etc., bör du veta att även om implementeringen tar cirka 10 minuter, kan ripple-effekten ta veckor av arbete. Eftersom det förstärks av innehåll som återanvänds över flera funktioner, av telemetri och ekonomi som är tätt kopplade, och av system som är ihållande och ofta kräver bakåtkompatibilitet. Så, den verkliga kostnaden du betalar för spridning ligger i förlängda tidslinjer, dold omarbetning, cross-team friktion, teknisk skuld, utbrändhet och så småningom, människor som avgår direkt eller indirekt. I stället för att tänka, "Åh, det här är en liten förändring", borde vi förmodligen tänka, "Vilka system berör denna förändring?" Tänk på detta som infrastruktur, inte en funktion, och försök alltid att ta det till cross-team medvetenhet. ** Hela poängen med min väg-för-lång introduktion är att det inte finns något sådant som en liten förändring i produktionssystem. Det finns bara förändringar i missförstådda drabbade områden. Och ju äldre du blir, desto mer din vision skiftar mot att förstå hur denna förändring kommer att resa i stället för att försöka undvika förändringen helt och hållet.

Read My Stories

Det här ljudet är producerat på berättelsens originalspråk!

Varför "små förändringar" inte existerar i produktionsspelssystem

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps