Skip to main content

Funktionsflaggor förändrar spelplanen för produktchefer. De låter dig lansera nya funktioner utan huvudvärk – inga kodändringar, inga fullständiga utrullningar och noll risk.

Tänk på dem som en omkopplare som du kan slå på eller av för att anpassa din produkt eller genomföra experiment i realtid. Oavsett om du vill snabba upp lanseringscykler eller testa nya idéer ger funktionsflaggor dig kontrollen.

I den här artikeln delar jag med mig av bästa praxis för hantering av funktionsflaggor och visar hur jag använde dessa tekniker på Guardian Soulmates, The Guardians dejtingplattform, för att förenkla en omfattande redesign.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

Key Takeaways

Definition: Funktionsflaggor förbättrar lanseringscykler genom att möjliggöra säkra och flexibla utrullningar av funktioner utan kodändringar.

Varför de är användbara: Tydliga namnkonventioner för funktionsflaggor hjälper team att enkelt förstå deras syfte och undvika förvirring.

Använd dem effektivt: Hantera flaggor effektivt genom att rensa bort föråldrade flaggor och se till att de enkelt kan aktiveras eller inaktiveras.

Börja i liten skala: Använd funktionsflaggor för testning genom att börja med små målgrupper och skala upp baserat på feedback för att minimera riskerna.

Bästa praxis för hantering av funktionsflaggor

För att hantera funktionsflaggor effektivt och säkerställa smidiga produktlanseringar är det viktigt att följa bästa praxis som främjar tydlighet och effektivitet. Här är några viktiga metoder att ha i åtanke:

  • Använd ett konsekvent system: Oavsett om det är via ett hanteringsverktyg eller en konfigurationsfil bör du se till att systemet är lätt att förstå och tillgängligt för alla teammedlemmar.
  • Fastställ tydliga namnkonventioner: Varje typ av flagga (t.ex. lansering, behörighet, avstängning) bör ha unika och beskrivande namn, så att alla förstår dem, även flera år senare.
  • Gör det enkelt att växla flaggor: Det ska vara enkelt att slå på eller av flaggor utan att kräva kodändringar eller ingripande från en utvecklare.
  • Rensa bort föråldrade flaggor: Ta bort flaggor som inte längre behövs för att undvika rörighet och minska teknisk skuld i systemet.

1. Använd ett konsekvent system för hantering av funktionsflaggor

Det spelar ingen roll om du använder ett verktyg för hantering av funktionsflaggor (som till exempel LaunchDarkly), en konfigurationsfil eller en databastabell. Oavsett vad du använder bör systemet vara lätt att förstå och innehålla bra namnkonventioner, så att varje programvaruingenjör förstår vad en flagga gör.

Lägg lite tid på att diskutera vilken lösning som passar bäst för dig när du introducerar funktionsflaggor, eftersom du vill hålla fast vid systemet på lång sikt. 

2. Fastställ namnkonventioner för olika typer av funktionsflaggor

Du kan implementera funktionsflaggor för att uppnå många olika saker:

  • Lanseringsflaggor: möjliggör utrullning av produktionskod innan en funktion är redo för offentlig lansering.
  • Experimentflaggor: vid skapandet av ett A/B-test styr flaggan vilken grupp av användare som får vilken upplevelse.
  • Behörighetsflaggor: låter dig styra åtkomsten till vissa funktioner för olika kunder 
  • Avstängningsflaggor: låter dig försämra din produkt på ett kontrollerat sätt vid prestanda- eller överbelastningsproblem. 

Tydliga namnkonventioner för varje typ av flagga innebär att alla vet vad varje flagga gör, även flera år senare. 

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

3. Gör det enkelt att slå på och av en flagga

Det fina med funktionsflaggor är att de enkelt kan slås på och av. Helst bör du ha ett sätt att ställa in en flagga utan någon kodändring eller något ingripande från en utvecklare. Eftersom flaggor kan användas så brett kan flera team vilja hantera dem, till exempel:

  • QA för att felsöka eller återskapa en viss kundsituation.
  • Kundtjänsten för att aktivera eller inaktivera en funktion för en kund.
  • DevOps-teamet för att på ett kontrollerat sätt stänga ner (delar av) din produkt vid överbelastning eller andra problem. 

Om du har en webbsida där flaggorna kan ställas in kan allt detta göras utan arbete från ditt ingenjörsteam. 

4. Gör inställningarna för funktionsflaggor synliga

Det bör vara enkelt att se vilken kombination av inställningar för funktionsflaggor som gäller för en viss användare. Detta bör lagras tillsammans med användarens profil både i användardatabasen och i analyssystemet.

Detta kan vara mycket användbart för kundtjänsten vid felsökning av rapporterade problem. Det kan också vara värdefullt för att analysera olika användarbeteenden med olika inställningar. Det är avgörande vid analys av resultaten från ett A/B-test.

5. Rensa bort föråldrade flaggor

Lanseringsflaggor och experimentflaggor behövs per definition endast tillfälligt. När en ny funktion som styrs av en flagga har lanserats fullt ut eller ett experiment har slutförts bör du planera in tid för att ta bort flaggan som sista steg. På så sätt samlar du inte på dig teknisk skuld i koden, och din hantering av funktionsflaggor förblir lättöverskådlig och enkel att förstå. 

6. Undvik beroenden mellan flaggor

Varje flagga bör ha ett specifikt syfte som är oberoende av alla andra flaggor. För behörighetsflaggor innebär detta att koden måste vara så modulär att olika funktioner kan aktiveras i valfri kombination.

Om flera flaggor behövs för att aktivera ett visst användningsfall, eller om de potentiellt står i konflikt med andra flaggor, kan inställningen av flaggorna bli förvirrande och förr eller senare kommer problem att uppstå i användarnas upplevelser. 

7. Använd en funktionsväxel för att undvika kodgrenar

När ni diskuterar implementeringen av en större funktion i produktteamet kommer ni att diskutera hur mjukvaruutvecklingen kan delas upp i mindre delar. Vid denna tidpunkt bör ni även diskutera användningen av en funktionsflagga. 

När du implementerar en flagga och låter den vara avstängd undviker du att skapa långlivade funktionsgrenar. I stället kan koden för den nya funktionen kontinuerligt sammanfogas och lanseras utan att exponeras för användare i en CI/CD-process (kontinuerlig integrering / kontinuerlig leverans) eller i en koddistribution under en agil sprint. Detta förbättrar kodbasens integritet eftersom du slipper stora och komplicerade sammanfogningsprocesser och eventuella konflikter identifieras snabbt.

Det frikopplar också lanseringen av kod från visningen av ändringarna för slutanvändare, som förklaras i punkt 8.

8. Använd funktionsflaggor för små testlanseringar

Stora lanseringar av nya funktioner tenderar att vara stressande och riskfyllda, men du kan hantera detta genom att först exponera funktionen för en liten målgrupp, övervaka effekterna och återställa ändringen vid behov.

Om du har använt en funktionsflagga för att kontinuerligt sammanfoga och lansera koden innan du exponerar den för omvärlden, enligt rekommendationen i punkt 7, har du redan verktyget för att uppnå detta.

När den nya funktionaliteten är klar aktiverar du den i produktionsmiljön så att den först exponeras endast för interna testare, därefter för en liten andel av kunderna (en så kallad kanarieutgåva) och sedan för hela kundbasen. 

Vid varje steg övervakar du dina viktigaste mätvärden. Om något går fel när som helst kan du enkelt stänga av flaggan igen och undersöka problemet utan stressen från en komplicerad återställning. 

Följande fallstudie visar ett exempel på hur man minskar riskerna vid en omfattande omdesign av en produkt. 

Fallstudie – funktionsflaggor vid omdesignen av Guardian Soulmates

När jag arbetade som produktchef för Guardian Soulmates (Guardians prenumerationsbaserade dejtingplattform vid den tiden) stod vi inför två utmaningar: en undermålig mobilwebbplats och ett trött varumärke. Vi beslutade att genomföra övergången till en responsiv webbplats med ny varumärkesprofil i två steg. 

Låt oss inse det: kunder hatar i allmänhet förändringar, särskilt betalande kunder. Ett nytt varumärke är ett omfattande arbete som kan orsaka stora störningar.

Vi diskuterade hur vi bäst kunde uppnå våra mål att ersätta mobilwebbplatsen och införa en ny varumärkesprofil utan att störa våra prenumeranter alltför mycket. Den valda lösningen var en process i två steg som omfattade två funktionsflaggor:

  • Flagga för responsiv layout: den här flaggan användes för att låta oss visa varje enskild sida antingen med responsiv layout eller i den befintliga skrivbordslayouten (den separata mobilwebbplatsen förblev orörd tills vi var redo att lansera den nya mobilwebbplatsen fullt ut). 
  • Flagga för ny varumärkesprofil: Den här flaggan gjorde det möjligt för oss att visa hela webbplatsen med den gamla eller den nya varumärkesprofilen.

Flagga för responsiv webbplats

Efter att ha skapat ett responsivt ramverk migrerade vi sidorna en i taget till den nya responsiva layouten. Om du arbetar med något liknande kan dessa verktyg för prototypframtagning av responsiv design hjälpa dig att testa och iterera layouter innan de publiceras.

För varje migrerad sida aktiverades den responsiva funktionsflaggan först för en liten grupp användare, med möjlighet att lämna feedback.

Efter några dagar gjordes den responsiva sidan sedan tillgänglig för alla användare. Detta upprepades tills hela webbplatsen var responsiv. 

Därefter bytte vi ut mobilwebbplatsen mot den nya responsiva webbplatsen. Störningarna för skrivbordsanvändarna var minimala eftersom vi hade övergått till de nya sidorna stegvis. 

Störningarna för mobilanvändarna var små eftersom vi inte hade särskilt många mobilanvändare vid den tiden (den gamla mobilwebbplatsen var trots allt inte särskilt bra!). 

Flagga för ny varumärkesprofil på den responsiva webbplatsen

Efter lanseringen av den responsiva webbplatsen gjorde funktionsflaggan för den nya varumärkesprofilen det möjligt för oss att växla hela webbplatsen mellan den gamla och den nya varumärkesprofilen.

Utvecklarna implementerade en knapp på webbplatsen för att växla varumärkesprofil per användare, vilket gjorde det möjligt för designers, QA och även mig som produktchef att se utvecklingen.

De omdesignade sidorna lanserades kontinuerligt, men i produktionsmiljön förblev den här flaggan avstängd så att ingen användare såg några sidor med den nya varumärkesprofilen.

När alla sidor var klara lade vi till en knapp på webbplatsen som gjorde det möjligt för användare att välja en offentlig förhandsvisning av den nya varumärkesprofilen. Den här knappen aktiverade den nya varumärkesprofilen för användaren. Användarna kunde ge oss feedback och efter en vecka aktiverade vi varumärkesprofilen för alla. 

Hela processen var helt problemfri, både för utvecklingsteamet och våra kunder. Det var ett utmärkt exempel på hur man kan använda funktionsflaggor för att minska riskerna vid en större omdesign av webbplatsen. 

Om du är intresserad av att förstå mer i detalj vad vi gjorde kan du läsa en artikel om Soulmates omdesignprojekt på Guardians ingenjörsblogg.

Avslutande tankar

Få det ursprungliga ramverket rätt, så kommer du att upptäcka att användningen av funktionsflaggor kan öka flexibiliteten och effektiviteten i din produkt avsevärt.

Du bör också överväga att använda funktionsflaggor för större initiativ för att minimera riskerna, samt ha en plan för versionshantering för att säkerställa en smidig utrullning. Du kan också använda AI inom versionshantering för att skapa denna plan. Den enda begränsningen för användningen av funktionsflaggor är din fantasi!

Berätta för oss om några smarta sätt som du har använt funktionsflaggor i din produkt i kommentarerna. 

Om du vill ha fler tips och knep för att förbättra dina färdigheter inom produktledning kan du prenumerera på vårt nyhetsbrev.

Få hjälp av en annan produktchef i ditt team med den här användbara guiden: Så skapar du en effektiv arbetsbeskrivning för en agil produktchef (+ exempel)

Också värt att läsa: