Come gestisci le richieste di funzionalità e le modifiche al software? [chiuso]

Ciò di cui abbiamo finito per venire a conoscenza del fatto che ora avremmo riunioni bimestrali di vendita / ingegneria per discutere dei progetti attuali e delle richieste di funzionalità imminenti o future. I tecnici di vendita diventeranno project manager e almeno saranno in sintonia con le ultime offerte di prodotti. In passato era semplicemente facile passarlo a Engineering e non pensarci più. Questo probabilmente ridurrà il carico che un ingegnere del software deve fare e metterà onere sulle vendite e sulla gestione per usare il nostro tempo con saggezza.

Ho scoperto che più un cliente si lamenta di quanto sia urgente la sua richiesta, a meno che non sia anche uno sviluppatore di per sé, di solito è un buon segno che la richiesta non è affatto urgente. Uno dei miei professori al college ci diceva sempre di non lasciare che l'urgente interrompesse l'importante.

Di solito classifico le richieste in questo ordine (YMMV):

1. Problemi relativi a un recente aggiornamento o migrazione (la più importante).
2. Correzioni di sicurezza.
3. Funzionalità danneggiata del sistema esistente.
4. Funzionalità interrotte nelle funzionalità RC e beta.
5. Richieste di funzionalità a pagamento.
6. Richieste di funzioni di R & D da gran parte della base di utenti.
7. Richieste di funzioni di R & D solo da uno o due utenti.

Quest'ultima richiede molto più tempo perché tendono ad essere quelle richieste "urgenti, di cui ho bisogno ieri". In realtà, l'utente ha raramente pensato completamente a ciò di cui ha effettivamente bisogno o in che modo supporterà il proprio modello di business. Molto spesso queste richieste urgenti, una volta consegnate, finiscono per essere usate una o due volte e dimenticate. E una volta dimenticati, diventano un mal di testa senza fine di buchi di sicurezza e conseguenze non intenzionali.

Mi piacciono i principi di :

1. QI - Importante e urgente
2. QII - Importante ma non urgente
3. QIII - Non importante ma urgente
4. QIV - Non importante e non urgente

1. Configura un sistema di tracciamento di funzionalità / bug / richieste e chiedi ai tuoi clienti / colleghi file di file. Se non presentano un biglietto per questo, non lo stai facendo. I ticket devono essere sufficientemente dettagliati per essere perseguibili e devono specificare un "urgenza" ("Ne ho bisogno ora" vs. "bello avere").
2. Passa attraverso i nuovi ticket e attentamente li spazia. Inserisci il costo nel biglietto in dollari, sviluppatori, risorse e / o tempo. Questo è essenziale . Quando i tuoi clienti vedono cosa costerebbe veramente , vedrai scelte molto diverse nel campo "urgenza".
3. Ogni giorno, calcola il tuo programma in base ai ticket registrati e amp; la loro urgenza. Rendi il programma visibile agli altri, quindi è ovvio che cosa stai facendo e la tua disponibilità per le richieste future.

Ho visto progetti in cui le modifiche ai requisiti sono gestite da un sistema di controllo delle modifiche molto pesante. Questo non va bene. Molti importanti cambiamenti non avvengono perché il cliente non vuole passare attraverso la seccatura di inviare un controllo delle modifiche, quindi il software non soddisfa le loro esigenze. Alcune piccole modifiche vengono inserite "sotto il radar" per evitare il processo, quindi il software non corrisponde nemmeno a quello che pensi che faccia.

Al contrario, ho visto anche progetti in cui il project manager pensa "reattivo" significa far sì che i programmatori rispondano ad ogni richiesta da parte degli utenti, il che significa che non si ottiene mai alcuno sviluppo di base e il codice diventa un grosso pasticcio ingombrante di hack in cima a mod. Essenzialmente ora non hai nessuno sviluppatore, hai un team di tecnici di vendita sovraqualificati.

Quindi si potrebbe sperare che ci sia una situazione tra questi due poli che funziona bene, e mi aspetto che ciò che funziona meglio per voi sia una scelta personale e situata. C'è sicuramente valore nel catturare il costo di ogni cambiamento. In un framework come Scrum puoi esprimere il costo nei punti storia, e il team può scambiare il lavoro che fanno in ogni iterazione rispetto allo sforzo totale disponibile. Se si dispone di un product manager, è possibile ottenere quella persona per quantificare il beneficio atteso di una richiesta di modifica o di funzionalità. Questo di solito viene fatto in termini di entrate protette (quanti clienti lascerebbero se non lo facessi) e ricavi attratti (quanti clienti arriveranno se lo farai). Ciò può aiutare con la definizione delle priorità, ma può anche solo riflettere la preferenza o le preferenze personali del product manager.

Ecco alcuni pensieri ...

C'è un sacco di software sul mercato che ti aiuta, link con Fogbugz, GeneXus USA con XPM link , ecc.

È come un'arte per bilanciare nuove richieste di funzionalità con correzioni di bug e con le proprie idee. Devi avere cibo per il prossimo inverno, ma devi mangiare anche oggi.

Hai tempo, risorse e obiettivi, fai del tuo meglio.

Anche Henry Ford, una volta famoso, disse: "Se avessi ascoltato i clienti, avrei dato loro un cavallo più veloce" ...

Personalmente: sii dinamico, non mettere regole come quelle che hai detto ... e stai attento alle regole degli altri ... potrebbero funzionare bene nel loro contesto, ma non nel tuo.

L'azienda per cui lavoro utilizza due applicazioni principali, uno strumento basato sul Web chiamato JIRA per gestire gli aspetti relativi al progetto e il nostro sistema di help desk per gestire la richiesta di modifica tramite la sua funzionalità rfc

Le risposte che vedo finora sono buone. Una cosa che specificherò esplicitamente è che dovrai essere bravo a dire "No" ad alcune richieste.

Se si consente al cliente di impostare l'urgenza, sarà quasi sempre "Alto" (o superiore).

Tu (o tu stesso, o una squadra, a seconda della tua configurazione) dovrai valutare queste richieste e stabilire la priorità in base ai tuoi criteri.