团队绩效考核的思考-CSDN博客

如果我做得很好，为什么有S、A、B、C这样的等级；如果我做得不好，为什么一定要等到考核时才反思

大部分人在工作中都会有考核，我所经历过的，有每月考核一次的，有一年考核一次的，目前是半年一次。7月初，是反思上半年工作的时候，因此我得填写下面的表格（省略部分内容，比如价值观的评分标准仅留下得0分的情况）。

img_cc08f74a9b982a84ae570dc036439502.jpe

绩效考核表格

在每个公司填写的表格都大同小异，请允许我先描述下填写这张表格的心情：我TM这半年都干了啥？这分打太高是不是不太好，领导会认为我自以为是？如果别人打很高自己打太低，是不是会被坑？领导给我打分太低怎么办？一定是他对我有意见？在纠结中，我填完了这张表格，发给领导，over！！！

回过头来仔细观察这张表格，我觉得至少存在以下问题：

不管是自我评价还是上级评价都带有强烈的主观意愿，只要主观就会与实际产生偏差。
关键绩效指标不能量化，那么评分的依据是什么？
价值观评估我也就不说什么，你们高兴就好。

因此，这张表格是否可以真实的反映出一个人的表现，我是存疑的，那如何解决？

我总结的一个基本原则就是：关键绩效指标可量化，价值观相互评价

具体如何实施？

上面表格其实可以把考核指标分为3个类别：

A、关键绩效(业务类)：产品功能、技术体系、准时完成任务、代码质量等等
B、关键绩效(贡献类)：推动新技术落地、优化流程、开发新工具提升效率、技术分享等等
C、价值观

A类业绩指标考核

对于A类指标，可以通过各种项目管理工具来统一量化。比如，我们使用团队TAPD(敏捷管理工具)来管理各个迭代的开发，每个人的贡献、评估规模是否准确、是否准时完成任务都可以在上面体现，但有一个基本前提是每个需求预估的工作量需要非常准确。我们团队在实际的落地过程中，几乎每个迭代均有延误，甚至偶尔会出现一些需求因为前期协调原因导致不能如期上线。究其原因，我认为有以下几个方面。

首先，我们的产品经理前期准备工作不足，有些复杂的逻辑没能在其设计的原型上体现出来，开发接到需求时以为很简单，但实际工作量却不止如此。还有一些交互逻辑原型上没能体现，也没有详细说明，导致该需求在已经完成后才发现交互不合适，需要返工。解决这些问题，需要给我们的产品团队提出更高的要求。

其次，是各个角色的协调配合问题。一个story通常需要UI设计师、前端、后端等3个角色协同完成。而前端开发依赖UI设计和后端接口开发，往往UI设计或者后端出现延期时，前端开发就不能按照原计划日期开始或者完成，最后导致整个需求的延迟。这时就需要考虑“UI设计” 与 “前端开发”、“后台开发”的前后置关系，比如UI设计应该是前置的，需要设计师设计完成且产品体验确认OK后，才进入开发阶段，而“前端开发”和”后台开发”是并行的。

综上，整个story可以定义以下流转状态：规划中 -> UI设计中 -> 开发中 -> 已完成(产品体验) -> 测试中 -> 已完成。由于UI设计这种前置任务的延迟会导致前后端都出现等待情况，为了避免这个问题，UI设计工作一般需要提前一个迭代，就是说当前迭代内，设计师的工作是设计下迭代需求的交互和视觉稿，并且需要和产品人员共同讨论确定。如果发现UI设计没有最终确定，一般这样的需求是不建议进入迭代的。最理想的情况是设计定稿，或者即使有些小细节未确定，评估也不影响本迭代开发进度。

解决了前面两个问题，最后就剩下开发自己预估了。我们团队在预估工作量时，往往把规模和工时两个概念混淆，但实际上它们还是有很大的不同。例如：同一个需求，资深程序员评估需要花费0.5天即可完成，普通程序员评估需要花费1.5天，这个就是工时，是一个绝对的概念；规模指需求的工作量有多大，是一个相对的概念，不会因为是资深或者是普通程序员的能力而变更其值。

我们团队目前都是按工时来预估需求的工作量，有太多的主观因素，会导致两个人的工作量在TAPD呈现出来是一样的，但实际工作量却大不相同。根据我们团队实际情况，可以设定1规模为半天的工作量，2规模为1天的工作量。在迭代会上，所有开发同学会针对某一需求进行估点，如果对规模估计有分歧，便阐述自己的理由，直到统一意见。一个迭代的总规模是固定的，估点完成后，按照优先级将超过规模的需求移到下一个迭代。最后根据预估的规模来安排时间，如果有任务延迟也一目了然。如果有紧急需求，那么需要产品和开发同学再次预估新需求的规模，然后根据优先级重新编排任务。

当团队严格按照以上流程完成每个迭代的任务时，我觉得基本上可以达到A类指标可量化的目标，对于代码质量，bug数量可以作为参考，但不应该是唯一的指标，具体问题具体分析吧。

B类业绩指标考核

对于B类指标，比如技术分享、推动新技术落地，不好量化，但仍然可以通过合理的方式来评价。比如我们团队可以统一规划未来一个时间段需要完成的技术任务（安全、监控系统、docker等）、自研工具......这些任务收集起来后统一放入需求池，然后由一个或者多个同学来认领，由认领的同学来推动实施，完成后将这个需求标记为已完成。对于这类需求的规模，团队讨论后得出一个相对值即可，当然这个需求池可以随时添加，只要团队意见统一即可。

这里提一下分享，其实目前我们不是没有时间分享，而是大家分享的积极性较低。如果要把分享纳入考核的话，给每次分享后打一个分数即可，比如每个人按照10分制打分，然后得出平均分，考核时累积一下分数即可。如果不纳入考核，每次分享后可以获得一份小礼物也是不错的。