Vraag:
Hoe dragen uw drukste mensen hun kennis over?
Reinstate Monica - Goodbye SE
2012-04-13 02:22:23 UTC
view on stackexchange narkive permalink

We hebben onlangs onze wiki-gebruikers binnen het hele bedrijf ondervraagd en kwamen erachter dat er twee grote groepen gebruikers zijn:

  • mensen met veel kennis maar (die beweren ze hebben) geen tijd om te documenteren
  • mensen met tijd maar (die beweren te hebben) niet genoeg kennis die het waard is om te documenteren

Elke groep behandelde bijna 50% van de gebruikers!

Hoe gaan uw bedrijven hiermee om? Dat wil zeggen: hoe moedigt u uw drukste / meest deskundige mensen aan om hun kennis te delen?

gerelateerde PM.SE v: [Hoe moedig je projectleden aan om hun werk te documenteren voor de overdracht aan het einde van het project?] (http://pm.stackexchange.com/q/799/167)
Acht antwoorden:
#1
+26
Karl Bielefeldt
2012-04-13 02:43:06 UTC
view on stackexchange narkive permalink

U kunt de kennishouders erop wijzen dat ze waarschijnlijk toch veel tijd besteden aan het lastigvallen van vragen. Het schrijven van een wiki-item is een investering op korte termijn die zich op de lange termijn terugverdient. Als ze niet lastig gevallen worden door vragen, is het waarschijnlijk niet belangrijk genoeg om te documenteren.

Ook zijn de kennisontvangers een betere keuze om een ​​wiki-artikel te schrijven dan je misschien denkt, omdat ze het punt van weergave van iemand die het onderwerp moet leren. Het helpt ook om hun gedachten te ordenen en te stollen. Iemand met meer tijd het artikel laten schrijven en het ter beoordeling door de goeroe laten leiden, kan zeer nuttig zijn.

+1 om de ontvanger het te laten schrijven. Soms begrijpen een houder en een ontvanger dezelfde zin anders.
Overeengekomen om de ontvanger het te laten schrijven, maar laat de kennishouders / experts het op twee fronten beoordelen: juistheid en volledigheid. Goede documentatie legt zowel het hoe als het * waarom * uit.
+1 Ervan uitgaande dat kennishouders ook goed zijn in documenteren, is een misvatting. Om nog maar te zwijgen van kostbare tijd en wat goed karma dat we zullen besparen door de juiste mensen voor de job aan te stellen.
@voretaq7, eigenlijk, een van de grote voordelen van een wiki is het bewerken. Ga je gang en post wat je hebt geleerd, markeer de onderdelen waarvan je niet zeker bent, en laat de KMO of de * volgende * persoon die dit moet weten, van daaruit bouwen.
@MonicaCellio Akkoord - Wiki's zijn geweldige bronnen. Helaas kan het bewerken van de community ook een nadeel zijn wanneer iemand wijzigingen aanbrengt in verkeerd begrepen / onjuiste informatie en vergeet deze als "onzeker" te markeren - Uiteindelijk is een Wiki zo goed als de mensen die hem beoordelen op juistheid :-)
ook - de ontvangers kunnen het "Q" -gedeelte van de wiki schrijven en de houders kunnen de "A" schrijven
Ik vind dat wiki's gewoon niet genoeg gelezen of bewerkt worden om de moeite waard te zijn.Ik heb ze bij meerdere banen zien proberen, nooit één werk gezien.
#2
+15
HLGEM
2012-04-13 03:33:59 UTC
view on stackexchange narkive permalink

Een van onze technische leads heeft een geweldig beleid. De derde keer dat ze dezelfde vraag krijgt, schrijft ze het antwoord op en e-mailt het naar de persoon die het vraagt ​​en naar de kenniswiki die we hebben opgezet. Aangezien ze die e-mail waarschijnlijk toch zou schrijven, is het enige extra werk om het adres voor de Wiki toe te voegen.

Goed algemeen beleid - als je het drie keer hebt gevraagd, is het belangrijk om te documenteren. Als bonus heb je er waarschijnlijk ook genoeg over nagedacht om een ​​goed, samenhangend antwoord te hebben om in officiële documentatie te verwerken. (Dit is ook de regel die ik gebruik voor het automatiseren van taken: de derde keer dat het moet worden gedaan, moet het worden geautomatiseerd)
@voretaq7, Ik dacht dat het gedeelte over het aansluiten van de Wiki op een e-mail om wiki-onderwerpen te herzien, zelf geïnspireerd was. Het is zoveel gemakkelijker om kennis te documenteren als je alleen maar een ander e-mailadres hoeft toe te voegen aan een e-mail die je toch zou gaan schrijven.
Waarom drie keer wachten, als iemand de vraag heeft gesteld, dan is de kans groot dat iemand anders dat zal doen, dus documenteer het en e-mail hem dan een link naar de bijgewerkte documenten. Scott Hanselman praat hier over het idee om je toetsaanslagen te behouden op zijn blog: http://www.hanselman.com/blog/DoTheyDeserveTheGiftOfYourKeystrokes.aspx
@ridecar2 Ik ben geen expert, maar ik zou dezelfde reden zeggen als ik wacht tot de derde keer om een ​​taak te automatiseren: soms is het zelf doen de snellere / betere oplossing als het maar één keer gebeurt, en vaak niet weet dat het de eerste keer een repetitief iets zal zijn. Tegen de derde keer nadert u meestal een omslagpunt tussen kosten en baten, waar het duidelijk is dat de taak zal blijven opduiken en het werk om te documenteren of automatiseren op de lange termijn zeker zijn vruchten zal afwerpen.
Er zijn geen extra kosten verbonden aan het plaatsen van een blogpost of het doen van een e-mail, dus waarom zou u de blogpost niet meteen doen? Ik ben het eens over automatisering van taken waarbij het moeilijk is om dat op te zetten, maar daar had ik het niet over.
#3
+6
Atif
2012-04-13 02:41:21 UTC
view on stackexchange narkive permalink

Ik raad aan om screencasts op te nemen van ongeveer 45 minuten. Breng iedereen bij elkaar en de presentator doet een screencast en draagt ​​de kennis over. Het is gemakkelijker en effectiever om te laten zien hoe je iets moet doen, dan alleen schriftelijke documentatie (die ook extra tijd voor opmaak kan bevatten, enz.)

Op een plek werkte ik , hadden ze wekelijks of maandelijks een "Lunch n'learn". Een man eet vroeg lunch en geeft een presentatie voor het team terwijl ze eten. Dit kan werken als mensen te weinig tijd hebben.

+1 geweldig idee! We hadden een soortgelijk idee, en het bedrijf zou een lunch verzorgen om deelname aan te moedigen.
Lunchen en leren is een vreselijke praktijk.Als het belangrijk genoeg is om te trainen, moet je dit doen als je op de klok bent en niet tijdens een pauze. Lunchtijd mag NOOIT werk bevatten.
@HLGEM - Ik ben een * ENORME * gelovige in Lunch & Learns.Ze werden echter nooit als pauzetijd geteld toen ik erbij betrokken was. Ik ben ook van mening dat de materiedeskundige op een bepaald gebied * NIET * degene moet zijn die de presentatie geeft.De best practice die ik heb gezien, is om mid- en junior medewerkers de leiding te geven over het voorbereiden van de presentaties.Ze komen eraan met minder aannames en maken het toegankelijker.en als ze zich erop voorbereiden, leren ze het.
Ik ben niet tegen dit soort trainingen, alleen dat het nooit tijdens de lunch moet worden gedaan, wat meestal geen betaalde tijd is en niet van het bedrijf is.Het is net zo erg als mij vragen om na het eten te gaan trainen.Er is een goede reden waarom lunchpauzes in veel rechtsgebieden wettelijk verplicht zijn.
#4
+6
Mark Booth
2012-04-17 19:14:11 UTC
view on stackexchange narkive permalink

De beste manier om kennis over te dragen is voor de mensen die de kennis nodig hebben om samen te werken met degenen die de kennis hebben.

Hoewel de goed geïnformeerde mensen misschien niet de tijd hebben om zelf aan het documenteren van hun kennis, besteden ze misschien al een deel van hun tijd aan het uitleggen aan anderen wat ze moeten doen en hoe ze het moeten doen.

Zelfs als de goed geïnformeerde mensen de tijd hadden om hun kennis op te schrijven, Het is niet noodzakelijk het geval dat de documentatie die ze produceerden nuttig zou zijn voor de minder goed geïnformeerde mensen. Het is verrassend eenvoudig om belangrijke ' voor de hand liggende ' informatie over het hoofd te zien wanneer u kennis probeert over te brengen.

Door de kennisoverdracht explicieter en coöperatiever te maken, en de gebruikers daarvan documentatie schrijven zodat ze het kunnen begrijpen, kunt u zowel de last van de goed geïnformeerde mensen verlichten als meer informatie overbrengen.

Als de ervaren mensen echt lang ingedrukt houdt, zou je de mensen die die kennis nodig hebben kunnen vragen om op te schrijven wat ze nu begrijpen, en vervolgens de goed geïnformeerde mensen kunnen laten proeflezen en eventuele misverstanden kunnen corrigeren. Dit zou de zaken aanzienlijk kunnen versnellen, en zou ook kunnen helpen bij het identificeren van gebieden waar de kennis ontbreekt.


Als voorbeeld hiervan werk ik aan wetenschappelijke software. Noch ik, noch de faciliteitswetenschappers waarmee ik werk, kunnen alleen veel van de software die ik schrijf documenteren. Ik zou kunnen uitleggen wat mijn software doet en zelfs waarom het op die manier doet, maar het zijn de faciliteitswetenschappers die documentatie moeten schrijven over waarom en hoe bezoekende wetenschappers het zouden moeten gebruiken.

Dit is inderdaad precies een van de oplossingen die we hebben overwogen; het is vergelijkbaar met het * leerlingwezen * idee. Als toevoeging kan de leerling (die waarschijnlijk meer tijd heeft) dan documenteren wat hij heeft geleerd.
#5
+5
voretaq7
2012-04-13 03:20:54 UTC
view on stackexchange narkive permalink

Mijn suggestie is om documentatietijd in elk project te besteden en het een essentieel onderdeel te laten zijn van wat je doet. Als je dat niet de hele tijd hebt gedaan, moet je waarschijnlijk "Documentatiedagen" plannen om dingen een vliegende start te geven (zeg bijvoorbeeld dat elke vrijdag na de lunch degenen met de kennis worden bevrijd van alle andere projecten en gewoon werken aan het schrijven van documentatie).

Het kan moeilijk zijn om de documentatiecultuur in een bedrijf te krijgen als het nog nooit een onderdeel is geweest van de manier waarop dingen eerder werden gedaan, maar de beloningen zijn duidelijk wanneer je een nieuw persoon kunt inhuren en ze op de hoogte hebt en binnen een week zelfstandig werken - Het PostgreSQL-project heeft bijvoorbeeld een sterke cultuur om uitstekende documentatie bij te houden. Hun handleiding is beter dan sommige commerciële producten.

In principe ben ik het ermee eens, maar ik heb vaak gezien dat documentatie werd overgeslagen vanwege kortetermijndenken met een projectdeadline.
@Wikis Slechte bedrijfscultuur IMHO. Documentatie maakt deel uit van het product (in mijn geval letterlijk: internationale normen en federale regelgeving vereisen dit voor fabrikanten van medische hulpmiddelen, dus ik hoef er niet te veel over te twisten. Ik heb geluk :-)
#6
+4
Karlson
2012-04-13 02:33:21 UTC
view on stackexchange narkive permalink

Er is een ongelukkige trend in mijn ervaring als het gaat om kennisoverdracht en dat is het gebrek aan interesse bij de ontvangende kant . Je zou de persoon bereid kunnen hebben om de brain dump aan iemand anders te doen, maar als er geen interesse is in de ontvangst, waarom zou de expert dan de tijd nemen?

Toen ik er een aantal vertrok? plaatsen waar ik werkte, werd mij gevraagd dit te doen omdat ik een van de weinige mensen was die de systemen begreep die ik ondersteunde, maar toen iemand mij voor deze taak werd toegewezen, kon ik aan hun manier van doen zien dat dit hinderlijk voor hen en zij was had er geen interesse in. Dus mijn motivatie om de kennisoverdracht te doen, werd in wezen tot niets teruggebracht.

Dus het enige dat ik over het onderwerp zou kunnen suggereren, is ervoor te zorgen dat de persoon die de kennis ontvangt, ook echt geïnteresseerd is in het onderwerp. Een vast publiek dat vragen stelt, doet wonderen voor de motivatie van de spreker.

+1 - Als een van de "drukste mensen" vind ik het vaak moeilijk om tijd te krijgen van * alle anderen * om ze goed te trainen.
+1 - @voretaq7 - Er zijn vaak momenten geweest waarop ik anderen heb voorgesteld om hen uit te leggen waarom of hoe ik iets deed en dat ze zeiden dat ze het niet nodig vonden. Dus misschien is een deel van het probleem het hebben van gewillige kennisontvangers.
@Giliane Klinkt als aparte, maar nauw verwante problemen die tot hetzelfde doel leiden: in mijn geval wilden de kennisontvangers eigenlijk * leren *, maar ze hadden het echt te druk toen ik tijd had om les te geven, of hun supervisors weigerden hen downtime voor training omdat de supervisor de waarde niet inzag.
#7
+4
Tangurena
2012-04-13 04:59:50 UTC
view on stackexchange narkive permalink

Ik probeer altijd een wiki op te zetten om dingen te documenteren. Wiki's zijn eenvoudig en moedigen het toevoegen van stukjes en beetjes aan naarmate de tijd verstrijkt. Met formele documentatiesystemen lijkt het blanco papier overweldigend voor de gebruikers en wordt het daarom alleen ingevuld als je een pistool tegen hun hoofd legt. Ik loop meestal rond met een notitieboekje en ik typ dingen in de wiki zodat ze gemakkelijk kunnen worden gevonden - op deze manier kunnen jaarlijkse taken correct worden herhaald in plaats van opnieuw te moeten ontdekken hoe ze zouden moeten gebeuren.

Een vorige baas was alleen bereid om "volledige en volledige documenten" toe te staan, wat nooit werd gedaan. Hij verbood wiki's omdat hij geloofde dat ze laks denken en slechte documentatie aanmoedigden. Aangezien de vorige "volledige en volledige documenten" allemaal 5+ jaar oud waren op het moment dat ik wegging, kon het hem niet schelen dat zijn verlangens lijnrecht in tegenspraak waren met hoe zijn personeel werkte.

Alleen in het ergste noodgeval dat een kritisch persoon vertrok, maakte hij webcasts en nam hij op waarin hij door de code liep die alleen hij begreep. Dit was een van de weinige keren dat wanneer een medewerker opzegde, hij kennis overdroeg in plaats van aan dingen te werken tot de dag dat hij vertrok.

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

Dit is echt een beleidsprobleem, geen motiverend probleem. Werknemers met kritische kennis moeten de kans krijgen en deze documenteren, en het moet verplicht zijn. Als ze niet voldoende documentatie verstrekken en hun supervisors hen genoeg "vrije" tijd hebben gegeven om het te doen, moeten ze worden gestraft.

Het maakt niet uit hoeveel iemand weet of kan bereiken, als hij de enige is met die kennis, dan is hij aansprakelijk. Documentatie mag niet optioneel zijn.

Ik denk dat "discipline" een [waarschijnlijke] slechte benadering is - zolang de werknemer (s) productief blijft, zal het straffen ervan hen alleen maar aanmoedigen om te vertrekken: dat zal het doel teniet doen. Gebruik in plaats van negatieve bekrachtiging positieve bekrachtiging - een vorm van stimulans / voordeel voor het verstrekken van documentatie.


Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...