绩效评定
在RH工作的转折点就是秋冬季新版绩效规则的推行。首先震撼人心的指标就是每千行Bug数，这让同时写Cpp, C#, Python的我一时不知道持什么标准好。这种规定我上次看到还是在对日外包公司写纯C代码，真的按行算钱，但是写多少行都定死的那种，是业界之耻的存在。
然后可以发现，规则中混杂了很多领导个人看不惯的问题，但是我觉得不要把个人偏好和个别问题，放到通行全公司，针对所有人，持续很长时间的规则当中。
设想两位员工，其中一位需要经常回答技术支持问题，另一位不用。那么绩效中有一项是关于对技术支持问题的回应，那么后一位员工该项打多少分合适？满分。零分，60及格分？如果两位员工不计较还好，一旦较真，打多少都是个破事。
通用绩效管理适合流水线作业式公司，即大家工作高度同质化。假设社会平均生产力是每人每天生产10个箱子，那生产11个箱子就是绩效优，9个箱子就是绩效差，这种情况下可以通用一套绩效管理制度。而现代软件行业是高度分工的，尤其是不大的公司几乎没有两个人从事相同工作，无论是通用绩效标准，还是末位淘汰制度，在这个大背景下都是不适用的，除非强行推动去分工化，面对复杂工作也是人均通才。
也有一种办法，在绩效中定的规则都是泛指的，比如要求有文档，运行速度快，造成崩溃少等等。这倒是能对应上所有人的工作了，但是规则越宽泛，则效果越虚化，打个比方就是越简单的题越拉不开分数阶层，这套更像是合规性要求而非体现成绩的绩效要求。
对绩效的评定，锚定物是市场平均生产力，而不是这个人之前的表现，更不要轻易参照其他人，尤其是领导自己的过往表现。否则，就会出现了“因为对你期望高，所以对你期望低”这种荒谬闭环，或者是"我当年轻松一下午修10个Bug，你怎么不抓点紧"这样的惊人言论出现。
说到我自己，最后还是被约谈了，悲哀的是，领导想列举我的工作，吭哧半天没说出来啥。我在想，如果连我做啥工作都不知道，让我怎么相信绩效评定是公正的？或者说，只关心核心逆向问题和关键友商功能实现，其他的都不值得关心？更悲哀的是，我想反驳一下，结果我也想不起我都干了什么值得称道的事，简直完美印证了领导对我的刻板印象。
若从博弈论来讲，我和公司陷入了经典的囚徒困境，处于赢利表中双输的右下角。即公司不相信我真的是在努力工作，我不相信在公司还能获得较好评价。那为啥不走到双赢的左上角呢？我只能说当初来的时候努力过，但是也确实是工作理念有点差别。
我一直秉承不欠工时的理念，显然大家对工时的理解没有达成一致。我所理解的不欠工时是指不以个人原因延长整体关键路径，甚至尽量缩短，这也是我一直追求的目标。而如果以在工位上对IDE看代码满八小时来算，那我确实没能满足要求。
还有一个可讨论的观点，那就是所谓的多功能选手到底有什么用？无论会多少种语言，不都是每天8小时工时么?我个人感觉，多功能选手的最大作用就是在多个项目的非关键路径上进行灵活调度，可以低成本的利用“闲余”的战斗力。
尽管做出了会努力改善的承诺，但是对于前景还是持悲观态度。有时候我会问自己三个问题，假如公司必须在组里开除一个人，这个人会不会是我？假如公司只给一部分人涨工资，我在哪个半区？我现在和未来所做的工作，有多大概率扭转这一局面？
不言而喻，一目了然。