Come gestire un singolo prodotto software per più clienti?

Nella mia esperienza, le modifiche richieste dai clienti rientrano in una delle 4 categorie:

1. Modifiche che gli altri clienti troveranno utili ma il cliente "iniziale" è disposto a pagare.
2. Cambiamenti che gli altri clienti troveranno utili ma il cliente "iniziale" non è disposto a pagare.
3. Cambiamenti che gli altri clienti non troveranno utili ma il cliente "iniziale" è disposto a pagare per
4. Modifiche che gli altri clienti non troveranno utili ma il cliente "iniziale" non è disposto a pagare.

Per 1, apporta le modifiche al prodotto principale e rilascia una versione aggiornata a tutti i tuoi clienti (vieni pagato per svilupparlo e il progresso andrà avanti).

Per 2, prendi una decisione aziendale se la modifica è abbastanza valida da generare ulteriori vendite per renderla utile, se è così, apporta le modifiche al prodotto principale.

Per 3, crea una sorta di sistema di plugin in cui puoi creare un componente aggiuntivo personalizzato per clienti specifici.

Per 4, mi raccomando di non farlo affatto.

Fondamentalmente ci sono due modi per affrontare questo:

1. Avere un singolo prodotto che può essere personalizzato principalmente tramite la configurazione per soddisfare i requisiti di un singolo cliente
2. Costruisci un prodotto per ogni client basato su un framework standard e un set di base comune di librerie.

Il problema con il primo è quello di riconciliare i requisiti in conflitto tra clienti diversi, il problema con quest'ultimo è che ora stai supportando un prodotto per client e che le cose andranno alla deriva nel tempo. In entrambi i casi si desidera disporre di meccanismi per la gestione dei dati di configurazione specifici per ciascun client.

Il mio punto di vista personale è che (senza molti più dettagli) è quasi certamente meglio affrontare una singola applicazione - certamente ho avuto un discreto successo con i pulsanti di attivazione di un'applicazione multi-client, ma tenere traccia è stato impegnativo.

Guardando il tuo set di strumenti, c'è un ragionevole supporto per Temi all'interno di ASP.NET e un sacco di possibilità per i sistemi plug-in - ma dovresti cercare di aggiornare i tuoi strumenti e soprattutto ottenere un sistema di controllo di versione più affidabile / più capace.

In tale applicazione sarebbe saggio separare il codice in parti generiche (driver di database, libreria di widget) e una parte di configurazione che descrive l'implementazione specifica di tali parti generiche. Mi piacerebbe mantenere la parte dinamica il più piccola possibile e riutilizzare il più possibile. Ogni cliente avrebbe una parte generica comune e una parte di configurazione personalizzata. Se sono necessarie modifiche all'infrastruttura di base, queste modifiche possono essere applicate anche agli altri clienti.

In pratica, puoi dividere il software in due repository, uno per la parte generica e uno per la parte di configurazione, quest'ultima unica per ciascun cliente.

Questa è una delle volte in cui si desidera visualizzare le opzioni configurabili. So che questo è un anti-pattern per alcuni casi, ma non in questo caso.

Ciò che è necessario identificare sono le aree che i clienti stanno cercando per la personalizzazione. Crea quei punti in cui dividi i file di configurazione o inserisci valori in una configurazione db.

Non esagerare, cerca di tenere sotto controllo il team di vendita con ciò che puoi e non puoi personalizzare. Ho visto anche questo e diventa molto caotico molto veloce.

Se questi tipi di configurazioni non sono possibili, cerca di creare interfacce per servizi o librerie che contengono il codice comune tra tutti i client e il codice che è univoco. Anche in questo caso il team di vendita deve sapere dove sono queste linee e quanto costosa sarà la creazione di ogni personalizzazione.

Ho trovato un podcast che parla di questi problemi . Forse questo ti sarà utile da ascoltare.

In this episode Michael interviews one of our regular listeners: Petri Ahonen. Petri introduces Software Configuration Management by defining key terms and describing relevant concepts