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

我建议使用wiki。它是一个非常好的中央文档源,具有内置的修订控制。也可以通过URL引用代码中的文档。

员工是公司最有效的知识容器。最有效的知识转移方式是人与人之间的交流。wiki和文档也很有用,但是除非你的员工是伟大的技术作家,否则书面文档是一种糟糕的方式,可以传递除最微不足道的知识之外的所有知识。写一本书花了好几年的时间,所以你不能期望开发人员在几个小时内写出高质量的文档。

在你的组织中保持知识的最好方法是让人们一起工作。确保没有人单独工作。让人们对程序进行配对,并互相检查代码。组织技术会议等。

如果你真的想把知识存储在某个地方,试着丰富数据。使添加白板等图片到wiki变得容易。书面文档的另一个问题是,人们似乎认为冗长的抽象文本是“专业的”。确保你的文档简短、清晰,并且切中要害,这样人们才能真正阅读。

如果你能获得支持,一个有声望的社交媒体(比如这个网站)就可以工作了。 极其 在内部网上。人们需要一点激励来充实知识库。

我会推荐 MindTouch Deki . 它远不止是一个wiki,它集成了许多其他资源,包括将其集成到组织中的自定义数据源的能力。

wiki的工作很好,但是我们用Ignite和Camtasia的屏幕广播来补充wiki。这些在描述配置等时节省了时间。屏幕播放很容易、快速,而且您不必担心是否为观众捕捉到了正确的细节,因为他们回放/重放了他们需要回顾的部分。

我们尝试过知识库文章,这让人们变得懒惰-“我不理解这一部分”意味着你要重写一大堆。给一个人放映剧本,他们可以自己做笔记。

无论解决方案如何,在公司中保留知识最重要的一点就是强制人们使用系统。维基是我最喜欢的,但是如果没有管理层或团队领导的强制执行,很难保持这种有用的知识水平——人们讨厌记录它,特别是当它使他们很容易被替换的时候。

维基很好,但其中一个最大的优势还没有被提到。通常,文档中的缺陷不会被编写者发现,因为作者不需要或不阅读文档。当作者休假或外出生病时,会发现一些缺陷,而其他人试图遵循文档,但部分文档不起作用。使用wiki,无论哪个可怜的家伙最终发现了文档中的缺陷,都可以立即纠正它,而不必给作者发电子邮件,而是把它埋在作者度假时收到的其他千封电子邮件中,或者在作者回来后试图记住告诉作者。

另外,确保至少有两个人知道如何做每件事,以及 保持人员配备水平 . 当有人离开时,如果你已经有其他人可以做他们所做的一切,那么不替换他们是很有诱惑力的,但是如果你现在有多个基础结构或代码,每个都只能被一个人理解,那么你就是脆弱的。从一个人到另一个人的知识转移需要时间和实践工作。这并不容易,但比仅仅从文档中学习基础结构或代码库要容易得多。

我过去使用过这两种方法,并且发现wiki格式是最容易被接受的。在源代码管理中存储文档会对合并版本产生影响(明显依赖于使用中的源代码管理软件和应用的方法)。基于wiki的解决方案也是如此,但出于某种原因,它似乎从未在我使用的实现中出现过大问题。

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

<2C/gt;

我喜欢维基。我甚至把它们用于我自己的爱好项目,记录我是如何绕过那些我不想再去处理的棘手问题的,或者维护一个相关资源的参考列表。

让许多人为这样一个wiki做贡献是更强大的,但是讨论的可能性也是非常重要的。

我实际上已经开始了一个解决这个问题的辅助项目。它仍处于计划阶段,但我已经确定了一些组织中保留技术知识的领域。现在,这并不适用于每个组织,但每个组织至少使用其中一个。

• 人
• 静态Web(Internet和Intranet)站点
• 图书(公司图书馆)
• 书(个人的书)
• 动态Web(Internet和Intranet)站点
• 数据库和存储库

准确地说,你如何利用每一个都是不同的,但关键是让人们使用静态和/或动态网站来获取信息,或者至少确定它在书籍和存储库中的位置。如果人们不给知识库提供食物,那么你使用什么技术就无关紧要了。知识必须是最新的、准确的、深入的,否则,从我所能收集到的信息来看,这是徒劳的。

正如Vinko Vrsalovic指出的,另一个重要的概念是将数据/信息/知识与推理联系起来的能力。需求分析中的一个常见实践是能够将需求跟踪到其源。知识也应该如此。组织中的每个人都可以了解世界上的一切。然而,如果没有人知道为什么知识是有用的,或者在哪里/什么时候使用这些知识,那就浪费了。

如果我遗漏了任何内容,请随意编辑此文章或作为评论回复。我认为这个问题将有助于我的项目工作。

编辑1:补充了Vinko Vrsalovic,它不仅仅是关于知识,而是将数据链接回与知识相关的生产问题。

我已经看到许多知识讨论发生在一个组织的电子邮件中。这些知识在电子邮件中保留了很长时间,最终会丢失,并且不属于最初讨论的一部分的其他人无法访问这些知识。

使用类似的工具 http://grexit.com 可以帮助您将这些知识从收件箱中移到组织内的Coomon共享存储库中。目前这只适用于谷歌应用程序,但值得一试。

当然是维基。我们使用 TWiki 利用一些优秀的插件。

编辑:我忘了补充一句,你可能想查阅答案 this question 关于文件和版本控制。

使用wiki,但要确保有人对进入的内容拥有编辑所有权。这个人需要确保遵循命名标准和文档管理——公司的wiki很容易变得一团糟。

我会给你一些wiki的缺点,或者需要额外考虑的地方:

1. 如果技术知识/文档是与无法访问您的wiki的客户或组织共享的
2. 与特定版本的软件相关联的文档通常在与版本相关联的源代码中更为有效。通常wiki包含最新的信息,但将文档映射到旧版本可能很困难(取决于编辑器的护理)。

我认为,你使用的工具并不那么重要。 真正重要的是,您的团队中的所有成员都以一种方式和一个地方进行文档记录。

您可以使用wiki、Notes数据库或自助BREW应用程序。

我个人更喜欢一切都在一个地方。因此,对于技术文档,源代码管理系统将是正确的位置。 对于非开发人员使用的文档,源代码管理显然是错误的地方。对于跨过Board文档,可能应该使用SharePoint服务器。它有某种版本控制,不需要特殊的客户端应用程序就可以访问。

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

我认为人们对维基感到有点反感——他们觉得至少需要输入几段来证明输入的合理性——所以我们创建了一个博客,它可以帮助实时捕获发生的小事情或事情,例如,“我将列字段长度从40改为50”,或者“清除了比上周更久的审计表数据”。

我希望随着项目的进展,一些博客条目将成为更长时间的wiki条目的源材料。

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

不利的是,我几乎可以保证会有一个路德分子,他会把每一个小小的用户界面口角都怪到你头上。不过,高层可能会喜欢它。

你也许可以看看 Associativy . 它将知识片段存储为图的节点,其中边缘表示关联(在人类意义上)连接。该图可以通过多种方式进行搜索和探索,给定一组搜索术语,软件可以“思考”合适的关联。

我是开源的,运行在 Orchard CMS 一个开源项目。

这是一个无耻的插件(关联性是我的项目),对不起。

编辑:刚刚认识到这个问题有多老……