Correggimi se sbaglio; ma penso che quello di cui stai parlando sia: "Posso / Come usare i sistemi di tracciamento dei bug e di tracciamento dei problemi per fare anche il" Tracciamento delle decisioni ". È o mi manca qualcosa?
All'inizio direi che è davvero una grande idea. Anche se non lo usiamo nel modo esatto detto, ha senso che lo usiamo allo scopo di tracciare. Nel nostro caso, una lunga discussione di email - più come un forum / mailing list è seguita.
Tuttavia, la tua domanda in un senso più ampio riguarda il modo in cui prendere (e gestire) le decisioni in modo efficace e collegare le implicazioni del lavoro alle decisioni prese che portano a intuizioni migliori.
Come ho detto, può essere una bella idea se questo aiuti le persone. Niente di sbagliato in proposito. Ma per prendere decisioni in modo efficace / maneggevole servono poche cose concrete.
-
È vero che la maggior parte delle decisioni dovrebbe essere uno sforzo inclusivo basato su un'ampia scala, in modo che tutti gli aspetti importanti siano trattati e valutati adeguatamente prima di prendere le decisioni. Quindi qualunque strumento tu usi deve aver permesso un accesso trasparente alle informazioni a tutti gli interessati. Hai ragione che la modalità asincrona di trasmissione e raccolta delle informazioni aiuta perché le persone possono dedicare tempo prima di inserire suggerimenti. Se ti viene chiesto di rispondere in anticipo - in genere durante le riunioni, il giudizio potrebbe non essere altrettanto valido rispetto alla stessa persona con abbastanza compiti a casa.
-
Tuttavia, questo non significa necessariamente "democrazia pura" in cui ogni voto è uguale. In generale, la persona che prende le decisioni dovrebbe essere uno o pochi - e mentre hanno preso tutte le opinioni, devono essere individualmente responsabili delle decisioni e non tutte le persone che hanno fornito le loro opinioni.
-
La maggior parte delle decisioni deve essere impugnabile. Questo potrebbe trovare difficile evitare contraddizioni; ma il fatto che le decisioni non siano perseguibili e solo soggettive significa possibilità di interpretazioni future (errate).
-
È importante classificare il livello e l'ambito della decisione. La cosa più importante è che dobbiamo identificare se stiamo discutendo problemi di progettazione specifici o aspetti specifici del codice, aspetto dei processi o sono questi problemi di pianificazione e monitoraggio dei progetti? Abbastanza spesso quando i problemi colpiscono da un codice di produzione - tutti questi sono applicabili, ma dobbiamo essere in grado di distinguere tutti i diversi aspetti e in modo indipendente per essere in grado di gestire queste decisioni in modo efficace.
-
A volte le decisioni potrebbero essere se usiamo determinati sistemi o ruoli e responsabilità per gli individui; potrebbe essere duro mettere queste decisioni insieme a codificare decisioni specifiche su un forum di tipo bacheca.
-
Solo un aneddoto aggiuntivo; ogni team deve mettere le revisioni del codice e le revisioni del design come un processo da solo - che coprirà in modo esauriente molti problemi come quelli che hai citato. Devono o meno decidere se il tracciamento delle decisioni riguarda o meno altre cose.
Un buon processo decisionale implica molta disciplina sul modo in cui raccogliamo le informazioni e assicuriamo che le decisioni siano seguite con le implementazioni con lo spirito giusto.
Uno strumento può solo aiutare a rendere le informazioni più presentabili non oltre a ciò; ma potrebbe essere un buon aiuto se funziona per te.