什麼是記住組織中的技術知識的最佳方式

Question

• 我們是否使用公司wiki？
• 你怎麼樣的技術文件保存爲源控制的一部分，然後讓來自不同源文件鏈接到他們（明白這是如何工作看文章...目錄...）

是什麼這些和其他方法的利弊？ 爲此目的的任何好工具？

如果您推薦Wiki， 您會推薦使用哪些Wiki？ 內部？託管？自由？付費？

Answer 1

我推薦使用wiki。它非常適合作爲中央文檔源，並具有內置修訂控制。你也可以通過URL參考代碼中的文檔。

Answer 2

如果你能鼓起支持，一個有聲望的社交媒體（像這個網站）可以在內部網上很好地工作極其。人們需要一點動力來提供知識庫。

Answer 3

我在過去使用過這兩種方法，並發現wiki格式是最容易接受的。在源代碼控制中存儲文檔可能會影響合併版本（顯然取決於正在使用的源代碼管理軟件和應用的方法）。基於wiki的解決方案也是如此，但由於某種原因，它似乎從未在我使用過的實現中出現嚴重問題。

主要wiki的可搜索性是其成功的另一個主要因素。在wiki中查找搜索詞比在可能不相關的代碼中找到對文檔的引用要容易得多。

< 2C/>

Answer 4

我喜歡維基百科。我甚至將它們用於我自己的業餘愛好項目，記錄我如何處理我不想再次處理的令人討厭的問題，或者維護對相關資源的引用列表。

有很多人爲這樣一個wiki貢獻的力量甚至更加強大，但討論的可能性也非常重要。

Answer 5

我實際上已經開始了一個解決它的副項目。它仍處於規劃階段，但我已經確定了一些技術知識保存在組織中的領域。現在，這不適用於每個組織，但每個組織至少使用其中之一。

• 人民
• 靜態網頁（Internet和Intranet）站點
• 圖書（公司庫）
• 圖書（個人的書籍）
• 動態Web（Internet和Intranet）站點
• 數據庫和知識庫

確切地說，你如何利用每個這些是不同的租用，但關鍵是讓人們使用靜態和/或動態網站來捕獲信息，或者至少確定它在書籍和存儲庫中的位置。如果人們不餵食知識庫，那麼使用什麼技術並不重要。這些知識必須是最新的，準確的，深入的，或者是無用的，從我所能收集到的。如Vinko Vrsalovic指出的另一個重要概念是將數據/信息/知識鏈接到推理的能力。需求分析中的一種常見做法是能夠將需求追溯到源頭。知識也應該這樣說。組織中的每個人都可以知道世界上的一切。然而，如果沒有人知道爲什麼知識是有用的或者在何時/何時使用這些知識，那就浪費了。

如果我想念任何，請隨時編輯這篇文章或回覆作爲評論。我認爲這個問題將有助於我的項目工作。

編輯1：增加了Vinko Vrsalovic，它不只是關於知識，而是將數據連接回知識所屬的生產問題。

Answer 6

肯定是一個wiki。我們使用TWiki並利用一些優秀的插件。

編輯：我忘了補充一點，您可能希望查閱關於文檔和版本控制的this question的答案。

Answer 7

維基的工作很好，但我們通過Ignite和Camtasia screencasts來補充Wiki。這些功能可以節省配置時間等。屏幕錄像很容易做到，速度也很快，您不必擔心是否爲觀衆拍攝了正確的細節，因爲它們回放/回放他們需要查看的部分。

我們已經嘗試過知識庫文章，它讓人懶惰 - 「我不明白這一節」意味着你會重寫一大堆。給一個人一個截屏，他們可以自己做筆記。

Answer 8

人是貴公司最有效的知識容器。而傳播知識的最有效方式是從人到人。 Wiki和文檔也很有用，但除非你的員工是優秀的技術撰稿人，否則書面文檔是轉移除最瑣碎知識之外的所有知識的一種可怕方式。作家需要花費數年才能寫出一本書，所以你不能指望開發人員在幾個小時內寫出質量文檔。

在組織中保持知識的最佳方式是讓人們一起工作。確保沒有人單獨工作。讓人們配對編程並查看每個其他代碼。組織技術會議等。

如果你真的想存儲知識的地方嘗試豐富數據。可以很容易地在wiki上添加白板等圖片。書面文件的另一個問題是人們似乎認爲漫長的抽象文本是'專業'的。確保你保持文檔簡潔，清晰，並且讓人們真正閱讀它。

Answer 9

無論解決方案如何，關於保留公司知識的最重要的事情是強制人們使用系統。維基是我的最愛，但如果沒有管理層或團隊領導的執法，它很難保持這種有用的知識水平 - 人們不喜歡記錄它，特別是當它使它們容易被替換時。

Answer 10

我會推薦MindTouch Deki。它不僅僅是一個wiki，它還集成到其他許多來源中，包括將其集成到組織中的自定義數據源中的能力。

Answer 11

使用維基，但要確保某人擁有編輯所有權。這個人需要確保遵守命名標準和文檔層次結構 - 公司wiki很容易變得亂七八糟。

Answer 12

我給你維基的，或一些缺點，其中一些額外的想法也許需要：

1. 如果技術知識/文檔與不具備你的維基
訪問客戶或組織共享
2. 與特定版本的軟件相關的文檔通常與版本相關的來源生活得更好。通常Wiki包含最新的信息，但它可能很難（取決於編輯的照顧）將文檔映射到舊版本

Answer 13

我認爲，您使用的工具並不重要。 真正重要的是，您團隊中的所有成員都會爲文檔的一個方向和一個地方而激烈競爭。

您可以使用維基或筆記數據庫或自制應用程序。

我個人比較喜歡所有的東西都在一個地方。因此對於技術文檔來說，源代碼管理系統將是正確的地方。 對於非開發人員使用的文檔，源代碼管理最初是錯誤的地方。對於全面的文檔，也許一個共享點服務器是您應該使用的工具。它具有某種版本控制功能，無需特殊的客戶端應用程序即可訪問。

Answer 14

Wiki很好，但他們最大的優點之一還沒有被提及。寫文檔的人往往找不到文檔中的缺陷，因爲作者不需要或不讀文檔。當作者休假或生病時，會發現缺陷，並且其他人試圖關注文檔，其中一部分不起作用。使用維基，任何可憐的傢伙最終都會發現文檔中的缺陷，可以立即糾正它，而不必通過電子郵件發送作者，將其埋在作者在度假期間獲得的其他數千封電子郵件中，或者試圖記住告訴作者在作者追回之後。

此外，請確保至少有兩個人知道如何去做所有事情，並且保持人員配置水平。當有人離開時，如果你已經有其他人可以做他們所做的一切，但是如果你現在有多個基礎設施或代碼只能被一個人理解，那麼你很容易就不能替換他們。從一個人到另一個人的知識轉移需要時間和上下班。這並不容易，但它比試圖從文檔中學習基礎架構或代碼庫更加容易。

Answer 15

我們使用項目博客和wiki的組合。

我認爲人們感覺有點被維基推遲 - 他們覺得他們需要至少輸入幾段才能證明這個入口 - 所以我們開始了一個博客，這對於捕捉小事或發生的事情很有用例如「我將列字段長度從40更改爲50」或「清除了比上週更早的審計表數據」。

我希望（希望）隨着項目進展，一些博客條目將成爲更長維基條目的源文件。

Answer 16

作爲wiki的替代品，請考慮使用SharePoint。它允許您處理事件（如會議），任務和文檔。它非常適合非技術人羣，這可能會使技術作家和管理人員看看發生了什麼。它也是Windows 2003的一部分，因此您可能不需要額外的許可證。

不利的一面，我幾乎可以保證，每個小UI都會有一個譴責你的譴責。上級可能會喜歡它。

Answer 17

我已經看到很多知識的討論發生在組織內的電子郵件中。這些知識長期保留在電子郵件中，最終會迷失方向，並且不屬於原始討論的其他人無法訪問。

使用像http://grexit.com這樣的工具可以幫助您將這些知識從您的收件箱移動到貴組織內的Coomon共享存儲庫。目前這隻適用於Gooogle Apps，但它值得嘗試。

Answer 18

你也許可以看看Associativy。它將知識片段存儲爲圖的節點，其中邊代表關聯（在人類意義上）連接。該圖可以多種方式搜索和探索，給定一組搜索條件，軟件可以「思考」一個合適的關聯。

我是開放源代碼，運行在Orchard CMS，也是一個開源項目。

這是一個無恥的插件（Associativy是我的項目），對不起。

編輯：剛剛意識到這個問題是如何老....