Perché è così difficile convincere i dipendenti ad aggiornare il tracker dei problemi?

Ho sempre avuto questa lotta per convincere la gente ad aggiornare i loro problemi, sia nella mia azienda che al lavoro. Ho avuto alcuni casi in cui le persone lo fanno effettivamente dalla bontà del loro cuore, ma ~ 70% delle volte devo inseguire le persone.

Essendo quello che generalmente fa una o l'altra forma di gestione (sono innanzitutto uno sviluppatore), il motivo principale che provo a dare è che non voglio inseguire le persone e interrompere l'interrogazione sui progressi, ma non Alla fine la gente pensa che molte cose vengano chieste. In alcuni casi rari ed estremi finisco per aggiornare i loro biglietti (quando ho bisogno di creare rapporti).

Quindi, hai riscontrato questo problema? In che modo hai incoraggiato gli sviluppatori ad aggiornare frequentemente il tracker dei problemi? Che grado di successo hai avuto?

Il motivo è che non si rendono conto del perché dovrebbero aggiornare il tracker dei problemi, a parte il fatto che lo dici tu.

Perché? La mia ipotesi è che l'aggiornamento del tracker non influisca in modo significativo sul loro lavoro, quindi la soluzione è probabilmente quella di implementare un sistema di tracciamento che li aiuti effettivamente a fare meglio il loro lavoro.

È difficile, perché i dipendenti ritengono chiaramente che l'aggiornamento del tracker dei problemi non sia importante. Devi cambiarlo, ma c'è un problema. La comunicazione è difficile. Una comunicazione efficace è davvero difficile, molto più difficile di quanto si pensi. Così difficile, quella comunicazione di solito fallisce, tranne per caso .

Mostra, non dirlo. Per esempio. non dire che tu (o il tuo capo) avete bisogno dei dati per un rapporto. Mostra dal punto di vista dei dipendenti in che modo il tracker dei problemi aggiornato influisce e li aiuta.

Dare l'esempio.

Sono uno sviluppatore e faccio fatica a utilizzare il tracker dei problemi che abbiamo al lavoro. Questo è un peccato perché sono tutto per loro per mantenere le cose organizzate. La mia soluzione per il momento è utilizzare uno strumento di monitoraggio personale e fare riferimento a esso per parlare dei progressi nelle nostre mischie quotidiane.

Ecco cosa mi farebbe usare sempre il tracker:

• Perfetta integrazione con l'IDE e il controllo del codice sorgente. Usiamo alcune app web ingombranti perché le licenze sono già state acquistate per questo. Ci vuole un'eternità per creare / aggiornare attività e ha alcune caratteristiche dell'interfaccia utente confuse. Sfortunatamente l'utilizzo di questo è al di fuori del controllo del nostro team.

• Semplicità. Con questo intendo non prendere 10 campi popolati manualmente solo per aggiungere un'attività. Stime orarie rispetto al tempo di completamento, inserendo manualmente il progetto / componente / ecc. in diversi campi, ecc. basta aumentare la quantità di tempo.

• Solo uno. Non sono sicuro di quanto sia comune, ma la gestione del progetto utilizza uno strumento, il supporto ne utilizza un altro e lo sviluppo ne utilizza un terzo. Se uno non viene aggiornato, tre sicuramente non lo sono e è improbabile che la sincronizzazione tra di essi sia automatizzata.

Prima di tutto: cosa intendi con "persone che aggiornano i loro progressi"?

Intendi "sviluppatori che aggiornano la stima corrente" o "sviluppatori che non hanno impostato un problema da risolvere", o piuttosto "clienti / tester che non chiudono un problema risolto" o tutti insieme?

Dal punto di vista di uno sviluppatore, è un misto di mentalità e cultura.

• mentalità: quando si imposta un problema per risolto significa che hai finito, e responsabile se è difettoso
• cultura: se l'intera azienda non è molto desiderosa di utilizzare tali strumenti, ma preferisce altre strategie organizzative

La mia esperienza è: almeno la cultura deve puntare nella giusta direzione. Ciò che aiuta in seguito è definire un DoD (definizione di 'done') - se uno sviluppatore (lavora anche per altri ruoli) può dire (i) di aver soddisfatto l'intero elenco, è sollevato contrassegnare il problema risolto e andare avanti senza necessità guardare indietro.

Smetti di chiedere informazioni sui progressi della codifica (di solito è una percentuale arbitraria estratta dal nulla comunque) fino a quando il biglietto non viene chiuso, non dà credito. Se la cosa principale che misuri è il numero di biglietti chiusi, migliorerà.

Si noti tuttavia che tutte le metriche possono essere giocate e che le metriche tendono a funzionare meglio quando si uniscono a metriche complementari, ad esempio probabilmente si desidera esaminare anche i problemi che vengono riaperti poiché ciò implica che vengono prematuramente chiusi

Come sottolineato da alcune altre risposte, la domanda giusta qui è probabilmente: perché hai un tracker di problemi. Una buona risposta a questa domanda (non solo dal punto di vista della gestione ma anche dal punto di vista dello sviluppatore) è indispensabile se si desidera che un sistema di tracciamento dei problemi funzioni davvero e venga regolarmente aggiornato.

In molte aziende il sistema di tracciamento dei problemi viene utilizzato principalmente come strumento di reportistica di gestione. Fare in modo che i programmatori aggiornino i problemi in modo che la gestione possa eseguire un report non funziona bene. E forzare i programmatori ad aggiornare i problemi non funziona neanche - potresti avere problemi aggiornati ma dovresti mettere in discussione i dati.

Nella mia esperienza, l'unico modo per avere davvero sviluppatori (e tester, gestione, ecc.) Utilizzare efficacemente un sistema di tracciamento dei problemi è quello di integrarlo nel processo di sviluppo. Ciò significa che l'output di una parte del processo diventa l'input per la parte successiva del processo.

Per dare l'autorizzazione al sistema di tracciamento dei bug, suggerirei quanto segue:

• Gli sviluppatori lavorano solo su bug / funzionalità registrati nel tracker dei problemi e nessun lavoro viene svolto al di fuori di esso. Anche tutte le idee, i progetti di refactoring, le nuove funzionalità, gli strumenti personalizzati da sviluppare, ecc. Devono essere registrati.
• I problemi vengono elaborati in ordine di priorità. La priorità dovrebbe essere in parte determinata dalla direzione, ma gli sviluppatori dovrebbero sicuramente avere voce in capitolo anche nel determinare le priorità. Ciò è particolarmente vero quando si tratta di problemi di manutenzione e refactoring.

Per quanto riguarda l'elaborazione, è possibile utilizzare qualcosa di simile al seguente:

• lo stato "nuovo" indica che un problema non è stato ancora rilevato da uno sviluppatore ed è ancora in coda ai problemi con priorità
• lo stato "assegnato" indica che è stato assegnato a uno sviluppatore. Questo potrebbe essere fatto dallo sviluppatore o da qualcun altro come il responsabile del team. Trovo che funzioni bene avere alcuni problemi assegnati a ciascuno sviluppatore e di solito un mix di "sollevamento di carichi pesanti" come nuove funzionalità e facili prelievi come semplici bug o alcuni semplici lavori di manutenzione. Ciò consente agli sviluppatori di scegliere il lavoro in base al loro umore.
• lo stato "in corso" indica che uno sviluppatore sta lavorando a un problema. Solo uno o due problemi per sviluppatore dovrebbero essere "in corso" in qualsiasi momento.
• una volta risolto un problema, lo sviluppatore può modificare lo stato del problema in "esigenze di test" e cambiare il proprietario in tester. Questo è un passaggio importante, poiché questa è anche la coda di lavoro dei tester.
• i tester possono cambiare lo stato in "test fallito" e riportare la proprietà allo sviluppatore, il che significa che va in cima alla coda per lo sviluppatore, oppure possono cambiare lo stato in "pronto per la distribuzione".
• i problemi con lo stato di "pronto per la distribuzione" possono quindi essere uniti e rilasciati in base al ciclo di rilascio da chiunque sia responsabile delle versioni.

In breve: rendi il sistema di tracciamento dei problemi una parte essenziale del processo di sviluppo e non dovrai preoccuparti che i problemi non vengano aggiornati.

Forse lo considerano troppo lavoro per aprire un browser, accedere, trovare il biglietto e compilarlo. Forse puoi provare a incoraggiarli con i ganci . Oggi è una caratteristica comune che nel messaggio git / hg [suppongo che tu usi uno di questi] puoi digitare qualcosa come FIXED # 123 gradito, e il ticket cambierà automagicamente una volta spinto il commit. In questo modo non è quasi un lavoro per lo sviluppatore [se lavora su ogni problema in un ramo separato - ha già un ID ticket] e molto probabilmente aggiungerà quei due caratteri nel messaggio di commit. Se questa soluzione non è sufficiente, forse significa che l'ambito dei biglietti è troppo grande e dovrebbe essere diviso in molti biglietti più piccoli?

Sembra una questione di cultura aziendale più di ogni altra cosa. Chi ha istituito la necessità di utilizzare il tracker? Se questo è qualcosa che una persona o un gruppo ha lanciato là fuori, e si aspetta che tutti gli altri accettino e utilizzino, buona fortuna. A meno che le persone non capiscano di cosa si tratta, sappiano come usarlo e accettino che in realtà rendano le loro vite più facili (le loro vite, NON le vostre), non lo useranno se non costretti dalla direzione. Detto questo, se l'utilizzo del tracker è una decisione dell'azienda, dovrebbe essere il management a farla rispettare. A meno che il tuo ruolo non includa la responsabilità e l'autorità di ottenere / indurre le persone a utilizzare il tracker (sembra che no, come hai indicato che sei uno sviluppatore), non andrai molto lontano, indipendentemente da ciò che fai (realisticamente, IMHO ).

Questo è probabilmente simile al motivo per cui è così difficile indurre le persone a entrare regolarmente nel loro tempo. È un lavoro noioso ...

Molti tracker di problemi si integrano con l'IDE. Ad esempio, TFS Work Item Tracker consente di contrassegnare un'attività come risolta quando si esegue un check-in. C'è anche un'opzione per richiedere che un check-in sia associato a un'attività. Rendere l'aggiornamento di un oggetto di lavoro parte del processo di check-in semplifica le cose. L'alternativa consiste nell'aprire il tracker dei problemi in un'interfaccia separata per eseguire la modifica.

Un'altra opzione è avere una riunione di stato (o durante lo standup giornaliero) in cui qualcuno apre il tracker e aggiorna le attività man mano che le persone forniscono lo stato.

Una cosa da tenere in considerazione è che la stessa GUI è un impedimento. Ad esempio, alcuni ostacoli possono includere:

• Troppi clic
• Server applicazioni Tracker Issue non ottimizzato o sottodimensionato
• Scarsa usabilità o accessibilità

L'esposizione di un'API consentirà l'aggiornamento del tracker dei problemi tramite lo scripting come gli artefatti tecnici (copertura del codice, rapporti sui test delle unità, stato della build, ecc.).

Riferimenti

• Scrumwise - API

• Riferimento API REST JIRA Cloud

• API REST di Alfresco Content Services