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

As an alternative to daily scrum, we're thinking about asking developers to provide daily reports with the following conditions:

Che idea terribile.

Do you think that this can decrease their productivity?

Sì.

Perché? Una presentazione verbale in una riunione combina la scrittura e le persone n "che leggono" il report in un'attività concorrente. Parlando più ascoltando. Fatto e finito. Domande subito risposte.

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

I rapporti giornalieri non verranno letti. Si trasformano rapidamente in rumore in-box.

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

Do you have any suggestion for us, so that we can get sure that we're not micromanaging?

Sì. Avere una situazione quotidiana. Ci vogliono alcuni minuti e il gioco è fatto.

Se il tuo stand-up quotidiano richiede più di pochi (15?) minuti, stai condividendo troppi dettagli e devi pianificare riunioni separate per quei dettagli. Gli stand-up giornalieri sono facili da fare. Dopo un riepilogo di 2 minuti, tutto il resto è probabilmente dettagli, non per l'intero team, e deve essere inserito in una riunione di follow-up. L'incontro passa al focus della persona successiva per il giorno.

L'ho fatto in passato, ma al mattino invece che alla fine della giornata. In genere ci sono voluti meno di cinque minuti per compilare, quindi no, non riesco a vedere come ci sarebbe una diminuzione della produttività di uno sviluppatore. La cosa bella del farlo al mattino è che ti ha fatto riflettere su ciò che 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 cosa avremmo lavorato quel giorno. Perché? Le persone in genere non li leggevano. Era un'attività programmata di Outlook, quindi tutti li inviavano tutti i giorni, ma o venivano ignorati o semplicemente persi del tutto (a parte i lead o la gestione).

Abbiamo scoperto che avere lo stand-up quotidiano era molto più prezioso in quanto le persone tendevano ad ascoltarsi a vicenda. Inoltre, se ci fosse stato un malinteso, sarebbe stato cancellato in quel momento, il che è più appropriato che qualcuno risponda a una e-mail di stato quotidiana per porre ulteriori domande.

In tutta onestà, permettere a chiunque di segnalare senza vincoli sembra un po 'troppo lontano dal lato liberale dell'equazione. Dove lavoro, andiamo in circolo e ogni sviluppatore dà il seguente:

1. Cosa è stato fatto il giorno precedente. 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 l'operazione è terminata, qual è il compito successivo, 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 da seguire per tutti può semplificare la lettura di un determinato report. Puoi facilmente impostare un metodo per tutti per ricevere un'email con i rapporti giornalieri e consentire così a chiunque di scoprire cosa sta succedendo.

IMO qualsiasi tipo di incontro / rapporto giornaliero riduce la produttività perché, per essere sinceri, puzza di microgestione. Sì, sono a conoscenza di Scrum e simili e quelli non sono troppo male a patto che siano brevi aggiornamenti di stato ("Ehi come sta arrivando Project X?") Ma credo fermamente che sia insultante agli sviluppatori professionisti per tenerci d'occhio a un livello così basso; è come utilizzare i cartellini orari per essere sicuri che siamo in ufficio 8 ore al giorno, o per assicurarci che non ci siano muri in modo da poter spiare i computer delle persone per vedere quali finestre hanno aperto in un dato momento.

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

Il mio team ha fatto la mischia per circa un anno. Prima avevamo due incontri alla settimana, durante i quali ogni membro del team ha riferito della sua attività nei precedenti 2, 3 giorni. Ogni riunione è durata 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 ancora facciamo, ovviamente).

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

Un altro svantaggio è che la riunione quotidiana è una interruzione pianificata (vedi ad esempio l'articolo di Paul Graham , punto 1. Evita le distrazioni): poiché sai che l'interruzione sta per venire, sei non inizierà nulla di difficile prima dell'incontro (gli incontri giornalieri possono svolgersi un'ora e mezza dopo che uno ha iniziato a lavorare).

Ultimo ma non meno importante, mentre i primi feedback hanno 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 causare rapidamente un sacco di brainstorming non necessario e non strutturato. Quindi, fai attenzione al feedback troppo presto : può confondervi e rallentarvi.

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

Aggiorna

Ho scritto la mia risposta originale un paio di anni fa, e nel frattempo ho cambiato squadra. Nel mio attuale team, facciamo riunioni giornaliere on-demand, cioè quando sentiamo di aver bisogno di un breve aggiornamento di 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ù incontri su richiesta durante il resto della settimana.

Se quello che vuoi veramente è uno stato approssimativo e prendere nota di eventuali ostacoli, il modo migliore è chiedere loro una breve "email di stato quotidiana". Se metti troppa enfasi su di esso, o fai un elenco di ciò che dovrebbe / non dovrebbe contenere, almeno alcuni dei tuoi sviluppatori dedicheranno più tempo a crearlo per soddisfare i requisiti. Invece di questo, basta chiedere una semplice email. Quando le cose escono durante il giorno dicono cose come "oh, metti quello nella tua e-mail di fine giornata" e se ricevi un'e-mail molto lunga di fine giornata, menziona casualmente "non devi essere così dettagliato ogni giorno".

È molto utile essere chiari sullo scopo di qualsiasi riunione o rapporto, in particolare uno fatto da tutti tutti i giorni. Tu dici che la ragione è:

we don't want to lose good parts of daily scrum, like getting a chance to coordinate developers everyday,

Che cosa intendi per coordinare gli sviluppatori ? Che tipo di lavoro ha bisogno di coordinamento e non è stato coordinato ad hoc dagli sviluppatori e dai loro manager quando necessario? C'è forse un modo per identificare le attività che necessitano di coordinamento e comunicare solo in quei casi?

or watching the work progress like a Key Performance Indicator, to take actions early.

Un buon KPI (come il tempo di risposta del sito o il numero di bug critici) sarà misurabile meccanicamente e non è necessario imporre un costo agli sviluppatori per farlo.

Ho dovuto fare report giornalieri in diversi formati sul posto di lavoro. In generale, penso che i report giornalieri tendano a aggiungere valore solo ai manager, non agli stessi sviluppatori. Mentre i manager traggono beneficio dalle relazioni quotidiane grazie alla capacità di comunicare 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 di stato degli altri.

Tuttavia, sembra che non imponga un formato per i tuoi rapporti giornalieri, rendi i rapporti più difficili da leggere e da elaborare sia per i gestori che per gli altri sviluppatori, esacerbando in tal modo il problema del tempo di sviluppo perduto.

Se decidi di andare avanti con i rapporti giornalieri per i tuoi sviluppatori, potrei suggerire di utilizzare un wiki interno invece dei rapporti email? In questo modo non invii spam alla posta in arrivo delle persone, pur mantenendo la cronologia degli stati giornalieri di tutti.

È una buona idea personalizzare i tuoi metodi Agile per renderli adatti a te - quindi complimenti per questo.

Quindi, rapporti giornalieri, direi che non è molto meglio di un incontro quotidiano, è sempre lo stesso approccio "dimmi cosa stai facendo", hai appena fatto scrivere a tutti invece di parla.

Ecco un approccio alternativo: invece di usare queste tecniche di "polling" in cui chiedi a ogni dev per il loro stato, usi invece una tecnica "push". Se lo sviluppatore non ha molto da segnalare, non lo fa, dovrebbe segnalare qualsiasi e tutti i problemi e progredire nel modo in cui si verificano comunque. Quindi, quando completano un modulo, devono inviare via email a tutto il team che ha finito, che è in SCM, dove è possibile trovare la documentazione, e un breve riassunto di cosa è, come funziona e / o come usare esso. Se hanno un problema, dovrebbero mandare una e-mail alla squadra chiedendo consigli, aiuto o suggerimenti. (sì, proprio come ai vecchi tempi in cui le squadre comunicavano bene senza la microgestione che oggi soffriamo)

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

Sono anche d'accordo sul fatto che sia una cattiva idea sostituire gli stand-up giornalieri con un rapporto. 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 le informazioni, tutto è lì, tutto è visibile, tutti si muovono e cambiano gli sticky su cui hanno lavorato, ma anche molto divertente.

Non riesci a estrarre queste informazioni dagli altri tuoi strumenti?

• A cosa stai lavorando attualmente? I biglietti che ho assegnato.
• Quali sono i tuoi progressi? Per i biglietti ho più di 1 giorno, vedere i commenti nel ticket o messaggi di commit del ramo. I biglietti sono più brevi: probabilmente fatto domani (non farai grandi biglietti di 5+ giorni, sì?)
• Qual è il progresso generale? vedi rapporto aperto / chiuso-ticket
• Che cosa deve essere organizzato? i biglietti tu vengono assegnati indietro, con lo stato feedback necessario e tutto ciò che viene discusso nell'IRC del tuo team, nella sala fuoco, qualunque sia.

Quando hai domande più specifiche a cui rispondere, vedrei la necessità di rapporti specifici, ma senza che i tuoi rapporti sembrino un fine a se stessi.