Esiste un fattore di relazione tra il tempo di incontro e il risparmio di tempo di sviluppo?

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

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

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

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

Mentre ci penso, mi sono chiesto, se c'è un fattore tra il tempo di incontro quando si tratta di risparmiare tempo di sviluppo?

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

In tal caso, ciò aiuterebbe a definire, quanto spesso e quanto a lungo dovrebbero essere i nostri incontri.

(Giusto per chiarire: non voglio fare riunioni migliori, anche essere in grado di determinare approssimativamente la durata delle riunioni è facoltativo. Sono principalmente interessato SE c'è una relazione tra il tempo della riunione e il tempo di sviluppo! Il mio motivo per chiedere: curiosità! )

"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 questo argomento, 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 far risparmiare 0 lavori di sviluppo. Cavolo, può farti risparmiare -2 ore di lavoro di sviluppo a causa di interruzioni o impatto sul morale.

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

Non esattamente.

Comprendere il cliente / stakeholder può far risparmiare tempo di sviluppo. E le conversazioni devono essere abbastanza lunghe per facilitare la comprensione. Tuttavia, discutere di una funzionalità che già presumi di comprendere non migliorerà necessariamente la tua comprensione.

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

E ricorda che comunicare è una combinazione di abilità e fortuna; la discussione non implica necessariamente la comunicazione (comprensione reciproca). Migliorerai tutti nell'esporre cattive assunzioni più a lungo lavori sul campo e più a lungo lavori insieme.

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

Mantieni le riunioni "brevi" e implementa interfacce utente o modelli grezzi il prima possibile dopo ogni riunione, molto prima ancora di sospettare di avere una piena comprensione. La tua UI / mock servirà come materiale per chiarire i malintesi. 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 in codice , hai anche iniziato lo sviluppo. (E i tuoi clienti / colleghi saranno entusiasti di sentirlo!)

E lo scenario peggiore, quando hai implementato un piccolo pezzo di codice visibile : sei totalmente fuori base e lo butti via. Ma, se hai dedicato solo una piccola quantità di tempo, l'investimento paga grande nel chiarire grave malinteso.

E ricorda, la società non si preoccupa dei tempi di sviluppo ; si preoccupa solo della persona-tempo . (Come mezzo per calcolare il costo totale , sia chiaro.) Quindi, devi cercare l'equilibrio in cui il tempo-persona è ridotto al minimo; non il tempo trascorso a scrivere codice.

Non credo ci sia alcun tipo di correlazione che possa essere generalmente applicata. Dipende molto dall'incontro e dalle cose che fai lì relative allo sviluppo.

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

E se la tua riunione fosse qualcosa di simile a una riunione sullo stato della società. Condividete buone informazioni in modo da sapere come sta andando l'azienda, siete consapevoli di altre cose in corso, ecc. Ma, per la maggior parte, ciò non avrà alcun effetto sul tempo di sviluppo del vostro progetto. Tutto quel tempo viene "sprecato" quando lo si guarda da una prospettiva di sviluppo.

Una volta che hai dovuto partecipare a riunioni sufficienti, inizi a rendersi conto che alcuni sono davvero produttivi (ad esempio, prendi un piccolo team di sviluppo e una buona serie di requisiti e inizia a fare la lavagna di un'architettura. Puoi fare molto se rimani concentrato .). Ne trovi anche alcuni che non sono affatto produttivi o hanno persino una produttività negativa (una volta un cliente ha avuto un dibattito di 15 minuti tra alcuni di loro sul fatto che una pagina di accesso dovrebbe dire "Accedi" o "Accedi". alla fine, nessuno lo sapeva e doveva essere presentato fino a tardi).

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