v1.0.2
常识是否可靠
大家都听过羊来了的故事，今天我分享个新版的。
一群牧民放羊，隔壁山坡的小孩扯着嗓子叫喊狼来了，结果牧民们一听狼来了，根据常识狼来了要跑，大伙儿赶着羊就跑了；结果呢，那小孩儿就是逗大家玩的，这把牧民们气的，毕竟大老远赶着羊跑来跑去还是很消耗精力的，于是大家又多了一个常识，这小孩儿就是小坏蛋，不可信。
隔了不久，牧民们依旧放羊，小孩儿依旧在隔壁山坡玩，不一会儿，小孩又扯着嗓子大喊：“这次狼真的来了，大家快跑！", 牧民们基于之前的常识这次一个都没跑，但这次狼是真的来了，结果的严重性可想而知。
于是我在想，到底什么是常识，我搜索一下，大概是这样的定义：
常识是指社会对同一事物普遍存在的日常共识。
最近，在和几个同事做软件项目，该软件的界面上有个小方块，需要产品设计一个浮动层，在特定的状态下弹出浮动层覆盖该方块，为了简单，就说A,B,C三个状态。其中C状态是在业务执行过程中可以忽略不计的，只需要根据A、B状态展示浮动层即可，所以产品并没有专门对C状态时如何处理浮动层作出明确的设计。
经常做开发的都知道，这个需求简单到令人发指，肯定不会出什么BUG，从产品设计好原型，再交由UI设计好浮动层效果，开发就参照着完成了任务，结果提测之后不通过，测试认为C状态下应该消除A、B状态时弹出的浮动层，目前的实现不够严谨。按照惯例，出了这样的问题开发找产品沟通并提出了这个问题，结果产品绕了一圈，来了句：“对啊，就是不应该这样展示，这不是常识吗？"，言外之意有点"你们开发连这点都不懂呀？"的意思。我和产品同事是室友，也爱开玩笑，对于这样的回复我不予置评，
毕竟人和人沟通总会牵涉沟通的哲学和心理学，一时半儿也说不清楚。
回到问题，我思考着，如果这是一个常识问题，为什么产品、UI、开发、测试对这次的需求理解不尽相同，如果真是这样，那岂不是产品，UI，开发真没有常识，需要测试提出来？带着问题我又去搜索了下，得到这样的答案：
常识是普通的知识，一般的知识，它是人们在日常生活中形成的基本认识和经验，通常不需要通过专业学习就能掌握。
这句话我们要是只看其陈述，不思辨，还真觉的是那么回事，认为那个关于ABC状态的需求就是常识问题。实际上，但凡有一点独立思考的能力，就会发现知识和经验是每个不同的人在不同环境，不同年龄，不同人格，有着不同的工作经历等种种不一样的背景下形成的，我们彼此认为对方的常识一定能解决问题，这种思维真的不值得思考吗？
我们再来看看生活中的一些常识：
红灯停，绿灯行，结果为什么还是有人闯红灯？
小时候经常听到的：
我在马路边捡到一分钱，交给警察叔叔手里边。 请问有多少人在不受道德约束，制度约束，社会评价约束的情况下捡到钱愿意上交的？
一屋不扫何以扫天下，但为什么制造行业车间还要制定6S,7S，明确要求工人交班后要打扫工位卫生？
这些常识感觉就像知识的诅咒一样。
知识的诅咒：斯坦福大学的“根据节拍猜儿歌名”实验
1990年，斯坦福大学的博士生伊丽莎白·牛顿做了一个实验。她把一群人分为两组：一组人为一些大家耳熟能详的儿歌打节拍；另外一组人则根据节拍来猜这些儿歌的名称。结果大多数打节拍的人认为另外一组竞猜者能够猜出歌名，可事实上很少有人能够猜出。
史蒂夫·斯洛曼和菲利普·费恩巴赫在《知识的错觉》中提到了“知识共同体”的概念，这个概念可协助解释“知识的诅咒”现象。人类的进化，实际上是一个认知分工的过程。为了工作更高效，人们会进行分工，人们会按照分工自然而然地进行归类。具有同一“知识共同体”的人，具有相同的知识背景；而具有不同“知识共同体”的人，具有认知差异但却很难被意识到，人们在沟通表达时就容易形成“假设你也知道”的条件，进而造成沟通障碍。
由此看来，常识不一定可靠，所以我们可以推论：
常识不一定可靠，
在工作中运用常识，
在工作中运用常识不一定可靠。
常识和沟通
沟通从广义上讲是一门哲学，至少目前为止，我也还处于初窥门径的阶段，还有许多值得思考和改善的地方。但我们今天已经知道，人和人在沟通过程中存在信息噪音以及不同的认知，会导致沟通的内容传递失效，所以在沟通过程中努力确认对方是否真的了解自己的需求以及对方的需求，避免因为“我知道你知道”或“我想你应该知道”这样是似而非的“常识”问题造成信息误差。
4086
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
