Hoppa till innehållet

Den första stora kunden visar SaaS-produktens gränser

Ett tänkt exempel med extra ordergodkännande kopplar kundvarianter till gemensamt underhåll och produktens omfattning.

Katharina Weber2 min läsning
Grön styrenhet med en rak väg från startsymbol till bock, en romb med frågetecken och en liten omkopplare ovanför.

En företagskund begär ett extra godkännande medan andra kunder använder det befintliga arbetsflödet. Det synliggör ett produktbeslut för SaaS-teamet: hör varianten till det gemensamma erbjudandet, och hur förblir den möjlig att underhålla där?

Följande exempel är helt hypotetiskt. Det beskriver varken en beställd funktion eller ett uppmätt projektresultat.

Beskriv varianten som en regel som går att följa

Anta att produkten behandlar beställningar för företagen C10 och C20. Den nya kunden kräver godkännande av en annan behörig person. Beställaren får inte godkänna sin egen beställning. Den andra kunden ska behålla den tidigare vägen.

Företag

Önskat arbetsflöde

Förväntad kontroll vid en gemensam uppdatering

C10

Vänta på oberoende godkännande efter inskickning

Eget godkännande nekas; bara den tillåtna andra personen kan godkänna

C20

Behandla beställningen utan extra godkännandesteg

Det tidigare flödet fungerar fortsatt utan den andra kundens godkännandekrav

Om en hanterad kundinställning kan bära varianten på ett rimligt sätt beror på produktmodellen. I exemplet är den testbar: regeln, dess omfattning och båda kundernas förväntade beteende är beskrivna.

En särskild lösning har också en framtid

En kodkopia som bara anpassats till ett kundnamn behöver också framtida rättningar, tester och uppdateringar. Vi skulle därför först undersöka om kravet är hållbart som en tydligt avgränsad variant i den gemensamma produkten. Det är en villkorad rekommendation, inget krav på att göra varje undantag till en inställning.

Kräver kunden en grundläggande annan process med eget underhåll och stöd kan en separat lösning vara ett medvetet val. Omfattning och ansvar bör då avtalas uttryckligen. Dedikerade resurser eller separata driftsättningar kräver inte automatiskt en annan produktkodbas.

Skilj funktion, nyttjanderätt och dataåtkomst åt

En feature flag kan hjälpa vid en tidsbegränsad introduktion. En varaktigt avtalad rätt till en tjänst kräver däremot lämplig hantering och tillämpning. En aktiverad funktion ersätter inte heller kontrollen av vem som får godkänna för vilket företag.

I exemplet behöver en uppdatering testa både godkännandevarianten och det oförändrade flödet. Den tydliga produktregeln och underhållsarbetet är avgörande; den första kundbegäran bestämmer inte ensam arkitekturen.

Källor

Skriven av

  • Katharina WeberRedaktör för mjukvara och teknikKatharina Weber ansvarar för artiklarna om mjukvaruutveckling på ASES. Hon skriver om de frågor företag ställs inför när de väljer mjukvara, utvecklar nya applikationer och moderniserar befintliga system.

Följ ASES

Läs vidare

Alla artiklar

Mjukvaruutveckling med ASES

Skräddarsydd programvara, webb- och mobilappar