Il primo grande cliente rivela i confini del prodotto SaaS
Un esempio ipotetico di approvazione aggiuntiva degli ordini collega varianti cliente, manutenzione comune e ambito del prodotto.
Un cliente aziendale richiede un’approvazione aggiuntiva, mentre gli altri usano il flusso esistente. Per il gruppo SaaS emerge una decisione di prodotto: questa variante rientra nell’offerta comune e come può restarvi manutenibile?
L’esempio seguente è interamente ipotetico. Non descrive una funzione realmente commissionata né un risultato di progetto misurato.
Descrivere la variante con una regola ricostruibile
Supponiamo che il prodotto elabori ordini per le aziende C10 e C20. Il nuovo cliente richiede l’approvazione di un’altra persona autorizzata. Chi inserisce l’ordine non può approvarlo personalmente. L’altro cliente deve mantenere il percorso attuale.
Azienda | Flusso richiesto | Verifica attesa in un aggiornamento comune |
|---|---|---|
| Attendere un’approvazione indipendente dopo l’invio | L’autoapprovazione viene negata; solo l’altra persona autorizzata può approvare |
| Elaborare l’ordine senza approvazione aggiuntiva | Il flusso attuale continua senza ricevere l’obbligo di approvazione dell’altro cliente |
La possibilità di gestire sensatamente la variante con un’impostazione cliente dipende dal modello di prodotto. Nell’esempio sarebbe verificabile: regola, ambito e comportamento atteso per entrambi i clienti sono definiti.
La soluzione particolare ha anche un futuro
Una copia del codice pensata solo per un cliente richiederà comunque correzioni, test e aggiornamenti. Esamineremmo quindi prima se il requisito sia sostenibile come variante ben delimitata del prodotto comune. È una raccomandazione condizionata, non l’obbligo di trasformare ogni eccezione in un’impostazione.
Se il cliente richiede un processo radicalmente diverso con manutenzione e assistenza proprie, una soluzione separata può essere una scelta consapevole. Ambito e responsabilità devono allora essere concordati esplicitamente. Risorse dedicate o distribuzioni separate non richiedono automaticamente un’altra base di codice prodotto.
Distinguere funzione, diritto al servizio e accesso ai dati
Un feature flag può aiutare durante un’introduzione limitata nel tempo. Un diritto al servizio concordato in modo permanente richiede invece gestione e applicazione adeguate. Nemmeno attivare una funzione sostituisce la verifica di chi possa approvare per quale azienda.
Nell’esempio, un aggiornamento dovrebbe verificare la variante di approvazione e il flusso invariato. Contano la regola di prodotto ricostruibile e l’impegno di manutenzione; la prima richiesta cliente non determina da sola l’architettura.
Fonti
Scritto da
- Katharina WeberRedattrice per software e tecnologiaKatharina Weber cura per ASES gli articoli sullo sviluppo software. Scrive delle questioni che le aziende affrontano nella scelta del software, nello sviluppo di nuove applicazioni e nella modernizzazione dei sistemi esistenti.
Continuate a leggere
Tutti gli articoli
Sviluppo software con ASES
Software su misura, app web e mobile