問題描述
你如何開始知識轉移？ (How do you start Knowledge Transfer?)
您是否使用正式的活動來讓 IT 部門的人們交談？就像在社交場所舉行的每月聚會、內部 wiki/聊天空間或只是一個定期的“信息市場”，其中包含一些關於技術或項目的介紹 由您的員工為您的員工製作？您是邀請銷售人員參加，還是僅限程序員參加的封閉式活動？
您如何讓人們參加這些活動？你允許他們把工作時間花在知識轉移上嗎？還是您將其理解為工作時間的一個組成部分？
我想知道如何監控知識轉移本身的進度。您如何在項目中發現關鍵的單人失敗點？有幾種方法可以避免，比如人員調換或修復錯誤的“fifo”嘗試。
注意： 好的，這是一個非常嘈雜的問題，我希望在發表一些評論後修復它。很抱歉混淆了。
編輯：我個人的經驗是，人們開始貢獻的門檻非常高。看起來他們不會花（最少的）額外時間來編輯我們的 wiki，或者在下午花一個小時與開發人員討論技術話題。就像人們不喜歡我們的 wiki、文檔管理系統或會議一樣。也許是因為它都是免費使用的，而不是管理層強迫的。但我不喜歡強迫人們加入它——但這是正確的方式嗎？
一個例子：我們的 wiki 包含有關項目的頁面，告訴誰在它上面工作，以便在遇到問題時獲得第一次聯繫。但是除了我和我的同事之外，沒有人在創建這個頁面......
參考解法
方法 1:
I think all of the above. But you're forgetting the most important way.
The most efficient way to transfer knowledge is to have people work together. You might think about doing 1 on 1 code reviews or even pair programming and make knowledge transfer an intergral part of the work.
方法 2:
Knowledge Transfer and Knowledge Management have one drawback. They seem to cost an aweful lot: if everybody knows what I know, am I still needed? All the time I use to bring others up to speed, what do I gain from it?
The best way to go about this is to be an example. Share your knowledge; in a wiki, blog about it, talk about it, make it easily accessible, and talk about the benefits you have from that: less people come to interupt and ask you stuff, as they can get an answer easily without even getting up. And show them that you are still there.
This with all the other things mentioned will actually win out. One more thing: one of my employers kept on paying me 1/3 of my salary for another year after I left (on my own initiative), just to keep my knowledge‑base up and running. Did he have to? No, it was his property anyway. But it motivated people still working for him to share their knowledge.
方法 3:
I think it depends on the knowledge you are trying to transfer. I've found the following:
Technical Knowledge: "How to guide" with screenshots and a short demo ‑ similar to the way you will see new features at a conference. The added benefit of this is what you have got is documented for when you leave the company.
Problem solving: informal discussions, short internal projects, lessons learned and an internal FAQ system which EVERYONE is responsible for updating.
Soft Skills (people skills): social meetings/outings/informal events etc.
Measuring that is going to be difficult though, as no matter how you transfer your knowledge there will always be varying degrees of uptake, after all, just because I do something one way doesnt mean its correct. Another developer/designer/manager may have a different way of doing the same thing with the same end result.
Mauro
方法 4:
At my workplace we use a wiki. The workplace is small enough (~20 people) so that you can always ask the person who was most involved in a particular project, however it is expected that you have searched on the wiki before you ask "the expert". If you cannot find your answer in the wiki, then you should add it after you have discussed it with your co‑worker.
方法 5:
One word: Lunch
(by cringe、Mendelt、Ralph M. Rickenbach、Mauro、Einar、Matthias Winkelmann)