Funksjonsflagg er en spillvender for produkteiere. De lar deg lansere nye funksjoner uten hodebry – ingen kodeendringer, ingen full utrulling og null risiko.
Tenk på dem som en bryter du kan slå av og på for å tilpasse produktet ditt eller kjøre eksperimenter på direkten. Enten du vil korte ned lanseringssyklusene eller teste nye ideer, gir funksjonsflagg deg kontrollen.
I denne artikkelen deler jeg beste praksis for håndtering av funksjonsflagg og viser hvordan jeg brukte disse teknikkene hos Guardian Soulmates, The Guardians datingplattform, for å forenkle en større redesign.
Key Takeaways
Definisjon: Funksjonsflagg forbedrer lanseringssykluser ved å muliggjøre trygg og fleksibel utrulling av funksjoner uten kodeendringer.
Hvorfor de er nyttige: Tydelige navnekonvensjoner for funksjonsflagg hjelper team med å forstå formålet deres enkelt og unngå forvirring.
Effektiv bruk: Administrer flagg effektivt ved å rydde opp i foreldede flagg og sørge for at de enkelt kan slås på eller av.
Begynn i det små: Bruk funksjonsflagg til testing ved å begynne med små målgrupper og skalere opp basert på tilbakemeldinger for å minimere risiko.
Beste praksis for håndtering av funksjonsflagg
For å håndtere funksjonsflagg effektivt og sikre smidige produktlanseringer er det viktig å følge beste praksis som fremmer tydelighet og effektivitet. Her er noen viktige praksiser du bør ha i mente:
- Bruk et konsekvent system: Enten du bruker et administrasjonsverktøy eller en konfigurasjonsfil, må du sørge for at systemet er lett å forstå og tilgjengelig for alle teammedlemmer.
- Etabler tydelige navnekonvensjoner: Hver type flagg (f.eks. lanserings-, tilgangs- og avstengingsflagg) bør ha unike og beskrivende navn, slik at alle forstår dem – også flere år senere.
- Gjør det enkelt å slå flagg av og på: Flagg bør være enkle å aktivere eller deaktivere uten at det kreves kodeendringer eller hjelp fra utviklere.
- Rydd opp i utdaterte flagg: Fjern flagg som ikke lenger trengs, for å unngå rot og redusere teknisk gjeld i systemet.
1. Bruk et konsekvent system for håndtering av funksjonsflagg
Det spiller ingen rolle om du bruker et verktøy for håndtering av funksjonsflagg (for eksempel LaunchDarkly), en konfigurasjonsfil eller en databasetabell. Uansett hva du bruker, bør systemet være lett å forstå og ha gode navnekonvensjoner, slik at alle programvareingeniører forstår hva et flagg gjør.
Bruk litt tid når du først introduserer funksjonsflagg, til å diskutere hvilken løsning som passer best for deg, siden du ønsker å holde fast ved dette systemet på lang sikt.
2. Etabler navnekonvensjoner for ulike typer funksjonsflagg
Du kan implementere funksjonsflagg for å oppnå mange forskjellige ting:
- Lanseringsflagg: gjør det mulig å rulle ut produksjonskode før en funksjon er klar for offentlig lansering.
- Eksperimentflagg: brukes til å opprette en A/B-test, der flagget styrer hvilken brukergruppe som får hvilken opplevelse.
- Tilgangsflagg: lar deg kontrollere tilgangen til bestemte funksjoner for ulike kunder
- Avstengingsflagg: lar deg gradvis redusere funksjonaliteten i produktet ved ytelses- eller overbelastningsproblemer.
Tydelige navnekonvensjoner for hver type flagg gjør at alle vet hva hvert flagg gjør, selv flere år senere.
Have an account? Log In
3. Gjør det enkelt å slå et flagg av og på
Det fine med funksjonsflagg er at de enkelt kan slås av og på. Ideelt sett bør du ha en måte å angi et flagg på uten kodeendringer eller hjelp fra en utvikler. Siden flagg kan brukes på så mange områder, kan flere team ønske å endre dem, for eksempel:
- QA for å feilsøke eller gjenskape en bestemt kundesituasjon.
- Kundeservice for å aktivere eller deaktivere en funksjon for en kunde.
- DevOps-teamet for å stenge ned (deler av) produktet på en kontrollert måte ved overbelastning eller andre problemer.
Hvis du har et nettbasert grensesnitt for å angi flaggene, kan alt dette gjøres uten arbeid fra utviklingsteamet.
4. Gjør innstillingene for funksjonsflagg synlige
Det bør være enkelt å se hvilken kombinasjon av innstillinger for funksjonsflagg som gjelder for en bestemt bruker. Dette bør lagres sammen med brukerens profil, både i brukerdatabasen og i analysesystemet.
Dette kan være svært nyttig for kundeservice ved feilsøking av innrapporterte problemer. Det kan også være svært verdifullt for å analysere ulike brukeratferder med forskjellige innstillinger. Det er avgjørende ved analyse av resultatene fra en A/B-test.
5. Rydd opp i utdaterte flagg
Lanseringsflagg og eksperimentflagg trengs per definisjon bare midlertidig. Etter full lansering av en ny funksjon som styres av et flagg, eller når et eksperiment er fullført, bør du sette av tid til å fjerne flagget som siste trinn. På denne måten bygger du ikke opp teknisk gjeld i koden, og håndteringen av funksjonsflagg forblir ryddig og lett å forstå.
6. Unngå avhengigheter mellom flagg
Hvert flagg bør ha sitt spesifikke formål, uavhengig av alle andre flagg. For tillatelsesflagg betyr dette at koden må være så modulær at ulike funksjoner kan slås på i enhver kombinasjon.
Hvis flere flagg er nødvendige for å aktivere et bestemt bruksområde, eller potensielt kommer i konflikt med andre flagg, kan innstillingen av flaggene bli forvirrende, og før eller senere vil det oppstå problemer med brukeropplevelsen.
7. Bruk en funksjonsbryter for å unngå kodegrener
Når dere diskuterer implementeringen av en større funksjon i produktteamet, vil dere diskutere hvordan programvareutviklingen kan deles opp i mindre deler. På dette tidspunktet bør dere også diskutere bruken av et funksjonsflagg.
Når du implementerer et flagg og lar det være avslått, unngår du å opprette langvarige funksjonsgrener. I stedet kan koden for den nye funksjonen slås sammen og lanseres kontinuerlig uten å bli eksponert for brukerne i en CI/CD (kontinuerlig integrasjon / kontinuerlig levering)- eller en smidig sprintbasert kodeutrulling. Dette forbedrer integriteten til kodebasen, siden du unngår store og kompliserte sammenslåingsprosesser, og eventuelle konflikter blir raskt identifisert.
Det kobler også lanseringen av kode fra visningen av endringene for sluttbrukere, som forklart i punkt 8.
8. Bruk funksjonsflagg for små testlanseringer
Store lanseringer av nye funksjoner har en tendens til å være stressende og risikable, men du kan håndtere dette ved å eksponere funksjonen for et lite publikum først, overvåke effektene og rulle tilbake om nødvendig.
Hvis du har brukt et funksjonsflagg til å slå sammen og lansere koden kontinuerlig før du eksponerer den for omverdenen, slik det anbefales i punkt 7, har du allerede verktøyet du trenger for å oppnå dette.
Når den nye funksjonaliteten er klar, slår du den på i produksjonsmiljøet slik at den først blir tilgjengelig for interne testere, deretter for en liten prosentandel av kundene (kalt en kanarilansering), og til slutt for hele kundebasen.
I hvert trinn overvåker du de viktigste måltallene. Hvis noe går galt på et hvilket som helst tidspunkt, kan du enkelt slå av flagget igjen og undersøke problemet uten stresset ved en komplisert tilbakerulling.
Den følgende eksempelstudien viser et eksempel på hvordan risikoen ved et større omdesign av et produkt kan reduseres.
Eksempelstudie – funksjonsflagg i omdesignen av Guardian Soulmates
Da jeg jobbet som produktsjef for Guardian Soulmates (Guardians abonnementsbaserte datingplattform på den tiden), sto vi overfor to utfordringer: et mobilnettsted under standard og en sliten merkevareprofil. Vi bestemte oss for å gjennomføre overgangen til et responsivt nettsted med ny merkevareprofil i to trinn.
La oss innse det: Kunder hater generelt endringer, særlig kunder som betaler. En merkevarefornyelse er et omfattende arbeid som kan føre til mye uro.
Vi diskuterte hvordan vi best kunne nå målene våre om å erstatte mobilnettstedet og innføre en ny merkevareprofil uten å skape for mye uro for abonnentene våre. Den valgte løsningen var en prosess i to trinn som involverte to funksjonsflagg:
- Flagg for responsivt oppsett: Dette flagget ble brukt til å gjøre det mulig for oss å vise hver enkelt side enten i et responsivt oppsett eller i det eksisterende skrivebordsoppsettet (det separate mobilnettstedet forble urørt til vi var klare til å lansere det nye mobilnettstedet fullt ut).
- Flagg for ny merkevareprofil: Dette flagget gjorde det mulig for oss å vise hele nettstedet med den gamle eller den nye merkevareprofilen.
More Articles
Flagg for responsivt nettsted
Etter at vi hadde opprettet et responsivt rammeverk, migrerte vi sidene én etter én til det nye responsive oppsettet. Hvis du jobber med noe lignende, kan disse verktøyene for prototyping av responsivt design hjelpe deg med å teste og forbedre oppsett før publisering.
For hver migrerte side ble funksjonsflagget for responsiv visning først slått på for en liten brukergruppe, med en mulighet til å gi tilbakemeldinger.
Etter noen dager ble den responsive siden gjort tilgjengelig for alle brukere. Dette ble gjentatt til hele nettstedet var responsivt.
Deretter ble mobilnettstedet byttet over til det nye responsive nettstedet. Forstyrrelsene for skrivebordsbrukerne var minimale, siden vi hadde gått over til de nye sidene trinnvis.
Forstyrrelsene for mobilbrukerne var små, siden vi ikke hadde særlig mange mobilbrukere på den tiden (det gamle mobilnettstedet var jo ikke særlig bra!).
Flagg for merkevarefornyelse av det responsive nettstedet
Etter lanseringen av det responsive nettstedet gjorde funksjonsflagget for den nye merkevareprofilen det mulig for oss å veksle mellom den gamle og den nye merkevareprofilen for hele nettstedet.
Utviklerne implementerte en knapp på nettstedet for å bytte merkevareprofil per bruker, slik at designere, kvalitetssikrere og jeg som produktsjef kunne se fremdriften.
Sider med nytt design ble lansert fortløpende, men i produksjonsmiljøet forble dette flagget avslått, slik at ingen brukere så sider med den nye merkevareprofilen.
Da alle sidene var klare, la vi inn en knapp på nettstedet som lot brukerne velge en offentlig forhåndsvisning av den nye merkevaren. Denne knappen slo på den nye merkevaren for en bruker. Brukerne kunne gi oss tilbakemeldinger, og etter en uke aktiverte vi merkevaren for alle.
Hele prosessen var helt problemfri, både for utviklingsteamet og kundene våre. Det var et utmerket eksempel på hvordan man kan bruke funksjonsflagg for å redusere risikoen ved en større redesign av nettstedet.
Hvis du er interessert i å forstå mer detaljert hva vi gjorde, finner du en artikkel om redesignprosjektet for Soulmates på Guardians teknologiblogg.
Avsluttende tanker
Få det innledende rammeverket på plass, så vil du oppdage at bruk av funksjonsflagg kan øke fleksibiliteten og effektiviteten i produktet ditt betraktelig.
Du bør også vurdere å bruke funksjonsflagg for større initiativer for å minimere risikoen, samt ha en lanseringsstyringsplan for å sikre en problemfri utrulling. Du kan også bruke KI i lanseringsstyringen til å utarbeide denne planen. Den eneste begrensningen for bruken av funksjonsflagg er fantasien din!
Fortell oss om smarte måter du har brukt funksjonsflagg i produktet ditt på, i kommentarfeltet.
Hvis du ønsker flere tips og triks for å forbedre ferdighetene dine innen produktstyring, kan du abonnere på nyhetsbrevet vårt.
Få hjelp fra en annen produktleder i teamet ditt med denne nyttige veiledningen: Slik lager du en effektiv stillingsbeskrivelse for en smidig produktleder (+eksempel)
Også verdt å sjekke ut:
