如何让组织的KPI成为敏捷转型的推手而不是杀手 | IDCF

Posted 2021-11-12 dotNET跨平台

作者：IDCF学员 伍雪锋   

某知名通讯公司首席敏捷教练，DevOps布道者。2020年到2021年小100人团队从0-1初步完成敏捷转型，专注传统制造业的IT转型，研发效能提升。

前言

在公司我们常常听见这么一个流传的故事，只要这件事情和考核挂钩，基本上就黄了一半，比如我们道听途说的亚某逊的组织KPI设计，IXM的销售部门KPI指标迫使大型机的销售人员长期推动大型机销售，某软的KPI设计让所有人围绕Windows系统转。正所谓你考核什么就会得到什么，惯性思维我们会觉得KPI发挥的都是消极作用，这是真的吗？

我们不妨问问这个问题是否永远成立。敏捷转型本质上也变革，关于变革可参考约翰科特。

今天我就聊聊敏捷转型过程中如何让KPI发挥积极的作用。

敏捷转型的三步法

在软件交付团队，过往瀑布交付模型的背景下，项目经理对WBS的依赖性极为重要，项目的范围、成本、进度、质量、风险都以WBS展开，在当时项目经理衡量项目团队成员的绩效主要看工时、看考勤。

随着2020年疫情的黑天鹅事件，企业的信息化能力，应对变化的能力成为关键要素，2021年数字化转型在这样的背景下风生水起。在2020年我们也开启了数字化转型的步伐。在开展项目之初，我们团队内部思考了很长时间，追问数字化转型的本质是什么？

接下来我就分享一下我们敏捷转型的三步法。

第一步：营造变革的紧迫感，达成上下同心，目标一致。

前期通过邀请高级经理、管理者、核心业务人员参与IDCF DevOps黑客马拉松体验端到端的交付，真实模拟从idea到设计、开发、测试、部署、发布的全流程，理解全生命周期中各角色发挥的作用，通过这种方式避免自嗨，用户卷入到敏捷转型的游戏中来，一起玩。

第二步：小范围试点。

高层松土后，是不是立刻就可以撸起袖子干了呢？我们还需要把核心成员识别出来，找出早期的积极分子、铁粉儿，接着就挑选3个项目进行小范围的敏捷运作，组织试运行过程中内部解决不了的疑难杂症，邀请王立杰老师带我们乘风破浪，赋能企业内部自己的敏捷种子教练。把这部分项目的成功经验内部分享，吸引更多的项目试点，参与；同时也能识别出谁是变革追随者，谁是变革阻拦者。

第三步：绩效考核机制的改变。

经过一年的时间，除软件项目都按照敏捷项目进行运转，我们一方面要营造一个试错的环境，给敏捷团队能够更快速的学习，获得正反馈；另一方面也要回答天使投资人：敏捷转型效果如何？当前处于什么阶段？

作为敏捷转型的牵头人，需要充当两者之间的润滑剂，桥梁。因为使用原始的度量体系，对于转型后的敏捷团队不再适用。如何过渡，以及节奏是什么？是转型需要回答的问题。每次开月会的时候我就见缝插针地引导到新绩效考核机制设定的话题，经过小半年的叨叨叨，叨叨叨，管理层实在受不了啦，确实也发现是这么回事儿，于是让我主导整个IT部门的绩效考核新机制设计。 

我脑袋里只有一个想法，这件事要兼容以前的KPI, 同时需要引入敏捷转型的真北指标。找到那个能够撬动整个团队持续迭代的业务指标，这个指标一定要让每个人都能秒懂。

前期的策略是从个人英雄主义的考核倾向导向最佳敏捷团队导向，用华为的黑话就是：胜则举杯相庆，败则拼死相救。

围绕转型的真北指标：用户提出一条需求到需求得到满足用了多久？设计我们的组织KPI模型，对于执行团队首当其冲的是扔个石头下去，听听声音，看大家是否能够接受这个概念。下面我举一个栗子：

润物细无声，做敏捷转型的陪伴者

发现敏捷交付过程中的真问题：无效度量。

单纯地讲敏捷文化，Sprint计划会议怎么开，回顾会议怎么开，故事如何拆而没有好的武器，工程能力方面没有提升，敏捷团队没有趁手的工具，组织心智没有改变，本质上就是耍流氓。长期作为开发人员，我深刻理解一天要切换十几个系统才能完成工作的痛苦，每一次切换耗散部分精力，研发一体化的协作平台对于敏捷团队的重要性不言而喻。

基于这样的背景我需要思考是采购还是自研，如下DevOps Report 2020年度报告中使用内部平台的一个数据详情：

2020年经过一年时间，IT部门内部完成了DevOps工具链1.0版本。

2021年搭建了DevOps工具链的2.0版本。

同样的人一旦配备上趁手的工具，效能10倍+成为可能，干起活来也倍儿有尊严感。

首先结合已经有的研发一体化平台，如何把绩效数据转变为绩效信息，最终展示为绩效报告成为关键。第一件事是沉到所有敏捷团队中，看看大家是如何使用这个平台的，有哪些方式可以通过流程、程序去设计，整个绩效考核的数据建模就变得尤为重要。

集合Jira的底层数据模型，我们小团队经过一番设计、培训就奠定了整个部门的绩效数据录入基础。

如下为我们从用户旅程地图全局视角去设计的一个作业链路。

如何通过KPI的设计改变当前的状况

经过三个冲刺的数据收集，试点，绩效数据开始有了积累，IT侧的作业可以做到百分百在线，但是如果让敏捷团队野蛮生产，绩效数据只是一堆数据，如何让数据发挥作用比数据本身更重要。

这就好比我们引导一个人闭眼进行转动魔方，一种是随机性转动，我们大概需要137亿年才能完成，但如果我们每一次都给转动者一个反馈，这一次是离目标远了还是近了，只需要2.6分钟，这就是传说中的魔方实验。

这个故事让我深深感受到了反馈的魔力，于是我们经过九九八十一难从天使投资人那里获取一小笔费用，作为项目的启动资金。设计了以最佳敏捷团队为导向的考核机制，每个冲刺评比一次，小伙伴们再也不用每个礼拜填写工时计划、周报了，开发、测试、BA都只需要在Jira上通过任务拖拽，将工作可视化，管理者和使用者都报以拥抱的心态。经过5个冲刺的试运行，效果真的是出奇的好。7月份从传统的工时考核切换到研发效能考核。

验证一个组织是否转型成功，就是要看敏捷转型团队撤出后，组织是否依然能够有效运行，所以我们需要从底层设计一套运行机制，让整个组织在持续学习与试错的过程中，快速迭代。

如下为我们团队的底层思考，找到敏捷转型的那个基石假设。

实践分享

需要清晰地定义边界，你是从用户视角在度量，还是从内部IT项目的视角在度量，也就是我们常说的Outcome VS Output。

• 组织转型初期可以循序渐进，先厘清内部的一个研发效能，避免一上来就从全局视角出发，业务部门直接甩锅所有的问题是IT侧的问题，内忧外患导致敏捷转型举步维艰，稳定中求发展。

• 明确度量的维度，根据不同的阶段，与团队确认考的逻辑和看的逻辑，先建立安全的环境，收集数据，逐步展开。

• 清晰地定义敏捷团队的度量指标，需求，开发，测试，设计形成一条完整的交付供应链。

• 拉通所有敏捷团队对项目，故事，任务的颗粒度理解。

• 明确考核指标的定义，计算规则，考核等级，常见的问题。

• 明确业务需求考核的优先级。

• 建立敏捷激励方案，让团队能够及时获得正反馈，让反馈的环转得更快。

• 通过物质激励和精神激励，让每一个敏捷转型的小伙伴从被变革转身为参与者。

总结

经过踩了一年的坑，做一个小小的总结：

• 业务价值是通过团队间的合作来实现的，IT部门的成功取决于为业务部门提供了什么价值，解决了业务部门什么痛点，组织绩效考核要围绕业务价值设计，避免IT侧自嗨。

• 全局优化大于局部优化，绩效考核要以业务结果指标为牵引。

• 绩效考核要分清是考的逻辑还是看的逻辑，让团队快速试错，营造安全、信任的环境。

• 不要试图只用绩效考核工具和技术来解决人文问题。

• 敏捷转型的过程中，新的绩效考核一定要跟得上，在过渡阶段的流程机制不免存在考虑不全面的情况，敏捷团队会有抱怨，会有要求，转型团队的负责人一定要作为润滑剂，连接管理层和敏捷团队的桥梁。

• 绩效考核要变得有趣，让团队从过去的受害者身份变为玩家，参与者。