这些和其他方法的优点和缺点是什么？ 为此目的的任何好工具？
如果您推荐维基 你会推荐使用哪些维基？ 内部？托管？自由？支付？
答案 0 :(得分：20)
我建议使用维基。它作为中央文档源非常有效，并具有内置的版本控制。您也可以通过网址引用代码中的文档。
答案 1 :(得分：9)
人是您公司中最有效的知识容器。转移知识的最有效方式是从人到人。 Wiki和文档也很有用，但除非你的员工是伟大的技术作家，否则书面文档是传递除了最琐碎知识以外的所有知识的可怕方式。作家花了数年时间写一本书，所以你不能指望开发人员在几个小时内写出高质量的文档。
保持组织知识的最佳方式是让人们一起工作。确保没有人独自工作。让人们配对并审查彼此的代码。组织技术会议等。
如果你真的想在某个地方存储知识，试着丰富数据。可以轻松地将白板等图片添加到维基。书面文档的另一个问题是人们似乎认为长篇大论的抽象文本是“专业的”。确保您保持文档简短，清晰，重要，以便人们真正阅读它。
答案 2 :(得分：6)
如果您能够获得支持，那么具有声誉的社交媒体（如此网站）可以在Intranet上非常工作。人们需要一点动力来养活知识库。
答案 3 :(得分：3)
我会推荐MindTouch Deki。它不仅仅是一个wiki，还集成了许多其他来源，包括将其集成到组织中的自定义数据源中的能力。
答案 4 :(得分：2)
Wiki的工作做得很好，但我们用Ignite和Camtasia的截屏视频补充了Wiki。这些节省了描述配置等的时间。屏幕录像很容易做到，快速，您不必担心是否为您的受众捕获了正确的细节，因为他们回放/重播他们需要审阅的部分。 / p>
我们已经尝试过知识库文章，它让人们变得懒惰 - “我不明白这一部分”意味着你将重写一大堆。给一个人一个截屏视频，他们可以自己做笔记。
答案 5 :(得分：2)
无论解决方案如何，保留公司知识的最重要的一点是强制人们使用系统。维基是我最喜欢的，但如果没有管理层或团队领导的强制执行，很难保持这种有用的知识水平 - 人们讨厌记录它，特别是当它很容易被替换时。
答案 6 :(得分：2)
维基很好，但尚未提及其最大优势之一。编写者通常不会发现文档中的缺陷，因为作者不需要或阅读文档。当作者休假或生病时会发现缺陷，而其他人则试图遵循文档，其中部分内容无效。使用Wiki，任何可怜的家伙最终发现文档中的缺陷都可以立即纠正它，而不必通过电子邮件发送给作者，将其隐藏在作者在度假时获得的其他一千封电子邮件中，或者试图记住告诉作者回来之后的作者。
此外，确保至少有两个人知道如何做所有事情，维持人员配置水平。当有人离开时，如果你已经有其他人可以做他们所做的一切，那么你可能很难取代他们，但如果你现在拥有多个基础设施或代码，每个人只能被一个人理解，那么你就很脆弱。从一个人到另一个人的知识转移需要时间和工作。这并不容易，但它比仅仅从文档中学习基础架构或代码库要容易得多。
答案 7 :(得分：1)
我实际上已经开始了一个解决它的副项目。它仍处于规划阶段，但我已经确定了一些技术知识保存在组织中的领域。现在，这并不适用于每个组织，但每个组织至少使用其中一个组织。
确切地说，如何利用这些中的每一个都是不同的，但关键是让人们使用静态和/或动态网站来捕获信息，或者至少确定它在书籍和存储库中的位置。如果人们没有喂养知识室，那么使用什么技术并不重要。从我能够收集到的知识来看，这些知识必须是最新的，准确的，深入的，或者是徒劳的。
正如Vinko Vrsalovic指出的那样，另一个重要的关键概念是将数据/信息/知识与其推理联系起来的能力。需求分析中的常见做法是将需求跟踪到其来源的能力。知识也应如此。组织中的每个人都可以了解世界上的一切。但是，如果没有人知道为什么知识是有用的，或者何时/何时使用这些知识，那就浪费了。
如果我遗失了任何内容，请随时编辑此帖或回复评论。我认为这个问题将有助于我的项目工作。
编辑1：Vinko Vrsalovic补充说，这不仅仅是知识，而是将数据链接回知识所涉及的生产问题。
答案 8 :(得分：1)
我喜欢维基。我甚至将它们用于我自己的爱好项目，记录我如何解决我不想再次处理的令人讨厌的问题，或维护一份对相关资源的引用列表。
让很多人为这样的wiki做出贡献更加强大，但讨论的可能性也非常重要。
答案 9 :(得分：1)
我过去曾使用过这两种方法，并发现wiki格式是最容易接受的。在源代码管理中存储文档会对合并版本产生影响（显然取决于使用的源代码控制软件和应用的方法）。基于wiki的解决方案也是如此，但由于某些原因，它在我使用的实现中似乎从来没有出现过大问题。
主要维基的可搜索性是其成功的另一个主要因素。在维基中查找搜索词比在可能不相关的代码段中查找对文档的引用要容易得多。
＆lt; 2c /＆gt;
答案 10 :(得分：1)
我已经看到在组织内的电子邮件中发生了很多知识讨论。这些知识会长时间保留在电子邮件中，最终会丢失，并且不属于原始讨论的其他人无法访问。
使用http://grexit.com之类的工具可以帮助您将这些知识从您的收件箱中移出到组织内的coomon共享存储库。目前，这仅适用于Gooogle Apps，但值得一试。
答案 11 :(得分：0)
绝对是一个维基。我们使用TWiki并使用一些优秀的插件。
编辑：我忘了补充一点，您可能想查阅有关文档和版本控制的this question的答案。
答案 12 :(得分：0)
使用维基，但要确保某人对所发生的内容拥有编辑所有权。该人需要确保命名标准并遵守文档层次结构 - 公司维基很容易成为一个庞大的混乱。
答案 13 :(得分：0)
我会给你一些Wiki的缺点，或者可能需要额外的想法：
答案 14 :(得分：0)
我认为，您使用的工具并不那么重要。 最重要的是，团队中的所有成员都会在文档的一个方向和一个位置上进行聚合。
您可以使用Wiki或笔记数据库或自酿应用程序。
我个人更喜欢所有的东西都放在一个地方。因此，对于技术文档，源控制系统将是正确的位置。 对于非开发人员使用的文档，源代码控制肯定是错误的。对于全面的文档，也许一个sharepoint服务器是你应该使用的工具。它具有某种版本控制，无需特殊的客户端应用程序即可访问。
答案 15 :(得分：0)
我们使用项目博客和wiki的组合。
我认为人们觉得wiki有点推迟 - 他们认为至少需要输入几段才能证明这一条目是合理的 - 所以我们开设了一个博客，它可以捕捉发生在我身上的小事或事情。实时，例如，'我将列字段长度从40更改为50'或'清除过去一周的审核表数据'。
我希望（希望）随着项目的进展，一些博客条目将成为更长的wiki条目的源材料。
答案 16 :(得分：0)
作为Wiki的替代方案，请考虑使用SharePoint。它允许您处理事件（如会议），任务和文档。它非常适合非技术人群，这可能让技术作家和管理人员看看正在发生的事情。它也是Windows 2003的一部分，因此您可能不需要额外的许可证。
在不利方面，我几乎可以保证会有一个luddite会因为每个小的UI狡辩而责备你。高层可能会喜欢它。
答案 17 :(得分：0)
您可以查看Associativy。它将知识片段存储为图形的节点，其中边缘表示关联（在人类意义上）连接。该图表可以通过多种方式进行搜索和探索，给定一组搜索术语，软件能够“思考”合适的关联。
我是开源的，并在Orchard CMS上运行，这也是一个开源项目。
这是一个无耻的插件（Associativy是我的项目），对不起。
编辑：刚认识到这个问题有多久了......