Come gestire il tipo di richieste "puoi aggiungere solo qualche altro campo" da parte dei clienti?

Molto comunemente abbiamo richieste di funzionalità per campi che solo un cliente desidera. Questo, nella migliore delle ipotesi, ingombra il codice dell'applicazione. Spesso quando guardiamo nel loro database qualche mese dopo aver aggiunto i campi, possiamo vedere che in realtà non stanno nemmeno usando i campi extra. Inoltre, è un'applicazione piuttosto vecchia, quindi l'aggiunta di un singolo campo richiede più modifiche al codice, la modifica dei report e la verifica che non influisca su altri clienti che non devono vedere il campo.

• Come possiamo assicurarci che un cliente abbia effettivamente bisogno di queste richieste di funzionalità?

• Come possiamo educatamente dire "non ne hai davvero bisogno"?

Attualmente stiamo iniziando a addebitare determinate richieste di funzionalità. (In precedenza, le richieste di funzionalità erano generalmente gratuite) C'è qualcos'altro che possiamo fare?

Stanno pagando per le funzionalità aggiuntive? In tal caso, non è davvero il tuo business se li stanno usando o meno. Dai loro quello per cui pagano. Se, tuttavia, non è così, spetta alla tua direzione decidere se sono disposti a continuare ad aggiungere funzionalità senza entrate aggiuntive.

Abbiamo una situazione simile. Il modo in cui gestiamo sta costruendo una relazione basata sulla fiducia che ci dà la libertà di dire "non hai bisogno di questo". Ci vuole tempo, pazienza e devi essere preparato a parlare molto e pranzare e altri compiti noiosi. Questi incontri noiosi si ripagheranno da soli a lungo termine, dove puoi concentrarti sulla creazione di funzionalità davvero importanti.

Parlare ti farà anche vedere se quello che stanno chiedendo è davvero così importante.

Non penso che tu possa entrare nel "ne hai davvero bisogno?" discussione con i clienti. Personalmente, vorrei chiedere: "In che modo questo renderà la tua azienda più soldi?" ma il fatto è che alcuni manager, per qualche motivo, vogliono rintracciarlo e sono abituati a farsi strada. Se non si desidera farlo, dire di no o addebitare un importo così elevato di denaro per scoraggiare la richiesta.

Inizia a considerare modi per rendere più semplice per la tua applicazione la gestione di un numero maggiore di campi cliente.

1. Consentire al cliente di impostare etichette nei report e nei moduli per utilizzare i campi esistenti.
2. Aggiungi campi generici (String12) a tabelle di campi personalizzate esistenti o aggiuntive.
3. Avere un sistema di campo definito dall'utente in cui tutto ciò è gestito dall'inserimento dei dati e non è necessario creare nuove colonne nelle tabelle (non ricordo cosa si chiama aiuto).

È possibile che i clienti esistenti stiano espandendo il sistema. L'industria potrebbe cambiare, quindi stanno emergendo nuove esigenze.

Siamo spiacenti, ma se non puoi offrire ai tuoi clienti ciò che desiderano solo per motivi tecnici e non di profitto, devi accelerare. Non sarebbe difficile per un nuovo arrivato entrare nel tuo mercato con più campi, quindi non lasciare che ciò accada.

Guardando dall'altro lato della finestra per un momento, nel mio ultimo lavoro sono stato esposto a un sistema ERP che permetteva all'utente finale di aggiungere colonne "personalizzate" a qualsiasi entità / tabella. Dalle mie brevi interazioni con esso, sembrava che stessero aggiungendo dinamicamente le colonne a una seconda tabella con un mapping uno a uno. Per esempio:

Tabella WIDGET con colonne statiche:

• WIDGET_ID
• WIDGET_NAME
• WIDGET_COST
• eccetera.

Tabella WIDGETCUSTOM con colonne definibili dall'utente:

• WIDGET_ID
• WIDGET_WEIGHT
• DID_BOB_WORK_ON_WIDGET
• eccetera.

La colonna WIDGET_ID potrebbe collegarli insieme. Mostrava automaticamente i tuoi campi extra quando stavi modificando un widget e potresti includerli in report dinamici o persino cercarli. Era abbastanza efficiente perché il database poteva ancora tenerne traccia e indicizzare quelle colonne se necessario, ecc.

Da un punto di vista della programmazione, vedo come ciò lo manterrebbe sano di mente. Ogni cliente può avere le proprie colonne personalizzate, ma quelle colonne personalizzate non interferiscono con la tua logica principale.

Le "richieste" di funzionalità sono proprio questo, richieste. Se stanno facendo richieste, allora devi decidere quanto vale per la società "ingombrare" la base di codice con quello. Se diventa un problema endemico, allora puoi reprimerlo, ma se sono disposti a pagare quello che stai chiedendo o qualcosa di simile ad esso ed è solo alcune funzionalità qua e là, dico di andare con i soldi.

Per andare ancora oltre, se questo è un problema costante con il tuo prodotto e più clienti sono alla ricerca di questo tipo di personalizzazioni, forse è il momento di ripensare queste porzioni della tua app e renderle flessibili in modo che i clienti abbiano il potere di farlo stessi, che si tratti di rapporti ad hoc, raccolta flessibile di dati, ecc. Cerca di trasformare questi fastidi in un punto di vendita. "Il nostro modello di dati di borsa non è abbastanza buono per te? Dai un'occhiata alle nostre opzioni di personalizzazione! Puoi farlo da solo!"

Dovresti specificare esattamente cosa farai in questa funzione e applicare un tempo stimato per costruirlo. Se il cliente desidera ulteriori campi che vanno bene, fatturarli. Dico ai miei clienti che se vuoi aggiungere funzionalità dopo che ho creato la funzionalità, va bene, ma in alcuni casi avrà un costo in più per lavorarci.

Sto facendo fatica a capire perché ti importa se lo usano o no. È semplice, costruisci quello che vogliono e vieni pagato per questo.

Disordine di base di codice? Se devi refactificare il tuo codice quando lavori con la nuova funzionalità, addebitali.

Crea un elenco di diverse funzionalità che pensi di aggiungere, inclusa l'aggiunta di "solo alcuni campi extra". Mostra l'elenco ai tuoi clienti e chiedi loro un feedback su quelli che vorrebbero per primi. Spiega che le tue risorse sono limitate e che non puoi farlo tutto in una volta. Usa il feedback per decidere quale direzione vuoi seguire con la tua applicazione.

Se un cliente insiste sul fatto che i pochi campi extra sono davvero così importanti e tu decidi ancora di non aggiungerli, si spera che il cliente possa comunque vedere il vantaggio delle funzionalità che stai implementando.

Sembra che potresti beneficiare di una sorta di sistema pull. Consenti all'utente di scegliere quale funzione verrà implementata successivamente, ma limita il numero che può essere in fase di sviluppo in qualsiasi momento. Una scheda Kanban è eccezionale per questo. Può dare all'utente la proprietà del processo di priortiztion (ovvero meno responsabilità e stress per te). Fidati di me, se l'utente è costretto a decidere quale funzione verrà messa in sviluppo successivamente, sapendo che le altre richieste verranno messe da parte, investiranno molto di più nel decidere davvero cosa devono avere.

Penso che dovresti chiedere al tuo cliente di passare uno o più di te in una "giornata in ufficio" per vedere come usano davvero il software ... Aspetta ... Assumimi per $ 250 / ora e lo scoprirò. Inoltre, per favore, per favore non dorare. Fallo funzionare. Alla maggior parte delle aziende non importa che appaia brutta quando funziona bene.

Tieni traccia delle richieste. Quando inizi a progettare / sviluppare le grandi funzionalità, scegli una manciata di richieste prioritarie da includere in quella versione.

Costruire un sistema di negoziazione standard per le richieste. Forse qualcosa basato su un sistema di segnalazione bug o di richiesta di funzionalità, come fogbugz. Consenti ai tuoi clienti di effettuare una richiesta e assegnale le priorità in base a:

• fattibilità tecnica / costo della funzionalità
• la richiesta di funzionalità è "a pagamento"? Se è in un contratto e / o se l'hanno pagato, inseriscilo
• la funzione "ha senso"? Questo è un po 'un'arte, ma, in generale, se un numero sufficiente di clienti richiede una funzionalità, la implementa gratuitamente. È un'opportunità per migliorare il tuo prodotto e semplificare la vendita al prossimo cliente
• hai cicli inutilizzati e a pagamento disponibili? Se includi un set di ore mensili per manutenzione / supporto come parte dei tuoi contratti (ti consiglio vivamente di farlo, anche se il numero è molto basso) e non vengono utilizzati, inizia a lanciarli per apportare questo tipo di modifiche

Se il cliente ha la proprietà totale dell'applicazione, fai quello che ti chiede. Lasciateli soffiare i loro soldi; è loro.

Tuttavia, in caso contrario, si desidera andare a una soluzione per questi campi ausiliari che prevede la loro memorizzazione al di fuori del modello di dati principale. È quindi possibile utilizzare qualcosa come una vista del database per unire nuovamente i campi aggiuntivi per questo particolare cliente. (Esistono alcuni modi per eseguire l'archivio ausiliario, a seconda della natura dei dati archiviati; il più semplice è solo una tabella che ha la stessa chiave primaria di alcuni PK nella tabella principale, ma è inefficiente quando l'uso del campo è molto scarso. È veramente un problema solo quando vogliono funzionalità del campo che richiedono cose come l'indicizzazione.)

Puoi anche rimandare le richieste dei clienti dicendo che non hai risorse sufficienti per implementarle in questa fase. Aiuta davvero se a quel punto fai riferimento alla tua tabella di marcia che dice (la tua migliore stima a) quando sarà possibile implementare ciò che vogliono a buon mercato. E dovresti dare la priorità a portare l'applicazione in uno stato in cui diventa possibile supportare le funzionalità a buon mercato, poiché quella meta-caratteristica diventa una caratteristica di vendita principale della tua applicazione principale.