摘要：作为项目经理，大多数项目经理没有直接绩效评价的权利，一般多是从间接角度去评价，或者提供绩效评价的参考。团队绩效准备，项目经理输出项目绩效数据，包括公司纬度指标、部门纬度指标、项目纬度指标（团队整体的需求、任务、缺陷、热修复等，各领域的值得表彰的人，或应该打低分

作为项目经理，大多数项目经理没有直接绩效评价的权利，一般多是从间接角度去评价，或者提供绩效评价的参考。团队绩效准备，项目经理输出项目绩效数据，包括公司纬度指标、部门纬度指标、项目纬度指标（团队整体的需求、任务、缺陷、热修复等，各领域的值得表彰的人，或应该打低分的人），数据提前准备好，或者做常态化准备，日常工作做记录，能够快速查看个人数据，方便在有疑问的时候快速调出来系统数据。

团队项目绩效数据

一般公司的绩效评价团队内是强制分布，打出差异性，比较知名的是阿里的361或者271分布，其他互联网公司有发扬光大，比如22231分布。当然也确实有这样的情况，团队同学都很优秀，很难分出ABC，那就全团队都拿一样的中等绩效；从强调激励的角度，那些付出多且有成绩的人，应该打出高绩效，那些付出少且没啥成绩的，自然应该打出低绩效。

具体操作，一般是团队内部先排好序（以中位数绩效往上往下打），每个人心目中都有一个排序，但每个人都可能只看到了一面，“兼听则明，偏信则暗”，除了看到大家的优点，更重要的尽量公平公正，不要让真正付出的同学受委屈，至少不能比那些“摸鱼”的绩效差，否则就太有失公允了，项目经理要站出来说明自己观察到的情况，发出项目纬度的声音。

项目纬度为成员发声

以数据为基础—偏正面的（完成交付需求任务最多的，代码行数最多的，响应缺陷最快的，计划最好的，评审最多的，分享最多的，公司战略项目的骨干成员，公司部门各种星）；说不准的（修复缺陷最多的—可能看本身那块的情况，提交测试任务多但打回率高的，发布任务数量最多的等—可能小任务多）；偏负面的（比较低级的代码问题，做得少打回得多，代码量少但出温特多的，没遵守流程造成线上故障的等）。辅之以日常观察+听到的内容，可以考虑这些维度：流程的合规性，交付项目“卷”的程度，对团队项目的支持程度，内外部项目影响度。从技术难度上说，可能技术负责人更有发言权；但从项目日常表现来说，项目经理无疑有更多发言权，尤其是很多细节层面，包括对项目的日常改进建议，对团队其他成员的帮助，在内外部团队的影响力，给团队整体指标/能力提升的影响等。

产出度/投入度/合规度/产出度

通常来说，人才的标准以能力为基础，以态度为根本。能力好，态度好，沟通能力强的，自然是受欢迎的，很容易拿到高绩效；能力不行，态度可以，想办法帮他们提升能力；有能力，态度不行的，有时候会心累，这种按照马斯洛需求搞一下；能力态度都不行的，直接双开算了。实际上，每次绩效有发现突然爆发的同学，绩效可能之前中规中矩，就是挪了一下项目或者手头上的工作就发光了。除了运气加成外，有些同学给了机会就真的把握住了，有些同学可能越陷越深，确实发现才能和所做工作不匹配的情况，负责人或者项目经理也要留意到，可能适合别的部门。

厚积薄发，可能只是缺少个机会

好久没有一气呵成的文章了，在这一块儿真的有话说，为项目团队成员发出应有的声音，以数据支撑，结合日常观察，让绩效评价成为项目管理的一部分，提前输出数据，提前认知，会上积极发言，强调多快好省/合作精神/团队精神/合规/解决问题/上下游的影响力/专家影响和—有问题找X哥等，关注部门各个成员的情况，能够给出令人信服的数据和事实，争取能够常态化准备，有自己的排序，然后跟负责人的比一下，提前沟通好，推动不同付出程度的人得到应有的绩效。

来源：英语小课堂