绩效管理是对团队成员进行工作评估和激励的过程，虽然很多时候会由人事部门进行员工的绩效管理，但对研发团队而言，技术人员的绩效管理很难把控，所以很多团队往往对绩效管理避而远之，采用管理层主观判断的方法进行绩效把控；有些团队虽然会做一些绩效管理，但只是关注于绩效考核，而忽略绩效背后的工作计划、评估、激励以及过程改进。个人认为研发团队的绩效管理是一项很有挑战性的工作，但难度再大首先还是要理一下思路，尤其作为轻量级过程改进的一环，绩效管理的目的并不是说能够达到很完善的程度，而是先做到60分，然后通过团队整体能力的提升再进一步改进绩效。本文主要阐述在项目绩效管理过程中涉及的主要规程、可能存在的问题、分析这些问题并提出相应的改进措施。
国内中小型研发团队往往是从作坊式开发模式中发展而来，通常对绩效管理的意识比较淡薄，或者干脆没有绩效管理的理念和流程，管理层凭自身主观判断确定员工的绩效结果。当团队发展到一定规模时，管理层发现靠自己的判断已经不行了，所以就要搞一下绩效管理。这时候的绩效管理可以理解为是团队需要进行过程改进的一种预示，也是本文所要讨论的场景和初衷。我们都知道过程改进领域有一个PDCA环（由美国质量管理大师Edwards Deming基于Walter Shewhart所提出的模型演变而来，故又名戴明环），个人认为绩效管理本身实际上也是一个PDCA环：
过程改进如同项目计划需要进行阶段性规划和控制，绩效管理也是一样。通常绩效管理具有周期性，即以一段时间为限形成上面的PDCA环，实际操作过程中以一个月或一个季度作为基准的情况较多，最好不要超过一个季度，否则PDCA环的时效性将大打折扣。下文统称这一周期为绩效周期。结合绩效管理的PDCA环及其周期性，绩效管理的规程如下：
绩效管理和绩效考核是两回事，个人认为绩效考核应该是绩效管理中的一个环节，结合上文中的绩效管理PDCA环，绩效考核通常只包括Plan和Check两个环节，多为事后进行评估，注重形式和结果，主要是人事部门参与整个流程；而绩效管理根据团队目标设定绩效期望值，设定绩效指标后，不断激励并辅导员工，注重整个管理流程，通常团队管理者参与整个过程。片面强调绩效考核而不关注整体绩效管理流程对员工自身的提升是不利的。
对过程改进而言，绩效管理需要形成完整的改进闭环，在本文中我们提倡的就是PDCA环。但很多时候绩效管理往往难以形成闭环管理，闭环管理需要制定绩效计划、数据收集和分析、绩效评价和绩效诊断与辅导这四个环节，绩效的自评、他评、沟通和改进措施缺一不可。自评能够触动员工自身的管理和提升意识，他评提升管理层对员工绩效的管理和激励意识，沟通确保个人和团队之间达成一致，改进措施是本次闭环的最终产出以及下一次闭环的输入。没有进行闭环管理是实施绩效管理过程改进的根本问题。
如果绩效管理的结果仅仅是对员工打个分，那肯定是不够的。有些时候员工甚至对绩效结果都不清楚，那如何作出改进呢？所以对绩效结果我们需要进行诊断，找出好的地方和不好的地方，对好的地方要保持，对不好的地方要改进。改进的方向和思路通常都需要辅导，因为对普通员工，尤其是新员工而言普遍缺少过程改进的意识和方法，这时候通过沟通进行绩效的诊断和辅导就变得非常重要了。
绩效激励措施不属于过程改进的内容，但在绩效管理实施过程中必不可少。激励措施可能是物质上的奖励，也可以是精神和思路上的梳理和鼓励，无论哪种手段，充分的沟通是确保绩效激励的最根本方式。缺乏激励会导致过程改进流于形式，导致团队成员对绩效管理的积极性下降和过程改进意识的淡薄。
绩效管理的本质是为了提高绩效，提高绩效当然不能只靠引入一套绩效管理流程就想起到立竿见影的效果。但没有绩效管理的理念，不把绩效透明出来作为个人和团队的一项日程工作，绩效提升也就无从谈起。同时，绩效管理也是个人与团队管理者之间的一种纽带，促使个人和团队之间形成一种沟通机制。绩效管理过程改进的切入点包括：
上面提到绩效管理中的一个问题是“缺少从团队的角度管理绩效”，关注团队绩效也就是说我们要站在团队角度看问题。对研发团队而言，一个团队中包含多种角色，而研发目标通常是一个进度要求，这个进度要求需要团队成员协作才能完成。从过程改进的角度看，个人绩效的提升是一个点，而团队绩效的提升才是一个面，点的提升也是为了面的提升。
绩效管理的过程和结果需要有合适的表现形式，也就是说好的绩效管理应该具备统一的、合理的模型。目前主流的如KPI（Key Performance Indicator，关键绩效指标）、BSC（BalancedScore Card，平衡计分卡），还有类似google的OKR（Objectivesand Key Results，目标和关键成果）等都是绩效模型。但这些模型也只是一种参考模型，我们需要根据团队认识和现状做一下裁剪，本文不对这些模型进行具体展开。
针对上述切入点，我们梳理绩效管理过程改进的模式和实践包括：
绩效管理的起点是绩效计划，所以我们第一步就是同步绩效周期内的团队目标和计划。团队的计划一部分如同项目管理中的计划一样，需要根据具体的项目进行过滤和透明并形成统一视图。实际操作中，项目日历通常是项目级别计划同步的一项有效实践。另一部分属于项目以外的工作计划需要根据具体团队的情况进行梳理。
对大团队的绩效管理首先需要进行小团队分解，每个小团队有一个leader，这些leader负责自己团队中所有成员的绩效管理以及对应的过程改进，同时这些leader的上一层管理者负责这些leader的绩效，以此类推。每个小团队的人数控制在10人以内，建议根据跨职能团队组建原则进行团队分解并维护各自的绩效计划和目标。
建议在绩效管理中引用KPI体系，相对其他绩效模型，KPI容易理解和上手，使用也比较广泛。KPI系统的核心是建立KPI指标库并确保每个KPI能够进行量化，通常我们会根据不同的角色设计不同的KPI指标，常见的有：
KPI的特点是量化，但有些工作不一定能做到量化，不能量化的工作可以归为“重点工作事项”。重点工作事项可以根据具体情况进行设定，例如在本文的上下文中，把过程改进措施作为重点工作事项就是一项最佳实践。
自评和他评两者缺一不可，自评由个人填写，他评由团队leader填写。自评和他评不是打分，而是对KPI和重点工作事项完成情况的客观描述。从这些客观描述中，个人及其直属上级之间的想法和建议可以得到总结和认识，确保为个人绩效沟通以及后续的过程改进提供输入。
确保对团队中每一位成员进行个人绩效沟通，这是触发个人过程改进的最有效时机。个人绩效沟通由团队leader主导，基于但不要局限于《个人绩效表》中的内容。对研发团队而言，研发人员普遍不善于沟通和表达自己的想法，团队leader需要有一定沟通技巧让大家把心里话说出来，同时能够结合团队的整体改进目标和方式以及每一位成员的个人想法为其进行个人过程改进提高思路和指导。关于个人软件过程（Personal Software Process，PSP）和团队软件过程（TeamSoftware Process，TSP）的相关思想和实践方式可参考过程改进大师Watts Humphrey的相关著作，这里不再展开。个人绩效沟通的时间不限，个人认为如果能够和团队成员进行定期/不定期深入沟通，对于沟通时间上的投入信价比是非常高的。
个人绩效表主要包括以下要点：
绩效管理是轻量级过程改进系列团队管理类的第一个改进域，也是研发团队的老大难问题。与传统行业相比，软件是“软”的，开发过程中的不确定性和变异性确实很难通过量化的方式得到绩效结果。作为一名技术管理人员，个人也没有太好的策略和模式进行完善的绩效管理，所以本文从过程改进的角度出发，试图基于个人和团队过程改进为绩效管理提供一些思路，与大家共同探讨这一话题，有任何好的建议、意见可与我联系。
原文地址：http://blog.csdn.net/lantian08251/article/details/41038623
