Come segui ciò su cui tu e il tuo team state lavorando quotidianamente?

Sto lottando su come tenere traccia di ciò che io e le persone del mio team effettivamente facciamo ogni giorno. Ottengo una buona immagine esaminando le carte completate ogni settimana e gli stand-up aiutano un po ', ma mi sento come se non avessi una buona padronanza del funzionamento quotidiano della mia squadra. Le carte rimarranno in corso per giorni interi senza un aggiornamento durante lo stand-up quotidiano, e alcuni ingegneri sono il mio team non il più comunicativo.

Ho pensato di implementare una sorta di record giornaliero che tutti compilano (tramite una mailing list o un documento google condiviso) ma questo sembra abbastanza ingombrante e manuale.

Il monitoraggio dell'attività di GitHub fa un buon lavoro, ma può essere un po 'schiacciante con quante email invia ogni giorno. Ho pensato di provare a costruire un sistema digest per questo, ma non ho tempo da perdere.

Quali strategie hai implementato per rimanere aggiornato su ciò che il tuo team sta facendo ogni giorno in modo da poter misurare il lavoro su attività "in corso"?

Parlo con loro.

La tecnologia non può risolvere i problemi sociali. Hai brevi standup mattutini. Cosa hai fatto ieri? Cosa farai oggi? Qualche impedimento?

Se qualcosa suona sospetto (o sono curioso), mi fermo e faccio domande: "Ieri stavi lavorando su XYZ, come è andata a finire?". Ciò costringe le persone a prestare attenzione e a sapere effettivamente cosa sta succedendo. Ti mantiene anche il leader del team nel loop (e prestando attenzione e sapendo effettivamente cosa sta succedendo). Questo deve essere puntuale e breve ( massimo 10 minuti ). Nient'altro e le persone non "accantoneranno" il lavoro. Si fermeranno e aspetteranno lo standup e poi prenderanno del tempo per ricominciare. Alcuni lo faranno comunque, ma è in gran parte inevitabile.

Poi mi fermo alla scrivania di tutti nel pomeriggio. Non tutti i pomeriggi (anche se potrebbe essere più di ogni pomeriggio per le nuove persone), non allo stesso tempo, ma più o meno alla stessa ora (quindi è sia informale che regolare). "Qualche problema? Qualche impedimento?"

Sarai sorpreso di quanto spesso incontrerai problemi quando le persone sono una a una.

Se le persone non hanno problemi, ottimo; tornare al lavoro. Se non hanno problemi per tutta la settimana ? Problema. Non li stai sfidando abbastanza, o non si stanno aprendo. Chiedi come sta andando XYZ (che hanno menzionato in stand-up). Fagli spiegare le cose.

Questo non è microgestione. Non stai dicendo loro come fare il loro lavoro. Non li fai da babysitter. Sei lì per rimuovere gli impedimenti dalla loro vita quotidiana. Hai bisogno di informazioni per farlo. Fintanto che mantieni il tuo team fuori dalle riunioni e i project manager fuori dai loro cubi, una persona che si ferma per aiutare una volta al giorno non causerà loro dolore. Ma tutte queste interazioni devono provenire dalla vena "Sono qui per aiutarti".

Un'altra cosa che farò è rivedere i changeset (da solo, in modo informale). Posso quindi vedere con quale frequenza le persone effettuano il check-in, quanto sono grandi i loro changeset, in che modo corrispondono a ciò che hanno segnalato, con che frequenza ripetono le cose, quante correzioni di bug hanno e così via. Un elemento di lavoro che cambia lo stato in "completato" è quasi privo di significato. Guarda il codice. Sembra fatto?

nota: un aspetto estremamente grave: quanto è grande la tua squadra? Sono più di 7 persone? Ovviamente non sarai in grado di tenere traccia di tutto ciò che accade se la tua squadra è troppo grande.

Non micro-gestire i tuoi sviluppatori!

Lo sviluppo di software produttivo richiede lunghi periodi di sforzo mentale concentrato. Non è realistico aspettarsi che producano un output costante. Se inizi a misurarli su base giornaliera, ristruttureranno il loro lavoro in modo da produrre sempre alcuni artefatti riconoscibili che puoi vedere ogni giorno. Ciò potrebbe avere o meno un impatto positivo sulla qualità del software. Quasi sicuramente avrà un impatto negativo sull'efficienza dei tuoi sviluppatori.

Come suggerisce Robert Harvey , non gestire micro la tua squadra. Assegna al team alcune attività prioritarie con un valore aziendale concreto e lascia che il tuo team capisca meglio come offrire questo valore aziendale.

Se il team offre valore aziendale, allora dovresti essere felice. Il modo in cui si assicurano che consegnino le funzionalità richieste dovrebbe dipendere da loro.

Però:

Le carte rimarranno in corso per giorni e giorni senza un aggiornamento durante lo stand-up giornaliero

Ciò potrebbe indicare che c'è una carenza nel processo.

Potrebbe essere la squadra che non funziona davvero come una squadra, e non intervenire per aiutarsi a vicenda quando sono bloccati. Potrebbe anche essere la comunicazione con l'azienda. I compiti sono troppo grandi, quindi diventa difficile capire cosa è necessario. Le specifiche non sono chiare.

Potrebbe anche essere che non ci siano problemi reali. Forse il team lavora bene con le carte che rappresentano i principali lavori che richiedono giorni per essere completati, e forse il team sta lavorando bene per raggiungere questo obiettivo.

Penso che sia valido utilizzare la retrospettiva come piattaforma per esprimere la tua preoccupazione. A volte è una buona cosa ricevere osservazioni dall'esterno.

Ma lascia che il team capisca se c'è un problema e qual è la causa di ciò. E sii pronto ad accettare che forse devi adattare il modo in cui i compiti vengono consegnati al team.

Ricorda che lo stand up quotidiano è uno strumento per il team per aiutarli a organizzare il lavoro; NON è uno strumento per i manager per tenere traccia di ciò che la squadra sta facendo.

'Push messaging' non 'pull messaging'

Uno sviluppatore arriva spesso in uno dei seguenti stati che ti interessano:

1. Yaaay, ho fatto X!
2. Sto lavorando su X, ma sembra che ci vorrà un tempo prolungato ...
3. Sono bloccato sul problema Y, lo sto studiando ma potrei aver bisogno di consigli;
4. Sono bloccato perché aspetto A, B e C.

Idealmente, si desidera disporre di informazioni ragionevolmente aggiornate su questi stati senza interrompere la produttività effettiva. Costante "Ci siamo ancora?" è controproducente, ma può darsi che tu possa fare qualcosa di utile per gli stati 2-4, quindi devi essere informato su di essi.

Ciò che funzionerà è una cultura del "push messaging", preferibilmente in modo automatizzato. Potrebbe non essere necessario esaminare l'intero registro di commit, ma è possibile creare una "dashboard" in cui è visualizzato l'ultimo commit o l'ultimo ticket risolto (per bug o funzionalità) di ogni membro del team. Per il resto delle situazioni, puoi convincerli a inviarti un'e-mail in modo proattivo con tali aggiornamenti (si spera siano più rari dei commit) o ​​andare a chiedere loro se non vedi progressi continui su qualsiasi dashboard - se hai deve essere sollevato un accordo interno sul fatto che rimanere bloccati (potrebbe darsi che alcune funzionalità non siano necessarie se si scopre che costa 80 ore e non 8 ore), quindi o ti terranno aggiornato o ti infastidiranno.

In alternativa, puoi creare una cultura di qualcosa come https://idonethis.com/ rapporti giornalieri in uscita per tutto il team - questo assicurerà che anche altri siano sulla stessa pagina.

Un'alternativa ad alcune delle altre risposte (incentrate sulla comunicazione) è che forse i compiti sulle tue note card possono essere suddivisi in pezzi più piccoli sui quali potresti quindi ricevere un feedback prima.

Con pezzi più piccoli la squadra si sente come se stessero realizzando qualcosa ogni giorno che dovrebbe riflettere in piedi.

Lo svantaggio è che queste carte separate probabilmente faranno molto affidamento l'una sull'altra. Una squadra che è in grado di comunicare molto facilmente tra loro è utile qui, oppure i pezzi potrebbero non combinarsi come dovrebbero. Potrebbe anche essere necessario trattenere alcune delle carte se prima hai bisogno di alcune cose.

Detto questo, le persone rimarranno comunque bloccate o scopriranno un compito molto più impegnativo di quanto loro o te, di tanto in tanto, anticipino. Questo è il motivo per cui è ancora utile discutere apertamente di questioni in piedi dove gli altri possono offrire consigli senza giudicare la persona che ha problemi.

Per rispondere al problema della microgestione come hanno sollevato alcune delle altre risposte: anche se le persone eseguiranno piccoli compiti ogni giorno, avrà una visione più ampia del loro lavoro compiuto per avere un'idea di quanto effettivamente ogni persona sta facendo, piuttosto che giudicarli in base alle loro conquiste quotidiane.

Lo consiglio perché lavoro in un team di 8 persone, in cui la comunicazione è molto semplice e le persone sono molto disponibili. Ci vengono affidati compiti che non dovrebbero durare più di due giorni di lavoro. A volte questi compiti sono strettamente correlati e dobbiamo tenerci reciprocamente aggiornati su come ognuno di noi svolge il proprio lavoro. Ognuno di noi è responsabile di riferire ciò che abbiamo realizzato ogni due settimane al nostro responsabile.

Dopo aver letto di nuovo la domanda, mi rendo conto che potresti chiederlo come membro del team, non come leader, e quindi potresti non avere il controllo sui tuoi compiti.

1. Potresti suggerire al tuo leader di interrompere di più i compiti
2. Se il tuo lavoro viene bloccato o dipende dal lavoro di un altro membro del team, sentiti libero di controllarlo e di svolgere un compito diverso se necessario.

Prima di tutto devi analizzare te stesso in termini di tempo e abilità. Se sei un tecnico con una precedente esperienza pratica, le cose potrebbero differire da quelle nel caso in cui tu sia solo un manager (non con una forte conoscenza tecnica su ciò su cui i tuoi sviluppatori stanno effettivamente lavorando) che deve solo assicurarsi di rispettare le scadenze .

Il punto comune in entrambi i casi è che devi essere in grado di facilitare la tua squadra e creare la sensazione di fidarti di loro. Non stai giudicando le loro prestazioni ma stai cercando di essere empatico e disponibile nel rendere la loro esperienza divertente e facile.

Ora supponiamo che tu sia solo un manager, come ho detto sopra, in quel caso anche se qualche sviluppatore sta davvero affrontando un grave problema di sviluppo potresti non essere in grado di aiutarlo. Il problema reale può richiedere molto tempo e richiederà anche concentrazione. Supponendo inoltre che lo sviluppatore sia veramente sincero nel suo lavoro e pagando a tempo pieno (anche i tempi supplementari) per risolvere il problema, ma purtroppo non è ancora in grado di risolverlo. E in una situazione del genere (quando non sei nemmeno in grado di comprendere appieno il problema) continui a chiedere informazioni sul problema facendo progressi ogni giorno e persino informalmente due volte al giorno. Il risultato sarebbe estrema frustrazione e disturbo per lo sviluppatore. Sia che si tratti di un'app per la raccolta dei progressi quotidiani o della sua riunione standup giornaliera, entrambi possono essere frustranti.

D'altra parte, mantenendo tutti gli altri fattori uguali, supponi solo di avere un forte background tecnico e di aver lavorato sulle stesse tecnologie in passato. In questo caso, fare progressi quotidiani o tenere riunioni stand-up è davvero utile. Gli sviluppatori avranno sicuramente fiducia in te e nelle tue competenze e saranno a loro agio nel discutere la grande sfida che stanno affrontando. Fornirai alcuni suggerimenti che possono essere utili o anche se non direttamente utili, ti aiuteranno a fornire alcuni approcci alternativi.

Tuttavia, in ogni caso le riunioni quotidiane di standup devono creare la sensazione che tu sia un membro del team e non un capo / capo / manager. A meno che i membri del tuo team non ti considerino allo stesso livello in cui sono, non saranno in grado di comunicare le loro preoccupazioni / suggerimenti / problemi / feedback ecc.
Un altro punto da considerareè la dimensione del tuo team e il tempo che hai a disposizione per gestirli, prima di pensare di utilizzare un software di monitoraggio automatico dei progressi o di aumentare la tua interazione. Devi assicurarti che qualsiasi preoccupazione sia stata sollevata dal tuo team, sei in grado di risolverli al più presto. Un importante fattore demotivante per un membro del team è che i suoi dubbi / suggerimenti / feedback non vengono presi sul serio o non vengono valutati. Conoscere i progressi quotidiani è importante, ma solo nel caso in cui tu sia pienamente coinvolto nel lavoro di gruppo. Se sei coinvolto anche in alcune attività secondarie, non provare a interagire di più con il tuo team. Pensa a una situazione in cui la risposta del tuo team è schiacciante e stanno sottoponendo i loro compiti molto prima del tempo, sollevando dubbi e domande ma non sei in grado di fornire feedback e recensioni tempestivi. In una situazione del genere,

Crea e fai buon uso di varie chat room IM per le varie configurazioni. Alcuni possono essere ampi come @engineers e altri possono essere specifici come @newFeatureA

Prendi in considerazione la possibilità di effettuare standup giornalieri includendo una revisione dei biglietti in volo.

Utilizzare un ambiente aperto che supporti la collaborazione e assicurarsi che QE e il proprietario principale del prodotto si trovino nel mezzo degli sviluppatori. Sentirai molto e avrai un'idea vedendo gli schermi intorno a te.

Come sottolinea Robert, soprattutto non si può vedere come una micro-gestione (notare l'uso di 'essere visto', vale a dire indipendentemente dal proprio intento reale).

Alla fine monitoriamo ciò che viene realizzato nel tempo e vediamo da cosa deriva la nostra velocità. Concentrarsi sui progressi durante il giorno è controproducente poiché le persone diventeranno demoralizzate e / o se ne andranno.

Sono sorpreso che nessuno qui abbia ancora menzionato messaggi di repository "seguiti" o "speciali" integrati in sistemi come GitHub o BitBucket.

I nostri stakeholder tecnici (responsabili del progetto, responsabili dello sviluppo e del supporto) seguono tutti il ​​nostro problema e impegnano la cronologia degli aggiornamenti sui rispettivi progetti. Abbiamo un piccolo team (15 appaltatori FTE +), ma questo sembra funzionare per noi

Nessuno è misurato su nessuna di queste cose, ma oltre ai rapporti sullo stato settimanali dei PM, questo fornisce una visione quotidiana del progetto per almeno tenere tutti al corrente su quali aree sono in fase di elaborazione, quindi nessuno passa senza visibilità.

Ha inoltre contribuito ad aumentare la trasparenza tra sviluppatori e appaltatori e le nostre relazioni commerciali, il che aiuta tutti a rendere conto dei propri programmi di consegna.

In combinazione con i feed RSS associati a repository specifici o nell'intera nostra organizzazione, siamo stati in grado di limitare le e-mail (dove desiderato) e offrire un insieme simile di dati in tempo reale e in sintesi tramite lettori RSS. Per alcuni utenti si tratta di Outlook, quindi è sostanzialmente un messaggio di posta elettronica per loro, sebbene leggermente diverso, ma per altri utenti usano un client RSS completo con tutto il filtro aggiuntivo di cui hanno bisogno per personalizzarlo in base alle loro esatte esigenze.

Inizialmente ci siamo imbattuti in preoccupazioni simili riguardo al volume delle e-mail, ma i nostri utenti finali hanno scoperto il sistema RSS senza che la Engineering Org dovesse fare molto, oltre a suggerire client per coloro che non utilizzano Outlook. Ha lavorato per noi, ancora una volta circa 20-30 contraenti FTE + durante tutto l'anno in più uffici e fusi orari. YMMV, ovviamente.

Questa è un'aggiunta molto marginale (e non è specifica del programmatore), ma ho avuto un buon successo con Asana in progetti recenti.

Per l'integrazione con gli strumenti di collaborazione online esistenti, non cercare oltre Slack . È costruito attorno a una chat room, ma funge da hub piuttosto minimalista per altri strumenti tra cui Asana, GitHub e Bitbucket. Ha una discreta collezione di queste "integrazioni", sia pre-made e comunità ha fatto , utilizzando l'API che naturalmente ti permette di costruire il proprio.