敏捷团队的绩效考核_迅思威尔敏捷咨询顾问_袁斌_V22.pdf

《敏捷团队的绩效考核_迅思威尔敏捷咨询顾问_袁斌_V22.pdf》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、大家好，我是袁斌，北京迅思威尔公司的敏捷开发咨询顾问，很高兴有机会和大家分享关于研发团队绩效考核的一些心得，我是来抛砖引玉的，同时也非常感谢无忧商务网提供了这个网络交流平台。今天我和大家分享的内容主要包括以下三个方面：①研发团队的绩效考核的方式②研发团队绩效考核KPI如何评估③如何让绩效考核发挥作用首先要说明一下：我给大家分享的内容是基于一个纯技术开发的考核案例。我先介绍两个词，以下内容用的比较多：“迭代”：整个开发周期分为多次小的开发周期，每一个小的开发周期是一个“迭代”“bug”：意思是漏洞、错误、缺陷等下面是具体的信息：①研发团队的绩效考核的方式很多人觉得研发

2、团队的绩效考核很头痛，甚至不想做绩效考核，其实研发团队绩效考核我认为是需要的，因为绩效考核实际是一个“指挥棒”，它会引导研发团队朝着企业认为最佳价值的方向，通过团队/个人自己的努力达到，而不是管理者通过“管理”的方式获得，这样的效果会更好。研发团队的绩效考核如何进行？以下是我的一些实践：研发团队的绩效考核要从团队和个人两个层面同时进行，团队的考核是为了增加团队整体对质量负责的效果，个人的考核是为了考量个体能力、责任心等的不同要体现个体的差异。下图是一个总体介绍：具体是：团队的考核主要是两个指标：每次迭代的交付物是否可以被接受；每次迭代的生产率是否理性的增长。前者是为

3、了保证每次迭代的质量，后者是为了减少团队开发的学习债务和技术债务。这里想多聊一下为什么我们会考量增加“每次迭代的生产率是否理性的增长”的指标。最初我们的团队考量指标是没有这一项的，但是我们会发现如下问题：团队在产品（或者项目）开发的初始阶段质量非常好，而且交付的效率也很高，然而在开发进行半年左右后，相同工作量的需求要比在初始阶段完成的时间长，bug的发散程度（指一个bug修改后，回归测试又出现了若干个bug，还可能是其他模块的bug）越来越高，后期维护成本也会不断增加。同时，如果开发过程中出现了人员流动，特别是核心人员的流动，项目的开发进度会出现非常大的风险我们不断

4、寻找原因，发现主要的原因是：团队在开发初始阶段追求“快”，但忽视了“学习债务”和“技术债务”。“学习债务”是指业务或者技术等信息掌握在某个人那里，在团队内部得不到共享，如果这个人遇到困难、调离团队甚至离开公司，会给团队带来很大的风险；“技术债务”是指代码、架构等缺少重构，造成扩展、维护等困难。这两种债务随着项目的进展，如果得不到及时解决，会越来越高。“每次迭代的生产率是否理性的增长”的指标主要就是为了解决“学习债务”和“技术债务”而定，我们并不希望管理层直接通过制度或者直接参与来“管理”团队以减少这两种债务，而是希望通过这个指标引导团队自我找到减少这两种债务的适合团

5、队实际场景的解决方案。刚才说的是团队考核指标，我们的个人的考核指标包含五个指标：质量、工作量、主动性、帮助团队以及成长性。质量是为了引导团队中的成员个体保证自己负责的工作交付质量工作量是为了体现团队中的成员个体对最终项目（或者产品）交付的贡献程度主动性是为了引导团队中的成员个体增加主动沟通和交流，因为一般研发团队的成员偏于内向，主动沟通的意愿和技巧不是很强，往往造成交付的产出出现需求质量问题（即做出来的不是需求方想要的）帮助团队是为了引导团队中的成员个体主动帮助团队的其他成员，共同对交付的产出质量负责，而不是“各扫门前雪”，否则很容易造成由于某个成员的某个环节出现了

6、“短木板”而造成交付不成功，同时也会影响团队的凝聚力和稳定性。成长性是是为了引导团队中的成员个体不断提高自己，持续改进。这个主要是为“新员工”而定，特别是工作经验不丰富的新员工。以上四个指标对于这样的新员工“不是很公平”，所以对于这样的新员工，我们不是很关注每一次开发迭代中的具体指标表现，而是关注每一次开发迭代后这些指标表现是否在理性的增长通过对于团队和个人指标的设定，我们考核就变得非常有效。下面跟大家分享一下第二个问题②研发团队绩效考核KPI如何评估团队部分KPI指标的评估方式：每次迭代的交付物是否可以被接受：以需求提出者对本次开发迭代交付物的评价为标准，分为“接

7、受”和“拒绝”两种每次迭代的生产率是否理性的增长：以每次开发迭代完成的需求工作量为评估标准，需求工作量不建议用代码行估算，而是建议用“故事点”、“理想工作日”等需求间的相对大小来评估个人部分KPI指标的评估方式：质量评估方式：对于开发人员，质量以“交付测试后发现的严重bug数量除以此需求工作量”来评估；对于测试人员，质量以“交付客户后发现的严重bug数量除以此需求工作量”来评估工作量评估方式：完成需求的工作量，需求工作量不建议用代码行估算，而是建议用“故事点”、“理想工作日”等需求间的相对大小来评估主动性评估方式：对于开发人员，质量以“交付测试后发现的严重需求b