En funktionsflag er en forandrende faktor for produktchefer. De giver dig mulighed for at udgive nye funktioner uden besværet – ingen kodeændringer, ingen fuld udrulning og nul risiko.
Tænk på dem som en kontakt, du kan slå til og fra for at tilpasse dit produkt eller køre eksperimenter undervejs. Uanset om du vil forkorte udgivelsescyklusser eller teste nye idéer, giver funktionsflag dig kontrollen.
I denne artikel deler jeg bedste praksis for håndtering af funktionsflag og viser dig, hvordan jeg brugte disse teknikker hos Guardian Soulmates, The Guardians datingplatform, til at forenkle en større redesignproces.
Key Takeaways
Definition: Funktionsflag forbedrer udgivelsescyklusser ved at muliggøre sikre og fleksible udrulninger af funktioner uden kodeændringer.
Hvorfor de er nyttige: Tydelige navngivningskonventioner for funktionsflag hjælper teams med nemt at forstå deres formål og undgå forvirring.
Sådan bruges de effektivt: Administrer flag effektivt ved at rydde op i forældede flag og sikre, at de nemt kan slås til eller fra.
Start i det små: Brug funktionsflag til test ved at starte med små målgrupper og skalere op baseret på feedback for at minimere risici.
Bedste praksis for håndtering af funktionsflag
For effektivt at håndtere funktionsflag og sikre problemfri produktudgivelser er det vigtigt at følge bedste praksis, der fremmer klarhed og effektivitet. Her er nogle vigtige fremgangsmåder, du bør huske:
- Brug et ensartet system: Uanset om det er gennem et administrationsværktøj eller en konfigurationsfil, skal du sørge for, at systemet er let at forstå og tilgængeligt for alle teammedlemmer.
- Fastlæg klare navngivningskonventioner: Hver type flag (f.eks. udgivelses-, tilladelses- og deaktiveringsflag) bør have unikke og beskrivende navne, så alle kan forstå dem, selv flere år senere.
- Gør det nemt at slå flag til og fra: Flag bør være nemme at aktivere eller deaktivere uden kodeændringer eller indblanding fra udviklere.
- Ryd op i forældede flag: Fjern flag, der ikke længere er nødvendige, for at undgå rod og reducere teknisk gæld i dit system.
1. Brug et ensartet system til håndtering af funktionsflag
Det er ikke afgørende, om du bruger et værktøj til håndtering af funktionsflag (som for eksempel LaunchDarkly), en konfigurationsfil eller en databasetabel. Uanset hvad du bruger, skal systemet være let at forstå og indeholde gode navngivningskonventioner, så alle softwareingeniører forstår, hvad et flag gør.
Brug lidt tid, når du introducerer funktionsflag for første gang, på at drøfte, hvad der er den bedste løsning for dig, da du gerne vil holde fast i dette system på lang sigt.
2. Fastlæg navngivningskonventioner for forskellige typer funktionsflag
Du kan implementere funktionsflag for at opnå mange forskellige ting:
- Udgivelsesflag: muliggør udrulning af produktionskode, før en funktion er klar til offentlig udgivelse.
- Eksperimentflag: ved oprettelse af en A/B-test styrer flaget, hvilken brugergruppe der får hvilken oplevelse.
- Tilladelsesflag: giver dig mulighed for at styre adgangen til bestemte funktioner for forskellige kunder
- Deaktiveringsflag: giver dig mulighed for at nedskalere dit produkt på en kontrolleret måde i tilfælde af problemer med ydeevne eller overbelastning.
Klare navngivningskonventioner for hver type flag betyder, at alle ved, hvad hvert flag gør, selv flere år senere.
Have an account? Log In
3. Gør det nemt at slå et flag til/fra
Det smarte ved funktionsflag er, at de nemt kan slås til og fra. Ideelt set bør du have en måde at indstille et flag på uden kodeændringer eller indblanding fra en udvikler. Da flag kan bruges så bredt, kan flere teams ønske at ændre dem, for eksempel:
- QA til fejlfinding eller genskabelse af en bestemt kundesituation.
- Kundeservice til at aktivere eller deaktivere en funktion for en kunde.
- DevOps-teamet til på en kontrolleret måde at lukke (dele af) dit produkt ned i tilfælde af overbelastning eller andre problemer.
Hvis du har en onlinevisning, hvor flagene kan indstilles, kan alt dette gøres uden arbejde fra dit udviklingsteam.
4. Gør indstillingerne for funktionsflag synlige
Det bør være let at se, hvilken kombination af indstillinger for funktionsflag der er angivet for en bestemt bruger. Dette bør gemmes sammen med brugerens profil både i din brugerdatabase og i dit analysesystem.
Det kan være meget nyttigt for kundeservice ved fejlfinding af indrapporterede problemer. Det kan også være meget værdifuldt at analysere forskellige brugeres adfærd med forskellige indstillinger. Det er afgørende, når resultaterne af en A/B-test analyseres.
5. Ryd op i forældede flag
Udgivelsesflag og eksperimentflag er pr. definition kun nødvendige midlertidigt. Efter den fulde udgivelse af en ny funktion, der styres af et flag, eller når et eksperiment er afsluttet, bør du afsætte tid til at fjerne flaget som det sidste trin. På den måde ophober du ikke teknisk gæld i koden, og din håndtering af funktionsflag forbliver overskuelig og let at forstå.
6. Undgå afhængigheder mellem flag
Hvert flag bør have sit specifikke formål, som er uafhængigt af alle andre flag. For tilladelsesflag betyder det, at koden skal være så modulær, at forskellige funktioner kan slås til i enhver kombination.
Hvis der er brug for flere flag for at aktivere et bestemt anvendelsestilfælde, eller hvis de potentielt er i konflikt med andre flag, kan indstillingen af flagene blive forvirrende, og før eller siden vil der opstå problemer med brugernes oplevelse.
7. Brug funktionsskift for at undgå kodeforgreninger
Når I drøfter implementeringen af en større funktion i produktteamet, vil I diskutere, hvordan softwareudviklingen kan opdeles i mindre dele. På dette tidspunkt bør I også drøfte brugen af et funktionsflag.
Når du implementerer et flag og holder det slået fra, undgår du at oprette langlivede funktionsforgreninger. I stedet kan koden til den nye funktion løbende flettes sammen og udgives uden at blive gjort synlig for brugerne i en CI/CD (kontinuerlig integration / kontinuerlig levering) eller i en agil sprintbaseret kodeudrulning. Det forbedrer kvaliteten af din kodebase, fordi du undgår store og komplicerede fletteprocesser, og eventuelle konflikter identificeres hurtigt.
Det afkobler også udgivelsen af kode fra visningen af ændringerne for slutbrugerne, som forklaret i punkt 8.
8. Brug funktionsflag til små testudgivelser
Store udgivelser af nye funktioner har en tendens til at være stressende og risikable, men du kan håndtere dette ved først at gøre din funktion tilgængelig for en lille målgruppe, overvåge effekten og rulle tilbage, hvis det er nødvendigt.
Hvis du har brugt et funktionsflag til løbende at flette og udgive din kode, før du gør den tilgængelig for hele verden, som anbefalet under punkt 7, har du allerede værktøjet til at opnå dette.
Når din nye funktionalitet er klar, skal du slå den til i produktionsmiljøet, så den først bliver tilgængelig for interne testere, derefter for en lille procentdel af kunderne (kaldet en kanarieudgivelse) og til sidst for hele kundebasen.
Ved hvert trin overvåger du dine vigtigste målepunkter. Hvis noget går galt på noget tidspunkt, kan du nemt slå flaget fra igen og undersøge problemet uden stresset ved en kompliceret tilbagerulning.
Det følgende casestudie viser et eksempel på, hvordan risikoen ved en større redesign af et produkt kan reduceres.
Casestudie - funktionsflag i redesignet af Guardian Soulmates
Da jeg arbejdede som produktchef for Guardian Soulmates (The Guardians abonnementsbaserede datingplatform på det tidspunkt), stod vi over for to udfordringer: et mobilwebsted under standard og et træt brand. Vi besluttede at håndtere overgangen til et responsivt websted med et nyt brand i to trin.
Lad os se det i øjnene: Kunder hader generelt forandringer, især betalende kunder. En rebranding er en omfattende opgave, der kan medføre mange forstyrrelser.
Vi drøftede, hvordan vi bedst kunne nå vores mål om at erstatte mobilwebstedet og implementere et nyt brand uden for mange forstyrrelser for vores abonnenter. Den valgte løsning var en proces i to trin, der involverede to funktionsflag:
- Flag for responsivt layout: Dette flag blev brugt til at give os mulighed for at vise hver enkelt side enten i et responsivt layout eller i det eksisterende desktoplayout (det separate mobilwebsted forblev urørt, indtil vi var klar til at lancere det nye mobilwebsted fuldt ud).
- Flag for nyt brand: Dette flag gjorde det muligt for os at vise hele webstedet med det gamle eller det nye brand.
More Articles
Flag for responsivt websted
Efter at have oprettet en responsiv ramme migrerede vi siderne én efter én til det nye responsive layout. Hvis du arbejder på noget lignende, kan disse værktøjer til prototyping af responsivt design hjælpe dig med at teste og tilpasse layouts, før de går live.
For hver migreret side blev det responsive funktionsflag først slået til for en lille gruppe brugere med mulighed for at give feedback.
Efter nogle dage blev den responsive side derefter gjort tilgængelig for alle brugere. Dette blev gentaget, indtil hele webstedet var responsivt.
Derefter blev mobilwebstedet skiftet over til det nye responsive websted. Forstyrrelsen for desktopbrugere var minimal, da vi havde overført siderne trinvist.
Forstyrrelsen for mobilbrugerne var lille, da vi ikke havde særlig mange mobilbrugere på det tidspunkt (fordi det gamle mobilwebsted ikke var særlig godt!).
Flag for rebranding af det responsive websted
Efter lanceringen af det responsive websted gjorde funktionsflaget for det nye brand det muligt for os at skifte hele webstedet mellem det gamle og det nye brand.
Udviklerne implementerede en knap på webstedet til at skifte brandet for den enkelte bruger, hvilket gjorde det muligt for designere, kvalitetssikringsmedarbejdere og også mig som produktchef at følge fremskridtene.
Redesignede sider blev udgivet løbende, men i det aktive miljø forblev dette flag slået fra, så ingen bruger så sider med det nye brand.
Da alle sider var klar, satte vi en knap på webstedet, så brugerne kunne tilmelde sig en offentlig forhåndsvisning af den nye branding. Denne knap aktiverede den nye branding for brugeren. Brugerne kunne give os feedback, og efter en uge aktiverede vi brandingen for alle.
Hele processen var fuldstændig problemfri både for udviklingsteamet og vores kunder. Det var et fremragende eksempel på brugen af funktionsflag til at reducere risikoen ved en større redesign af webstedet.
Hvis du er interesseret i at forstå mere detaljeret, hvad vi gjorde, kan du finde en artikel om Soulmates-redesignprojektet på Guardians teknologiblog.
Afsluttende tanker
Få den indledende ramme på plads, så vil du opdage, at brugen af funktionsflag i høj grad kan øge fleksibiliteten og effektiviteten i dit produkt.
Du bør også overveje at bruge funktionsflag til større initiativer for at minimere risikoen samt have en plan for releasehåndtering for at sikre en problemfri udrulning. Du kan også bruge AI i releasehåndtering til at udarbejde denne plan. Den eneste begrænsning for brugen af funktionsflag er din fantasi!
Fortæl os om nogle smarte måder, du har brugt funktionsflag i dit produkt på, i kommentarerne.
Hvis du gerne vil have flere tips og tricks til at forbedre dine færdigheder inden for produktledelse, kan du tilmelde dig vores nyhedsbrev.
Få hjælp fra en anden produktchef på dit team med denne nyttige guide: Sådan opretter du en effektiv jobbeskrivelse for en agil produktchef (+eksempel)
Også værd at se nærmere på:
