Passaggio da uno sviluppo su misura a una casa di sviluppo COTS

Alcuni importanti cambiamenti organizzativi e architettonici dovrebbero essere implementati per avere successo nello sviluppo di un prodotto comune che soddisfi tutte le esigenze specifiche dei tuoi clienti.

Dal punto di vista organizzativo è necessario passare dall'erogazione diretta delle richieste dei clienti a una situazione in cui il team di sviluppo consegna richieste al proprietario del prodotto all'interno dell'azienda. Una volta fatto questo, il team di sviluppo non lavora più per i clienti dell'azienda, l'unico cliente che dovrebbe interessare al team di sviluppo è il proprietario del prodotto nella TUA azienda.

Il proprietario del prodotto dovrà raccogliere i requisiti dei clienti più stretti e determinare un insieme comune di requisiti che renderà felice la maggior parte di loro. Il team di sviluppo deve solo preoccuparsi di rendere felice il proprietario del prodotto.

Architettonicamente aiuta quando si progetta un prodotto che ha una vasta gamma di esigenze del cliente per renderlo configurabile, estensibile, disaccoppiato, scalabile e componentizzato come logicamente possibile.

Alcuni buoni approcci in questo senso consistono nel prendere i diversi pool di requisiti e scoprire quali pezzi sono comuni a tutti loro. Questi requisiti comuni costituiranno il nucleo del tuo set di funzionalità. Tutto ciò che è leggermente diverso dal core può essere determinato come una caratteristica configurabile, impostazione, o forse un'intera caratteristica unica che è separata dal nucleo. Rendi queste funzionalità separate quanto più possibile componenti e specificane bene.

I tuoi clienti possono esaminare diverse funzionalità che sono attualmente disabilitate per la loro installazione di un prodotto e potrebbero rendersi conto che potrebbero effettivamente volere quella funzione.

Infine, cerca di essere un "Progettista difensivo" senza violare il principio YAGNI. Questa può essere una linea sottile da attraversare, ma è una possibilità molto reale che certi presupposti architettonici e di progettazione possano farti sviluppare in un angolo, causando la necessità di un importante refactoring in una versione futura. Le ipotesi sono CRITICAMENTE importanti e dovrebbero essere strettamente dettagliate e scrutinate nelle specifiche tecniche. Un'assunzione errata può costarti caro dopo. Un buon modo sarebbe: "So che i clienti sono abbastanza sicuri che vorrebbero che questo componente funzionasse in questo modo specifico, ma nel caso, sto lasciando aperta l'opzione che questo POTREBBE cambiare in futuro senza causare la necessità di un importante rinnovamento. " A volte questo è semplice quanto la componentizzazione e il disaccoppiamento corretti, altre volte confina con possibilità di sviluppo di funzionalità che non sono state richieste. Devi fare quel giudizio per la tua situazione.

Dato che avrai più client, il tuo processo di build / test / deploy dovrà essere più robusto. Se hai già solide pratiche ingegneristiche, allora dovrebbe essere fattibile, anche se sarà ancora una transizione. Ma questa è la parte facile ...

Con un solo cliente ora, la parte della tua azienda rivolta al cliente è semplice. Tuttavia con molti clienti, dovrai essere in grado di gestirli tutti in modo indipendente. Avrai bisogno di un help desk, possibilmente di un tracker di problemi pubblici, ecc. (C'è un motivo per cui le grandi aziende hanno "supportato" ingegneri sul personale, questo è un lavoro a tempo pieno.)

Dal punto di vista commerciale, è necessario aumentare le vendite e il marketing. Dovrai coltivare nuovi lead di vendita e monitorare la soddisfazione dei clienti esistenti. Quindi, se vuoi crescere abbastanza, questo potrebbe voler dire usare CRM o altre soluzioni automatizzate. Dovrai anche "diffondere la voce" sul tuo prodotto, che può avvenire tramite pubbliche relazioni, pubblicità, conferenze tecniche, ecc.

Quindi il tuo processo per costruire il prodotto dovrà diventare più "professionale", sì. Ma è vendere il prodotto che sarà la parte difficile. Buona fortuna!

Uno dei maggiori problemi che devi affrontare è la personalizzazione. Dal momento che potresti non rispondere più alle singole richieste ma piuttosto apportare modifiche a un prodotto che serve molti, devi decidere come gestire la necessità di alcuni dei tuoi clienti (in particolare il tuo cliente iniziale che è abituato a richiedere soluzioni personalizzate) per l'abitudine informazioni.

Dovrai anche imparare a filtrare le richieste di modifica in base a ciò che il prodotto ha bisogno di vizio di quello di cui una società ha bisogno.

Ci sono diversi percorsi da seguire per la personalizzazione e devi decidere quale:

• Non consentire la personalizzazione - perderà alcuni clienti, forse anche il tuo primo e primo cliente
• Crea una tabella EAV nel database relazionale per consentire molte personalizzazione - flessibile ma lenta e difficile da interrogare
• Crea poche colonne non definite nelle tabelle chiave per consentire limitazioni personalizzazione - può funzionare se hai già progettato il 95% che è davvero necessario
• Utilizza un database SQL non per informazioni personalizzate - va bene per le cose che non ha bisogno di integrità transazionale
• Crea istanze separate per cliente e carica un braccio e una gamba per la personalizzazione (soprattutto per i report personalizzati) - può essere molto costoso e difficile da gestire
• Tratta tutte le richieste di personalizzazione come qualcosa che tutti i clienti faranno ottenere o essere offerto come un add on (modularmente sviluppare la personalizzazione così le persone possono scegliere e scegliere quali caratteristiche vogliono) - potrebbe essere in grado gestire la maggior parte dello sviluppo in questo modo, a seconda di come la tua attuale il software è strutturato e cosa fa.

È necessario riflettere attentamente su questi aspetti, poiché la personalizzazione eseguita in modo errato può rendere il software incredibilmente lento o può comportare la necessità di molti più programmatori rispetto alla personalizzazione. Si può anche prendere in considerazione l'utilizzo di diverse di queste tecniche. Tutti hanno vantaggi e svantaggi.