Sembra che il problema non sia "mancanza di cooperazione" ma mancanza di responsabilità.

Hai menzionato un paio di scenari in cui, apparentemente, qualcuno in un'altra squadra ha responsabilità chiara e inequivocabile per un problema. Non hanno gestito questo problema, eppure non sono stati ritenuti responsabili per questo. Il loro mancato completamento di un'attività non è stato evidenziato e presumibilmente (dal fatto che stai postando una domanda qui), la colpa è del tuo team.

Penso che il problema sia probabilmente qualcosa di più fondamentale con il tuo processo di sviluppo, piuttosto che poche persone "inutili". Nel mondo ideale, non vuoi un sistema basato su persone che svolgono il lavoro di altri team in modo utile. Vuoi un modo per assegnare chiaramente il lavoro alla persona giusta e assicurarti che ciò avvenga effettivamente.

La cooperazione potrebbe non essere effettivamente una buona metrica da scegliere come target. Quando un processo viene interrotto, le persone "utili" finiscono per essere la chiave, perché partecipano, indipendentemente dal fatto che si tratti di lavoro. Ciò garantisce che le cose vengano fatte, nonostante i problemi. Ma la disponibilità è in realtà un'arma a doppio taglio. Le persone più "cooperative" possono finire per aiutare gli altri così tanto da non portare a termine i propri compiti importanti. E possono anche servire come spugne per assorbire il lavoro di dipendenti pigri o incompetenti. Se miri alla cooperazione, alcuni comportamenti indesiderabili vengono considerati positivi.

È difficile dire di più sui problemi specifici della tua azienda senza maggiori dettagli sul tuo processo di sviluppo. Ma una cosa che mi viene in mente è che un software appropriato per il monitoraggio di progetti / problemi, utilizzato in modo appropriato, dovrebbe semplicemente evidenziare questi problemi come conseguenza del suo utilizzo.

In tale software, un test fallito o un bug in qualche parte del progetto porterebbe alla creazione di un problema con il nome di una persona o di un team su di esso. Questo problema potrebbe essere successivamente rintracciato e potresti utilizzarlo come prova del problema ("Come puoi vedere, abbiamo segnalato questo bug al team di frobulator un mese fa, ma non ci hanno ancora risposto con una risposta ... ").

Il software non è l'intera soluzione. Se usato correttamente, fornisce le prove di ciò che è (o non è) accaduto. Hai ancora bisogno che le persone agiscano in base a tali prove in modo appropriato.

Aggiornamento: poiché hai detto che hai già un bug tracker, un buon posto per concentrare i tuoi sforzi probabilmente sarà quello di utilizzarlo in modo più coerente.

Abbiamo un vero e proprio sistema di tracciamento dei problemi (redmine), ma cerca di non attutirlo creando un ticket per tutto (ad esempio un test formale in stile codice fallito).

Questo è il tuo errore.

Non "attutisci" un sistema di monitoraggio dei problemi utilizzandolo. I rapporti sui problemi lo rendono solo più prezioso.

La tua fonte di alcune misure "oggettive" è qui. Ma funzionerà solo se lo usi.

Come misurare oggettivamente la cooperazione tra colleghi

Non capisco cosa ti aspetti di ottenere da un simile misurare. Dubito che esista veramente un modo "oggettivo" per misurare qualcosa di vago come "cooperazione".

Potresti iniziare scrivendo una definizione formale del termine "cooperazione", quindi elencando tanti casi quanti te questo può indicare casi positivi e negativi. Forse avrai una svolta in un modo o nell'altro.

Sospetto che scoprirai che la cooperazione è un termine soggettivo. Ciò che un individuo contrassegnerebbe come non cooperativo, un altro no. E se è così e vuoi davvero renderlo una misura soggettiva, allora sarà sufficiente un "diario degli incidenti".

Alcune metriche che puoi valutare oggettivamente sono

• tempo fino alla prima risposta (quanto tempo ci vuole per ottenere un "Lo esaminerò")
• tempo fino alla definizione risposta (quanto tempo ci vuole per ottenere una risposta effettivamente utile)

Ciò che non puoi misurare oggettivamente è l'effettiva utilità di una risposta che va oltre il "lo esaminerò". Ad esempio, una risposta che risponde solo alla metà delle tue domande e schiva il resto. Potresti non considerarla una "risposta definitiva", ma il mittente potrebbe farlo e non vedere alcun motivo per scrivere altro a meno che tu non lo chieda. Quello che puoi fare in questa situazione è porre una domanda di follow-up e monitorare la risposta al follow-up nello stesso modo.

Dovresti misurare il tempo solo nell'orario di lavoro effettivo. Esempio: il tuo orario lavorativo ufficiale è dal lunedì al venerdì dalle 9:00 alle 19:00. Invia una richiesta venerdì alle 18:00 e ricevi una risposta lunedì alle 10:00. Si tratta di un tempo di risposta di 2 ore.

Molte aziende più grandi cercano di tenere traccia di tutte le richieste nel software di gestione delle attività per misurare automaticamente tali numeri. Se vuoi qualcosa da qualcuno, crei un ticket nel software. Quando rispondono, lo fanno attraverso lo stesso sistema. Ciò consente alla direzione di ottenere una statistica su chi risponde quanto velocemente. Inoltre, le attività non completate tendono a sembrare molto scomode in tali sistemi. Ci sono vari prodotti per questo sul mercato.

Tuttavia, non è molto saggio fare troppo affidamento sui numeri generati da tali strumenti. Se lo fai, finisci per fare la gestione in base ai numeri. Riporre troppa fiducia nei numeri e non abbastanza nelle persone è un pericoloso anti-pattern gestionale.

La mia interpretazione del tuo post è che hai alcuni problemi:

• Come monitorare la cooperazione?
• Come rendere le persone responsabili?
• Come promuovere la cooperazione?

Ma prima affrontiamo il motivo per cui qualcuno potrebbe rispondere

Dò un'occhiata

ma non lo fanno mai veramente. Sebbene sia impossibile conoscere le ragioni esatte di ciò in ogni scenario, vorrei dare un'idea dal punto di vista di uno sviluppatore perché ho potuto vedere questo accadere per i motivi più preoccupanti. YMMV ma per me correggere i bug è un compito che uccide la carriera. È un lavoro di manutenzione non apprezzato. È anche un lavoro davvero spiacevole: cercare tra i registri e le tracce di pile solo per trovare gli errori più semplici. Perché gli sviluppatori dovrebbero dedicare del tempo a un compito irritante non apprezzato senza alcun vantaggio di carriera? Sicuramente uno sviluppatore lo farà per un livello accettabile, ma se questo livello è impostato troppo alto perché questo lavoro consuma la loro vita lavorativa, questo genere di cose può accadere. L'altro motivo preoccupante che uno sviluppatore può fare è evitare conflitti. Ciò si verifica se non esiste una cultura aperta sul posto di lavoro e una cultura del non biasimo, con la direzione che prende decisioni unilaterali. Ho scoperto che questo è prevalente nei progetti legacy. Potrebbero esserci problemi di progettazione fondamentali con un progetto e potrebbe essere impossibile ripetere il codice. In questa situazione, se la gestione non si livella con gli sviluppatori e stabilisce impegni accettabili per entrambe le parti in relazione alla risoluzione dei bug, avrai questa situazione. Ti consiglio caldamente di riflettere se questa è o meno la situazione nel tuo lavoro. Lavoravo in un'azienda (stranamente usavo anche redmine) e se la direzione mi avesse suggerito di non collaborare dopo aver corretto innumerevoli bug, me ne sarei andato prima di quanto ho fatto. Ti avverto che citi quella parola a tuo rischio e pericolo nel migliore dei casi creerà solo un cuneo tra te e la tua squadra, nel peggiore dei casi un esodo di massa.

Cooperazione nel monitoraggio - Anche se esistesse un software in grado di farlo in modo efficace, sicuramente non è un problema. IMHO questa metodologia è difettosa. Qualunque soluzione tu possa trovare, spingeranno gli sviluppatori a gravitare intorno a buchi circolari, passerai un'eternità a rivederlo e tornerai qui un anno dopo senza che nulla venga risolto. Puoi assegnare problemi a qualcuno nella miniera rossa e giudicare per ogni problema se ha collaborato, ma sono certo che creerai più spese generali e problemi di quanti ne abbia risolti.

Responsabilità delle persone - Personalmente credo che la responsabilità del gruppo sia molto più importante, il successo è dovuto alla buona gestione e al lavoro di squadra, non ai singoli. Dovrebbe essere assolutamente ovvio se qualcuno non sta tirando il proprio peso. Ciò è evidente nel codice di revisione tra pari, sessioni di pianificazione di gruppo, riunioni, retrospettive in metodologie agili o di altro tipo e molto altro ancora. Dovrebbero esserci contratti di gruppo stabiliti dal gruppo e il gruppo nel suo insieme dovrebbe tirare su gli altri sulla loro performance. Se decidi da solo come funziona, sarai tu a controllarlo, diventando più un'autorità che un leader.

Promuovi la cooperazione - Livellare con gli sviluppatori, capire cosa il lavoro di correzione dei bug è accettabile da un punto di vista aziendale e l'esperienza dello sviluppatore è la chiave per promuovere una cultura aperta senza colpa. Che ne dici delle attività di team building (adorano questo in Germania, quasi tutte le aziende hanno un giorno in cui escono e fanno insieme problem solving / avventura o altre attività di team building). Ma se prendi decisioni unilaterali e poi ti aspetti che tutti le seguano a una T o altrimenti metti un'etichetta non collaborativa su di loro, ti ritroverai con yes-men o evitatori di conflitti.

Nota finale, prendi più mosche con il miele. A me sembra che tu abbia una questione culturale piuttosto che un problema con gli individui. Scusami per il lungo post, sono appassionato di questo problema avendo cambiato lavoro a causa di questo genere di cose. (potrebbe essere questa compagnia). Spero davvero che la tua azienda trovi una soluzione.

  "Ci impegneremo di più per monitorare il lavoro tramite ticket che per essere effettivamente produttivi" 

Questo non si applica al tuo caso. Essere produttivi non significa "programmare ininterrottamente per 8 ore", significa completare i compiti, secondo l'ordine delle loro priorità. Se uno sviluppatore impiega 2 ore per un bug, deve renderlo un caso e segnalarlo.

Chiedere al team di preparare una relazione giornaliera sui progressi potrebbe farti risparmiare un po 'di tempo, tuttavia il tuo problema è più serio: dì "Lo farò" e non guardare non è una mancanza di irresponsabilità.

La tua risposta a tutte le tue domande è il "sistema di tracciamento dei bug". Non abbiamo tempo non applicabile, perché questa documentazione minima fa parte del lavoro, proprio come la codifica.

L'obiettivo della direzione è probabilmente ottenere il rilascio di software che generi vendite e soddisfazione del cliente. Ci sono parti di questo processo che sono interamente controllate dal tuo gruppo. Tutti voi dovreste essere valutati e, si spera, ricompensati per averli completati.

Hai identificato processi che coinvolgono il tuo gruppo e altri. Tutte le parti coinvolte in quel pezzo dovrebbero essere valutate e, si spera, ricompensate per il completamento di quel processo. Non dovrebbe esserci alcun incentivo per nessuna delle parti a fare qualcosa o a non fare ciò che è necessario per portare a termine questa parte senza che ci siano conseguenze. In quanto adulti professionisti, penso che un manager debba metterlo a tutte le parti per elaborare strategie reciprocamente accettabili.

O alcune delle parti non stanno effettuando la connessione al livello di input richiesto loro per portare a termine le cose o non hanno le risorse. Chissà, un incontro veloce potrebbe scoprire che c'è solo una piccola cosa che il tuo gruppo potrebbe fare per rendere questo molto più facile per gli altri. Non lo saprai mai finché non riunirai le persone che sanno cosa sta succedendo e la direzione per rendere importante questo compito. Le cose raramente vengono risolte in altro modo.

Un modo per non misurare la "cooperazione" ma per renderla visibile è il tabellone Kanban (o equivalente) e il quotidiano stand-up show-and-tell.

"Questo è quello che ho fatto ieri, questo è quello che voglio fare oggi, questo è ciò di cui ho bisogno, questo è ciò che mi ferma."

Qui definiamo anche le priorità. i biglietti Kanban sono tenuti sulla lavagna da magneti colorati, e se hai la priorità ottieni un colore diverso (verde), e quelli verdi vengono discussi per primi.

Se qualcuno sta trascinando i piedi è ovvio. Comunque, di solito c'è una buona ragione, e qui quella persona può dire qual è il problema e ottenere aiuto.