Un buon modo per condividere la conoscenza di una nuova tecnologia con i membri del team quando il tempo è breve?

Question

Un buon modo per condividere la conoscenza di una nuova tecnologia con i membri del team quando il tempo è breve?

#1 da (6 voti)
#2 da (0 voti)

5

Abbiamo avuto costanti modifiche al requisito di dover scegliere quale libreria di rendering grafica utilizzare per il nostro progetto.

In un team di circa 10 membri, due di noi stanno esplorando la nuova libreria grafica. Il team leader si aspetta che apprendiamo ciò che è necessario entro 2 giorni e lo introduciamo al resto della squadra ( vuole che noi due diamo un valore aggiunto agli altri team introducendoli a loro in modo che non lo facciano essere perso ). Gli abbiamo detto che 2 giorni sono ridicoli, quindi ci ha chiesto di dargli il nostro piano. Abbiamo già perso alcuni mesi nell'esplorazione di alcune altre librerie grafiche, quindi il progetto è in ritardo. Gli altri membri del team stanno sviluppando algoritmi che effettueranno chiamate alla libreria grafica. Dovranno scrivere del codice usando anche la libreria grafica.

In una situazione del genere, qual è un buon modo per condividere la conoscenza?

Fai sessioni di brainstorming ogni giorno per un'ora, dove ci dicono il loro algoritmo si interfaccia e diciamo loro la libreria grafica interfacce che possono usare?
Fornisci loro una breve panoramica dello scheletro di come le loro interfacce si adatterebbe con il nostro e permetterà loro di capire la libreria grafica codice per se stessi?
Altri modi?

teamwork knowledge-transfer knowledge-base

posta Nav 17.04.2012 - 10:43

fonte

2 risposte

0

Mentre il compito non è del tutto ragionevole - due giorni per imparare una nuova biblioteca ??? - Il modo più veloce per trasferire la conoscenza è creare modelli di codice ed esempi che gli altri programmatori possono usare per cough copia-incolla alle loro implementazioni.

Qualcosa di simile

// initialize graphic subsystem
MegaDraw.loadDriver(DriverManager.locateDriver(DRIVER_OPENGL2));
// create viewport
Viewport vp = MegaDraw.createViewport(1, null, FOOBAR_DEFAULT);

// draw a line
Point p1 = vp.createPoint(0,0);
Point p2 = vp.createPoint(10,10);
Line l = vp.drawLine(p1,p2);

Una volta che un programmatore conosce i metodi da chiamare, è relativamente facile consultare la guida di riferimento per i dettagli.

risposta data 17.04.2012 - 12:28

fonte

Leggi altre domande sui tag teamwork knowledge-transfer knowledge-base

Quando dovrei iniziare la codifica lato server? MVVM - finestre secondarie e contesti dati

score 6 · Accepted Answer

Trascorri i due giorni a lavorare con la nuova libreria grafica. Quindi lavorare con uno o al massimo due membri del team senior per trasferire i loro algoritmi nella nuova libreria grafica. Dopo due settimane presenta un seminario formale su ciò che hai imparato dallo sforzo di porting per l'intera squadra. Crea un wiki.

Ecco la logica:

Sono necessari almeno due giorni per capire di cosa tratta la biblioteca e scrivere "Hello World".

Devi iniziare a fare un po 'di lavoro "reale" dopo due giorni per convincere il tuo team che non stai perdendo tempo. Probabilmente ha bisogno di riferire questo sulla catena di comando in modo da essere comprensivo.

Devi iniziare il lavoro di integrazione con i membri senior del team in modo che se incontri dei problemi queste persone credibili possono spiegare al leader del team perché sei bloccato.

Hai bisogno di almeno due settimane con gli ingegneri senior e i loro algoritmi per completare una programmazione significativa, ma più di due settimane renderanno il management nervoso.

Dopo due giorni e due settimane è necessario tenere un seminario per gli altri membri del team in modo che possano iniziare e la direzione vedrà che la conoscenza viene diffusa a tutto il team e in modo che il team non si allontani troppo lungo la strada con codice che potrebbe richiedere molte modifiche per adattarsi alla nuova API grafica. Il team può quindi utilizzare gli esempi sul wiki che hai sviluppato con i due membri senior per iniziare il proprio lavoro.

Non iniziare facendo un brainstorming: le cose andranno fuori controllo e genereranno molto rumore. Non lasciare che i programmatori riescano a capirlo da soli dopo una breve presentazione: alcuni si bloccheranno e poi si lamenteranno, e ci sarà un sacco di apprendimento duplicato in corso.