我們最近對公司範圍內的Wiki用戶進行了調查，發現有兩大類用戶：
每個小組幾乎50％的用戶！
貴公司如何處理此問題？也就是說，您如何鼓勵最忙/最有知識的人們分享他們的知識？
您可以向知識持有人指出，無論如何，他們很可能會花費大量時間來困擾問題。編寫Wiki條目是一項短期投資，從長遠來看會有所回報。如果他們不被問題困擾，那麼記錄文檔可能還不夠重要。需要學習該主題的人的觀點。它還有助於組織和鞏固他們的思想。讓更多的時間寫這篇文章並由專家運行以進行審查可能會非常有益。
我們的一位技術負責人制定了很好的政策，第三次遇到同樣的問題時，她寫下了答案並將其通過電子郵件發送給詢問的人和我們建立的Knowledge Wiki。由於她可能無論如何都要寫那封電子郵件，因此唯一的附加工作就是為Wiki添加地址。
我建議錄製大約45分鐘的截屏視頻。大家聚在一起，演示者進行屏幕錄像並傳播知識。 展示如何做某事，然後只是書面文檔（可能還包括額外的格式化時間，等等），更容易，更有效。
在我以前工作過的地方，他們每週或每月進行一次“午餐學習”。一個人提早吃午餐，並在他們進餐時為團隊做介紹。如果人們束縛時間，這可能會起作用。
轉移知識的最好方法是，需要知識的人與擁有知識的人一起工作。
知識淵博的人可能沒有時間自己記錄知識的工作，他們可能已經花了一些時間向他人解釋該怎麼做和如何做。
即使知識淵博的人有時間寫下他們的知識，不一定是他們製作的文檔將對知識淵博的人有用。試圖傳授知識時，很容易會錯過重要的' obvious '信息。
通過使知識轉移更加明確和合作，並使用戶受益文檔進行編寫，以便他們能夠理解它，這樣既可以減輕知識淵博的人的負擔，又可以傳遞更多的信息。
如果知識淵博的人真的是 / em>急於花費時間，您可以要求需要該知識的人寫下他們現在所了解的內容，然後讓知識淵博的人進行校對並糾正任何誤解。這樣可以大大加快工作速度，還可以幫助您確定缺少知識的領域。
例如，我從事科學軟件的研究。我和與我合作的設施科學家都無法單獨記錄我編寫的許多軟件。我可以解釋軟件的功能，甚至可以解釋為什麼這樣做，但是設施科學家需要編寫關於為什麼的文檔，並且如何訪問科學家應該使用它。
我的建議是預算每個項目的文檔編制時間，並將其作為您所做工作的一部分。如果您一直沒有這樣做，那麼您可能需要安排“ Documentation Days”來開始工作（例如，說午飯後的每個星期五，那些有知識的人可以從所有其他項目中解放出來，而只是從事編寫文檔的工作）。 / p>
在以前從未經歷過的事情中，很難將文檔文化帶入公司中，但是當您僱用新人並讓他們加快工作速度並獲得成功時，回報是顯而易見的在一周內獨立工作-例如，PostgreSQL項目具有維護優秀文檔的強烈文化。 他們的手冊比某些商業產品要好。
在經歷知識轉移方面，我的經歷有一個不幸的趨勢，那就是在接收端缺乏興趣。您可以讓該人願意對其他人進行大腦轉儲，但是如果對收據沒有興趣，為什麼專家會花時間？
當我要離開幾個在我工作的地方，我被要求這樣做，因為我是了解我所支持的系統的極少數人之一，但是當有人指派我來執行此任務時，我可以從他們的舉止中看出這對他們來說很麻煩對它沒有興趣。因此，我進行知識轉移的動力基本上減少了。
所以我唯一可以建議的就是確保接受知識的人實際上對該學科感興趣。詢問問題的聽眾確實會激發演講者的動力。
我總是嘗試建立一個Wiki來記錄事物。 Wiki很簡單，鼓勵隨著時間的流逝添加點點滴滴。在正式的文檔系統中，空白紙似乎對用戶不堪重負，結果只有當您將槍對准他們的頭時，空白紙才會被填寫。我通常會帶著筆記本走來走去，然後在Wiki中輸入內容，以便可以輕鬆找到它們-這樣，可以正確地重複執行年度任務，而不必重新發現它們應該如何發生。
以前的一位老闆只願意允許從未完成過的“完整文件”。他之所以禁止維基，是因為他相信維基鼓勵鬆懈的思維和不良的文檔。由於以前的“完整文件”在我離開時都是5歲以上，因此他不介意理解自己的願望與員工的工作方式直接相反。
只有在緊急情況下，當一個關鍵人物離開時，他才製作並記錄了僅通過他自己能理解的代碼進行演播的網絡廣播。這是當僱員發出通知時，他轉移知識而不是在他離開那天之前一直在從事工作的少數幾次。
這確實是一個政策問題，而不是動機問題。應該給具有關鍵知識的員工機會，並對其進行記錄，並且這應該是強制性的。如果他們沒有提供足夠的文檔，而他們的主管給了他們足夠的“自由”時間來這樣做，那麼他們應該受到紀律處分。
無論一個人知道多少知識或可以完成什麼，如果他們是唯一擁有這些知識的人，那麼這就是一種責任。文檔不應是可選的。