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

Sono un ingegnere del software e negli ultimi anni sono diventato il project manager del software di fatto semplicemente perché non ce n'è uno. Quindi, per mantenere la nostra sanità mentale nel reparto R & S / Engineering, i clienti si sono abituati a venire da me con le loro richieste. Non ho esperienza in questo ambito, quindi è la prima volta che lavoro come project manager per progetti software. Ho gestito altre cose ma non il software.

Quindi, come gestite i progetti software e segnate le priorità? Le richieste arrivano a intervalli rari, quindi potremmo davvero lavorare su qualcosa per qualcun altro e poi un'altra persona arriva con un lavoro "urgente" su cui bisogna lavorare. È più semplice dire First Come, First Serve o è la persona con più soldi?

Ho scoperto che più un cliente si lamenta dell'urgenza della sua richiesta, a meno che non sia anche uno sviluppatore a sé stante, 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.

In genere classifico le richieste in questo ordine (YMMV):

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

Quest'ultimo in realtà richiede molto più tempo perché tendono ad essere quelle richieste "urgenti, ne ho bisogno ieri". In realtà, l'utente raramente ha riflettuto completamente su ciò di cui ha effettivamente bisogno o su come supporterà il proprio modello di business. Molto spesso, queste richieste urgenti, una volta consegnate, finiscono per essere utilizzate una o due volte e dimenticate. E una volta dimenticati, diventano un infinito mal di testa di falle nella sicurezza e conseguenze indesiderate.

Mi piacciono i principi:

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. Imposta un sistema di tracciamento funzionalità / bug / richiesta e fai in modo che i tuoi clienti / colleghi archivino i ticket. Se non presentano un ticket, non lo stai facendo. I biglietti devono essere sufficientemente dettagliati per essere utilizzabili e devono specificare una "urgenza" ("Ne ho bisogno ora" vs. "bello avere").
2. Passa attraverso nuovi biglietti e cercali attentamente . Inserisci il costo nel biglietto in dollari, sviluppatori, risorse e / o tempo. Questo è essenziale . Quando i vostri clienti vedono quello che qualcosa sarà veramente li costerà, vedrete scelte molto diverse nel campo "urgenza".
3. Su base giornaliera, calcola il tuo programma in base ai biglietti archiviati e alla loro urgenza. Rendi il programma visibile agli altri, quindi è ovvio cosa stai facendo e la tua disponibilità per 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. Molte modifiche importanti non accadono perché il cliente non vuole passare attraverso la seccatura di presentare un controllo delle modifiche, quindi il software non soddisfa le sue esigenze. Alcuni piccoli cambiamenti vengono inseriti "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 che "reattivo" significhi far sì che i programmatori rispondano ad ogni richiesta da parte degli utenti, il che significa semplicemente che non si ottiene mai alcun sviluppo di base e il codice diventa un grosso disordine ingombrante di hack in cima mod. Essenzialmente ora non hai sviluppatori, hai un team di tecnici di vendita sovraqualificati.

Quindi si potrebbe sperare che ci sia una situazione tra questi due poli che funzioni bene, e mi aspetto che ciò che funziona meglio per te sia sia una scelta personale che situata. C'è sicuramente valore nel catturare il costo di ogni modifica. In un framework come Scrum puoi esprimere il costo in punti trama e il team può scambiare il lavoro che svolgono in ogni iterazione rispetto allo sforzo totale disponibile. Se hai un product manager puoi convincere quella persona a quantificare il beneficio atteso da una richiesta di modifica o funzionalità. Questo di solito viene fatto in termini di entrate protette (quanti clienti lascerebbero se non lo facessi) e di entrate attratte (quanti clienti arriveranno se lo fai). Questo può aiutare con la definizione delle priorità, ma può anche solo riflettere la propensione o la preferenza personale del product manager.

Ecco alcuni pensieri ...

Esistono molti software sul mercato che ti aiutano, http://www.fogcreek.com/ con Fogbugz, GeneXus USA con XPM http://www.genexususa.com/xpm , ecc.

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

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

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

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

Ciò che abbiamo concluso è che avremmo ora incontri di vendita / ingegneria bimestrali per discutere i progetti attuali e le richieste di funzionalità future o future. Gli ingegneri delle vendite diventeranno project manager e almeno saranno in sintonia con le ultime offerte di prodotti. In passato è stato semplice trasmetterlo a Engineering e dimenticarsene. Ciò probabilmente ridurrà il carico che un ingegnere del software deve fare e darà il via alle vendite e alla gestione per usare saggiamente il nostro tempo.

La società 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 spiegherò espressamente è che dovrai essere bravo a dire "No" ad alcune richieste.

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

Tu (o tu stesso, o un team, a seconda della configurazione) dovrai valutare queste richieste e assegnarle le priorità in base ai tuoi criteri.