- 我们使用公司维基吗？
- 您如何将技术文档保存为源代码控制的一部分，然后从各种源文件中获得指向它们的链接（要了解其工作原理，请参阅目录中的文章...）
这些方法和其他方法的优缺点是什么？为此目的有什么好的工具吗？
如果您推荐一个 wiki， 您会推荐使用哪些 Wiki？内部的？托管？自由？有薪酬的？
2073 次
18 回答
20
我建议使用维基。它作为中央文档源工作得非常好，并具有内置的修订控制。您还可以通过 URL 引用代码中的文档。
于 2008-10-07T11:57:23.353 回答
9
人是贵公司最有效的知识容器。而最有效的知识转移方式是人与人之间的交流。Wiki 和文档也很有用，但除非您的员工是出色的技术作家，否则书面文档是一种传递除最琐碎知识之外的所有知识的糟糕方式。作家需要花费数年时间才能写出一本书，因此您不能指望开发人员在几个小时内就能编写出高质量的文档。
在您的组织中保持知识的最佳方式是让人们一起工作。确保没有人单独工作。让人们结对编程并检查彼此的代码。组织技术会议等。
如果您真的想将知识存储在某个地方，请尝试丰富数据。轻松将白板图片等添加到 wiki。书面文档的另一个问题是人们似乎认为冗长的抽象文本是“专业的”。确保您的文档简短、清晰且中肯，以便人们真正阅读它。
于 2008-10-07T12:10:36.183 回答
6
如果您能够获得支持，那么具有声誉的社交媒体（例如这个网站）可以在 Intranet 上运行得非常好。人们需要一些激励来充实知识库。
于 2008-10-07T11:56:44.260 回答
3
我会推荐MindTouch Deki。它不仅仅是一个 wiki，还集成了许多其他来源，包括将其集成到组织中的自定义数据源中的能力。
于 2008-10-07T12:13:49.140 回答
2
Wiki 运行良好，但我们用 Ignite 和 Camtasia 截屏视频补充了 Wiki。这些可以在描述配置等时节省时间。截屏视频操作简单、快捷，您不必担心是否为观众捕捉到了正确的细节，因为他们可以倒带/重播他们需要查看的部分。
我们已经尝试过知识库文章，但它让人们变得懒惰——“我不明白这部分”意味着你将重写一大堆。给一个人一个截屏视频，他们可以自己做笔记。
于 2008-10-07T12:08:46.420 回答
2
无论解决方案如何，在公司中保留知识的最重要的事情就是强制人们使用该系统。Wiki 是我的最爱，但如果没有管理层或团队领导的强制执行，很难保持这种有用的知识水平——人们似乎讨厌记录它，尤其是当它使它们很容易被替换时。
于 2008-10-07T12:12:49.983 回答
2
Wiki 很好，但尚未提及其最大优势之一。很多时候，文档中的缺陷不是由编写它的人发现的，因为作者不需要或阅读文档。当作者休假或生病时发现缺陷，并且其他人试图遵循文档并且其中一部分不起作用。使用 Wiki，任何可怜的家伙最终发现文档中的缺陷都可以立即纠正它，而不必给作者发电子邮件，因为它被埋在作者度假时收到的其他数千封电子邮件中，或者试图记住告诉作者回来后的作者。
此外，确保至少有两个人知道如何做所有事情，并保持人员配备水平。当有人离开时，如果您已经有其他人可以做他们所做的一切，那么不替换他们可能是非常诱人的，但是如果您现在拥有多个基础设施或代码，每一个都只能由一个人理解，那么您很容易受到攻击. 知识从一个人转移到另一个人需要时间和动手工作。这并不容易，但它比尝试仅从文档中学习基础设施或代码库要容易得多。
于 2008-10-07T15:18:30.907 回答
1
我过去使用过这两种方法，发现 wiki 格式是最容易接受的。在源代码控制中存储文档可能会对合并版本产生影响（显然取决于使用的源代码控制软件和应用的方法）。基于 wiki 的解决方案也是如此，但由于某种原因，它似乎从未在我使用的实现中出现过大问题。
主要 wiki 的可搜索性是其成功的另一个主要因素。在 wiki 中查找搜索词比在可能不相关的代码段中查找对文档的引用要容易得多。
<2c />
于 2008-10-07T11:58:56.410 回答
1
我喜欢维基。我什至将它们用于我自己的爱好项目，记录我如何解决我不想再次处理的令人讨厌的问题，或者维护对相关资源的引用列表。
让很多人为这样的 wiki 做出贡献更加强大，但是讨论的可能性也非常重要。
于 2008-10-07T11:59:53.707 回答
1
我实际上已经开始了一个解决它的副项目。它仍处于规划阶段，但我已经确定了组织中保留技术知识的一些领域。现在，这并不适用于每个组织，但每个组织都至少使用其中一个。
- 人们
- 静态 Web（Internet 和 Intranet）站点
- 书籍（公司图书馆）
- 书籍（个人的书籍）
- 动态 Web（Internet 和 Intranet）站点
- 数据库和存储库
你如何使用这些是不同的，但关键是让人们使用静态和/或动态网站来捕获信息，或者至少确定它在书籍和存储库中的位置。如果人们不为知识库提供食物，那么你使用什么技术就无关紧要了。从我能够收集到的知识中，知识必须是最新的、准确的和深入的，否则它是徒劳的。
正如 Vinko Vrsalovic 指出的那样，另一个重要的关键概念是将数据/信息/知识链接回其推理的能力。需求分析中的一个常见做法是跟踪需求源的能力。对于知识也应该这样说。组织中的每个人都可以了解世界上的一切。但是，如果没有人知道为什么该知识有用或在何处/何时使用该知识，那就浪费了。
如果我遗漏了任何内容，请随时编辑此帖子或回复评论。我认为这个问题将有助于我的项目工作。
编辑 1：添加了 Vinko Vrsalovic，它不仅仅是关于知识，而是将数据链接回与知识相关的生产问题。
于 2008-10-07T12:00:15.440 回答
1
我已经看到很多知识讨论发生在组织内的电子邮件中。这些知识会在电子邮件中保留很长时间，最终会丢失，并且不属于原始讨论的其他人无法访问。
使用http://grexit.com之类的工具可以帮助您将这些知识从收件箱中转移到组织内的 coomon 共享存储库中。目前这仅适用于 Google Apps，但值得一试。
于 2010-10-20T11:28:14.313 回答
0
使用 wiki，但要确保某人对其中的内容拥有编辑所有权。该人需要确保遵守命名标准和文档层次结构 - 公司 wiki 很容易变得一团糟。
于 2008-10-07T12:14:52.040 回答
0
我会给你一些 Wiki 的缺点，或者可能需要额外思考的地方：
- 如果技术知识/文档与无权访问您的 Wiki 的客户或组织共享
- 与特定软件版本相关的文档通常与发布相关的源一起保存得更好。通常 Wiki 包含最新的信息，但可能很难（取决于编辑的关心）将文档映射到旧版本
于 2008-10-07T12:32:50.553 回答
0
我认为，您使用的工具并不那么重要。真正重要的是，您团队中的所有成员都同意一种方式和一个文档位置。
您可以使用 wiki 或笔记数据库或自酿应用程序。
我个人更喜欢所有东西都在一个地方。因此，对于技术文档，源代码控制系统将是正确的位置。对于非开发人员使用的文档，源代码管理绝对是错误的地方。对于全面的文档，也许共享点服务器是您应该使用的工具。它具有某种版本控制，无需特殊的客户端应用程序即可访问。
于 2008-10-07T12:38:24.783 回答
0
我们结合使用项目博客和维基。
我认为人们对 wiki 感到有些厌烦——他们觉得他们至少需要输入几个段落来证明输入的合理性——所以我们创建了一个博客，它对于捕捉实时发生的小事情或事情很有用，例如，“我将列字段长度从 40 更改为 50”或“清除了比上周旧的审计表数据”。
我期望（希望）随着项目的进展，一些博客条目将成为更长的 wiki 条目的源材料。
于 2008-10-07T16:10:11.487 回答
0
作为 wiki 的替代方案，请考虑使用 SharePoint。它允许您处理事件（如会议）、任务和文档。它非常适用于非技术人群，这可以让技术作家和管理人员了解正在发生的事情。它也是 Windows 2003 的一部分，因此您可能不需要额外的许可证。
不利的一面是，我几乎可以保证会有一个 luddite 将每一个 UI 小问题都归咎于你。不过，高层可能会喜欢它。
于 2008-10-07T16:23:03.287 回答
0
您可能可以看看Associativy。它将知识片段存储为图的节点，其中边表示关联（在人类意义上）连接。该图可以多种方式搜索和探索，给定一组搜索词，软件能够“思考”一个合适的关联。
我是开源的，并且在Orchard CMS上运行，这也是一个开源项目。
这是一个无耻的插件（Associativy 是我的项目），对不起。
编辑：刚刚认识到这个问题有多老....
于 2012-10-15T11:14:38.687 回答