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.

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 |
|---|---|---|
| Vänta på oberoende godkännande efter inskickning | Eget godkännande nekas; bara den tillåtna andra personen kan godkänna |
| 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
Läs vidare
Alla artiklar



Mjukvaruutveckling med ASES
Skräddarsydd programvara, webb- och mobilappar



