Il modo migliore per far sì che i programmatori chiedano aiuto quando rimangono bloccati

Riunione di mischia giornaliera.

Fa meraviglie. E devi farlo lo stesso. Più di un giorno bloccato è un serio ostacolo che deve essere affrontato.

[BTW: "evitare di sviluppare dipendenza dagli altri" è un obiettivo terribile. Perché preoccuparsi? Inoltre "il costo del tempo impiegato dallo sviluppatore A per aiutare contro lo sviluppatore B" è una falsa ottimizzazione.]

I miei due centesimi dalla mia esperienza:

Nessun programmatore si blocca mai. Tendono solo ad andare in tangente. Ricerca e sviluppo tangenti.

Il modo migliore per assicurarsi che non vadano in tangenti è quello di separare il ruolo del programmatore principale dal ruolo del manager: il programmatore principale è di solito qualcuno molto dotato che preferirebbe programmare piuttosto che gestire altri programmatori . Il manager deve essere qualcuno che fa poco, se non altro, la codifica, e il suo compito è quello di essere costantemente allenatore della squadra.

Questo perché quando lasciati soli, i programmatori tendono ad essere orientati esclusivamente verso l'aspetto ingegneristico del loro lavoro, (lussuria ingegneristica?) con relativa noncuranza verso gli obiettivi del progetto. Quindi, aiuta avere qualcuno che ricorda loro che c'è un progetto da completare.

Una cosa che non è stata menzionata è la tecnica pomodoro delle interruzioni di pianificazione durante la giornata lavorativa.

www.pomodorotechnique.com

Solo alzarsi e bere un bicchiere d'acqua o fare una chiacchierata con qualcun altro può essere molto utile per "resettare" il cervello e guardare con occhi un po 'più freschi. Tutte le altre opzioni qui sono fantastiche. Ho pensato di aggiungere questo dato che mi ha aiutato molto.

Come vantaggio collaterale, il monitoraggio del tempo è più facile in quanto ora è solo "quanti pomodori ci sono voluti?" Moltiplica quello per 25 e hai la tua risposta. :)

Sai perché la gente non chiede aiuto? È perché chiedere aiuto è visto come una debolezza; un'incapacità di svolgere correttamente il proprio lavoro? Inoltre, che dire delle persone che chiedono aiuto e non ottenere un supporto efficace?

Secondo me, se questo tipo di cultura esiste, avrai problemi a cambiarlo perché si tratta di un problema top-down.

Contribuirò con altri due centesimi a questo ...

Happy Hour.

Prima di tutto, dirò semplicemente che non conosco la risposta perché abbiamo avuto circostanze simili. Ma sembra alla radice, il problema sono le comunicazioni. Tutto ciò che puoi fare per aiutare la squadra a comunicare meglio e in modo più efficiente aiuterà. Quando le persone iniziano a parlare sempre più spesso, non saranno quasi riluttanti a lanciare un messaggio istantaneo solo per fare un rumore con qualcun altro e vedere se sanno qual è la soluzione. D'altro canto, quando la tua squadra si sente come se fossero un gruppo di estranei gettati nella stessa squadra, le loro comunicazioni saranno molto limitate e alcuni potrebbero pensare che se chiedono aiuto a un lead o a qualcun altro, si starebbero "disturbando" "loro.

E so che può essere ancora più difficile con i team distribuiti. Sono un po 'incagliato su due squadre diverse. In ogni squadra, abbiamo uno sviluppatore fuori dallo stato. La parte interessante è che i due team si sentono molto diversi quando interagisco con gli altri membri del team. Quello che ho notato è che in una squadra "migliore" (non so se è una buona parola, sono tutti bravi ragazzi), abbiamo molte più conversazioni casuali. Parleremo di neve, serpenti, hamburger ... Nell'altra squadra, tutto è troppo non personale e gli effetti di ciò sembrano riversarsi anche nelle comunicazioni professionali. Non abbiamo tanti incontri casuali, o sessioni di chat e quando parliamo, tutti cercano di stare alla larga e di essere prudenti e riservati.

Come credo che l'alcol sia una soluzione a molti problemi, uno dei miei obiettivi a breve termine è quello di salire su un aereo con alcuni degli altri membri del team e andare a bere una birra con i due ragazzi fuori dallo stato. Forse funzionerà o forse pubblicherò una risposta diversa su SE in futuro.

La linea di fondo è fare tutto il possibile per migliorare le comunicazioni:

• Cerca di convincere le persone a socializzare in ambito non lavorativo (ad esempio, cosa ho già detto sopra)
• Promuovi la programmazione delle coppie o almeno la collaborazione ogni volta che ha senso. So che alcuni si fermeranno all'idea di essere sempre legati a un altro sviluppatore, quindi questo potrebbe non essere adatto a tutti.
• La co-locazione, se possibile, aiuta sicuramente ma è sempre possibile?
• Come sottolineato da S.Lott, gli stand-up promuoveranno sicuramente le comunicazioni del team
• Assegni casuali - a volte anche negli stand-up giornalieri le persone segnalano che il loro compito sta andando "bene", ma quando si inserisce il cubo, si potrebbe scoprire che sono bloccati su qualcosa per le ultime 3 ore.
• Investire in un software di comunicazione migliore. Abbiamo la messaggistica istantanea e sento ancora che rende le persone troppo distaccate. Abbiamo gettato le idee per dare a tutti le web cam.
• Informale, nessuna gestione, incontri per parlare di ciò che è nelle menti delle persone. Come sentono il progetto sta andando, dove ti mancano, potenziali aree problematiche a cui prestare attenzione. Questo è un po 'come la retrospettiva Agile, ma almeno come abbiamo fatto noi, sembra che sia troppo formale e spesso alle persone viene detto di smettere di parlare perché c'è un ordine del giorno. Mentre quel tipo di incontro aiuta a spostare le cose in avanti e facciamo progressi in termini di retrospettiva, sembra schiacciare parte del desiderio di comunicare.
• Infine, le revisioni del codice aiutano decisamente e dovresti presentarle e assicurarti che vengano eseguite regolarmente. Sono un altro punto di comunicazione per la tua squadra. Tuttavia, riconoscerai molti problemi simili nelle revisioni del codice che vedi ora. Molte volte, ci sarebbe una soluzione migliore ma dal momento in cui la revisione del codice viene girata è già stata codificata e non hai voglia di far rielaborare le persone. Sarebbe bello convincerli a parlare prima di iniziare un percorso.

Se li fai, condividere la stima del tempo con il team può aiutarti. Non sto nemmeno parlando di "timeboxing". Piuttosto, dirò a uno dei miei seguaci che penso che un compito dovrebbe richiedere X ore / giorni. Se iniziano il compito e si rendono conto che non stanno facendo progressi sufficienti mentre si avvicinano a X, allora sanno che hanno bisogno di raggiungere. Il rovescio della medaglia di questo è che devi fare la stessa cosa per te stesso, il che dimostra al team che stai raggiungendo i tuoi obiettivi e aiuta a rinforzare che stai stimando accuratamente e in grado di offrire solidi consigli per affrontare un problema.