本次社区活动第三大收获是对自省和搭档意义的再认识，因为活动中我又多次亲历知识的诅咒。

何为知识诅咒？有很多相关说法，佛家云：知见障；彼得.圣吉道：心智模式；还有人称：偏见的自我证实。虽然各说法在关注点上略有差别，却指向同一个源头：知识丰富、想得多、想得深，未必总是好事。本次社区活动过程中，我就有好几次教训：

第一次教训发生在14日话题讨论迭代时，当时我们组的阶段任务是：分析在中型组织中如何驱动转型。由于去年自己一直参与这方面工作，已经有一定思考，所以任务一安排，脑海中自然而然浮现出全盘脉络：先绘制中型组织结构模型，再选单团队试点，顺带培养团队教练，成功后再扩散教练到更多团队中引导转型，由此核心问题就变成如何选拔培养教练（回到自己熟悉的话题）。但和队友一交流，却发现，怎么这么“明显”的思路，大家好像都不明白，而且是从一开始就不明白？再一想迭代所剩时间不多，要赶紧输出东西啊！于是我心急火燎的想给大家解释，但越是急着解释，好像大家越不明白，于是。。。。我们开始无休止的反复绕圈澄清？最后还是大卫张忍不住住介入，让我们重新审视要解决什么问题，绕圈才停止。

事后一思考，这里至少有两个问题：首先，大家不明白我说的话，是因为这问题自己以前想了很多，已在不知不觉中把大量假设前提当作不言而喻，但事实上，他人脑海中并没有这些预设假设，所以我的描述在别人听来，就是在不断跳跃，当然难以明白，而这时，越急着解释，就越是在假设基础上又牵扯出更多的事，短时间内大量信息挤在一起，不让人糊涂才怪！其次，我参与这话题，本是希望在与大家交流中找到组织转型的一些新思路或启发，也就是说，真正对自己最有价值的是先让集体思路飞，看看是否有新思想涌现，而不是急着沿自己思路往下引。

这个教训说的是知识诅咒头两大特征：一则，对问题想太久，不知不觉中已把推理依赖的大量假设当成事实，或者想当然觉得这已是共识，大家自然就能明白；二是，想得越多，就越喜欢自己的想法，于是总忍不住为之摇旗，即使完全没必要这样做时。

第二次教训发生在16号的CSPO培训中，我们玩Dice游戏。每个团队得到一大堆扔骰子获得特定点数的任务，不同任务价值不同。PO要求各组每个sprint扔15次骰子以得到尽可能多的价值。我们组一个sprint下来只得了30分，而其他组竟然纷纷报200分，300分，差不多是我们的十倍！难道是我们选任务时太保守，不敢选高价值任务所致？于是第二个迭代，我们大胆选了一些100以上的高价值任务！但是，15次骰子扔完，一个任务都没能完成！看其他组好像一直在攻城掠地，我们终于忍不住了，直接问PO，任务太难，我们运气太背，不亏钱不行了！PO问到，“任务怎么写的？”，“扔三个骰子，获得2，3，4”，“这很难么？”“确实难，概率差不多是三个六分之一相乘，想在十五次投掷中就得到简直不可能！”，“扔一把，有2出现就是获得2，再扔一把有3就算获得3，什么时候3个数字都获得过，任务不就完成了么。”“啊！？这也行？”“这就是我要的，任务单上可没说必须是一次扔三骰子，同时出现2、3、4”，“……”，是啊，任务单上确实没写，但我们刚才怎么就这么确定需求文字描述清楚无误？

这也是知识的诅咒，惯性思维导致错觉！当我们看过前一个任务“扔一个骰子，获得2”后，自然而然就认为 “扔三个骰子，获得2，3，4”必须是一次扔三个骰子同时得到2、3、4。

第三次教训发生在18号的CSPO培训时，当时我们在做作业，名词解释：匹诺曹。这故事我太熟悉了，匹诺曹是一个小木偶，特点是说谎鼻子就会变长。而Daniel在分析案例时讲过，用户很多时候口头说的和他们真正想要的并不一致，需要我们设计实验去验证。“那这名词含义不就很清楚了么，匹诺曹就是测谎仪的意思，即设计实验场景，场景中放置匹诺曹，当用户的实际行为和他们口头承诺不一致时，匹诺曹就会将其暴露出来让我们知道”。想起来，这真是完美的解答！实际上是这样么？当然不是！教材40页有清楚的解释：Pinocchio（匹诺曹 ）：Build a live-less version of your product。也就是说，在这里，匹诺曹取的是“假人”（木偶当然是假人）之意！

这案例最有意思之处在于，如果我根本不知道匹诺曹的故事，或者不知道匹诺曹说谎鼻子会变长，或者不知道“用户是骗子”及类似故事。那我就无法推测“匹诺曹”的意思，就只好去翻教材，但要是这样，就不会犯下这个望文猜意的错误。现在恰恰因为我知道这些知识，所以自信的不再翻书，反而就搞错了。这不是知识的诅咒是什么？因为熟悉知识，所以很容易做出推论，而自己的知识又让自己更确信推理是正确的，于是小心求证不再被需要了，最终就掉坑里。

可怕的知识诅咒！可能打破么？目前所知有两种做法。

一种如曾子曰：吾日三省吾身。经常回顾反省，这确实有用，但可能还不够，因为对知识诅咒的感知，我去年就或多或少有所体悟，并有心想避免之，但事到临头，还是多次着道，毕竟修行非易事。

另一种做法呢？ 回想前面这三次教训，教训一的解决是大卫张从外部介入，建议我们不要纠结一处，转移下思路；教训二的解决，是队友对我们组掷骰子效率太低难以容忍去问PO；教训三的解决，则是学友查书后发现我对匹诺曹解释和教材不一致，于是提出疑问。

这就是说，他人介入是打破知识诅咒的强大武器。课堂上，我向Daniel请教，ScrumMaster是守望者，但守望者也会犯错误，这时谁来提醒守望者？答案是，建议两个ScrumMaster结对，在第一人引导团队时，另一人在旁边观察，并给出反馈。

这种工作搭档机制对破除知识诅咒应该是非常有意义的。我在想，结对编程被推崇是不是很大程度上就是因此缘故？更进一步，我们是否可以在更多工作场景中引入搭档结对机制？比如，所有非重复性机械工作都以两人搭档为基础安排？后面在工作中，要考虑多尝试一下。