程序员 | Tony Bai

知识管理推广难的几点原因

去年在产品线内部尝试了一些知识管理的实践：建立了知识库，初步在产品线内部养成了知识整理和总结的习惯，建立了工作流程与知识库之间的粘性，取得了一定效果。今年年初在事业部内部做了有关知识库实践方面的分享，大家也都认识到这几年我们在知识积累方面上的不足，也都很赞同知识管理的重要性与必要性。会后领导决定建立事业部级知识库，并安排专人负责知识库的维护与推广。

于是乎负责知识库搭建的那个部门申请服务器、安装和调试知识库系统，甚至是修改代码以满足我们内部对权限的要求，后续还召开了一次子部门知识负责人会议，以推动各个子部门应用知识库。这样的开头看起来还是蛮不错的。但随着时间的推移，热情经过冷却也渐渐凉了下来。知识库的负责人也变更了，定期的知识管理交流会也不再举行了，仅仅剩下我们的产品线依旧保持着已经养成的热度。

万事开头难，确实不假。但究竟是何原因导致出现此种情形呢？近期做了一番思考，想到了以下几点。

1、领导意志的持续性

最初，知识管理受到了领导的推崇，并做出了部署并使用知识库的决策。但随后领导似乎“忘记”了这件事情，缺少了持续性的关注。这似乎无意中给了大家一个错误的信号：知识管理并非我最在意的事情。领导不关心，下面的人如何行动可想而知。换位思考，我十分能够理解领导们每天的忙碌，毕竟在中国这个激烈竞争的IT市场环境中，摆在第一位的永远是“如何活下来”，所以领导们的确应该将市场、客户等放在头位，这无可厚非。但如果用经典时间管理理论来理解的话，知识管理就是一件重要不紧急的事情，市场、客户关心之余应该得到领导给予地持续关注，否则知识管理就逐渐陷入不重要不紧急的象限中去了。组织的持续成长是需要有知识积累作为保证的，“铁打的营盘，流水的兵”，组织内一批批的人员更迭，甚至若干年后领导们也都已经高升到其他岗位了，留下的也只能是组织运行多年来积累下来的那些知识(技术、经验等)了。因此真正为组织着想的领导是应该给予知识管理持续关注的。

2、员工的工作心态

说完了领导，说员工。对普通员工而言，最重要的莫过于：把活按时干完，每月都能拿到高绩效奖金，年底拿更多年终奖，来年涨更多薪水。同时，在这个过程中，自己也能成长，翅膀将变得更硬朗，弄不好就飞走了，把一切都带走，不留下一丝痕迹。工作了若干年，后来人甚至不知道你的存在，除了你那日益发出腐朽味道的代码外，你没有给后人留下任何有帮助的东西。很遗憾，我看到的不少人都是这么做的。一些人工作就是当一天和尚，撞一天钟，甚至都不为自己后续的工作考虑，没有总结，没有思考。后续遇到相同的问题时，一切从头来。试想一下，如果在这样的一个群体里，即使搭建出一个知识库平台，又有几人能够使用呢。当然这里仅仅是一个例子，我看到了越来越多的年轻人报着Open和虚心学习的心态，主动应用组织提供的知识平台，认真学习技术、了解业务，并在工作一段时间后，贡献出了高质量的知识，他们意识到了知识积累和总结的重要性，他们从中得到了益处，他们认为自己在工作过程中的收获可能对其他人也很有益处，也会给自己后续的工作带来方便，这样的工作心态是值得赞赏的。如果一个组织内部员工的工作心态均是如此，知识管理推广将十分容易，而且我相信这样的组织将会有更为持久的生命力。

3、这个人适合吗

有了知识库后，不能放任自流，务必要有专门人管理和推广。如果组织够大，这个人最好专职；如果组织不大，知识管理的工作量不足以饱和，可考虑兼职；但什么样的人合适呢？如果让一个不适合的人来负责知识管理，那就是"搬起石头砸自己的脚"，不仅不能扩大知识库在组织内部的作用，甚至还可能让其他人产生“知识库无用”的观点。像我们这样的组织，开发人员占据大多数，没有设立专职知识管理专员职位，大家都是门外汉。我也不是知识管理专家，但我希望组织内有人通过我们搭建的平台逐渐成为知识管理方面的专家。因此我们需要一个其自己就致力于在知识管理领域有所建树的人负责，这样的人有热情、有意愿将组织的知识管理做好，这绝对是做好知识管理的一个必要条件。这个人的需要能让组织以及领导们时刻意识到知识管理的存在以及重要性。如果做不到这一点，那这个人就是一个不合适的人选。

4、策划和推广有计划吗

知识管理是重要不紧急的任务，因此应该做长期计划，分阶段达成目标，无计划、无政府状态的知识管理将会变成一盘散沙。知识库这座大厦的结构是动态的，是始终趋向更满足组织需求而变化和重构的。知识库负责人应定期根据最新需求策划调整知识结构，并在组织内做足推广和宣传，引导大家在正确的位置贡献知识；知识库的新版本升级、新功能的支持都应该让组织内的成员知晓；更重要的是要设定知识管理的阶段性目标，并努力达成，定期组织汇报，用成果打动大家，增加大家对知识库的粘度。

5、理论结合实际了吗

知识管理是有一套理论做支撑的，我是门外汉，从来没有系统学习过。但我想如果要做好知识管理，理论必不可少。这更多是知识管理负责人的事情。他/她应该主动学习这方面的一些理论，结合实践，搞好知识管理。我想知识管理想要上一个台阶，上一个档次，这一步必不可少。

能想到的原因上面已经列了出来，但如何解决呢？人的问题，非技术问题，难啊！不过我觉得也许最关键的一步应该是选好一个合适的知识管理负责人。这也是下一步我要力促的事情。

做正确的事要趁早

最近闲暇时间在策划实施两件事儿：一是产品的自动化回归测试；二是尝试在项目中使用一些静态代码语义分析工具。我觉得这两件事是应该做的正确的事，对提升产品质量，提前发现产品中潜在的缺陷都大有裨益。但在做的过程中才感觉到：现在做有些晚，正确的事要趁早做。

去年自动化测试组发布了自动化测试框架的第一个版本，我们的产品参加了试点。但经过自动化测试组大半年的投入，效果十分有限，根本没有达到我的预期。最主要的问题是使用他们提供的框架编写和维护test case都十分困难，工作量投入很大，这很打击大家的积极性。今年大家决定将自动化测试框架换成nokia开源的robotframework。经过预研，robotframework完全可以满足我们的测试需求，并且robotframework的用例编写和维护效率太高了，编写门槛却很低。

虽然换成了robotframework，但我们应用的时机还是有些晚了。试点项目已经接近开发尾声，这时候如果要加上自动化测试，势必就要在短时间进行大量测试用例开发。如果在项目初期，增量的用例添加相信会达到更好的效果。但即便是“亡羊补牢”，我们也还是要做的，还好这个产品版本的生命周期才刚刚开始，后续可能还会持续很多年，加上自动化回归测试还是有重大意义的。

不过鉴于之前的教训，我们调整了自动化测试的切入点。之前自动化测试组只是闷头写用例，并未太多考虑自动化测试框架与被测目标如何配合的问题：比如没有考虑自动化测试在哪个环节应用、谁来驱动、谁来执行以及测试环境如何生成等。这次我们先绕过用例编写，先从“基础设施”搭建开始。我们的目标是将自动化测试与我们的持续集成流程集成在一起，也就是说我们将通过jenkins这样的ci平台来作为自动化回归测试的驱动。我们首先就是要将这个驱动流程run起来，即便测试用例库中一条用例也没有。一旦run起来后，我们再将关注点集中在用例的编写和调试上，我想这才是正确的思路。

第二件感觉做得有些晚的正确的事儿就是为项目增加静态代码检查环节。之前项目静态代码检查仅停留在打开GCC编译器的-Wall选项这个层次。就是否有必要引入第三方静态代码分析工具对代码进行缺陷检查，大家一直没有统一意见。质量部门希望我们引入，但关键问题是我们没有找到一款适合的开源工具(for C)，在维基提供的C语言静态分析工具列表中，我感觉似乎只有splint符合我们的要求 – 开源、功能强大且支持linux/unix。不过splint似乎已经停止开发了，最新版本停留在3.1.2。

使用类似splint这样的工具对代码进行检查时总是能给出大量的warning，如果不加以控制，那么屏幕就会被warning淹没。因此正式使用之前，需要一个“磨合期”。先确定打开或关闭哪些检查规则开关，原则只有一个，即尽量避免误警告，又不能漏掉真实的隐患。splint对C99新增语法的支持不是很好。splint碰到下面这种语法时会提示parse error，并且无法recover：

struct foo {
int a;
int b;
};

int main() {
    struct foo f = {.a = 1, .b = 2}; /* Parse Error */
    printf("%d %d\n", f.a, f.b);
    return 0;
}

这类静态代码检查的基础设施在项目初期搭建起来是最佳的，开发人员可以增量的对代码进行语义检查，并修正缺陷。但如果在代码开发即将结束的阶段加入，即使是设置了一套合理的检查规则组合，你也可能困惑于工具产生的大量Warning。不过“有胜于无”，在没有找到更好的工具前，我将splint加入到工程中，建议组员适当时机使用，并随时对check rules组合开关进行调整和优化。也许经过一段时间的磨合后，可以实现在ci job中加入自动代码静态检查这个环节，当然目前肯定不是适宜时间。

正确的事，你会发现早做和晚做效果是截然不同的。但“亡羊补牢“的工作也不能不做。既然是你认为正确的事，从长远来看，还是能带来很大价值的。