Frage:
Wie übertragen Ihre meistbeschäftigten Personen ihr Wissen?
Reinstate Monica - Goodbye SE
2012-04-13 02:22:23 UTC
view on stackexchange narkive permalink

Wir haben kürzlich unsere unternehmensweiten Wiki-Benutzer befragt und festgestellt, dass es zwei große Benutzergruppen gibt:

  • Personen mit viel Wissen aber (die behaupten) Sie haben) keine Zeit, um
  • Personen mit Zeit zu dokumentieren, aber (die behaupten, sie haben) nicht genug Wissen, das es wert ist, dokumentiert zu werden

Jede abgedeckte Gruppe Fast 50% der Nutzer!

Wie gehen Ihre Unternehmen damit um? Das heißt, wie ermutigen Sie Ihre meistbeschäftigten / sachkundigsten Personen, ihr Wissen zu teilen?

verwandte PM.SE q: [Wie ermutigen Sie Projektmitglieder, ihre Arbeit für die Übergabe am Ende des Projekts zu dokumentieren?] (http://pm.stackexchange.com/q/799/167)
Acht antworten:
#1
+26
Karl Bielefeldt
2012-04-13 02:43:06 UTC
view on stackexchange narkive permalink

Sie können die Wissensinhaber darauf hinweisen, dass sie wahrscheinlich sowieso viel Zeit damit verbringen, von Fragen belästigt zu werden. Das Schreiben eines Wiki-Eintrags ist eine kurzfristige Investition, die sich langfristig auszahlt. Wenn sie nicht von Fragen belästigt werden, ist es wahrscheinlich nicht wichtig genug, sie zu dokumentieren.

Außerdem sind die Wissensempfänger eine bessere Wahl, um einen Wiki-Artikel zu schreiben, als Sie vielleicht denken, weil sie den Sinn von verstehen Ansicht von jemandem, der das Thema lernen muss. Es hilft auch, ihre Gedanken zu organisieren und zu festigen. Es könnte sehr nützlich sein, wenn jemand mit mehr Zeit den Artikel schreibt und ihn vom Guru zur Überprüfung ausführt.

+1 für das Schreiben durch den Empfänger. Manchmal verstehen Inhaber und Empfänger denselben Satz unterschiedlich.
Einverstanden, dass der Empfänger es schreibt, aber die Wissensinhaber / Experten es an zwei Fronten überprüfen lassen: Korrektheit und Vollständigkeit. Gute Dokumentation erklärt sowohl das Wie als auch das * Warum *.
+1 Die Annahme, dass Wissensinhaber auch gut dokumentieren können, ist ein Irrtum. Ganz zu schweigen von wertvoller Zeit und gutem Karma, das wir sparen, indem wir die richtigen Leute für den Job einstellen.
@voretaq7, ist einer der großen Vorteile eines Wikis die Bearbeitung. Veröffentlichen Sie das Gelernte, markieren Sie die Teile, bei denen Sie sich nicht sicher sind, und lassen Sie entweder das KMU oder die * nächste * Person, die diesen Build kennen muss, von dort aus bauen.
@MonicaCellio Einverstanden - Wikis sind großartige Ressourcen. Leider kann die Community-Bearbeitung auch ein Nachteil sein, wenn jemand missverstandene / falsche Informationen bearbeitet und vergisst, diese als "unsicher" zu markieren. Letztendlich ist ein Wiki nur so gut wie die Leute, die es auf Richtigkeit überprüfen :-)
auch - die Empfänger können den "Q" -Teil des Wikis schreiben, und die Inhaber können das "A" schreiben.
Ich finde, dass Wikis einfach nicht genug gelesen oder bearbeitet werden, um die Mühe wert zu sein.Ich habe gesehen, wie sie bei mehreren Jobs ausprobiert wurden und noch nie eine Arbeit gesehen haben.
#2
+15
HLGEM
2012-04-13 03:33:59 UTC
view on stackexchange narkive permalink

Eine unserer technischen Leiterinnen hat eine großartige Richtlinie. Wenn sie zum dritten Mal dieselbe Frage erhält, schreibt sie die Antwort auf und sendet sie per E-Mail an die fragende Person und an das von uns eingerichtete Wissens-Wiki. Da sie diese E-Mail wahrscheinlich sowieso schreiben würde, besteht die einzige zusätzliche Arbeit darin, die Adresse für das Wiki hinzuzufügen.

Gute allgemeine Richtlinien - wenn Sie dreimal danach gefragt wurden, ist es wichtig zu dokumentieren. Als Bonus haben Sie wahrscheinlich auch genug darüber nachgedacht, um eine gute, kohärente Antwort für die offizielle Dokumentation zu erhalten. (Dies ist auch die Regel, die ich für die Automatisierung von Aufgaben verwende: Wenn sie zum dritten Mal ausgeführt werden muss, sollte sie automatisiert werden.)
@voretaq7, Ich dachte, der Teil über das Anschließen des Wikis an eine E-Mail, um Wiki-Themen zu überprüfen, war selbst inspiriert. Es ist so viel einfacher, Wissen zu dokumentieren, wenn Sie einer E-Mail, die Sie sowieso schreiben wollten, lediglich eine weitere E-Mail-Adresse hinzufügen müssen.
Warum dreimal warten, wenn jemand die Frage gestellt hat, besteht die Wahrscheinlichkeit, dass dies jemand anderes tut. Dokumentieren Sie sie also und senden Sie ihm per E-Mail einen Link zu den aktualisierten Dokumenten. Scott Hanselman spricht in seinem Blog hier über die Idee, Ihre Tastenanschläge zu erhalten: http://www.hanselman.com/blog/DoTheyDeserveTheGiftOfYourKeystrokes.aspx
@ridecar2 Ich bin kein Experte, aber ich würde den gleichen Grund sagen, warum ich bis zum dritten Mal warte, um eine Aufgabe zu automatisieren: Manchmal ist es die schnellere / bessere Lösung, wenn es nur einmal passiert, und oft nicht Ich weiß, dass es sich beim ersten Mal wiederholen wird. Beim dritten Mal nähern Sie sich normalerweise einem Kosten-Nutzen-Wendepunkt, an dem es offensichtlich ist, dass die Aufgabe immer wieder auftaucht und sich die Arbeit zum Dokumentieren oder Automatisieren auf lange Sicht definitiv auszahlt.
Es gibt keine zusätzlichen Kosten für das Erstellen eines Blogposts für das Erstellen einer E-Mail. Warum also nicht gleich den Blogpost veröffentlichen? Ich stimme der Automatisierung von Aufgaben zu, bei denen das Einrichten schwierig ist. Darum ging es mir jedoch nicht.
#3
+6
Atif
2012-04-13 02:41:21 UTC
view on stackexchange narkive permalink

Ich schlage vor, Screencasts von ca. 45 Minuten aufzunehmen. Bringen Sie alle zusammen und der Moderator macht einen Screencast und überträgt das Wissen. Es ist einfacher und effektiver, zu zeigen , wie etwas zu tun ist, als nur eine schriftliche Dokumentation (die möglicherweise auch zusätzliche Zeit für die Formatierung usw. enthält).

An einem Ort habe ich früher gearbeitet Sie hatten wöchentlich oder monatlich ein "Lunch n'learn". Ein Mann isst früh zu Mittag und hält eine Präsentation für das Team, während sie essen. Dies kann funktionieren, wenn die Zeit knapp wird.

+1 tolle Idee! Wir hatten eine ähnliche Idee, und das Unternehmen würde ein Mittagessen anbieten, um die Teilnahme zu fördern.
Mittagessen und Lernen ist eine schreckliche Praxis.Wenn es wichtig genug ist, um zu trainieren, sollte es gemacht werden, wenn Sie nicht während einer Pause auf der Uhr sind. Die Mittagszeit sollte NIEMALS Arbeit beinhalten.
@HLGEM - Ich bin ein * RIESIGER * Anhänger von Lunch & Learns.Sie wurden jedoch nie als Pausenzeit gezählt, als ich beteiligt war. Ich glaube auch, dass der Fachexperte auf einem bestimmten Gebiet * NICHT * derjenige sein sollte, der die Präsentation hält.Die beste Vorgehensweise, die ich gesehen habe, besteht darin, mittlere und junge Mitarbeiter mit der Vorbereitung der Präsentationen zu beauftragen.Sie kommen mit weniger Annahmen dazu und machen es zugänglicher.und wenn sie sich darauf vorbereiten, lernen sie es.
Ich bin nicht gegen diese Art von Training, nur dass es niemals beim Mittagessen durchgeführt werden sollte, das normalerweise nicht bezahlt wird und nicht zum Unternehmen gehört.Es ist genauso schlimm, als mich zu bitten, nach dem Abendessen zu trainieren.Es gibt einen guten Grund, warum Mittagspausen in vielen Ländern gesetzlich vorgeschrieben sind.
#4
+6
Mark Booth
2012-04-17 19:14:11 UTC
view on stackexchange narkive permalink

Der beste Weg, Wissen zu übertragen, ist für die Personen, die das Wissen benötigen, um mit denjenigen zusammenzuarbeiten, die über das Wissen verfügen.

Während die sachkundigen Personen möglicherweise nicht die Zeit dazu haben Wenn sie daran arbeiten, ihr Wissen selbst zu dokumentieren, verbringen sie möglicherweise bereits einen Teil ihrer Zeit damit, anderen zu erklären, was zu tun ist und wie es zu tun ist.

Selbst wenn die sachkundigen Personen die Zeit hatten, ihr Wissen aufzuschreiben, ist es Es ist nicht unbedingt so, dass die von ihnen erstellte Dokumentation für weniger sachkundige Personen von Nutzen wäre. Es ist überraschend leicht, wichtige ' offensichtliche ' Informationen zu verpassen, wenn versucht wird, Wissen zu vermitteln.

Indem der Wissenstransfer expliziter und kooperativer gestaltet wird und die Benutzer davon betroffen sind Wenn Sie die Dokumentation so schreiben, dass sie sie verstehen können, können Sie sowohl die sachkundigen Personen entlasten als auch mehr Informationen übertragen.

Wenn die sachkundigen Personen wirklich jetzt verstehen, und dann die sachkundigen Personen Korrekturen vorlesen und etwaige Missverständnisse korrigieren lassen. Dies könnte die Dinge erheblich beschleunigen und auch dazu beitragen, Bereiche zu identifizieren, in denen das Wissen fehlt.


Als Beispiel hierfür arbeite ich an wissenschaftlicher Software. Weder ich noch die Facility-Wissenschaftler, mit denen ich zusammenarbeite, konnten allein einen Großteil der von mir geschriebenen Software dokumentieren. Ich könnte erklären, was meine Software macht und sogar warum es so macht, aber es sind die Wissenschaftler der Einrichtung, die Dokumentation über warum und schreiben müssen wie Gastwissenschaftler es verwenden sollten.

Dies ist in der Tat genau eine der Lösungen, die wir in Betracht gezogen haben. es ähnelt der Idee der * Lehre *. Zusätzlich kann der Auszubildende (der wahrscheinlich mehr Zeit hat) als dokumentieren, was er gelernt hat.
#5
+5
voretaq7
2012-04-13 03:20:54 UTC
view on stackexchange narkive permalink

Mein Vorschlag ist, die Dokumentationszeit für jedes Projekt zu budgetieren und es zu einem festen Bestandteil Ihrer Arbeit zu machen. Wenn Sie das die ganze Zeit nicht getan haben, müssen Sie wahrscheinlich "Dokumentationstage" einplanen, um die Dinge zu beschleunigen (sagen wir beispielsweise, jeden Freitag nach dem Mittagessen werden diejenigen mit dem Wissen von allen anderen Projekten befreit und arbeiten nur daran, Dokumentation zu schreiben).

Es kann schwierig sein, die Dokumentationskultur in ein Unternehmen zu bringen, wenn dies noch nie Teil der bisherigen Vorgehensweise war. Die Belohnungen sind jedoch offensichtlich, wenn Sie eine neue Person einstellen und sie auf den neuesten Stand bringen können Innerhalb einer Woche unabhängig arbeiten - Zum Beispiel hat das PostgreSQL-Projekt eine starke Kultur der Aufrechterhaltung einer exzellenten Dokumentation. Ihr Handbuch ist besser als einige kommerzielle Produkte.

Im Prinzip stimme ich zu, aber ich habe oft gesehen, dass die Dokumentation wegen kurzfristigen Denkens mit einer Projektfrist übersprungen wurde.
@Wikis Schlechte Unternehmenskultur IMHO. Die Dokumentation ist Teil des Produkts (in meinem Fall wörtlich: Internationale Standards und Bundesvorschriften verlangen dies für Hersteller von Medizinprodukten, damit ich nicht zu viel darüber streiten muss. Ich habe Glück :-)
#6
+4
Karlson
2012-04-13 02:33:21 UTC
view on stackexchange narkive permalink

Nach meiner Erfahrung gibt es einen unglücklichen Trend beim Wissenstransfer, und das ist das mangelnde Interesse auf der Empfängerseite . Sie könnten die Person bereit haben, den Brain Dump an eine andere Person weiterzugeben, aber wenn kein Interesse an deren Erhalt besteht, warum sollte sich der Experte dann die Zeit nehmen?

Als ich mehrere verließ An Orten, an denen ich arbeitete, wurde ich gebeten, dies zu tun, weil ich einer der wenigen war, die die von mir unterstützten Systeme verstanden, aber als mir jemand für diese Aufgabe zugewiesen wurde, konnte ich an ihrem Verhalten erkennen, dass dies für sie und sie störend war hatte kein Interesse daran. Meine Motivation für den Wissenstransfer war also im Grunde genommen auf nichts reduziert.

Das einzige, was ich zu diesem Thema vorschlagen könnte, ist sicherzustellen, dass die Person, die Wissen erhält, tatsächlich an dem Thema interessiert ist. Gefangenes Publikum, das Fragen stellt, wirkt Wunder für die Motivation des Sprechers.

+1 - Als einer der "beschäftigtsten Leute" fällt es mir oft schwer, Zeit von * allen anderen * zu bekommen, um sie richtig zu trainieren.
+1 - @voretaq7 - Es gab viele Male, in denen ich anderen vorgeschlagen habe, ihnen zu erklären, warum oder wie ich etwas getan habe, und sie sagen zu lassen, dass sie es nicht für notwendig hielten. Vielleicht liegt ein Teil des Problems darin, willige Wissensempfänger zu haben.
@Giliane Klingt nach getrennten, aber eng verwandten Problemen, die zum gleichen Ziel führen: In meinem Fall wollten die Wissensempfänger tatsächlich * lernen *, aber entweder waren sie wirklich zu beschäftigt, als ich Zeit zum Unterrichten hatte, oder ihre Vorgesetzten weigerten sich, sie zuzulassen Ausfallzeit für das Training, weil der Supervisor den Wert nicht gesehen hat.
#7
+4
Tangurena
2012-04-13 04:59:50 UTC
view on stackexchange narkive permalink

Ich versuche immer, ein Wiki einzurichten, um Dinge zu dokumentieren. Wikis sind einfach und ermutigen dazu, im Laufe der Zeit Kleinigkeiten hinzuzufügen. Bei formalen Dokumentationssystemen erscheint das leere Papier den Benutzern überwältigend und wird daher nur ausgefüllt, wenn Sie eine Waffe an den Kopf legen. Normalerweise gehe ich mit einem Notizbuch herum und gebe Dinge in das Wiki ein, damit sie leicht gefunden werden können. Auf diese Weise können jährliche Aufgaben korrekt wiederholt werden, anstatt neu entdecken zu müssen, wie sie passieren sollten.

Ein früherer Chef war nur bereit, "vollständige Dokumente" zuzulassen, die nie erstellt wurden. Er verbot Wikis, weil er glaubte, dass sie nachlässiges Denken und schlechte Dokumentation förderten. Da die vorherigen "vollständigen und vollständigen Dokumente" zum Zeitpunkt meiner Abreise alle mehr als 5 Jahre alt waren, wollte er nicht verstehen, dass seine Wünsche in direktem Widerspruch zur Arbeitsweise seiner Mitarbeiter standen.

Nur im schlimmsten Notfall, als eine kritische Person ging, erstellte und zeichnete er Webcasts auf, in denen er den Code durchging, den nur er verstand. Dies war eines der wenigen Male, dass ein Mitarbeiter, als er kündigte, Wissen weitergab, anstatt bis zu seiner Abreise an Dingen zu arbeiten.

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

Dies ist wirklich ein politisches Problem, kein Motivationsproblem. Mitarbeitern mit kritischem Wissen sollte die Möglichkeit gegeben werden, es zu dokumentieren, und es sollte obligatorisch sein. Wenn sie nicht genügend Unterlagen vorlegen und ihre Vorgesetzten ihnen genügend "freie" Zeit dafür gegeben haben, sollten sie diszipliniert werden.

Egal wie viel eine Person weiß oder erreichen kann, wenn sie die einzige Person mit diesem Wissen ist, sind sie haftbar. Die Dokumentation sollte nicht optional sein.

Ich denke, dass "Disziplin" ein [wahrscheinlich] schlechter Ansatz ist - solange die Mitarbeiter produktiv bleiben, werden sie durch Bestrafung nur zum Verlassen ermutigt: was den Zweck zunichte macht. Verwenden Sie anstelle einer negativen Verstärkung eine positive Verstärkung - eine Art Anreiz / Vorteil für die Bereitstellung von Dokumentation.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...