I report giornalieri possono ridurre la produttività di uno sviluppatore? [chiuso]

In un'altra domanda , ho chiesto perché gli sviluppatori potrebbero non apprezzare la mischia quotidiana . Abbiamo parlato con gli sviluppatori e abbiamo deciso di non trattenere la mischia giornaliera per un po '(per provarlo e scrum personalizzato nel nostro primo tentativo). Questo è il risultato della consulenza diretta con gli sviluppatori.

D'altra parte, non vogliamo perdere buona parte della mischia quotidiana, come avere la possibilità di coordinare gli sviluppatori ogni giorno, o guardare i progressi del lavoro come un indicatore chiave di prestazione, per agire in anticipo.

In alternativa alla mischia quotidiana, stiamo pensando di chiedere agli sviluppatori di fornire report giornalieri con le seguenti condizioni:

1. Non è necessario seguire alcun formato specifico. Ogni formato è accettato.
2. Anche se il lavoro non viene svolto, vogliamo ascoltare la quantità di progressi.
3. Non è necessario menzionare il tempo dedicato a ciascuna attività.
4. Dovrebbero essere menzionati gli ostacoli allo sviluppo e i requisiti di coordinamento.
5. Non è necessario essere ossessionati dai rapporti quotidiani. Non è così severo.

Pensi che questo possa diminuire la loro produttività? Hai avuto esperienze con rapporti giornalieri? Hai qualche suggerimento per noi, in modo che possiamo essere sicuri di non essere microgestiti ?

In alternativa alla mischia quotidiana, stiamo pensando di chiedere agli sviluppatori di fornire report giornalieri con le seguenti condizioni:

Che idea terribile.

Pensi che questo possa diminuire la loro produttività?

Sì.

Perché? Una presentazione verbale in una riunione combina la scrittura e n "persone" che leggono il rapporto in un'unica attività concorrente. Parlando più ascoltando. Fatto e finito. Risposte alle domande subito.

Scrivere un rapporto è una perdita di tempo perché ci saranno domande e dovrai rivedere il rapporto con persone che (a) hanno domande e (b) non l'hanno davvero letto.

Rapporti giornalieri, non verranno letti. Passano rapidamente al rumore interno.

"Non è necessario essere ossessionati dai rapporti quotidiani". In tal caso, perché li fanno?

Hai qualche suggerimento per noi, in modo che possiamo essere sicuri di non essere microgestiti?

Sì. Avere uno stand-up quotidiano. Ci vogliono pochi minuti e il gioco è fatto.

Se il tuo stand-up quotidiano richiede più di alcuni (15?) Minuti, stai condividendo troppi dettagli e devi pianificare riunioni separate per tali dettagli. Le alzate giornaliere sono facili da fare. Dopo un riepilogo di 2 minuti, tutto il resto è probabilmente dettagli, non per l'intera squadra, e deve essere inserito in una riunione di follow-up. L'incontro passa al focus della persona successiva per la giornata.

Ho fatto queste cose in passato, ma al mattino anziché alla fine della giornata. In genere ci sono voluti meno di cinque minuti per compilare, quindi no, non riesco a vedere come si ridurrebbe la produttività di uno sviluppatore. La cosa bella di farlo al mattino è che ti ha fatto pensare a cosa farai per il resto della giornata.

Detto questo ...

Abbiamo scoperto che era più volte che no, non era il metodo più efficace per comunicare ciò che avevamo fatto il giorno precedente e ciò su cui avremmo lavorato quel giorno. Perché? Le persone in genere non le leggevano. Era un'attività programmata di Outlook, quindi tutti li inviavano tutti i giorni, ma erano stati sorpresi o persi del tutto (tranne che dai lead o dalla gestione).

Abbiamo scoperto che avere le alzate giornaliere era molto più prezioso poiché le persone tendevano ad ascoltarsi a vicenda. Inoltre, se ci fosse un malinteso, verrebbe cancellato allora e là, il che è più probabile che accada di qualcuno che risponde a un'e-mail di stato quotidiana per porre ulteriori domande.

In tutta onestà, consentire a chiunque di riferire senza vincoli sembra un po 'troppo lontano dal lato liberale dell'equazione. Dove lavoro, andiamo in cerchio e ogni sviluppatore fornisce quanto segue:

1. Cosa è stato fatto il giorno prima. Non tutti i piccoli dettagli, ma nel complesso.
   • Se quanto sopra non è finito, in caso contrario, cosa è necessario per finire e quanto tempo ci vorrà.
   • Se quanto sopra è terminato, qual è l'attività successiva, cosa è richiesto e il tempo necessario.
2. Bloccanti. Se stai lavorando su Foo, che dipende da Bar, e Bar non è finito, questo deve essere chiarito.

L'impostazione di uno schema generale che tutti possano seguire può semplificare la lettura di un determinato report. Puoi facilmente impostare un metodo per consentire a tutti di ricevere un'e-mail con i rapporti giornalieri e quindi consentire a chiunque di scoprire cosa sta succedendo.

Ogni tipo di incontro / report giornaliero dell'IMO diminuisce la produttività perché, a dire il vero, puzza di microgestione. Sì, sono a conoscenza di Scrum e simili e quelli non sono poi così male a condizione che siano brevi aggiornamenti di stato ("Hey come sta arrivando Project X?") Ma credo fermamente che sia offensivo per gli sviluppatori professionisti tenere d'occhio noi a un livello così basso; è simile all'utilizzo dei timecards per assicurarsi che siamo in ufficio 8 ore al giorno o per assicurarsi che non ci siano muri in modo da poter spiare i computer delle persone per vedere quali finestre hanno aperto in un determinato momento.

Se devi tenere d'occhio tutti per assicurarti che funzionino, significa che non ti fidi di loro. Se non ti fidi di loro, c'è un problema più grande sul lavoro di quello di cui ti preoccupi.

La mia squadra fa mischia da circa un anno. In precedenza, avevamo due incontri a settimana, durante i quali ogni membro del team riferiva della propria attività nei precedenti 2, 3 giorni. Ogni incontro è durato tra 30 minuti e 1 ora. Nel caso in cui avessimo bisogno di scambiare informazioni e coordinare il nostro lavoro, eravamo soliti andare dai nostri colleghi e parlare con loro (cosa che facciamo ancora, ovviamente).

Ora che stiamo facendo la mischia abbiamo spesso l'impressione che un incontro al giorno (anche se dura solo 15 minuti) sia troppo. Spesso i rapporti di alcuni membri si riducono a: "Niente di nuovo da ieri". Abbiamo spesso avuto l'impressione che lo schema 2 incontri a settimana fosse più efficace.

Un altro aspetto negativo è che l'incontro quotidiano è un'interruzione pianificata (vedi ad esempio l'articolo di Paul Graham , punto 1. Evita distrazioni): poiché sai che l'interruzione arriverà, non inizierai nulla di difficile prima dell'incontro (gli incontri quotidiani possono si svolgono da un'ora a un'ora e mezza dopo che uno ha iniziato a lavorare).

Ultimo ma non meno importante, mentre il feedback iniziale ha dei vantaggi ("Oh, stai lavorando su quel problema, dovremmo discuterne!"), A volte è più efficace iniziare una discussione solo quando hai già organizzato le tue idee nella tua mente , hai domande specifiche e ti senti pronto per la discussione. Invece, i rapporti giornalieri possono rapidamente causare molti brainstorming non necessari e non strutturati. Quindi, attenzione ai feedback troppo precoci : può confonderti e rallentarti.

Quindi: in alcuni casi i rapporti giornalieri hanno diminuito la nostra produttività. In media, non ho la sensazione che abbiano reso il nostro lavoro più efficace.

AGGIORNARE

Ho scritto la mia risposta originale un paio di anni fa e nel frattempo ho cambiato squadra. Nel mio attuale team, teniamo riunioni quotidiane su richiesta, ovvero quando sentiamo di aver bisogno di un breve aggiornamento dello stato. Quindi, ogni giorno c'è la possibilità di avere un tale incontro, ma non lo facciamo se nessuno lo richiede. Abbiamo una riunione retrospettiva settimanale. Questo è fondamentalmente molto simile all'approccio che stavamo usando originariamente nel mio precedente team non agile: riunioni settimanali fisse più riunioni su richiesta aggiuntive durante il resto della settimana.

Se quello che vuoi davvero è uno stato approssimativo e prendere nota di eventuali ostacoli, il modo migliore è chiedere loro una breve "e-mail di stato giornaliera". Se ci metti troppa enfasi su di esso, o fai un elenco di ciò che dovrebbe / non dovrebbe contenere, almeno alcuni dei tuoi sviluppatori passeranno più tempo a elaborarlo per soddisfare i requisiti. Invece, basta chiedere una semplice e-mail. Quando le cose accadono durante il giorno, dite cose come "oh, inseritele nella vostra e-mail di fine giornata" e se ricevete un'e-mail di fine giornata davvero lunga, menzionate casualmente "non è necessario essere così dettagliati ogni giorno".

È molto utile essere chiari sullo scopo di qualsiasi riunione o relazione, in particolare uno fatto da tutti ogni giorno. Dici che il motivo è:

non vogliamo perdere buona parte della mischia quotidiana, come avere la possibilità di coordinare gli sviluppatori ogni giorno,

Cosa intendi per sviluppatori di coordinate ? Che tipo di lavoro ha bisogno di coordinamento e non è stato coordinato ad hoc dagli sviluppatori e dai loro manager quando necessario? Esiste forse un modo per identificare le attività che richiedono un coordinamento e comunicare solo in quei casi?

o guardare l'avanzamento del lavoro come un indicatore chiave di prestazione, per agire tempestivamente.

Molti buoni KPI (come il tempo di risposta del sito o il numero di bug critici) saranno misurabili meccanicamente e non è necessario imporre un costo agli sviluppatori per farlo.

Ho dovuto fare rapporti quotidiani in diversi formati sul posto di lavoro. In generale, penso che i report giornalieri tendano ad aggiungere valore solo ai manager, non agli sviluppatori stessi. Mentre i manager traggono vantaggio dai report giornalieri essendo in grado di dire lo stato generale di ciascun progetto e il carico di lavoro di ciascun dipendente in un breve lasso di tempo, nella mia esperienza la maggior parte degli sviluppatori non si preoccupa di leggere i rapporti sullo stato degli altri.

Tuttavia, sembra che non imponendo un formato per i report giornalieri, rendi i report più difficili da leggere ed elaborare sia per i manager che per i colleghi sviluppatori, aggravando così il problema del tempo perso degli sviluppatori.

Se decidi di andare avanti con i rapporti giornalieri per i tuoi sviluppatori, potrei suggerire di utilizzare un wiki interno anziché i rapporti via e-mail? In questo modo non invii spam alle caselle di posta delle persone, pur mantenendo la cronologia degli stati quotidiani di tutti.

È un'ottima idea personalizzare i tuoi metodi Agile per adattarli a te, quindi complimenti per quello.

Quindi, secondo i rapporti giornalieri, direi che non è molto meglio di una riunione quotidiana, è sempre lo stesso approccio "dimmi cosa stai facendo", hai appena fatto scrivere a tutti invece di parlarlo.

Ecco un approccio alternativo: invece di utilizzare queste tecniche di "polling" in cui chiedi a ogni sviluppatore il loro stato, usi invece una tecnica di "push". Se lo sviluppatore non ha molto da segnalare, non dovrebbe, dovrebbe comunque segnalare tutti i problemi e i progressi man mano che si verificano. Quindi, quando completano un modulo, dovrebbero inviare per e-mail a tutto il team che è finito, che è in SCM, dove è possibile trovare la documentazione e un breve riepilogo di cosa è, come funziona e / o come utilizzare esso. In caso di problemi, devono inviare un'e-mail al team per chiedere consigli, aiuto o suggerimenti. (sì, proprio come ai vecchi tempi in cui i team comunicavano bene senza il microgestione di cui soffriamo oggi)

scoprirai che questo è molto più produttivo e costruttivo. Non otterrai rapporti insignificanti per il loro bene e otterrai una squadra più motivata poiché a tutti piace informare i loro colleghi del loro lavoro.

Concordo anche sul fatto che sia una cattiva idea sostituire gli stand-up quotidiani con una relazione. Uno stand-up quotidiano è un ottimo posto per vocalizzare idee e problemi. Questo è uno dei motivi per cui mi piace la buona vecchia lavagna (che usiamo insieme a Jira + Greenhopper). La lavagna è un luogo in cui il gruppo "si stringe" e condivide informazioni, tutto è lì, tutto è visibile, tutti si muovono e cambiano gli sticky su cui hanno lavorato, è anche molto divertente.

Non riesci a estrarre queste informazioni dagli altri tuoi strumenti?

• A cosa stai attualmente lavorando? I biglietti che ho assegnato.
• Quali sono i tuoi progressi? Per i biglietti che ho più di 1 giorno, vedere i commenti nel biglietto o inviare messaggi della filiale. Biglietti che ho più corto: probabilmente fatto domani (non fai grandi biglietti da 5+ giorni, sì?)
• Qual è il progresso generale? vedi rapporto ticket aperto / chiuso
• Cosa deve essere organizzato? i biglietti che ti vengono assegnati, con il feedback sullo stato necessario , e tutto ciò che è stato discusso nell'IRC della tua squadra, nella sala del fuoco, ecc.

Quando hai domande più specifiche a cui rispondere, vedrei la necessità di rapporti specifici, ma senza di ciò i tuoi rapporti sembrano un po 'fine a se stessi.