知识管理的唯一出路：与业务融合，构建情景化知识管理体系

本文主要是介绍知识管理的唯一出路：与业务融合，构建情景化知识管理体系，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

早在20世纪80年代，以美国麻省理工学院教授彼得•圣吉（Peter M．Senge）为代表的学者，开始致力于学习型组织的研究。以此为起点，屈指算来，知识管理也已经走过了20多年的漫长历程。虽然随着知识管理理论在实践中不断升华，同时IT技术的导入又大大提升了知识管理的可操作性，但一直无法得到大面积的成功推广。

造成以上局面并不是由于对知识管理的重要性缺乏认识：研发经理们也明白其重要性。他们也知道，对研发知识与经验更好的利用会带来巨大的回报，结合对国内众多科技型企业的知识管理现状的分析，认为国内企业到目前为止研发知识管理失败的原因主要归结为以下两点：

1）缺少有效的知识分享的文化；

2）没有将知识管理与主干业务很好的结合；

在谈具体怎么实施知识管理前，我们有必要对研发中的有价值的经验与知识的种类进行初步的了解，与研发相关的CBB(共用技术模块)、模板、准则、检查单、经验、教训、方法论、参考文件、专利信息等都属于知识管理的范畴，尤其是项目实际运作的经验教训对其他后续项目有很大的借鉴价值，而实际我们发现很多研发类的企业项目的经验教训伴随项目的结束而消失，同时在其他项目还在继续着同样的错误，怎有效管理和重复使用这些知识，直接关系到产品开发的成本、质量和进度。

要构建情境化的知识管理体系

首先，需要培养公司的流程意识和知识共享的文化，作为研发企业可以借鉴其他标竿企业的经验教训，但不同企业的实际情况，产品领域都有所不同，我们自身企业内部知识的持续积累才是我们应该关注的核心; 知识管理推行的最大阻力来自公司内部全体员工；其最大的障碍来自于缺乏分享的意愿、动机和习惯。人们花许多时间发展个人知识，以凸显自己，这自然地引发所谓“知识即权力”的态度。传统上，员工担心自己辛苦获得或因时间累积而得的知识与人分享后，职务将被取代或工作朝不保夕，害怕变成“教了徒弟，没了师傅”，因此，不愿对别人分享自己的知识。成功的知识管理需透过企业文化的改造，改变员工的思维模式并培养“知识分享”的文化。

知识分享不是一个可以自行发展的过程，需要让员工切实认识到知识的共享会对每个员工自身能力提升的意义，高层需要带头做知识分享的工作，高层的支持不能只停留在语言上，而应该有切实的行动，例如高层对员工的培训就是参与知识管理的具体行动；知识共享文化的形成过程中，必要的制度和适当的物质、精神激励也是必须的，例如研发经验教训案例奖励就是一种很值得推广使用的方法，鼓励研发人员将实际项目中遇到的问题以书面的形式总结出来，然后由评价专家团队对提交的案例进行评价，根据评价得分作者可以获得不同数量的奖励；如果起初确实没有任何人愿意提交案例怎么办？必要的强制分配也是必须的，例如可以根据部门、项目团队人员的不同每月强制分配不同数量的经典案例提案指标。

知识管理要想保持持续的生命力就需要和公司的主业务保持一致，不能为了知识管理而进行知识管理，业务的需求是知识管理的指南针，具体怎么将知识管理与公司的主体业务进行融合呢？这就需要构建情境化知识管理体系，具体什么是情境知识管理体系呢？

我们不妨先看一下目前一些公司的知识管理的方法，他们也建立起来了知识管理系统，利用文件夹与文件夹命名规则组织知识文件，然后指望开发人员到那些文件夹中找他们所需的文件，但不幸的是，这种方案很难生效，一方面是堆积如山的知识文件，另一方面却是具体的开发人员进行一项开发活动时不知道需要什么知识文件来支撑，即使知道也发现很难快速找到相应的知识文件。

为了解决这个问题，我们可以借鉴软件的API的思想，将具体的知识文件依附于具体的项目开发活动，通过适当的IT系统或项目管理工具（例如：PROJECT）我们可以知道具体开发人员即将从事什么开发活动，这时知识管理系统就类似软件调用API一样，将与该活动相关的知识文件自动展现在开发人员面前，这样很好地解决了日常开发活动和知识管理的融合问题，这就是情境式知识管理体系的核心概念，要想建立这样的情境知识管理体系，首先需要将我们的产品研发流程进行固化，产品研发流程本身就可以成为我们知识持续积累的平台，正是因为不同项目遵从相同的研发流程，历史项目的经验教训才对后续的项目有借鉴价值，同时通过流程就可以明确每个活动需要什么样的知识文件来支撑，实现研发日常活动与知识管理的融合。

案例学习：青铜器RDM借鉴网络游戏过关模式，每个步骤都可以灵活定义所需知识，并自动展现给相应“玩家”