Esiste un fattore di relazione tra il tempo di riunione e il tempo di sviluppo risparmiato?

10

Sto lavorando a un progetto e abbiamo incontri regolari (di solito settimanali), informali, in cui discutiamo lo stato del progetto e la sua interfaccia grafica.

Sono l'unico sviluppatore lì, le altre 4-5 persone hanno uno sfondo non IT.

Questo incontro ha richiesto molto più tempo del solito, ma a un certo punto uno dei miei colleghi ha chiesto alcuni campi del programma e il modo in cui si sono riempiti. Ho risposto e nella discussione ho notato che avevo completamente sbagliato il processo nella mia mente.

Ma dal momento che ne abbiamo parlato e abbiamo trovato l'errore in anticipo, posso cambiarlo abbastanza rapidamente.

Pensando a questo, mi sono chiesto, se c'è un fattore tra l'orario di riunione quando si tratta di risparmiare tempo di sviluppo?

Ad esempio, 1 minuto del tempo di riunione potrebbe far risparmiare X minuti di tempo di sviluppo.

Se è così, questo aiuterebbe a definire, quanto spesso e quanto dovrebbero durare i nostri incontri.

(Giusto per chiarire: non voglio fare riunioni migliori, anche essere in grado di determinare approssimativamente la lunghezza degli incontri è facoltativo. Sono per lo più interessato SE esiste una relazione tra tempo di incontro e sviluppo tempo! La mia ragione per chiedere: curiosità!)

    
posta hamena314 25.05.2016 - 15:34
fonte

3 risposte

14

"Finché devono essere, e non più."

La cosa da capire qui è che il tempo di incontro per risparmiare tempo di sviluppo non è in alcun modo lineare. Per il tuo team, per la tua azienda, per l'argomento questo , quindi 1 ora di riunioni potrebbe risparmiare 2 ore di lavoro di sviluppo. Se hai 10 ore di riunioni, un'altra ora di riunioni potrebbe salvare 0 lavori di sviluppo. Diavolo, potrebbe salvarti -2 ore di lavoro dev a causa di interruzioni o impatto sul morale.

Alla fine, l'intero punto delle riunioni è che la comunicazione e la collaborazione ti aiutano a fare le cose. Se le riunioni non ti aiutano a fare le cose, allora dovrebbero essere uccise.

    
risposta data 25.05.2016 - 15:50
fonte
7

Non esattamente.

Capire il cliente / stakeholder può far risparmiare tempo allo sviluppo. E le conversazioni devono essere abbastanza lunghe da facilitare la comprensione. Tuttavia, discutere di una funzione che presumi già di capire non migliorerà necessariamente la tua comprensione.

Se nessuno nella stanza ha sospetti di incomprensioni o false supposizioni, lascia la stanza estendendo artificialmente una "discussione" nella speranza che il tempo e la pressione di taglio spingano fuori un conflitto e creare armonia è senza speranza e demoralizzante.

E ricorda che comunicare è una combinazione di abilità e fortuna; la discussione non implica necessariamente la comunicazione (comprensione reciproca). Sarai sempre più bravo nell'esporre le ipotesi sbagliate più a lungo lavorerai sul campo e più a lungo lavorerai insieme.

Nel frattempo, "Agilità" può essere utile.

Mantieni le riunioni "brevi" e implementa le UI o i mockup grezzi il più presto possibile dopo ogni riunione, molto prima che persino sospetti abbia una piena comprensione. I tuoi UI / mock serviranno da materiale per chiarire le incomprensioni. Il tempo che intercorre tra le riunioni aiuterà tutti a decomprimere e riflettere su ciò che è stato detto. E se implementi i tuoi materiali show-and-tell nel codice , hai anche iniziato nello sviluppo. (E i tuoi clienti / colleghi saranno entusiasti di sentirlo!)

E lo scenario peggiore, quando hai implementato un frammento piccolo del codice visibile : sei totalmente fuori di testa e lo butti via. Ma se hai dedicato solo una piccola quantità di tempo, l'investimento ripaga grande nel chiarire il grossolano equivoco.

E ricorda, l'azienda non si preoccupa del tempo di sviluppo ; ti interessa solo persona-tempo . (come mezzo per calcolare costo totale , attenzione.) Quindi, devi cercare l'equilibrio in cui persona-tempo è ridotto al minimo; non tempo impiegato a scrivere codice.

    
risposta data 25.05.2016 - 17:33
fonte
4

Non credo che ci sia un qualche tipo di correlazione che potrebbe essere generalmente applicata. Dipende davvero dall'incontro e dalle cose che fai lì che riguardano lo sviluppo.

Nella situazione che descrivi, in pochi minuti sei passato dall'avere un requisito cattivo o poco compreso per averne uno migliore. Sappiamo che avere buone esigenze ha un impatto diretto sui tempi di sviluppo.

E se la riunione fosse qualcosa di simile a una riunione sullo stato della compagnia. Condividete buone informazioni in modo da sapere come sta andando la società, siete a conoscenza di altri eventi in corso, ecc. Ma, per la maggior parte, ciò non avrà alcun effetto sul tempo di sviluppo del vostro progetto. Tutto il tempo è "sprecato" quando lo si guarda da una prospettiva di sviluppo.

Una volta che hai dovuto partecipare a un numero sufficiente di riunioni, inizi a rendertene conto che alcuni sono davvero produttivi (ad esempio, prendi un piccolo team di sviluppo e una buona serie di requisiti e inizia a realizzare un'architettura in whiteboard. rimani concentrato.). Trovate anche alcuni che non sono affatto produttivi o addirittura hanno una produttività negativa (una volta un cliente ha avuto un dibattito di 15 minuti tra alcuni di essi sul fatto che una pagina di login dovrebbe dire "Accedi" o "Accedi". fine di ciò, nessuno sapeva e doveva essere presentato fino a tardi).

TL / DR: dipende dall'incontro, dalle persone e dagli obiettivi dell'incontro.

    
risposta data 25.05.2016 - 15:51
fonte

Leggi altre domande sui tag