Il trasferimento della conoscenza è un’attività imprescindibile per le aziende di oggi.
Ci sono vari tipi di conoscenza da trasferire: quelle sul codice del prodotto, quelle tecniche, le esperienze.
Per quanto riguarda il codice, si cerca di scriverlo con delle buone pratiche, autoesplicativo, e di documentarlo.
Nel caso delle API è sempre meglio seguire un approccio contract-first, in modo di averlo documentato già prima che realizzato.
L’insegnamento in questo caso è più limitato a come funziona l’architettura del software stesso, consigliando al team gli strumenti migliori e evidenziandone pregi e difetti.
Le conoscenze tecniche, spesso sono personali: non tutti i membri del team hanno lo stesso compito e spesso usano tool, piattaforme e linguaggi differenti. Perfino il background culturale varia.
Trovo importantissimo però che tutti i reparti si scambino la propria conoscenza in breve, in riunioni di team building, per far calare gli altri nei propri panni.
Un team che ha delle basi di conoscenza e empatizza il lavoro altrui è certamente più produttivo.
Questo genere di attività insegna ad ognuno un proprio metodo di spiegare e presentare le cose, formando ogni componente del team di volta in volta.
Le esperienze sono le più difficili da tramandare: sono frutto di noi stessi e del nostro lavoro, e spesso, il nostro cervello le tira fuori nel momento del bisogno. Nel caso dello sviluppo software vengono spesso fuori in attività di pairing o durante gli hackaton.
Le esperienze spesso hanno a che fare col tempo: non necessariamente molto, ma è probabile che un componente del team più “anziano” ne abbia accumulate di più, alcune utili, altre meno:
Fate attenzione sempre a tramandare le esperienze giuste, analizzare quello che state trasferendo e controllare se è frutto di saggezza o di pregiudizi.
Tutti nel team hanno qualcosa da insegnarci: facciamone tesoro e sfruttiamo la cosa per migliorare tutti, come persone e come organizzazione.
