Ogni uscita, la nostra scia di bug continua ad aumentare. Questi sono bug validi, tuttavia, dobbiamo anche scrivere nuove funzionalità per rimanere nella competizione. Inoltre, quelle funzioni saranno più utilizzate delle correzioni di bug; e fornire un ROI migliore.
In che modo altri ingegneri e proprietari di prodotti gestiscono questa situazione?
A livello tecnico, bug, funzionalità, è lo stesso, una richiesta di modifica. Hai mai deciso di non aggiungere una funzione perché non ne vale la pena? È lo stesso con gli errori. L'unica differenza tra bug e funzionalità è commerciale: la retribuzione "clienti" per le funzionalità, la "società" paga per le correzioni di errori o qualcosa del genere.
Tuttavia, come per le richieste di funzionalità, ogni segnalazione di bug necessita di un ticket di tracciamento delle modifiche. Il biglietto deve essere facile da chiudere quanto aprire. Questo è l'unico modo per acquisire i dati necessari per prendere decisioni.
Le richieste di modifica dovrebbero essere chiuse il più rapidamente possibile. La ragione di questo è che le richieste aperte richiedono tempo per analizzare, intasare il sistema e aggiungere poco valore. Hai bisogno di un modo rapido per decidere che non lo farai e, una volta presa la decisione, chiudi il ticket. Dovresti mirare a non discutere mai se un oggetto dovrebbe essere aperto o chiuso più di una volta. Uno dei più grandi problemi che vedo è la riluttanza delle persone a chiudere un ticket "Non risolverà", quindi lo lasciano aperto. Se non hai il gong per sistemarlo, sii onesto con tutti e basta dire "Non abbiamo intenzione di sistemarlo, superarlo".
Avere priorità e gravità nel biglietto. L'effetto del difetto sul sistema è la sua gravità, le vendite e il marketing impostano la priorità.
Altri suggerimenti: Usa una cifra (diciamo il 20%) dal budget delle richieste di funzionalità / miglioramenti per correggere i bug. (Ad esempio, se faccio 10 giorni aggiungendo funzionalità, faccio 2 giorni per correggere i bug). I bug vengono risolti in ordine di priorità fino a quando il budget è esaurito. Questo aggira l'unità commerciale per lo sviluppo delle sole funzionalità.
Il costo di un difetto è esponenzialmente proporzionale al tempo che intercorre tra l'inserimento del difetto e la correzione (o la decisione di non risolvere) di tale difetto. Per evitare che questi bug esorbitanti costino importi sproporzionati di $ perché non li aggiustano, e rifiuti di chiuderli, i ticket aperti hanno la priorità su base regolare (diciamo 5 livelli di priorità - una volta al mese) e non possono essere abbassati. In questo modo, sarai costretto a occupartene entro diciamo 6-12 mesi.
Dovresti avere un triage e riunioni prioritarie su base regolare.
Al mio precedente incarico avevamo una riunione settimanale consistente in proprietari di prodotti e lead di sviluppo (io). Vorremmo
L'obiettivo era assicurarsi che ci fosse un equilibrio in ciò che abbiamo lavorato. Spiegherei il costo di ignorare alcuni problemi e quanto costerebbero in futuro. Vorrei anche spiegare il costo di sviluppo per ogni cambiamento e offrire alternative quando appropriato. In cambio avrei capito l'importanza di alcune funzionalità per il business. Ciò ha fornito sia me stesso che i product manager con
Una volta stabilito un rapporto, gli incontri sono passati rapidamente con pochi disaccordi.
Mantieni un database con tutti i bug e le segnalazioni di bug e affrontali quando le nuove funzionalità smettono di essere pertinenti, mentre cerchi di focalizzare i bug che si verificano più spesso e con maggiore impatto sul programma.
Leggi altre domande sui tag issue-tracking quality defect