从绩效考核到绩效管理——支付宝成都研发中心负责人

i__++

支付宝成都研发中心负责人
作者姓名:张林
作者简介:从纯粹的开发人员成长起来，后来扩展到架构设计、产品设计、流程改进、企业管理咨询、团队管理等方向。目前还不时会在上述领域进行实操示范。致力式带领软甲研发团队取得成功，擅长复杂系统理论的应用，熟练应用敏捷精益思想优化组织并取得成功。在个人与组织学习，软件研发中的绩效管理，组织流程设计改进,自份织团队管理，敏捷软件研发，精益管理改进，组织交付能力提升、异地研发团队组建与管理等方面有自信。站在软件行业发展前沿，乐于总结分享学习，2013IT博客大赛十大博主，多个软件大会讲师，2013敏捷中国大会联合制作人，敏捷之旅组织者，QCIun成都社区组织者，目前任支付宝成都研发中心负责人。
所在研发团队规模:50人
研发团队职能定位:软件研发中心。

从绩效考核到绩效管理

一、引言
软件研发团队的绩效管理一直以来都是个大众热衷谈论的敏感话题。似乎每个人都能说上几句绩效管理的优缺点，绩效管理的理论也广为人知，然而关于绩效管理的实战案例却少有人分享。无数人对现有的绩效管理不满，然而对敏捷之类的绩效管理，大家又觉得过于理想。时至今日，争论不仅没有停息，反而愈演愈烈。
本文将一个软件研发中心两年来的绩效演变为案例，结合笔者在绩效管理上的探索经历，展示如何带领团队从传统的绩效考核一步步走向绩效管理。
二、案例简述
这是一只异地研发团队，简称C研发中心，在成立三年后终于被公认为有激情敢承担的团队，开始承担起更大的职责。其绩效管理的模式在经过了多轮演变后，已经成为了团队发展的发动机。
虽然结果是令人鼓舞的，但是过程却总是曲折的。在这三年中，C研发中心经历了许多挑战，绩效管理也发生了一波三折的变化。
1.美好幻想:绩效管理很美好
在加入C研发中心之前，我对该企业的价值观和绩效管理有所风闻，听说就是强大的企业文化帮助了企业的成功。加上自己之前作为外企的“top performer",对绩效管理心存感激，就是因为绩效管理挖掘了自己的优劣势，找到了方向，自己才干得很好。在自己即将加入有强大绩效管理能力的团队，学习新的绩效管理知识时，我对未来充满了美好幻想。
2、初入牢笼:可怕的绩效考核
然而，理想是美好的，现实是残酷的。让人没想到的是，绩效考核、命令控制打造了一支高执行力但缺乏自主性的团队。由于这一点C研发中心负责的产品被公司取消，团队陷入被解散的危机。风雨飘摇中，人心惶惶，我也陷入了困境。下面是这段时间发生的3个典型案例。
初到公司，我就被主管堵门。因为没有明确指令他们不知道下一步工作该如何开展。而我因为不了解情况坦承自己无法做决定而饱受质疑。同年12月，整个研发中心基本停摆，几乎所有正在研发中的软件都不能上线，都需要延期。因为所有测试同学的(KPI里面都写着UI自动化测试的覆盖率，绩效考核期快到了，他们必须去提升UI自动化测试覆盖率，即将上线的软件面临无人测试的困境。因为主管掌控了绩效考核权，所以团队做事需要观察主管喜好。听说要加强沟通、提升透明度、扩大影响，于是人们的周报都是精心制作的职场感悟、工作思考，不这样不足以让主管看到。因此，作秀风泛滥，江湖俗称“秀亮点”。
3.转机出现:整顿调整，抓住机会
2012年上半年，公司进行了组织机构变更，研发中心也被调整，更换了领导，调整了定位。研发中心的人员作为公司共享资源池，动态承接公司项目。为了和外包NDC区别，简称ADC。一时间又风雨飘摇，部分人选择离开。
这时，在新领导的支持下，我们抓住机会进行了绩效梳理，组织了岗位层级职责梳理和价值观培训，统一了组织绩效考核的判断依据。通过晒目标的方式，让研发中心管理团队对研发中心的绩效目标、相互协作方式达成共识。为团队制定了细致详尽的绩效辅导方案，并逐一辅导沟通。通过双周会的形式，让整个团队对组织的绩效情况有所了解，明确后续工作并针对问题制定措施。
我们还尝试了集体评估绩效的方式，让绩效结果不再由主管单方面决定，这使得绩效评估更加公开透明。
次序，人心也稳定下来。但真正的转变还是来自业务上的成功。当公司将一个基本已经确定失项目从总部放到研发中心来后，团队顶住困难，化危机为机会，用4个选位
来了逆转。
4.柳暗花明:乘胜追击，多线开花
为了拿到更好的绩效结果，C研发中心进行了更多探索和尝试。
尝试建立多个稳定团队，让开发测试同学组成跨职能的稳定团队，长期务于一个固定业务。梳理了PM、主管、架构师等人的职责分工，明确了结合工层级岗位的工作指引。在团队建立、项目启动时，通过团队nception,对项目目标的认识。随着组织结构逐步向交付小团队转变，调整了绩效模板，交付小团队为团队的交付结果负责。同时，建立了交付能力模型，推动交付团队能力评估和现状分析。
通过上述措施，C研发中心从传统的命令驱动式组织机构转变为以多付小团队为中心的交付结构。前期的各项准备工作激发了各个小团队的工情，让小团队放心为团队结果努力，业务开始出现多线开花的趋势，逐渐承担起更加核心的业务，C研发中心逐步得到认可。
5.新的探索
初步取得成功后，C研发中心继续尝试新的旅程。C研发中心进行机构调整，让组织更加扁平化，每个管理者大概管理20人左右，减少了的绩效辅导;尝试调整发布频率，让某域的多个小团队通过每月一次的变与客户的联系，有效改变了该域在客户心目中的形象。不仅集体进行估，还集体进行绩效设定，绩效工作逐渐变成了公开的日常工作，团队对绩效管理的关注中转向怎么拿到更好的结果。
三、经验教训
C研发中心经过两年多的发展，从濒临关闭、众人失去信心的情况出来，开始承担起公司比较重要的职责。这两年多来，C研发中心的莫式也从比较传统的绩效考核走向新绩效管理的探索，业绩与绩效管理模式的发展基本同步。下面是对绩效管理活动提出的一些尝试和规避建议。
1.避免固定不变的绩效管理模式
固定不变的绩效管理模式看似标准公平，但实际上真正带来的是僵化，就如那让人诟病的GDP。绩效管理模式需要随组织发展需要变化，与组织同步发展，甚至推动组织发展。
2.避免绩效考核与敏捷不匹配
一支死气沉沉、全靠绩效考核推动的团队是不可能敏捷的。而且细致入微的绩效管理与微观管理是好伙伴。在C研发中心，强推敏捷软件研发的结果就是，把偶尔加班变成了一直加班，个人工作负担和压力巨大，但都不敢表露出来。
3.避免绩效考核的斗智斗勇
以考核为中心的绩效管理模式往往会演变成绩效设定时的斗智斗勇。员工期望设置难度低、标准清晰、容易达成的目标，而主管则期望设置难度高、相对模糊、难以达成的目标，双方斗智斗勇，相持不下，直到设定时间用完为止。建议避免这种情况的出现。
4.避免绩效考核强推SMART 目标
SMART目标才是“高大上”，所有的绩效管理都强调 SMART。但是，在软件研发中强推SMART的问题是，到最后只考核了那些容易考核的过程指标，并且这些易于考核的指标往往代表着上个世纪的软件研发，最后带来的是组织的僵化、低战斗力。
5.尝试晒目标
晒目标是一个会议活动，在该会议上让同一组织的成员相互晒出自己的绩效目标。本活动可以让组织成员一起思考组织的目标能否通过各自目标完成而完成，相互间存在哪些协作点，这对目标共识、沟通协作等都有不小帮助。
6.尝试人员盘点
在绩效考核时期，细致的人员盘点对主管的管理帮助巨大。当团队逐渐走向绩效管理后，人员盘点将不再是主要的管理工具，无需经常进行。
7. 尝试职责分工岗位层级梳理
明确分工、流程固化是很多组织的行为习惯。然而，没有永远合理的分流程，人员能力、互动一直在变，组织也会遇到外部变化。每隔一段时间，这行一次职责分工岗位层级梳理是非常必要的，让每个人清楚自己的位置。所的敏捷自组织团队，则是以更快的速度调整。
8.尝试设定与考核分离        考核是按比例的，设定是按指标的，只有神仙才能在设定指标的时候就
按照最后达成的比例来调整指标。既然你不是神仙，为什么最后考核的时候是按照前面设定的指标来考核呢?这不是骗人吗?所以，得想办法把设定与考
分开，设定是设定，考核是考核。
9.尝试稳定团队为业务负责
绩效考核的难题在于，绝大多数组织是按照资源利用率最大化来优化的,并未考虑到绩效考核，从而让绩效结果与组织的实际业务结果基本上没有连锁这给绩效考核带来了很大的难度。稳定团队是一种很有意思的尝试,被激励值稳定团队力求拿到更好的业务结果，可以让绩效考核更简单更有效。
10.尝试让绩效管理从有到无
很多组织的绩效管理都做得很重，组织成员的注意力不在工作上，而是在绩效管理上。这种不专注的工作状态并不能给组织、个人带来更好的工作绩效,建议将绩效管理的工作逐渐融入到组织拿结果的过程中，让组织的员工更加专注于去拿到好的绩效结果。
11.尝试持续变革绩效管理模式
绩效管理看起来很简单，实施起来很复杂。需要结合组织当前的情况，断对实施方式进行变革，绩效管理活起来了，组织也能活起来。一方面批判织的僵化，另一方面却想用僵化的绩效管理提升组织活力，这似乎有点说不通
四、启示
1.绩效是组织的，也是个人的
很多人对绩效都有误解，认为绩效的关键在于是否能有效考核并激励个然而，绩效其实是连接组织与个人的重要工具，绩效管理的真正价值是让的努力能够真正给组织产生价值，帮助组织拿到更好的绩效。
仅能推动个人努力工作，却未能给组织带来更好结果的绩效管理比比胃很多管理者自觉不自觉地承担起绩效分解的工作，将绩效目标进行。然而们自身并未站在软件研发的前沿，他们对绩效分解的方式还来自于上个世这往往导致错误的方向。但这不重要，关键问题还是在于员工执行力不足他们早就准备好了理由。
在这种情况下，很多个体也接受了明显不合理的分解。他们不再关注组织的绩效，只关心自己绩效设定中的指标有没有达成。久而久之，他们就变成了本组织固定分解模式下的螺丝钉，不再有拿结果的能力，甚至不再适应其他组织螺丝钉的要求。
2. 绩效是阻碍，还是助推器?
鉴于软件研发组织中的绩效实施情况是如此让人怨声载道，很多人都认为绩效是软件组织发展的一大障碍，呼吁取消绩效。然而，绩效只是工具，工具的好坏更在于使用者。从本案例(也有其他案例)可以看出，合理使用绩效，绩效就不仅不是障碍，而且能够推动组织发展。
3.管理者、员工眼中的绩效层次
闲来无事，构思了一个绩效管理的成熟度等级，仅供参考，请勿对号入座。管理者的绩效管理成熟度:①用绩效控制工作;②绩效辅助理清工作;③绩效是团队做出来的;④绩效是自己做出来的;⑤创造让员工成功的环境。
员工的绩效管理成熟度:①为指标工作;②为工作工作;③为团队工作;④为自己工作;⑤工作就是工作。
五、建议
最后，祝愿更多人能不再为软件研发团队的绩效管理而困惑，用好绩效管理工具，让绩效管理真正成为组织发展的助推器。