我的知识管理之路(1)—序言

萌动：

最早萌动推动研发中心知识管理的想法源于去年12月份组织过CMMI L3 评鉴时，在LA做最终总结报告时，将组织资产库的建设列为一条Weakness。虽然经过了流程的历练，知道做事情的结构化思考顺序，应该从Why，What想起，再去想How，但做RD出身的人往往还是会直接一步跳到How。反正，当时自己就纠结在希望能够找到一个知识管理的平台上了，也就是说首先就被挡在了工具的面前。

 

工具：

BBS：公司的服务器上建的有BBS，但是大家的使用热情不是很高，灌水还行，分享就很少有人主动。偶尔有人想发起一个议题讨论也多是用邮件群发或者用QQ群了，BBS被大家冷落的一塌糊涂。

Blog：我也曾经在CSDN上为我们测试部申请了一个公共帐号，希望大家把一些经验分享到Blog中，坚持了一段时间之后，乐于分享的人，结果纷纷开了自己的Blog。而有些知识涉及组织机密和核心竞争力其实也是不能够发布到公众平台上的。那个Blog随后也就逐渐陨落了。

Wiki：2月份台北一个Manager J 过来讨论工作，谈到研发管理中彼此使用到的一些平台和工具。他提到在使用Dokuwiki作为个人知识管理的工具，并向我做了简单的展示。看到他个人用dokuwiki记录每天的工作、存放会议记录、管理联系人(他会把名片扫描或拍照)；在小团队内则用dokuwiki做一些合作文档撰写的工作。J 说dokuwiki的语法要比mediawiki简单很多，他自己也会做一些模板修改的工作，让它更适合自己的使用。其实，公司一直在推mediawiki，看到有一些别的部门在用，不过至少还没有推到研发中心这里来，也暂时还没有看到一个用得特别成体系的。鉴于研发中心还算充足的服务器资源和人力资源。我决定—我们自己做，暂时不依赖于IT部门的支持。经过对mediawiki和dokuwiki两个平台的比较，dokuwiki丰富的插件，和较为简单的编辑语法赢得了我们的青睐。只是有一点，我们没有找到dokuwiki支持域认证的方法。不过暂且忽略这个问题，计划在这个平台上试行知识管理成功，有了较为完善的使用经验和知识管理机制之后，再考虑二次开发。

 

契机：

六七月份那阵子，有一个产品的客户反馈的Bug特别多，测试人员一直忙碌于bug 复现和客户回复中。那阵子就一直在想，到底为什么？这个产品出了什么问题？我希望负责这个产品的测试人员能够把客户反馈拿到部门会议上和大家一起讨论一下。顺着这个思路发散下去，就有了第一次的QA 品质案例分析会议。会议的目的是彼此分享各自所负责的产品线的客户反馈，一起讨论问题遗漏的原因和改进措施。其实，QA Team一直保持着分享会议的习惯，但之前多是进行简报分享、读书会等等。专门的一次讨论客户反馈的会议还真的是头一次。我将它称之为析错会议。在析错会议之前，我做了一个Bug Review Form的模板，请每位测试人员按照模板书面准备至少3个客户反馈。QA的第一次析错会议，基本达到了我的预期。可能在会议当场，我们没办法立刻决策如何改进这个产品；但至少我们找到了问题的症结，有了follow up item；另外，也彼此分享了可能遗漏的测试用例。

在QA析错会议之后，继续照此思路发散下去。在一个RD Team，同样如法炮制。RD的析错重点在于单元测试和系统测试过程中的Bug，目的在于分享问题发生原因和解决方案。有一点需要特别说明的是，在析错会议上，Team Leader作为部门最资深的大虾对于每个人的分享都做了点评。我们发现有些RD的问题解决方法并不是最优的，有的甚至是表面上的解决；这些问题由于RD本身认为已经得到了解决，往往并不会拿出来和其他人讨论；但通过析错会议这个平台，就让大虾一下子发现了问题，并给与了真正的终极解决方案，这一点发现很让人兴奋，也让我们更加坚定了析错会议的必要性，由此也坚定了我要将析错会议当作例会持续推动的想法。

在流程中，规定项目结案后需要召开项目结案会议，分享成功的经验、总结失败的教训。但是由于我们的项目大部分比较小，一个人从头做到尾，也就2.3个月时间。基本上不会有严格和正式的立项和结案动作，结案会议也就无从提起。一直在思考这个流程要如何实施，刚好析错会议的成功也让我找到了解决的方案——定期回顾会议，不限于析错，包括任何你想要回顾的问题，可以是你的成功，你的教训，你认为他人也可复用的素材、信息、元件等等等等……而回顾会议上大家分享的议题，恰好也就是组织知识库中经验分享的来源。会前请大家在wiki中提前进行书面准备，会后根据讨论结果更新。从而，利用回顾会议也就建立起了推动组织经验分享的机制。

有人说，回顾会议有必要开，但是会上大家说说，交流一下就可以，写出来太花时间了。我的回答是：写还是非常必要的。提前书面准备的过程，就是你重新将知识结构化的过程。写可以促使你更进一步弄清楚还存在模糊的问题，否则会上怎么应对别人的提问；写出来可以让你避免在会上说时遗漏一些信息，也可以避免你说的不够条理化。从这个角度讲，写其实节约了会议上的时间，提高了效率。从另一个角度，只有写出来，隐形知识才能够外化为显性知识，让更多的人得到参考。

关于回顾会议，详见Blog文章《我的知识管理之路(3)—非敏捷团队的回顾会议》 。

 

偶遇:

在《哈佛商业评论》上，偶遇了这样一篇文章《测一测，你离学习型组织有多远？》。我在组织内做了抽样问卷调查，结果不似我们之前自以为的那么好。在接受新思想、信息采集、信息传递、教育和培训等领域的学习深度还有较大的改善空间。暂时，我还没有找到改善的策略和方法，但也将此纳入了知识管理之路的规划中，希望透过知识管理能够有所改善。

关于组织学习深度评估，详见Bog文章《我的知识管理之路(2)—测一测，你离学习型组织有多远？》

 

希望：

在过去的流程改善中，我们都明白这样一个道理—我们不缺流程、也不缺乏流程改善的企图心；但我们缺乏运行流程改善的机制。知识管理也如此、如何建立机制并流畅的运作。这大概是这条路上最大的障碍了。希望我们能够找到一条创新之路……

 

Follow Up Item：

要达成目标，也深感自己知识的匮乏。在当当上买了几本书看，希望能够将研发中心知识管理的规划系统化、专业化，希望透过知识的内化碰撞出更多的创新思想……第一步的待办事项，当然就是“读书笔记了”……

写到这里，想起今天和一位不甚爱看书的朋友说的一句话：“看书可以帮你绘制自己的知识地图，它可能不能帮你直接决定路线，但不看书，你连地图都没有”。