对于广大的从业IT从业者而言,大部分都要一个绕不过去的话题,就是KPI。 KPI:Key Performance Indicator的含义是关键绩效指标。
我对KPI的理解 通过这段描述,我提取到几个我认为的关键点。
对公司战略目标的分解: 关键绩效指标是来自于关键目标。衡量的背后要思考目标从哪里来,到哪里去,不要为了衡量而衡量。 对绩效可控部分的衡量: 这块有一个很实在的案例,2个潜力差不多的工程师分别担任了2个平台的主力研发,也走上了架构师的角色。小A对应的业务一直没有井喷,业务场景还轮换了几个,产品经理也换了几茬。而小B做的平台随着业务发展反作用平台诉求,得到了持续发展。那么要讨论一下,做技术平台跟业务指标有没有关系?业务没发展好,可能是市场原因,产品原因? 技术同学一脸懵逼的,怪我咯?这里稍微展开一下,要衡量绩效的可控部分,其根本原因是通过努力可以达成。回到前面的观点,目标是一个方向,是灯塔,关键绩效指标是通过努力可以达成的,这样才能发挥承担KPI人员的主观能动性和潜力。 所以,对于创新类产品的研发,更看重推出市场的周期、研发的顺畅、质量等;对于平台类研发,我更看重支持产品创新的研发效能,产品接入的SLA。一句题外话,对于扶不上的那些产品,发挥老人做新活、新人做老活的策略。避免征战沙场的大将无用武之地。
这年头流行名词是一阵一阵的,比如当年的'X'DD;如果你还在说SOA而不是微服务的话,基本上是要被嗤之以鼻的。所以,你不提OKR而聊KPI显得多不合时宜? 有朋友说,如果要说 OKR 和 KPI 的区别,区别就在于 KPI 只能让驴使劲走,而 OKR 用于保证驴头朝正确的方向。有些驴拼命想往前走,不希望落后于别人,这时候 OKR 用于帮助驴少走曲线。有些驴本来就不想走,这时候就需要 KPI 充当鞭子了。一家公司能不能用 OKR,首先要看有没有正确的驴。
我对OKR的学习体会主要来自于吴军老师。 他在硅谷来信中写道, Google的每个员工,每个季度都会给自己定一个或者几个目标Objectives,并且衡量目标是不是能达成关键结果Key Results,这几个词合在一起被称为OKR。每个人的OKR会放到自己的网页上,大约半页纸长,大家都可以看到。如果谁没有制定OKR,一目了然。即使没人催你,大家看到你的网页上是一片空白,你自己都不好意思。到了季度结束时,每个人会给自己的目标完成情况打分,完成了得分是1,部分完成的话,得分是0到1之间的一个数字,没完成的得分就是0。Google强调每个人制定的目标要有挑战性,所以如果谁完成目标的情况总是1,并不能说明他工作好,而是目标定的太低。大部分情况下,大家完成的目标都在0.7-0.8左右。
..... 我的感受是OKR是自己给自己定的目标,很强调【本我】。比如作为TL,要实现所带领团队拿到xx故障分的结果,是不是强化的关键结果是我要做什么,而不是团队要做什么。第二个感受,关于评分,0.7-0.8较好,这是一个非常关注过程的工具。如果是衡量结果,而到了衡量周期的话,没有找到合适英语合作者只有0分和1分这2个选择。
夯实底盘(稳定性、资金风险):通过xxx,xxx(此处省略几十字)等等加强事前、事中、事后的风险防控。 【衡量标准】: 最终结果:
过程关键指标: 线下缺陷,缺陷密度、紧急发布等作为观察指标。 应急体系:(衡量指标:变更导致线上的问题的发现时效、主动发现线上问题比例等) 子域1:精细业务分钟级异动感知,自动问题定位分析(w%),V分钟响应,消除Py/Px风险 子域2:略 ... 子域n:略 加分项: 1:创新解决问题方案,有案例支撑并具备跨子域或者更大范围的推广价值。 2:在问题的解决过程中追求极致,有典型案例支撑。 3:团队全年线下质量、交付品质有明显提升,和主要抓手强相关。 ps:过程关键指标,不传递到一线作为考核依据,而是相关TL要基于关注过程,及时发现风险,调整。质量过程数据作为参考,平台研发关键风险要通过一线工作掌握。 ps:绩效管理分为目标设定、 过程管理、结果考核、绩效改善等环节,不应把目标全部聚焦在考核结果本事;而是随时可以看到距离目标还有多远,是否走在正确的道路上。 |
|