防止老好人“破坏”体系，绩效 271 是在帮助中层
本期云上私享会讨论了百人规模研发团队的绩效管理，共有 5 位 TGO 鲲鹏会会员参与。他们结合自己的管理经验，交流了技术团队的个人和小组分别如何管理绩效、强制 271 分布比例的利弊、公司层面如何定义技术团队的”成功“等话题，希望帮助技术管理者及团队成员更好地进行绩效管理。
刘松是本话题的发起人，同时担任讨论的主持人。
刚才讨论中有人提到，绩效考核与晋升可以部分分开，我对这个观点也是支持的。绩效体现的应该是一些容易量化的部分，一些不易量化但是也比较重要的，例如团队协调、对他人成长的帮助、对外技术影响力等，可以在晋升时候加以考虑或者用其它形式进行鼓励。我们公司对技术人员的评价有两种形式，包括常规的绩效考核和季度之星的评选。季度之星有提名环节，会综合考虑一个人的团队贡献度，并且获得季度之星会对年底总体绩效评价有积极影响。
我们的研发采用 Sprint 的方式进行组织管理。基于管理工具，从 Sprint 的执行情况中可以直接获得量化考核所需的数字。但这有两个前提：
其一就是 Leader 必须敦促大家按照要求更新进度信息，这需要投入前期的培训成本。在初期养成使用习惯前，每个 Leader 每天例行的工作都要包含这一部分；
其二是任务工作量估算的合理性十分重要。完全客观的估算是不存在的，但要做到相对合理，例如引入双向的评估机制。在我们的评价体系里，研发守时性和质量大概占到权重的 60%。
绩效本质是为达成战略服务的，要看结果。而研发的工作是很难量化的，它的维度很多，没办法用单独的维度衡量。有可能 A 做出来的功能点比 B 差一点，但是他在协调团队、增加凝聚力上发挥了更重要的价值。再比如有些同学，他可能在业务代码上的贡献不见得比别人多，但在评审代码、重构代码上做出了较好的贡献。
针对量化，跟肃哥（陈肃）提到的有点不一样。规范性的东西可以通过工具来实现，每次提交代码，我们都通过代码检查的插件给他提示，并且我们要求整体覆盖。这等于做了一个硬性的约定。
对于代码质量的评估，是通过 PR 跟 CR 进行评分。评分会作为主要代码质量的一个考核，这是第一个。
第二个是 Bug 率。大家会经常提出说，“我的模块比较复杂，所以 Bug 数量多；他做的模块比较简单，所以 Bug 数量少。”我们是依据实际承担的工作量来进行评估的。现在针对工作任务的拆解，最大颗粒度不能超过两天，最好是一天以内可以进行代码提交的。我们用 Bug 和“工作量”得到一个比例，虽然不是很科学，但是 Bug 比例跟实际工作量应该是有一个平衡点的。
第三个就是上线后的问题。线上 Bug 的问题是整个团队都会背，肯定有一个团队主要负责，是研发的问题，测试的问题，规范性问题，还是产品逻辑上就已经缺失的问题？
在绩效考评上，我这里做的主要是二级控制，也就是把控住经理这一级。如果组长的考核评分有问题，那么经理就会直接去找组长。
再一个，我有一些客观的数据在那里摆着，如果能力也不行，并且有客观数据摆着，你还连分数都打不明白的话，这就一线管理者能力的问题了——这是另外一个话题。
如果是管理者的主观决定绩效，如何给同学们明确的导向呢？同学们怎么才能知道自己怎么做才能取得好的绩效？
我一开始创业搞研发绩效项目时，就想弄一套最佳实践，让大家都这么用。现在我发现，想一招鲜吃遍天是完全不对的——当时，我的思路是错误的。现在是标准化产品 + 个性化配置。也就是说，每一家公司就会按照 CTO 的理解、按照 CTO 的意志给他进行设计。CTO 是对整个研发体系负责的。你要投产快还是效率高？要哪个，就把哪个权重设置得更高，然后这方面做得好的人排名就会靠前，这就有导向了。
我不太同意这种观点，我觉得绩效绝对不能变成一个数学问题。数学问题涉及到制定全面的指标，这就一定会产生某些方面的偏差。我听过最夸张的笑话是，公司以代码行数作为衡量指标，半年以后基本上所有开源项目的源代码都出现在公司代码库里面了——大家不是用组件的方式，而是用代码拷贝的方式去解决问题。
我自己比较困惑的，也是我觉得最重要的一点是，做任何量化的时候，最终被量化的基础单元的合理性决定了你最终结果的合理性。大家都提到，无论是算工作量还算 Bug 率，测试出多少个问题，或者说做了多少个 Feature，这是很容易的。
但是，你的分母是什么？我问过一些朋友，当然无非就两种方式，
一种是非常简单的用人天。所有东西都用人天来估算。高级人员和初级人员的人天生产率肯定是不一样的，这会带来问题。
大一点的互联公司会涉及到很多的产品线，人员结构也比较复杂，他们更多是用像 Story Point 进行工作量的估算。 Story Point 的评估涉及方面比较多，是要大家坐下来讨论的。
我们之前也尝试过 Story Point 估算工作量，但最终又回到了人天。先是 Team Leader 估算说，我觉得这个东西大概需要多长时间完成。过后，如果他觉得这个东西难度比较高的话，可能倾向于让团队里经验丰富的人去做，以承担者的能力作为人天估算的基础。
我自己的观点比较简单。对于开发一个功能的工作量估算，只要是经过充分的讨论，其实都还好——不是说上面直接压下去的，而是有双向 Review，最终它一定开放透明地体现在我们整个版本迭代计划里，大家都能够看到。大家都知道每个人能力有差别，为什么给他分到 10 人天，其他人却是 15 人天？特别不合理的东西，大家都能看到，也会提出一些异议。增加透明性之后，它的客观性就能得到一定的保证了。
我从来不相信说，你直接导出一个报表，然后可以给研发人员进行一个打分——他确实还要去综合一些因素。这也是为什么现在做的绩效计划里量化的部分通常也就是 50-60 %。这是我的观点。
老陈，你的 Story Point 用得怎么样？我对这个比较感兴趣。
其实，我们最终又回到人天了，因为无法特别科学地定义 Story Point 是什么。
有一次，我们全公司级别做集体打分，结果排名跟我心目中的排名一样——我觉得这是挺可怕的。在这之前，我一直觉得我的判断比别人更公正一些，更准确一些。最后发现大家集体打出来的结果和我的判断是一样的，也就是说，谁也不比谁高明。这个事对我有很深的教育，之后我就比较相信，只要这帮人是有一定水平的，他们打出来的分数就是差不多的。 但是需要注意的是，评价人群要有一定水平。
我们现在的规模，我觉得一定是要强制分布的。强制分布也是一个公平的手段，否则出现一些问题。比如人比较好的 Leader 评出来高绩效的人会比较多、低绩效的人比较少；狠心一点的 Leader 评出来低绩效的人会多。
回到本质，我同意绩效本质上是个数学问题，只是说在此阶段这个数学问题还没有太好的解。 任总（任晶磊，Merico 思码逸 CEO & TGO 鲲鹏会会员）在分享中提到的观点，我觉得真的挺好，所有的程序员做的主要是在两个端，一端是 Activity 活跃度，一端 Achievement 成果，要往这两个方向去做，因为这些都是可以有数据的。如果这种数据能度量出来，并且和主观判断非常接近的话，那么它会解决公平性的问题——达到这个阶段的话，我觉得强制不强制就不是问题。
来自 TGO 鲲鹏会公众号文章《我是怎么用数学方法，统计分析远程研发团队效能的？》
总结一下，强制不强制在没办法解决度量的问题时，是有意义的，特别是在大一点的团队里面。 如果度量能解决公平性的问题，度量的评价跟主观评价非常接近，那就不需要去强制了。
我对这个问题也是蛮困扰的，特别是在 AB 的结合部、BC 的结合部——谁比谁差多少吗？没有差得那么明显。但是你一定要有个排序，对吧？你也一定要有一个比例，这部分人还是挺受打击的。这当然是个问题，我想把这个问题拆解来看，分成两个问题：
一是要不要分级。我觉得分级是必要的。 你得有最突出的同学，得有比较不错的同学，也要识别干得不怎么样的、达不到要求的同学。
二是要不要有强制的比例。这个我还没有太想好。我了解到华为有的部门在尝试放大 A 和 B+ 的比例，让部门有比较大的自主权，决定这些做得还比较良好的同学到底占多少。不那么严格地一刀切，这可能更适合研发同学。当然，这比较要考验主管的水平了，主管不能不按实际情况乱来。
要分级，分级比例是不是一定要强制，比如 271？我觉得这个可以放开一点。就像刚才智泉说的，如果结合了更多的数据指标的参考，让他没办法乱来，就可以有更大幅度的浮动。我是这样考虑的。
我也赞同智泉（冯智泉）的说法，就是小团队没有明确的 271，每个人的任务和结果都看得很清晰，我们整个团队在刚开始的稳定性也不错。
为什么后面开始强制 271？原因有两个：
团队大了，我们要有指标性跟结果导向。
团队大了，要有淘汰机制，让团队活力更强。如果没有绩效跟 271 的强制约定，可能就会存在有些人吃大锅饭。271 的比例激活整个团队的竞争意识，也让突出的人更快地显现出来。
强制分布到底是解决什么问题？或者是解决谁的问题？
我理解强制分布解决的是中层管理者评绩效标准问题。这帮哥们评绩效可能能力不够，可能倾向于当老好人。不拿这个东西卡一下，他的主观评分肯定是问题。这是一个保底线的问题，防止中层的老好人把绩效体系彻底破坏掉。如果是你用量化的方式能解决这个问题，强不强制是无所谓了。客观的标准上去了，能解决甚至能替代掉中层评价的话，完全就按照客观的结果走。就是这么一个话题。 这是第一个，关于强制分布。
第二，我是看重排名的。强制分布出来以后，怎么处理？我设计的逻辑是，最后 10% 默认强制淘汰。 有些中层是知道有的人该淘汰，他开不了口，老好人。我用这个机制就帮他开口，就是说最后 10% 默认淘汰状态——但是，你的 Leader 有权利说我不淘汰，Leader 如果要救你，我允许他再给你一条命，你还继续在这干。我这里放了这么一个口子。
核心就是说，这是一种简单的规则，体现 CTO 的意志。
刚才于人提的一点，我觉得比较赞同，就是在机制上让 Leader 更容易地去施行淘汰的事情。有些人非常不情愿去做淘汰，他觉得虽然说你产出不够高，但是一起工作这么久了，我不愿意去做这件事情……这点我还是蛮赞同。
微软转向云计算的过程中重拾工程师文化，其中重要的一点就是取消排名。对于创造性工作，员工需要安全感，而强制 271 也给员工带来的坏处，这个怎么理解？
这是个高档问题。日本还有企业提倡终身雇佣制。这个和每个公司的阶段情况是相关的。我的团队很强调 Team 考核，轻个人考核。
为什么微软可以这么做？一是他的工资高于平均工资，二是招聘的都是高级人才。如果追求的是高性价比的人才，这样的方式就不适用。
我们是业务结果驱动的，就是看什么时候完成、上线后是不是会出现问题、客户问题是不是及时解决了。我们现在客户续费情况很好，公司对研发团队的服务满意度是没问题的。绩效方面公司最看中的，是量化研发团队的延期率和客户生产环境的 Bug 率。
我觉得两方面。一方面，“老板如何看”这是老板的事儿，比如老板不懂技术，他就不知道什么对于技术团队是真的好，他知道的是研发有没有支撑好业务。另一方面是看长期、短期两个维度做的事情。长期上，我们要做制度建设比如 CI/CD、自动化平台来提升效率；短期上我们就是根据战略，用最优方法支撑业务。
还有就是，公司觉得你好，这个问题很复杂，需要多和老板谈，做向上管理，知道老板的要求。
这个问题我也有困惑。我认为这个问题的前提是，技术要保证业务成功。战略目标对应的是战略项目，在战略项目上必须不能掉链子。没有业务成功，什么都没有用。第二是一些量化指标，比如研发效能、需求的产出率，这是保证底线的。第三是向上管理和沟通，和业务部门和老板都要有比较好的沟通。
我理解的跟松哥（刘松）比较像。我主要是负责技术指标和项目达成这两个事情。在拆分下一年度 OKR 指标的时候，花了一个月的时间，从这个角度，我这里的风险比较小了，项目很明确。我们要做好的就是项目交付，这是第一。
第二是研发质量，这是老板看得到的。我们今年的大投入是质量控制。上线后的质量是业务和老板能直接看到的。今年的质量指标会比较高。
第三个是向上管理和横向管理。我们都是有机会接触到业务，这时必须提供高响应的服务，要有双向的交流，业务提问题，我这里提出解决方案和时间。研发团队的人比较多、工资比较高，用前面这三点可以保证研发团队在公司的定位和在业务部门心中的定位。
我的一个总结是，数字化势在必行。我本身是提倡考核绩效要有主观因素的。但是现在我看数字化这个趋势是不以人的意志为转移。回归本质，CTO 的价值就是研发团队的整体经营绩效。
TGO 鲲鹏会发起的视频主题讨论活动。其特点是面向全球的 TGO 鲲鹏会会员，聚焦垂直话题，汇聚 6-8 人的小规模讨论；采用 Zoom 会议，打破地域空间限制；每场 2 小时，一起交朋友、长见识。