Domanda:
In che modo le persone più impegnate trasferiscono le loro conoscenze?
Reinstate Monica - Goodbye SE
2012-04-13 02:22:23 UTC
view on stackexchange narkive permalink

Abbiamo recentemente intervistato gli utenti del wiki della nostra azienda e abbiamo scoperto che ci sono due grandi gruppi di utenti:

  • persone con molte conoscenze ma (che affermano non hanno) tempo per documentare
  • persone con tempo ma (che affermano di avere) conoscenze insufficienti che valga la pena documentare

Ciascun gruppo ha coperto quasi il 50% degli utenti!

Come lo gestiscono le vostre aziende? Cioè, come incoraggi le persone più impegnate / più informate a condividere le loro conoscenze?

PM.SE correlato q: [Come incoraggiate i membri del progetto a documentare il loro lavoro per il passaggio di consegne a fine progetto?] (http://pm.stackexchange.com/q/799/167)
Otto risposte:
#1
+26
Karl Bielefeldt
2012-04-13 02:43:06 UTC
view on stackexchange narkive permalink

Puoi far notare ai detentori della conoscenza che probabilmente trascorrono molto tempo comunque a essere infastiditi dalle domande. Scrivere una voce wiki è un investimento a breve termine che si ripaga a lungo termine. Se non vengono infastiditi dalle domande, probabilmente non è abbastanza importante da documentare.

Inoltre, i destinatari della conoscenza sono una scelta migliore per scrivere un articolo wiki di quanto si possa pensare, perché capiscono il punto di vista di qualcuno che ha bisogno di imparare l'argomento. Aiuta anche a organizzare e consolidare i loro pensieri. Avere qualcuno con più tempo a disposizione per scrivere l'articolo e farlo rivedere dal guru potrebbe essere molto utile.

+1 per averlo scritto al destinatario. A volte un detentore e un ricevente capiranno la stessa frase in modo diverso.
Concordato sul fatto che il destinatario lo scriva, ma chiedi ai detentori della conoscenza / agli esperti di esaminarlo su due fronti: correttezza e completezza. Una buona documentazione spiega sia il come che il * perché *.
+1 Presumere che i detentori della conoscenza siano bravi anche a documentare è un errore. Per non parlare del tempo prezioso e del buon karma che risparmieremo mettendo le persone giuste per il lavoro.
@voretaq7, in realtà, uno dei grandi vantaggi di un wiki è l'editing. Vai avanti e pubblica ciò che hai imparato, contrassegna le parti di cui non sei sicuro e lascia che sia lo SME o la * prossima * persona che ha bisogno di conoscere questa build da lì.
@MonicaCellio d'accordo - I wiki sono ottime risorse. Sfortunatamente l'editing della community può anche essere uno svantaggio quando qualcuno modifica informazioni incomprese / errate e si dimentica di contrassegnarle come "incerte" - In definitiva un Wiki è buono solo quanto le persone che lo esaminano per verificarne la correttezza :-)
inoltre - i destinatari possono scrivere la parte "Q" del wiki, e i possessori possono scrivere la "A"
Trovo che i wiki non vengano letti o modificati abbastanza da valerne la pena.Li ho visti provati in più lavori, mai visto uno solo.
#2
+15
HLGEM
2012-04-13 03:33:59 UTC
view on stackexchange narkive permalink

Uno dei nostri responsabili tecnici ha un'ottima politica, la terza volta che riceve la stessa domanda, scrive la risposta e la invia per e-mail alla persona che lo chiede e al wiki di knowlege che abbiamo creato. Dal momento che probabilmente avrebbe scritto quell'email comunque, l'unico lavoro aggiuntivo è aggiungere l'indirizzo per il Wiki.

Buona politica generale: se ti è stato chiesto tre volte è importante documentare. Come bonus probabilmente ci hai anche pensato abbastanza per avere una risposta buona e coerente da trasformare in documentazione ufficiale. (Questa è anche la regola che uso per automatizzare le attività: la terza volta che deve essere eseguita, dovrebbe essere automatizzata)
@voretaq7, Ho pensato che la parte relativa al collegamento del Wiki a un'e-mail per rivedere gli argomenti del wiki sia stata ispirata da me. È molto più facile documentare la conoscenza quando tutto ciò che devi fare è aggiungere un altro indirizzo e-mail a un'e-mail che avresti comunque scritto.
Perché aspettare tre volte, se qualcuno ha posto la domanda, è probabile che qualcun altro lo farà, quindi documentalo e poi inviagli un link ai documenti aggiornati. Scott Hanselman parla dell'idea di conservare le sequenze di tasti sul suo blog qui: http://www.hanselman.com/blog/DoTheyDeserveTheGiftOfYourKeystrokes.aspx
@ridecar2 Non sono un esperto, ma direi lo stesso motivo per cui aspetto fino alla terza volta per automatizzare un'attività: a volte lo fai da solo è la soluzione più veloce / migliore se accadrà solo una volta, e spesso no so che sarà una cosa ripetitiva la prima volta. Per la terza volta di solito ti stai avvicinando a un punto di svolta in termini di costi e benefici in cui è ovvio che l'attività continuerà a spuntare e il lavoro per documentare o automatizzare sarà sicuramente ripagato a lungo termine.
Non ci sono costi aggiuntivi per scrivere un post sul blog o inviare un'e-mail, quindi perché non scrivere il post sul blog immediatamente? Sono d'accordo sull'automazione delle attività in cui l'impostazione è difficile, ma non è quello di cui stavo parlando.
#3
+6
Atif
2012-04-13 02:41:21 UTC
view on stackexchange narkive permalink

Suggerisco di registrare screencast di circa 45 minuti. Riunisci tutti e il presentatore fa uno screencast e trasferisce la conoscenza. È più facile ed efficace mostrare come fare qualcosa, quindi solo documentazione scritta (che potrebbe anche includere tempo extra per la formattazione, ecc.)

In un posto dove lavoravo , avevano un "Lunch n'learn" su base settimanale o mensile. Un ragazzo pranza presto e fa una presentazione per la squadra mentre mangiano. Questo potrebbe funzionare se le persone hanno poco tempo.

+1 ottima idea! Avevamo un'idea simile e l'azienda avrebbe fornito il pranzo per incoraggiare la partecipazione.
Pranzare e imparare è una pratica orribile.Se è abbastanza importante per fare l'allenamento, dovrebbe essere fatto quando sei di guardia e non durante una pausa, l'ora di pranzo non dovrebbe MAI includere il lavoro.
@HLGEM - Sono un * ENORME * credente in Lunch & Learns.Tuttavia, non sono mai stati conteggiati come tempo di pausa quando sono stato coinvolto. Credo anche che l'esperto in materia di una particolare area * NON * dovrebbe essere quello che fa la presentazione.La migliore pratica che ho visto è quella di incaricare dipendenti di livello medio e inferiore di preparare le presentazioni.Ci arrivano con meno supposizioni e lo rendono più accessibile.e quando si stanno preparando, lo imparano.
Non sono contrario a questo tipo di formazione solo che non dovrebbe mai essere fatta a pranzo che di solito non è tempo retribuito e non appartiene all'azienda.È brutto come chiedermi di allenarmi dopo cena.C'è una buona ragione per cui le pause pranzo sono obbligatorie legalmente in molte giurisdizioni.
#4
+6
Mark Booth
2012-04-17 19:14:11 UTC
view on stackexchange narkive permalink

Il modo migliore per trasferire la conoscenza è che le persone che ne hanno bisogno lavorino con coloro che ne hanno la conoscenza.

Anche se le persone esperte potrebbero non avere il tempo di lavorano per documentare le proprie conoscenze, potrebbero già dedicare parte del loro tempo a spiegare agli altri cosa fare e come farlo.

Anche se le persone esperte hanno avuto il tempo di scrivere le proprie conoscenze, non è necessariamente vero che la documentazione da loro prodotta sarebbe utile alle persone meno informate. È sorprendentemente facile perdere importanti informazioni " ovvie " quando si cerca di trasmettere la conoscenza.

Rendendo il trasferimento della conoscenza più esplicito e cooperativo e facendo in modo che gli utenti scrivila in modo che possano comprenderla, potresti sia alleviare il peso delle persone informate e trasferire più informazioni.

Se le persone informate sono davvero a corto di tempo, potresti chiedere alle persone che hanno bisogno di quella conoscenza di scrivere ciò che capiscono ora , e poi chiedere alle persone esperte di correggere e correggere eventuali malintesi. Ciò potrebbe accelerare notevolmente le cose e potrebbe anche aiutare a identificare le aree in cui la conoscenza è carente.


Come esempio di ciò, lavoro su software scientifico. Né io né gli scienziati della struttura con cui lavoro potremmo, da soli, documentare gran parte del software che scrivo. Potrei spiegare cosa fa il mio software e anche perché lo fa in questo modo, ma sono gli scienziati della struttura che hanno bisogno di scrivere documentazione sul perché e come gli scienziati in visita dovrebbero usarlo.

In effetti, questa è esattamente una delle soluzioni che abbiamo considerato; è simile all'idea di * apprendistato *. Inoltre, l'apprendista (che probabilmente ha più tempo) può documentare ciò che ha appreso.
#5
+5
voretaq7
2012-04-13 03:20:54 UTC
view on stackexchange narkive permalink

Il mio suggerimento è di programmare il tempo della documentazione in ogni progetto e renderlo parte integrante di ciò che fai. Se non lo hai fatto da sempre, probabilmente devi programmare i "Giorni della documentazione" per far ripartire le cose (ad esempio, diciamo ogni venerdì dopo pranzo quelli con la conoscenza sono liberati da tutti gli altri progetti e lavorano solo sulla scrittura della documentazione). / p>

Può essere difficile portare la cultura della documentazione in un'azienda quando non ha mai fatto parte del modo in cui si facevano le cose prima, ma i benefici sono evidenti quando puoi assumere una nuova persona e tenerla al passo con lavorare in modo indipendente entro una settimana - Ad esempio, il progetto PostgreSQL ha una forte cultura del mantenimento di una documentazione eccellente. Il loro manuale è migliore di alcuni prodotti commerciali.

In linea di principio sono d'accordo, ma ho visto molte volte che la documentazione è stata saltata a causa del pensiero a breve termine con una scadenza del progetto.
@Wikis Cattiva cultura aziendale IMHO. La documentazione fa parte del prodotto (nel mio caso, letteralmente: gli standard internazionali e le normative federali lo richiedono per i produttori di dispositivi medici, quindi non devo discuterne troppo. Sono fortunato :-)
#6
+4
Karlson
2012-04-13 02:33:21 UTC
view on stackexchange narkive permalink

C'è una tendenza sfortunata nella mia esperienza quando si tratta di trasferimento di conoscenze e questa è la mancanza di interesse da parte di chi riceve . Potresti avere la persona disposta a fare la discarica del cervello a qualcun altro, ma se non c'è interesse nella sua ricezione perché l'esperto dovrebbe prendersi del tempo?

Quando stavo lasciando diversi luoghi in cui lavoravo mi è stato chiesto di farlo perché ero una delle pochissime persone che capivano i sistemi che stavo supportando, ma quando qualcuno mi è stato assegnato per questo compito ho potuto vedere dal loro comportamento che questo era fastidioso per loro e per loro non aveva alcun interesse in esso. Quindi la mia motivazione a fare il trasferimento della conoscenza è stata sostanzialmente ridotta a nulla.

Quindi l'unica cosa che potrei suggerire sull'argomento è assicurarmi che la persona che riceve la conoscenza sia effettivamente interessata all'argomento. Il pubblico in cattività che fa domande fa miracoli per la motivazione dell'oratore.

+1 - Essendo una delle "persone più impegnate", spesso trovo difficile ottenere tempo da * tutti gli altri * per addestrarli adeguatamente.
+1 - @voretaq7 - Ci sono state molte volte in cui ho suggerito ad altri che avrei potuto spiegare loro perché o come ho fatto qualcosa e ho detto loro che non pensavano fosse necessario. Quindi forse parte del problema è avere ricevitori di conoscenza disponibili.
@Giliane Suona come problemi separati ma strettamente correlati che portano allo stesso fine: nel mio caso i ricevitori della conoscenza in realtà * volevano * imparare, ma o erano veramente troppo occupati quando avevo tempo per insegnare oi loro supervisori si rifiutavano di lasciarglielo fare tempo di inattività per la formazione perché il supervisore non ha visto il valore.
#7
+4
Tangurena
2012-04-13 04:59:50 UTC
view on stackexchange narkive permalink

Cerco sempre di creare un wiki per documentare le cose. I wiki sono semplici e incoraggiano ad aggiungere bit e pezzi col passare del tempo. Con i sistemi di documentazione formale, il foglio bianco sembra opprimente per gli utenti e di conseguenza viene compilato solo quando gli si punta una pistola alla testa. Di solito vado in giro con un taccuino e inserisco le cose nel wiki in modo che possano essere localizzate facilmente: in questo modo, le attività annuali possono essere ripetute correttamente anziché dover riscoprire come avrebbero dovuto accadere.

Un capo precedente era disposto solo a consentire "documenti completi e completi" che non sono mai stati fatti. Ha vietato i wiki perché credeva che incoraggiassero il pensiero rilassato e la scarsa documentazione. Poiché i precedenti "documenti completi e completi" avevano tutti più di 5 anni al momento della mia partenza, non gli interessava comprendere che i suoi desideri erano in diretta opposizione al modo in cui lavorava il suo staff.

Solo nella peggiore emergenza, quando una persona critica se ne andò, fece e registrò webcast di camminare attraverso il codice che solo lui capiva. Questa è stata una delle poche volte in cui un dipendente ha dato preavviso, ha trasferito la conoscenza, invece di lavorare su cose fino al giorno in cui se ne è andato.

#8
+2
Hi pals
2012-04-13 04:06:32 UTC
view on stackexchange narkive permalink

Questo è davvero un problema politico, non motivazionale. Ai dipendenti con conoscenze critiche dovrebbe essere data l'opportunità e di documentarla e dovrebbe essere obbligatorio. Se non forniscono un'ampia documentazione e i loro supervisori hanno dato loro abbastanza tempo "libero" per farlo, dovrebbero essere disciplinati.

Non importa quanto una persona sappia o possa realizzare, se è l'unico con quella conoscenza, allora è una responsabilità. La documentazione non dovrebbe essere facoltativa.

Penso che la "disciplina" sia un [probabilmente] cattivo approccio - fintanto che i dipendenti rimangono produttivi, penalizzarli li incoraggerà solo ad andarsene: il che vanificherà lo scopo. Invece del rinforzo negativo, usa il rinforzo positivo - una qualche forma di incentivo / beneficio per fornire la documentazione.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...