【华为云技术分享】“敏捷+ DevOps”先行,效能提升助推企业升级
前言当今企业发展不再以大为目标,而更多追求强和快,因为只有后者才能适应时代变化让企业处以不败之地,我们称这个时代为快鱼吃大鱼的时代,也是企业的新形态。传统行业小到菜场经济,大到航空航天在逐步被互联网和创新颠覆。由于数字化、智能化给企业发展和管理带来的竞争压力,我们将开始看到更多以敏捷为起点的跨职能协作正在逐步发展。因此企业在这个时代如何寻找生命力和增长动力,如何去定义产品的“强”和研发的“快”是管
前言
当今企业发展不再以大为目标,而更多追求强和快,因为只有后者才能适应时代变化让企业处以不败之地,我们称这个时代为快鱼吃大鱼的时代,也是企业的新形态。传统行业小到菜场经济,大到航空航天在逐步被互联网和创新颠覆。由于数字化、智能化给企业发展和管理带来的竞争压力,我们将开始看到更多以敏捷为起点的跨职能协作正在逐步发展。因此企业在这个时代如何寻找生命力和增长动力,如何去定义产品的“强”和研发的“快”是管理者们必须面临的课题。
业务效能
传统业务效能以KPI指标为导向,将企业经营目标分解到各个业务领域,并挂钩绩效以促进员工积极性,实现企业经营目标的达成。指标通常包含业务增长、净值、用户数等,往往以年为周期进行计划,执行和考核验收。
这种模式在大多数情况下是行之有效的,但是当企业面临环境变化,竞争对手变化,供需变化时变成难以应对。如新冠病毒影响打乱了多数企业年初的目标部署,导致业务发展受挫,对于传统绩效管理这是场灾难,但是对于拥有敏捷思维的快鱼们,这是种机遇。新形态的业务效能包含两个层面的含义:业务效能机制、业务效能指标
业务效能机制:企业最高目标和最终执行者之间必须是相互对应的,否则就存在损耗。这意味着企业目标必须穿越董事会、总经理、部门领导精确传达到执行者,同样执行者的执行结果需要及时反馈为上层领导们调整目标提供切实有效的量化依据。为了保障双线链路的畅通,需要引入更为频繁的敏捷迭代效能制度机制,将年度规划转换为季度QBR(Quarterly Business Review)模式。
业务效能指标: 企业需要重塑产品价值定义,而这不仅仅是业务指标。更应该关注实现业务指标增长所需要的一切相关元素,我们称之为价值元素。需要增加北极星指标、用户分层转换率、用户净荐值NPS(Net Promoter Score)、用户行为数据等,以大数据为依据设计产品核心效能指标,甚至在没有发展空间的情况下,我们需要为我们的产品发展构建生态。产品在不同的阶段应该对不同的价值元素进行OKR方式的进行管理,实现产品综合竞争力提升,这样的产品才能称之为“强”竞争力和生命力。
交付效能
科技型企业研发交付管理主要围绕三大核心领域展开管理:产能(或效率)、质量、成本。传统度量通常围绕三大领域设置指标如人均代码行,故事数(点)作为产能,测试和生产缺陷数作为质量依据、人月费率来考核成本等。对研发的效能评价因为技术和产品的差异性变得不可执行。在新形态下,研发效能的定义需要在原有管理领域基础上同时关注:价值流动效率、工程效率、度量基准。
价值流动效率:对于业务人员在研发领域最关心的是从需求提出到触发最终用户操作所需经历周期时长,我们称之为前置时间,这代表着我们响应市场的速度有多快。在平均40天的创新叠加周期内,企业的研发效能必须保持小于40天的前置时间才能确保产品的竞争力始终领先。而这也是敏捷迭代交付模式中追求MVP,高频交付的小步快跑模式的意义所在。分析前置时间中各个环节的过程数据是提升产品“快”速交付的关键。
工程效率:迭代高频的交付模式需借助自动化来实现交付效率最大化,并减少人为发生的错误风险和时间成本。在DevOps指标中分层自动化测试覆盖率、持续集成频率、一次投产成功率、环境可用率等都是需要关注的指标项。
度量基准:研发指标都和研发的输入即需求相关。需求规模的度量方式将影响研发指标结果的客观性,如代码行、故事点、人天经验值都是效能度量产生偏差的根本原因。选择统一规范的需求度量基准方法(如FPA),将为研发效能度量和改进提供最重要的依据。
结束语
敏捷研发已成为业界主流,更是企业提升效能的制胜法宝。DevOps 作为敏捷理念向运维领域的延伸,为企业在数字化进程中追求创新和市场响应提供坚实的支撑,更是提升企业转型的动力。作为企业需要做的就是拥抱敏捷和DevOps,让交付团队与运维团队互相协作,提升业务的能力,重塑企业效能。
点击这里→了解更多精彩内容
更多推荐
所有评论(0)