导语:
随着市场竞争日益激烈,企业面临的压力越来越大,需要不断优化自身的效率和质量,以更好地应对市场变化和竞争压力。因此,效能改进已成为企业实现长期发展的关键要素。
研发浓度作为一种能够准确反映研发效率的指标,可以帮助企业发现研发过程中的问题,及时调整策略,提高研发效率。因此,研发浓度的应用场景非常广泛,包括提高研发效率、降低研发成本、优化研发资源配置以及提高研发成果质量等方面。
上周,飞书邀请到荔枝集团质量与项目管理总监黄奕彬,通过分享荔枝在项目管理中提高效能的应用和实践案例,为大家提供一些有益的参考和借鉴。
以下是黄奕彬的分享:
定指标、用工具,让过程在线
大家好,我是奕彬。
上次说到,现在整个时代变化很快,我们遇到了很多问题,比如修复效率、人员提升以及资源的利用效率等。在荔枝的实践中,处理问题的核心逻辑是从项目痛点出发,统一项目管理平台,让整个项目过程在线上进行,高效地进行数据监控和采集,持续地进行效能报告,并在项目中推广“人人都是项目经理”的项目管理文化,最终形成持续改进的循环。
我们还提到研发浓度的概念:需求总估分 / (研发周期 * 人)的比值,需求总估分就是工作量,这个概念体现的是资源的有效利用率。在飞书项目的 SOP 中,我们就可以以时间维度去定义准入和准出标准、人数、角色。
研发浓度的实质一是在制品控制,二是工作量评估的合理性,三是体现预估浓度和实际浓度的里程碑偏差,四是判断是否存在依赖和过多等待。
因此,首先,建立一个度量体系可以帮助我们快速进入新项目并分析问题,进而解决问题,这是合理的依据。
第二,使用研发浓度指标,并将其融入到管理实践中,这样可以不断积累经验。
第三,培养教练思维,旨在不断提升团队的项目管理能力,这也符合PMI第七版的整体思想。
最后,深度使用飞书项目管理平台,并将其融入到日常工作中,这个平台确实有助于提高工作效率。
沉淀有效流程,灵活适配团队
如果你需要为团队做效能改进或项目管理改进的时候,你会怎么做?
其实并没有能帮助所有项目团队做量级提升的通用性办法。在研究研发效能时,我发现自己也曾面临一些普遍存在的困境。例如,接手一个项目时,不知道从何处下手来提升效能;或者没有时间关注研发效能;或者经过几个月的尝试,一些效率指标不升反降;或者推进了一些改进事项,结果却并不理想。
在处理这些问题时,很常见的情况是,一刀切地按照行业最佳实践来改造团队。这样实际上忽略了一线员工的执行体验,管理上未必见得会提效。
所以我更推荐的改进模式,第一是以效能改进为核心和方向,包括人、流程和工具,最核心的还是激发人,流程和工具为人服务。
第二,关注行业的优秀实践,但应该灵活务实地适配团队情况去解决研发中的痛点和实际问题。
第三,关注全局的提升,调动多角色参与。
第四,整个过程需要在线,也就是说需要一个平台来管理需求缺陷、任务和其他事情。
第五,目标也需要明确。在“降本增效”的背景下,我们应该对人效有清晰的标准和定义。
最后,实践落地之后,我们需要把它们固化成 SOP,再落到飞书项目中。
总结来说,我们通过度量来可视化现状,实现项目全过程在线可见,确保能够实时分析和改进,最终激发员工、同学和一线服务人员的积极性,形成这样的闭环。
拆解研发浓度,合理分配资源
在实践过程中,我们经常会遇到技术同学或产品同学询问研发浓度的含义以及如何使用。研发浓度的公式虽然简单易懂,但在实际应用中仍需进一步拆解。
研发浓度有三个重要参数:需求的总估分、需求的研发周期以及参与需求的人数。
需求总估分:研发浓度会涉及到工作量估算的合理性,与技术方案类型有必然关系,过渡设计方案和兼顾当下业务和效率的技术方案的工作量都是不一样的。同时,WBS 也会直接影响估分。
需求研发周期:研发浓度与里程碑密切相关,通过发现预期研发浓度与实际情况的差距,我们能够看出里程碑是否存在偏差。使用研发浓度可以更量化地评估过程风险、把握差距。协作的依赖与等待也会直接影响研发周期,这时候就需要在流程前置上做一些改进,控制需求的资源蔓延。另外,研发周期也与流程的及时流转有关,这会直接影响数据的真实性。
需求参与人数:人数是项目管理的重要资源。首先,我们需要考虑人员排期的合理性;其次,我们需要考虑的是组织架构的设计合理性;再次,也要考虑技能的全面性。
这其实就是对研发浓度的拆解,它可以帮助你解决不同阶段下的问题,通过数据的变动,分析出许多需要改进的环节。
推进项目实战,交付快进50%
接下来,我想分享一些实战案例。
第一个案例来自创新业务团队,战略地位非常重要。在进入项目之前,我们先准确地收集了数据,发现这个团队的研发浓度非常低,只有 10% 左右。
于是我们会问,这个团队是否使用了飞书项目?过程中的数据分工排期是否合理?通过洞察和分析这些问题,我们找到了问题的根本原因,并制定了相应的措施和待办。
这些数据其实用飞书项目就可以配置出来,同时结合需求交付数量包、需求交付变化、需求大小、交付周期和效率等多方面数据,可以验证是否与研发浓度分析出的问题类似,甚至可以用来举证结论。
完成这个项目后,我认为最有价值的是产品 Roadmap 更加标准化了。从浓度上来看,至少在 Q1 和 Q2 期间上升趋势非常明显,一些需求的交付数量也增加了,版本的迭代效率提升,交付周期至少缩短了一半。
第二个案例来自我们平台团队。实际上,将研发浓度应用于平台团队效果非常好,因为平台团队对需求有更多决策权和掌控权,可以进行长期规划。但是通过与团队交流了解到,他们遇到的问题比较典型,比如一旦业务紧急,资源就会被调配过去,导致整个需求变化迅速,协作效率低下。最终的整体效果都会体现在研发浓度上。
在这个项目里,有几个比较好的策略。一个是让管理者形成效能改进小组;二是将资源可视化,同时推行小批量交付的模式。现在基本上 90% 以上的需求都控制在一到两周以内。如果是比较大的需求,就会安排专门的领导评估合理性。独立的平台支持项目,则会用专项的项目制,快速聚焦,敏捷交付,然后再将资源分散到其他项目里面去。
平台项目目前研发浓度持续在 40% 左右,与最初的个位数相比,现在的整个需求交付数有了很大的提升,这意味着大家基本上可以很快地完成一个项目。
第三个案例和管理人员相关。管理人员与效能改进密切相关,因此必须调动他们的积极性,参与到项目中。这样就可以帮助他们理解研发浓度指标,评估哪些过程需要改进,一起制定提升团队能力的措施,然后进行试运行,再全面推广,不断沉淀经验。除了研发浓度指标外,他们也关注工作量。因此,调用管理同学的积极性,可以让效果执行更加明显。
写在最后
总结来说,首先,要坚持正确的效能改进文化。流程、工具都是为了服务人,我们可以用飞书项目、DevOps 工具、敏捷流程等,但需要明确这些工具、流程或方法的最终目的都是激发员工的上进心和发挥其特长能力。
第二,效能改进需要耐心,更关注趋势而非指标的绝对值。
第三,当你不知道用什么指标时,就可以用研发浓度,因为它对项目协作效率非常敏感,能够及时暴露风险。创新项目的研发浓度在 20~30 之间是可以接受的;成熟型项目的研发浓度应该在 35~40 之间;平台项目的浓度则在 50~60 之间。
最后送大家一句话:成就组织,成就自己。