La maggior parte dei tracker di problemi è rivolta agli sviluppatori. Ma quando si lavora in una piccola squadra che include uomini d'affari: ha senso che mettano problemi non-dev all'interno del tracker?
Devo dire che non ho mai sentito parlare di questa combinazione. Nel mio lavoro a tempo pieno, le cose da fare sono da qualche altra parte. Ma in una startup in cui disponi di contanti limitati, perché non investire nello stesso tracker da un giorno all'altro? "
Per me, a patto che ci siano filtri e code appropriati (quindi gli sviluppatori non sono sopraffatti dai biglietti per "chiamare Bob riguardo al nuovo contratto"), la combinazione di questi ha un senso.
Nella mia linea di lavoro (software finanziario per clienti esterni), la maggior parte dei problemi di sviluppo richiederà comunque la priorità dall'azienda. Alla fine della giornata, sono tutti problemi con la relazione con il cliente (il software fa quello che il cliente vuole o c'è un bug? Abbiamo trovato un problema nel codice che renderà il codice meno gestibile e influenza la nostra capacità di mantenere i clienti felici in futuro? il cliente ha bisogno di un nuovo contratto?)
L'approccio combinato può anche aiutare a trovare soluzioni non tecniche ai bug tecnici
perché no. Redmine (ad esempio) viene fornito con 3 tracker pronti all'uso e consente di crearne altri. I 3 sono bug, funzionalità e supporto.
bug è ovvio, ma la funzionalità richiede una cosa per lo sviluppatore, o più un problema di progettazione / gestione? Che cosa di supporto: potrebbe non essere un bug ma un problema di configurazione.
Puoi facilmente aggiungere Requisito alla lista.
Il vantaggio di aggiungere tutti questi allo stesso tracker tool è che puoi collegarli insieme. Immagina che qualcuno crei una richiesta di funzionalità che passa attraverso diverse modifiche attraverso la discussione con architetti o designer. Quando la direzione decide di implementarlo, può essere associato a un tracker "di lavoro" per controllare l'origine e quindi associarlo a un tracker "di prova" mentre passa attraverso il QA e quindi può essere associato al supporto o bug in futuro.
Si chiama "tracciabilità" ed è una cosa enorme con progetti software su larga scala o molto controllati. Finché non si aggiungono flussi di lavoro onerosi (cioè solo un lead di squadra può creare un oggetto di lavoro, ecc.), Allora è una cosa molto buona.
Manterrei un tracker per mantenere i problemi sollevati dagli utenti aziendali. Questo è particolarmente utile quando si effettua la raccolta dei requisiti. Potresti voler utilizzare lo stesso tracker quando esegui test di accettazione degli utenti per eliminare i problemi esistenti o raccogliere feedback dagli utenti. Ho utilizzato principalmente più fogli Excel nello stesso gruppo di lavoro per mantenere diversi problemi (problemi di sviluppo in un foglio, problemi di business in un altro).
Leggi altre domande sui tag project-management issue-tracking business