快手、孩子王、华为等专家分享大模型在电商运营、母婴消费、翻译等行业场景的实际应用 了解详情
写点什么

效能改进中的度量实践

  • 2020-03-18
  • 本文字数:2876 字

    阅读完需:约 9 分钟

效能改进中的度量实践

You can’t manage what you don’t measure. - Peter Drucker

你如果无法度量它,就无法管理它。——彼得·德鲁克


笔者在面试项目经理时,常会抛出这样一个问题:如何在改进过程中进行度量?答案大多是关于质量方面的指标。然而,众所周知,效能管理中的很多问题,并不只是发生在项目的研发过程,还可能出现在其他环节或管理领域。所以,如何进行有效度量,成了摆在管理者和效能改进者面前的一个现实问题。

一、度量的目的

度量是管理者发现和处理问题的有效抓手,所以度量的最终目的一定是为了解决问题。而迈出管理第一步的推动力,则必然是管理者意识到组织可能出现了(或潜在的、预防的)一些问题,但因为没有数据支撑,无法对问题进行定量分析。


所以,笔者认为,度量是基于假设的,只有用数据模型来印证假设成立,才能给予管理者信心,进而采取行动加以改进,最后再基于改进结果,发现更深层次的问题,修正和优化度量手段。形成 PDCA 式的闭环。


二、度量的过程

第一步:指标收集

基于度量目的(即:问题假设),定义相关的指标,进行数据采集。组织的成熟度不同,亟需在当下阶段被解决的问题也各异,需要读者用心挑选。如果能找到有效的指标,则改进工作将事半功倍。举个笔者在有赞效能改进中的实际场景为例:


某个时段收到产品经理的反馈:「最近的项目周期感觉有点长,印象中甚至有一些要持续两个月才会上线」。那么,我们要收集的基础指标就可能包括:历史项目的研发周期、研发周期中各阶段的处理时长、参与人员投入时间及工作量分布、各项任务的依赖关系等等。要看一下所谓的「感觉很久」到底是多久,以及在哪个环节停留得比较久。目的是要「适当缩短项目的研发周期」。


有赞效能改进团队,在组织的不同阶段和场景下,幸运地提取到了若干指标,目前依然在有赞内部自研的「起码效能平台」上持久地发挥作用,现列举如下,供读者参考:


1)流动效率。从「事」的角度,收集每件事(比如:需求、项目、线上问题、工单等)的处理时效,并以进度、周期、 SLA ( Service-Level Agreement,服务等级协议)达标率等方式进行体现。精益方法十分重视流动效率,我们通过指标关注问题是否得以按时解决。下图是用控制流图的方式,展示了在一段时期内,有赞某业务线的项目吞吐情况:



2)资源效率。从「人」的角度,收集研发人员的工作任务,并以各种维度进行聚合。一般来说,研发人员的日常工作大致包括:参与项目开发、处理零碎的日常小需求、解决线上 Bug 等。所有的工作任务都可以量化,然后折算成指标(比如:工时、天数等),便能推算出组织资源的利用率,进一步可以发现资源瓶颈或资源闲置情况。下图是以有赞技术经理的视角查看团队中每个人的工作负荷:



3)价值偏差。也是从「事」的角度,但它统计的是在长周期范围里,与战略目标的一致性情况,代表了组织的交付成果展示,以及按各种细分维度(比如:业务属性、需求来源、当前状态分布)进行的统计和比较。采集价值偏差相关的指标,能帮助我们站在业务的视角,观察研发产出与商业价值之间的关系(并非高流动效率和高资源效率,就能带来高价值回报)。下图是有赞在某一业务线,上线项目与公司战略目标重合度的相关指标统计:


第二步:相关性分析

万事万物皆有联系,指标并非孤立存在的,避免将所有指标一股脑儿平铺罗列——这只是一种无序的堆砌,并没有发挥数据的价值。而通过相关性分析,可以发现一些造成目前状况的驱动因素。这样的成果不亚于发现「在超市里,与尿布一并购买最多的商品是啤酒」。


笔者对有赞的部分度量指标进行相关性分析时,就发现过一些很有趣的现象。


比如下图所示,工单交付(红色折线)的峰值出现在中午前后(12 点)、傍晚前后(18 点)、午夜前后(23 点),这与工单递交(蓝色折线)的时间节奏完全无法匹配。然而,对研发人员的工作习惯进行调研后发现:为了避免时间被碎片化,大家会将自己收到的工单,积攒在某个相对空闲的时间段,进行集中处理和回复。



前文「适当缩短项目的研发周期」案例,当拿到基础指标的数据后,要与研发周期相关的因素进行对照,比如:需求颗粒度不够 MVP ( Minimum Viable Product,最小可行产品)?、人员净投入(并行参与多个项目?)、项目节奏感(缺少项目经理的参与?)、代码质量(缺少单测等必要保障?),分析一下问题会出在哪里。如果条件有限,可参考的数据不完整,那也可以通过跟进项目、访谈、问卷、走查等方式了解和感受,再有针对性地设计关联性的度量指标,去抓住问题的根源。

第三步:结论和行动项

度量数据及其相关性分析是非常重要的改进依据,但如果没有给出一个具有较高可信度的结论、以及可落地的改进项,度量就没有任何意义。切忌不要只是陈述数据的增减变化或图表的走势变化(这谁都看得出来),也不要「推测」可能是什么因素造成的(这并没有说服力),也许未来新生成的数据就与你的臆测相左,结果贻笑大方。而且对当事人来说,容易丧失信心。


此外,所谓的结论,请注意是「较高可信度的结论」,而非完全正确的结论。因为并不存在完全正确的结论。一方面,在结论被落实之前,无法证明它是完全正确的;另一方面,随着时间的推移和局势的发展,最初的「正确」结论会变得并不那么正确。这也是我们为什么说「管理是一门艺术」的原因了。



前文「适当缩短项目的研发周期」案例,有可能是是某一项(或几项)因素造成的影响。故而,我们可以给出一个结论,并提出若干行动项。比如说——

结论:根据数据显示,目前的平均研发周期 X 个工作日。其中技术方案筹备时间约 Y 个工作日,用专家法评估认为筹备过久,且通过项目的过程数据发现,技术负责人未设定技术方案评审的时间目标,调研发现多是在并行处理其他事项,故造成该阶段节奏较为拖沓,影响整体进度。

行动项:

  1. 与产研团队共同约定项目流程,增加「技术评审时间」的里程碑,并与各项目经理约定落实;

  2. 与技术部门达成一致,技术方案筹备阶段,核心成员切勿并行其他工作;

  3. 建立技术筹备时长的数据度量指标;

  4. 技术筹备一旦超时,通过工具触发预警,调用企微通知到技术负责人和架构师。


下图是有赞某技术团队,为度量单测质量等情况,而采取的行动(在工位旁开辟一块看板,关键的度量指标达成与否一目了然)。而且,在有赞,这样的实践比比皆是:


三、小结

所谓「数据驱动」,在笔者看来,这并非是盲目地让数据指挥实践,而是以事实调研为前提,再辅以数据度量来证明,并据此制定目标,进而驱动实践。正所谓:


效能管理须度量,问题假设心中酿。

相关指标再三尝,结论目标行动项。


从系统思考的角度看,没有一项数据是会永远增长的,它一定会受到现实中的某些因素的制约(所谓「增长的极限」)。所以在根据度量结果来制定目标时,需要尽量客观和保守(但可以频繁地改进)。上文案例「缩短项目的研发周期」必定是有限的,因为如果过度压缩,反倒会因为方案设计质量降低而可能导致返工。


那么,如果我们想提升处理时效,在拿到度量数据后,是:1)在「数据密集区」附近画一条红线,超过就是违规,抑或是:2)设定一个「期望时长」,以提升「达标率」来作为度量目标呢?这个就留给读者来思考和实践吧!欢迎大家在留言区给出你的答案,并说明理由喔~


2020-03-18 19:55826

评论

发布
暂无评论
发现更多内容

产品经理训练营 Week2 学习心得

Mai

第二周总结

岛乾坤

抽奖小程序-利益相关方分析

思亭

产品利益相关方

高和不在家

产品经理训练营作业第2周

黑小白白白

极客大学产品经理训练营

产品经理训练营 - 第二次作业

羽室

Spring Boot 中使用监听器

武哥聊编程

Java springboot SpringBoot 2 28天写作

产品经理训练营--第二周作业

孤星

第二周作业 - 抽奖助手利益相关者

Geek_971380

第二章作业

Kalman

产品经理 产品经理训练营

产品经理第 0 期训练营第二周作业提交

Krystal

作业2-产品的利益相关人分析

赝品

主机安全产品利益相关方

赵志广

产品经理训练营

第二章学习总结

Kalman

产品经理 产品经理训练营

看 AWS 如何帮助客户以低成本造就更多可能 | AWS 创新视野

亚马逊云科技 (Amazon Web Services)

产品训练营-第二周学习总结

Trigger

极客时间 极客大学产品经理训练营 产品训练营

SpotMax:在云上,看我帮助企业省“余粮”

亚马逊云科技 (Amazon Web Services)

云计算

重学JS | Ajax发送数据序列化问题以及Object序列化整理

梁龙先森

JavaScript 大前端 编程语言 28天写作

京东发布《未来科技趋势白皮书》,101页详解5大关键技术

京东数科风险算法与技术

删库跑路被判入狱,明知不可为而为之

李忠良

28天写作

产品的利益相关方

沈弋

产品训练营作业-week02

anyou

【纯CSS】画 多国国旗

德育处主任

css3 html/css CSS小技巧 28天写作 纯CSS

第二周 作业

Geek_72d5ab

产品利益相关者分析

Dylan Zhu

CSS(五)——设置文本样式

程序员的时光

程序员 大前端 七日更 28天写作

产品经理第二周作业

克比

Stakeholder list

顾远山

成功逆袭:外包—苏宁—阿里 论我是怎么快速晋升的?

比伯

Java 编程 架构 面试 程序人生

产品作业2

Tomz

产品经理训练营

看西联软件如何拿下四川省 7 成连锁卖场 | AWS 精选案例

亚马逊云科技 (Amazon Web Services)

效能改进中的度量实践_文化 & 方法_feijieppm_InfoQ精选文章