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)设定一个「期望时长」,以提升「达标率」来作为度量目标呢?这个就留给读者来思考和实践吧!欢迎大家在留言区给出你的答案,并说明理由喔~
评论