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

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

Abbiamo una situazione simile. Il modo in cui gestiamo è la costruzione di una relazione basata sulla fiducia che ci dà la possibilità di dire "non ne hai bisogno". Ci vuole tempo, pazienza e devi essere preparato a parlare molto e fare pranzi e altri compiti noiosi. Queste riunioni noiose si ripagheranno a lungo termine dove è possibile concentrarsi 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 veramente bisogno?" discussione con i clienti. Personalmente, vorrei chiedere: "In che modo questo renderà la tua azienda più denaro?" ma il fatto è che alcuni manager, per qualche ragione, vogliono rintracciarlo e sono abituati a fare a modo loro. Se non vuoi farlo, dì di no o carica una quantità così grande di denaro per scoraggiare la richiesta.

Inizia a valutare come rendere più semplice alla tua applicazione la gestione di un numero maggiore di campi cliente.

1. Consenti alle etichette nei report e nei moduli di essere impostate dal cliente per utilizzare i campi esistenti.
2. Aggiungi campi generici (String12) a tabelle di campi personalizzati esistenti o aggiuntivi.
3. Avere un sistema di campo definito dall'utente dove tutto questo è gestito dall'immissione di dati e non dover creare nuove colonne nelle tabelle (non riesco a ricordare come si chiama-help.).

Potresti scoprire che i clienti esistenti stanno espandendo il tuo sistema. L'industria potrebbe cambiare così nuovi requisiti stanno spuntando.

Ci dispiace, ma se non puoi offrire ai tuoi clienti ciò che vogliono puramente per motivi tecnici e non di profitto, devi aumentare il ritmo. Non sarebbe difficile per un nuovo arrivato entrare nel tuo mercato con più campi, quindi non lasciare che ciò accada.

Guardando dall'altra parte della finestra per un momento, nel mio ultimo lavoro sono stato esposto a un sistema ERP che consentiva l'aggiunta di colonne "personalizzate" dall'utente finale a qualsiasi entità / tabella. Dalle mie brevi interazioni con esso, sembrava che stessero aggiungendo dinamicamente le colonne a una seconda tabella con un mapping one-to-one. Ad esempio:

Tabella WIDGET con colonne statiche:

• WIDGET_ID
• WIDGET_NAME
• WIDGET_COST
• ecc.

Tabella WIDGETCUSTOM con colonne definibili dall'utente:

• WIDGET_ID
• WIDGET_WEIGHT
• DID_BOB_WORK_ON_WIDGET
• ecc.

La colonna WIDGET_ID potrebbe legarli insieme. Mostrava automaticamente i campi extra quando stavi modificando un widget, e potevi includerli in report dinamici, o anche cercare da loro. 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 logica principale.

Le "richieste" di funzionalità sono proprio questo, le richieste. Se stanno facendo richieste allora è necessario decidere quanto vale la pena per la società "ingombrare" il codice base con quello. Se diventa un problema endemico, puoi bloccarlo, ma se sono disposti a pagare quello che stai chiedendo o qualcosa di simile ad esso e sono solo alcune caratteristiche qua e là, dico 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 parti della tua app e renderle flessibili in modo che i clienti abbiano il potere per farlo da soli, sia che si tratti di rapporti ad hoc, di raccolta dati flessibile, ecc. Cerca di trasformare questi fastidi in un punto vendita. "Il nostro modello di dati sulle scorte non è abbastanza buono per te? Consulta le nostre opzioni di personalizzazione! Puoi farlo da solo!"

Dovresti specificare esattamente cosa stai per fare in detta funzione e applicare un tempo stimato per costruirlo. Se il cliente desidera campi aggiuntivi che vanno bene, fatturarli per questo. Dico ai miei clienti che, se si desidera aggiungere funzionalità dopo aver sviluppato la funzione, va bene, ma in alcuni casi ci vorrà un po 'di più per lavorarci.

Ho difficoltà a capire perché ti importa se lo usano o no. È semplice, costruisci quello che vogliono e ti viene pagato per questo.

Ingombro di base del codice? Se hai bisogno di rifattorizzare il tuo codice quando lavori nella nuova funzione, addebitalo per esso.

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

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

Sembra che tu possa trarre beneficio da una sorta di sistema pull. Lascia che l'utente scelga quali funzionalità vengono implementate 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 scelta dei termini (ovvero meno responsabilità e stress per te). Fidati di me, se l'utente è costretto a decidere quale funzione sarà messa in sviluppo, sapendo che le altre richieste saranno messe da parte, investiranno molto di più nel decidere davvero cosa devono avere.

Penso che dovresti chiedere al tuo cliente di mettere uno o più di voi attraverso una "giornata in ufficio" per vedere come usano davvero il software ... Aspettate ... Assumetemi per $ 250 / ora e andrò scoprire. Inoltre, per favore, si prega di non goldplate. Falla funzionare. La maggior parte delle aziende non si preoccupa che sembri brutta quando funziona bene.

Tieni traccia delle richieste. Quando inizi a progettare / sviluppare le grandi caratteristiche, 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 di bug o di funzionalità, come fogbugz. Consenti ai tuoi clienti di effettuare una richiesta e assegna la priorità in base a:

• la fattibilità tecnica / costo della funzione
• la funzione richiede uno "per pagare"? Se è in un contratto, e / o lo hanno pagato, mettilo in
• la funzionalità "ha senso"? Questo è un po 'un'arte, ma, in generale, se un numero sufficiente di clienti richiede una funzionalità, implementarla gratuitamente. È un'opportunità per migliorare il tuo prodotto e rendere più facile la vendita al prossimo cliente
• hai a disposizione cicli a pagamento non utilizzati? Se includi una serie di ore mensili per la manutenzione / supporto come parte dei tuoi contratti (ti raccomando caldamente di farlo, anche se il numero è molto basso), e non vengono abituati, inizia a lanciarli a fare questo tipo di cambiamenti

Se il cliente ha la proprietà totale dell'applicazione, quindi fare ciò che chiedono. Lascia che facciano saltare i loro soldi; è loro.

Tuttavia, se non lo fai, allora vuoi andare a una soluzione per questi campi ausiliari che coinvolge la memorizzazione al di fuori del core datamodel 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 memorizzati: la più semplice è solo una tabella che ha la stessa chiave primaria di alcuni PK nella tabella principale, ma che è inefficiente quando si usa del campo è molto scarso, è veramente un problema quando vogliono caratteristiche 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 punti alla tua roadmap che dice (la tua migliore stima) quando diventerà possibile implementare ciò che vogliono a poco prezzo. E tu dovresti dare la priorità all'ottenere l'applicazione in uno stato in cui diventa possibile supportare le funzionalità a basso costo, in quanto tale meta-funzionalità diventa una caratteristica di vendita principale della tua applicazione principale.