什么是记住组织中的技术知识的最佳方式

我们是否使用公司wiki？
你怎么样的技术文件保存为源控制的一部分，然后让来自不同源文件链接到他们（明白这是如何工作看文章...目录...）

是什么这些和其他方法的利弊？为此目的的任何好工具？什么是记住组织中的技术知识的最佳方式

如果您推荐Wiki， 您会推荐使用哪些Wiki？内部？托管？自由？付费？

来源

2008-10-07 RoyOsherove

我投票关闭这一问题作为题外话，因为它不是关于编程 – 2017-10-24 08:43:45

我推荐使用wiki。它非常适合作为中央文档源，并具有内置修订控制。你也可以通过URL参考代码中的文档。

来源

2008-10-07 11:57:23

我们在我们公司托管的TWiki服务器上使用TWiki。它工作的很好，但如果组织不好，可能会很麻烦。 – 2008-10-07 12:13:10

我想说，维基只能在你的组织没有达到一定规模之前工作。 – 2008-10-07 12:16:33

如果你能鼓起支持，一个有声望的社交媒体（像这个网站）可以在内部网上很好地工作极其。人们需要一点动力来提供知识库。

来源

2008-10-07 11:56:44

如果您不希望实现_STACK Overflow_然后你可以使用一个wiki并拥有一个“最佳贡献者”页面来简单地计算编辑次数等。 - 不完美，但是如果你匆忙，这是一个很好的激励。 – 2008-10-30 17:03:01

我在过去使用过这两种方法，并发现wiki格式是最容易接受的。在源代码控制中存储文档可能会影响合并版本（显然取决于正在使用的源代码管理软件和应用的方法）。基于wiki的解决方案也是如此，但由于某种原因，它似乎从未在我使用过的实现中出现严重问题。

主要wiki的可搜索性是其成功的另一个主要因素。在wiki中查找搜索词比在可能不相关的代码中找到对文档的引用要容易得多。

< 2C/>

来源

2008-10-07 11:58:56 ZombieSheep

我喜欢维基百科。我甚至将它们用于我自己的业余爱好项目，记录我如何处理我不想再次处理的令人讨厌的问题，或者维护对相关资源的引用列表。

有很多人为这样一个wiki贡献的力量甚至更加强大，但讨论的可能性也非常重要。

来源

2008-10-07 11:59:53 Rik

我实际上已经开始了一个解决它的副项目。它仍处于规划阶段，但我已经确定了一些技术知识保存在组织中的领域。现在，这不适用于每个组织，但每个组织至少使用其中之一。

人民
静态网页（Internet和Intranet）站点
图书（公司库）
图书（个人的书籍）
动态Web（Internet和Intranet）站点
数据库和知识库

确切地说，你如何利用每个这些是不同的租用，但关键是让人们使用静态和/或动态网站来捕获信息，或者至少确定它在书籍和存储库中的位置。如果人们不喂食知识库，那么使用什么技术并不重要。这些知识必须是最新的，准确的，深入的，或者是无用的，从我所能收集到的。如Vinko Vrsalovic指出的另一个重要概念是将数据/信息/知识链接到推理的能力。需求分析中的一种常见做法是能够将需求追溯到源头。知识也应该这样说。组织中的每个人都可以知道世界上的一切。然而，如果没有人知道为什么知识是有用的或者在何时/何时使用这些知识，那就浪费了。

如果我想念任何，请随时编辑这篇文章或回复作为评论。我认为这个问题将有助于我的项目工作。

编辑1：增加了Vinko Vrsalovic，它不只是关于知识，而是将数据连接回知识所属的生产问题。

来源

2008-10-07 12:00:15

肯定是一个wiki。我们使用TWiki并利用一些优秀的插件。

编辑：我忘了补充一点，您可能希望查阅关于文档和版本控制的this question的答案。

来源

2008-10-07 12:04:47

维基的工作很好，但我们通过Ignite和Camtasia screencasts来补充Wiki。这些功能可以节省配置时间等。屏幕录像很容易做到，速度也很快，您不必担心是否为观众拍摄了正确的细节，因为它们回放/回放他们需要查看的部分。

我们已经尝试过知识库文章，它让人懒惰 - “我不明白这一节”意味着你会重写一大堆。给一个人一个截屏，他们可以自己做笔记。

来源

2008-10-07 12:08:46

人是贵公司最有效的知识容器。而传播知识的最有效方式是从人到人。 Wiki和文档也很有用，但除非你的员工是优秀的技术撰稿人，否则书面文档是转移除最琐碎知识之外的所有知识的一种可怕方式。作家需要花费数年才能写出一本书，所以你不能指望开发人员在几个小时内写出质量文档。

在组织中保持知识的最佳方式是让人们一起工作。确保没有人单独工作。让人们配对编程并查看每个其他代码。组织技术会议等。

如果你真的想存储知识的地方尝试丰富数据。可以很容易地在wiki上添加白板等图片。书面文件的另一个问题是人们似乎认为漫长的抽象文本是'专业'的。确保你保持文档简洁，清晰，并且让人们真正阅读它。

来源

2008-10-07 12:10:36 Mendelt

无论解决方案如何，关于保留公司知识的最重要的事情是强制人们使用系统。维基是我的最爱，但如果没有管理层或团队领导的执法，它很难保持这种有用的知识水平 - 人们不喜欢记录它，特别是当它使它们容易被替换时。

来源

2008-10-07 12:12:49

我会推荐MindTouch Deki。它不仅仅是一个wiki，它还集成到其他许多来源中，包括将其集成到组织中的自定义数据源中的能力。

来源

2008-10-07 12:13:49

使用维基，但要确保某人拥有编辑所有权。这个人需要确保遵守命名标准和文档层次结构 - 公司wiki很容易变得乱七八糟。

来源

2008-10-07 12:14:52

我给你维基的，或一些缺点，其中一些额外的想法也许需要：

如果技术知识/文档与不具备你的维基
与特定版本的软件相关的文档通常与版本相关的来源生活得更好。通常Wiki包含最新的信息，但它可能很难（取决于编辑的照顾）将文档映射到旧版本

来源

2008-10-07 12:32:50 tonylo

我认为，您使用的工具并不重要。真正重要的是，您团队中的所有成员都会为文档的一个方向和一个地方而激烈竞争。

您可以使用维基或笔记数据库或自制应用程序。

我个人比较喜欢所有的东西都在一个地方。因此对于技术文档来说，源代码管理系统将是正确的地方。对于非开发人员使用的文档，源代码管理最初是错误的地方。对于全面的文档，也许一个共享点服务器是您应该使用的工具。它具有某种版本控制功能，无需特殊的客户端应用程序即可访问。

来源

2008-10-07 12:38:24 Jan

Wiki很好，但他们最大的优点之一还没有被提及。写文档的人往往找不到文档中的缺陷，因为作者不需要或不读文档。当作者休假或生病时，会发现缺陷，并且其他人试图关注文档，其中一部分不起作用。使用维基，任何可怜的家伙最终都会发现文档中的缺陷，可以立即纠正它，而不必通过电子邮件发送作者，将其埋在作者在度假期间获得的其他数千封电子邮件中，或者试图记住告诉作者在作者追回之后。

此外，请确保至少有两个人知道如何去做所有事情，并且保持人员配置水平。当有人离开时，如果你已经有其他人可以做他们所做的一切，但是如果你现在有多个基础设施或代码只能被一个人理解，那么你很容易就不能替换他们。从一个人到另一个人的知识转移需要时间和上下班。这并不容易，但它比试图从文档中学习基础架构或代码库更加容易。

来源

2008-10-07 15:18:30 Glomek

我们使用项目博客和wiki的组合。

我认为人们感觉有点被维基推迟 - 他们觉得他们需要至少输入几段才能证明这个入口 - 所以我们开始了一个博客，这对于捕捉小事或发生的事情很有用例如“我将列字段长度从40更改为50”或“清除了比上周更早的审计表数据”。

我希望（希望）随着项目进展，一些博客条目将成为更长维基条目的源文件。

来源

2008-10-07 16:10:11 Rikalous

作为wiki的替代品，请考虑使用SharePoint。它允许您处理事件（如会议），任务和文档。它非常适合非技术人群，这可能会使技术作家和管理人员看看发生了什么。它也是Windows 2003的一部分，因此您可能不需要额外的许可证。

不利的一面，我几乎可以保证，每个小UI都会有一个谴责你的谴责。上级可能会喜欢它。

来源

2008-10-07 16:23:03

我已经看到很多知识的讨论发生在组织内的电子邮件中。这些知识长期保留在电子邮件中，最终会迷失方向，并且不属于原始讨论的其他人无法访问。