扫码阅读
手机扫码阅读

从敏捷团队到细分市场:如何在复杂组织中打通产研成本度量链路

370 2023-07-22
前言


酷家乐产研团队约千人规模,是一个混杂着敏捷、项目、职能线、产品线等多种运作形式的典型互联网产研组织,但成熟企业的经营决策往往需要从细分市场的投入和收益出发,方能做出及时合理的判断,这中间存在着巨大的GAP,如何从最底层的各种运作模式中实现产研成本的有效度量,并最终反馈到细分市场投入上,是一个颇为艰难的过程。酷家乐的实践对于业界也应该具备一定的借鉴意义。


作为一家快速发展的tob互联网公司,产研团队也在不断进行新的行业探索,但新行业如果高举高打,存在不小的成本风险,如果想要小步快跑,快速迭代,则免不了对产研团队成本度量提出了更高诉求,即产研的成本度量要能够快速的帮组织做好决策辅助,方向有误时控制投入或及时止损,方向正确时加大投入或调配资源。



一、酷家乐实现了怎样的产研成本度量


我们先看下最终的产研成本度量结果,度量系统默认展示涵盖公司约74%的研发投入成本,这些成本是直接和细分市场关联的。

1.1
细分市场成本度量展示



每月末自动展示出当月在各个细分市场的投入占比情况,提供给各级产研决策组织和高层管理者,然后再结合预设目标和收益情况,即可作为在特定细分市场经营决策的重要输入。

1.2
敏捷组投入度量展示



展示66个敏捷组的成本投入的实际情况,以及在项目开发、日常迭代角度的投入比例,可以持续观察项目开发对于Backlog的占用程度,以及通过日常迭代比例来关注敏捷组在专注领域的投入强度。


1.3
项目投入度量展示



展示项目视角的投入比例,以及在各项目类型、各优先级项目中投入的比例。因为产研战略中最重要的事情往往被项目化了(20-30%),所以定期关注我们在最重要项目上的投入比例是十分重要的,避免在次优项目上投入过多资源。




二、如何实现从敏捷团队到细分市场的产研成本度量


2.1
应用细分行业标签,让数据在多敏捷组、项目和细分市场之间tag流转
  • 为什么需要细分市场tag,并且让它顺利流转呢?举个例子,A敏捷组开发的开通权限的需求,这个需求如果是继承自一个项目,那么会自动打上该项目的标签,同时这个任务也可以直接服务于具体的行业线,同样也会打上行业线的标签,那么这个需求就分别从敏捷组、项目和细分市场维度都有了「身份」,这样下来,所有的敏捷组数据(需求或任务)就组成了【细分行业大盘】的基本要素。

  • 同时,我们也推进了组织内部的产品开发团队,在创建敏捷组Backlog Issue时,如果没有细分市场tag,就需要补充细分市场标签,或者有质量任务、技术任务的时候,也需要带上细分市场标签。这样也解决了酷家乐在产品和技术耦合较重的情况下,常常出现的一个敏捷团队在同个迭代服务多个细分市场,而导致无法把握整体各个细分市场投入的问题。

2.2
敏捷开发流程、项目管理流程为后盾,规范化Kaptain的推荐配置和操作
  • 前面提到所有涉及产研的任务均会落到敏捷组内,我们拿到资源投入数据的同时更需要确保数据的准确性,酷家乐PMO推行并落地了一系列的敏捷开发流程和项目管理流程,并结合各种敏捷治理动作(如定期敏捷走查、敏捷成熟度评估等)持续提升团队的人效和团队协作,这样一套组合拳下来,基本可以保证度量数据是真实可靠,每阶段采集到的数据不仅会进行大盘数据披露,执行结果也同样作为各敏捷团队工作持续改进的指导依据。

  • 同时我们提供了推荐的敏捷组在Kaptain中配置,确保各敏捷组的个性化配置不会影响到度量主线。

2.3
通过Kaptain自研产研协同工具,固化流程并获取精确数据
  • 精确的研发人力投入计算是需要建立在完善的基础协作工具之上的,酷家乐自主研发的产研协同工具Kaptain可以很好地支持敏捷组日常运作、项目管理以及资源管理。在涉及前台业务的逾70个敏捷组中,因耦合性高导致项目或日常需求跨多业务线、多敏捷组协作是常态,所有研发任务均会拆解后落到各个敏捷组内,如此所有产研人员均可系统被记录确切人力投入数据(如项目通过人天估算,敏捷组通过SP估算)。

  • 通过Kaptain工具,我们将流程和度量规则固化其中,最终实现了数据的精确获取和自动计算。



三、关键难点突破及其解决方案


难点1:在需要同时支撑多行业线交付的情况下,在众多敏捷组中(60+)如何提炼出对应行业线具体的工作量,并转换成可识别的HC投入?且在敏捷组HC随时会发生变化的场景下,如何保证数据的准确性?

解决方案:

1. 抽象本质,巧「换」概念

  • 引入“行业投入百分比”的概念拉齐事项的投入与实际HC的投入,通过计算敏捷组一定周期内投入在某行业线的投入SP占组内总SP的比例,结合敏捷组周期内的记录总人数,即可得到敏捷组在某行业线/产品线的实际投入HC。


2. 按天记录,按月固化

  • 面对HC实时变化的情况,系统需要支持按天记录各个敏捷组实际的HC总数,并按月结合每个组的HC总数计算并固化得到当月单敏捷组实际投入在某行业线/产品线的HC;统计周期横跨多月份时,再实时统计每个月固化的数据计算该周期内投入在某行业线/产品线的实际投入HC,确保数据的准确性。

难点2:随着数据大盘建设的逻辑逐渐明朗后,管理层提出了与展现的行业线/产品线不一样维度的资源结构展现形式,且后续依然存在被调整的风险时,如何进行有效适配?

解决方案:


数据分层,支持动态映射

为了可灵活适配不同的展示视角,系统将产品线/业务线维度生成的数据单独保存,与管理视角需要看到的结构剥离开来,通过独立的映射表进行实时匹配并生成相应的数据集合。但后续若有数据架构的调整,可手动支持&维护映射关系并进行二次固化,即可有效适配不同视角的管理诉求,产出相应的看板,降低维护成本的同时进一步提高了系统的稳定性。



四、快速铺开工具运营推广,让度量结果尽快创造价值


待获取大盘数据和展示方式确认了之后,基本上这件事情也就完成一大半,接下来需要考虑如何在众多业务线、涉及70+敏捷团队中进行规则推广和落地,我们制定了有节奏的实施计划。

4.1
抓重点干系人,由点向面,逐步普及
  • 首先,在产研PM内部进行宣讲,输出详细的操作手册,普及基本操作原则,结合敏捷流程进行重点答疑解惑;

  • 其次,由各PM牵头,对各自覆盖的敏捷组进行宣讲,邀请各敏捷组关键干系人,如SM,产品,开发及测试负责人参会,普及操作方式;

  • 每个敏捷组落实到迭代中,对事项所属行业线进行关联,逐步输入源头数据。

4.2
试点先行,逐步推进
  • 聚焦局部业务线,部分敏捷团队先行试跑,手动获取成本数据并进行图表分析;

  • 手动验证方案可行性后,即可推动IT化;并逐步推广业务线覆盖范围,减少试错成本。

4.3
良性循环,保证数据正确性
  • 阶段性复核数据,监控操作过程中的具体问题并及时修正,反哺操作手册;

  • 数据报告反哺敏捷组,作为迭代投入资源的数据支撑。



五、 心得体会


5.1
以结果为导向
  • 【细分行业资源消耗分析大盘】的提出,其实最早是在2021年初与CTO的一次交谈上,时隔一年才能将整体大盘落地,过程是烧脑的,也很考究数据获取标准和数据维度的选取,更重要的是缺少IT工具的支撑,在庞大的研发体系和复杂的组织架构下,靠人肉分析数据是件非常费时费力的事情;

  • 这一年,项目核心成员们始终以终为始,面对交叉繁杂的工作内容和动态环境,没有捷径和讨巧的实现方式。虽然难以做到面面俱到,但采用项目制、滚动式地推进,不断完善数据大盘,最终拿到想要的结果。

5.2
要细节更要有视角
  • 时刻站在决策者的角度出发,模拟数据展示维度及内容,确保数据参考的价值。

  • 当敏捷组的一条任务可能会被同时打上【行业线】、【项目】、【产品线】以及【敏捷组】标签的时候,需要精确处理数据的统计,将误差控制在1%以内。

写在篇尾:

本文的撰写凝聚了酷家乐管理工程部多位同仁的心血,特此感谢夹克、悦然、松饼的倾力贡献。

原文链接: http://mp.weixin.qq.com/s?__biz=MzI3MDg3MjQ1Ng==&mid=2247483969&idx=1&sn=7714958571cddc2cc1d40a8768cc5420&chksm=eacb38a6ddbcb1b096311fb430b0da2c9c7d31d3a6da3c56974f82743d2bfb7a346af3c2a438#rd

群核科技(酷家乐)管理工程部。 互联网独角兽项目管理专家团队,分享众多项目管理、敏捷开发、研发效能、流程建设、组织能力提升等方面的实践经验。

25 篇文章
浏览 8900
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线