在我工作的12年中，发现一个现象，如果公司存在绩效考核，那么实施者的流动性很大，也就是说实施者的绩效较其他人更低，为什么会出现这种现象，我们今天就来说说这个问题。
上节课讲到易得性启发式的一个表现是“易于回忆”一起的，我们常常会根据易于回忆的事情做出判断，这导致这在固定周期内，接近考核时间点你的表现大概率决定你的绩效。今天我们再来学习源于代表性启发式误判的表现，即“对基础比率不敏感”。先举一个例子：
有一个人去看病，已知患病概率1/1000， 但有第三种检测方法，检出率为86%，对为患病者仍有5%的错检率，这个人经过第三种检测方法被检出有病，问这个人患病的可能性有多大？
请先闭着眼睛想一想，一般人认为第三方检测准确率高达86%，则这个人大概率会患病，但通过正确的概率学计算，此人患病概率大概是1.7%。如果你觉得这个结果太不可思议了，那么你基本对“基础比率”太不敏感了。
那么回过头来，我谈一下有关于我自己工作中关于绩效考核，公司在判定方面的误判在哪里。我们说在一次版本迭代过程，合理的权重基础比率，产品定义需求：30%，产品设计20%，需求讨论10%，开发30%，测试：10%。
但实际情况是什么？需求不完善，就开始做的，设计不完整，中间补的，需求讨论，就是在需求告知阶段当场给出评估的，测试测出需求、设计问题的。中间边做边改、边加需求，程序员不好意思要时间的，最后项目延期了，产品说：我的需求给全了，设计说，我的设计也给全了，测试说，我们测出的问题，开发没改完，不知道互联网公司的同行们是否有这样的经历，无论你是哪个职位，可以仔细思考一下这个问题。当然这中间基本忽略了项目管理的权重。（顺便说一下，大多数项目管理可能都不太清楚让各方评估耗时的目的，其目的是保证在这个时间点可以按期交付，而不是给出一个较短的时间。）
在实际实施过程中，那些未确定，或者临时修改的需求，如何估算时间？每个改动看起来都貌似很微小，不值一提，于是开发人员很少能去修改时间，如果你提出，那是否会给人造成你能力不行的印象？如果没新加一个需求，你都提一次，会如何？
最终项目延期，各方都已经完成任务，实施者90%未按照要求完成任务，所以实施者的责任。其实很多情况下复盘都会说我们并不是要追究谁的责任，但事实数据现实，程序员的离职率远高于其他职位。我们往往忽略了其他职位的基础比率。但实施者对自己的过高估计，也是造成延期的一个重要因素，还有评估时的心理因素。
这是我在工作中人员流动性的一个体会。为了减少误判，也为了分析问题究竟出现在里，每次项目完成后，复盘应该包括一下几点：1.需求那些做了改动。2.需求那些做了增加。3.需求那些出现了逻辑矛盾。4.设计遗漏了那些。5.程序那些未按照需求实现。6.程序那些没有做。7.程序为什么没有改完测出的问题。等等……，我们应该把影响到项目进度的所有问题都找出来，按照基础比率来分析，最终得出一个比较合理的数值，来表示问题出现在了哪里。
找问题就应该用科学的方法，科学的数字，正是由于代表性启发式，即使原因和后果关系微弱或者毫无关系，我们也倾向于认定他们是联系在一起的。，学习误判心理学，就是要从本质上找出误判的根源在哪里，学有所用。
