形容优秀的词语-优秀的常识

最近在看国外软件工程方面的杂志，里面很多文章都反复提到了一个词：common sense。汉语里一般将其翻译为“常识”。

在Wiki里，特意还提到了另一个词，那就是common knowledge，也是翻译为常识。就是这个词，还是博弈论中的一个术语。

在英文的世界里，这两个词有类似，但是也有不同的地方。Common sense更多是指判断力。我的理解应该是人做事情的时候，一些底层的、基于我们普遍认可的知识（common knowledge）上的判断逻辑。

其实，我们每个人做事、做判断、做选择，很多的时候都是在依靠这个常识。只是，没有经过特定的训练，很多人是不能够意识到自己是被common sencen所左右的。

在英文世界里，common sense，是个魔力词组。从公元前300多年，亚里士多德就开始思考，直到2000多年后的今天，很多人还是不能够理解其哲学思辨。

对于常识而言，有优秀的，有平庸的，还有拙劣的。

看了国外专家的文章，2018年也在跟着吴军老师学习一些课程，我忽然想起了一个故事。从“常识”的角度上考虑，也终于有所释怀。

某国内知名的软件公司，大概在2007年左右，成功签约了某著名房地产公司，为其提供企业管理信息化软件。对于中国的房地产行业，那正是梦开始的时候，这家公司更是如此——XX广场在全国各地遍地开花。业务扩展的同时，企业管理者逐渐意识到了信息化的重要。

就企业管理信息化而言，我逐步认识到了一些“优秀常识”——

首先，就是要认识到什么是“信息”本身？——要理解到香农(Shannon)先生对信息的定义。信息是不确定性，信息是熵。信息论是一门科学。

其次，管理信息化绝对不是将原来的手工或者Excel业务电子化。而是要遵守信息论的思想，对业务进行改造。

第三，信息流是不能被企业的“现有部门、管理条线”所割裂——财务，人事，资金，物资，应该是围绕着业务目标而整合。忽悠了20多年的“财务业务一体化”，其实真正实现的寥寥无几。

对于房地产企业而言，是典型的项目管理导向型。

在项目管理的领域，已经有了非常优秀的“常识”，那就是PMI的PMBOK，即项目管理知识体系。经过对这个知识体系的学习和考试，人们可以获得PMP认证（项目管理专业人士）。其实在中国有很多人都在学习，并持有此认证，数量仅次于美国。

再说回到这个项目故事上，很遗憾，软件开发团队几乎没有PMP，也并没有上述的这些“优秀常识”。他们的常识还是——客户说什么，我们就做什么。

其结果可以想象——很多中国软件团队最恐惧，也是难以逃脱的宿命——客户最后评价：“这不是我们想要的”。

2010年左右，就在这个房地产信息化项目失败已现端倪的时候，软件公司的董事长下定决心在新版软件中重点打造项目管理模块。

为此，产品总监，根据常识选择了一个博士来做此模块的产品经理。

但是，很遗憾的是，产品总监（要真实管理研发项目）与产品经理也都不是PMP，对上述的优秀常识，也没有深入了解。

举一个具体的例子：在整个项目管理的常识中，一个很基础的常识，就是WBS（工作分解结构）了。

对于这个优秀常识，产品的BA，曾经是多次提议，将其作为软件的一个基础数据功能。而产品经理对于这一点极力反对。在产品研发过程在，出现了严重的“冲突”。

“冲突管理”本身就是一个管理范畴，是有优秀常识的。

产品总监以及开发团队，在这一点上的常识是：具体的功能要以产品经理的决定为准，BA应该服从产品经理。其背后的常识，也许就是“职位”就代表了正确性。

由于缺少优秀常识支持，这个重金打造的项目管理模块也是处处显示出了逻辑矛盾的地方。几乎就是沿着以前失败的路线走了一遍。

之所以造成这种情况，也是源于此软件公司内部的常识：只要在一个时点把软件发版、客户签字验收、回款，就是工作的绩效（KPI/PBC）；而客户是否从软件中获得价值，是否能够持续应用，就不用考虑了，因为与绩效无关。而有了工作绩效，就意味着A和B+，意味着丰厚的年终奖，以及职位的升迁。

这个常识可以说是在公司内部屡试不爽。

最后，我以陈春花老师的某次讲演收尾，陈老师的讲演原话中是没有提及“常识”二字的，是我掺加进来的——很多中国企业都会说：客户是重要的。这是一个常识（common knowledge）。但是在实际的操作中，很多企业做事的时候往往都会忘掉了这个常识（common sense）。