标签归档:研发效能

从定义到落地:如何系统构建研发效能优化机制

在带团队过程中,经常会听到「搞一个机制」,[某某某机制]的场景,这种一般是出现了问题或故障之类的时候,或者为了某个特定的目标。又或者一天老板说,你搞一下研发效能优化的机制。

那,机制到底是什么,包括什么内容,构建机制有什么价值,如何构建机制,如何保持机制的有效性和合理性?想以今天的文章大概回答一下这些问题。

1 机制的定义

从比较泛的概念来看,机制是指为了实现某种目标或功能,而建立起来的一整套运作方式、管理方法和规则体系。它是由一系列相互关联、相互作用的要素和环节构成的,通过这些要素和环节的有机结合和协调运转,来保证整个系统高效、有序、可持续地运行,从而实现预期的目标或功能。

提取关键词:实现目标或功能,一整套体系,可大可小。

从管理上来看,机制通常包含以下几层含义:

  1. 体制层面:是由一系列制度、规则、流程等构成的框架,用以规范和指导组织的运作。
  2. 运作层面:是在既定的体制框架下,通过各要素之间的互动、协调和反馈,推动组织高效运转的动态过程。
  3. 方法层面:是为实现特定管理目标,在体制和运作的基础上,采取的一系列具体的管理方法、工具和技巧。
  4. 保障层面:是为维持机制的正常运行,提供必要的资源、环境和监督等支持条件。

机制强调系统性、规范性和持续性

建立科学完善的机制,有利于在组织内形成清晰的责权利关系,规范有序的工作流程,可预期的行为模式,从而提高组织效率,实现组织目标。同时,机制也强调动态优化,需要在实践中不断评估改进,以适应内外部环境的变化。

2 机制的价值

机制的价值在机制的定义中做了说明,其价值就是为了实现某种目标或功能,其价值大小和机制本身强相关联。

以项目研发管理机制来看,其定义是指在项目的研发过程中,为了提高研发效率、控制研发成本和确保项目质量,所制定的一系列管理规范和方法。其价值在于提高研发效率、控制研发成本和确保项目质量,更细一点,价值在机制的落地文档中有明确说明。

3 如何构建机制

构建一个完整的机制是一项系统工程,从大来说需要全面考虑组织的战略目标、业务规模和特点、资源条件等因素,从小来说需要考虑具体的问题,目标,条件限制等等。

一个大的管理机制的构建大概会是如下的步骤,小的机制也可按此逻辑,但过程中的相关人员等都可缩小范围:

  1. 确定问题、目标或需求:在构建管理机制的过程中,明确问题和目标是首要步骤。这一步骤要求明确机制建设的主要目的和目标,如提高工作效率、增强员工激励、防范潜在风险等。这些目标应与组织的整体战略紧密相连,确保机制的设计能够支持组织的长远发展。接下来的需求分析阶段则涉及到对组织内外部需求的全面分析,这包括理解员工的期望、管理层的要求、合作伙伴的互动方式以及环境的变化。这一阶段的目的是确保新机制能够解决实际问题并满足不同利益相关者的需求。

  2. 设计机制框架:在制定原则环节,需要依据组织的文化和战略目标来设定机制设计的基本原则和标准,确保机制既符合组织的核心价值观,又能实现预定的战略目标。选择机制类型阶段则涉及选择合适的机制类型来应对特定的需求,例如激励机制用于提高员工动力,约束机制用于规范行为,协调机制用于优化部门间合作。草案设计则是将这些原则和类型综合起来,形成一个初步的机制设计草案,这一草案将详细描述机制的具体内容和操作方式。

  3. 征求反馈与优化:在内部沟通阶段,将草案在组织内部进行广泛讨论,这通常涉及不同层级的员工和管理者,以确保机制的设计能得到广泛的支持和理解。通过收集反馈,机构可以利用会议、问卷等方式广泛收集员工、管理层甚至是客户的反馈意见。这些反馈将在修改优化阶段被用来调整和优化机制的设计,以确保其最终的实用性和有效性。

  4. 制定实施计划:在这一阶段,组织需要制定详细步骤,包括机制实施的时间表、具体步骤和责任人。这有助于确保实施过程的有序进行。同时,准备资源环节要确保所有必要的资源都已到位,例如技术支持和培训材料等。此外,风险管理则要求预见并计划应对可能的挑战和风险,确保机制能够顺利实施。

  5. 执行与监控:这一阶段的关键在于正式实施,按照既定计划开始执行机制,并进行必要的员工培训和指导。监控执行阶段要持续跟踪机制的实施效果,监控包括员工接受程度和机制的运行状态。在此基础上,数据收集对操作数据和反馈信息的收集是必不可少的,这些数据将用于后续的评估和调整。

  6. 评估与持续改进效果评估是通过定期的机制效果评估来检查是否达到了预定的目标。这一阶段的重点是根据评估结果对机制进行必要的调整,以实现持续改进。组织应该建立一种机制,使得每一次评估都能成为未来改进的基础,确保机制始终能够适应组织发展的需求和外部环境的变化。通过这种循环反馈的方式,组织可以持续优化管理机制,从而持续提升组织的整体表现和效率。

总的来说,就是明确目标和需求、设定原则和方案,征求意见,试点运行,完善优化,全面实施,评估改进。

以下以构建研发效能优化机制为例来看下如何落地。

4 构建研发效能优化机制

4.1 确定问题、目标或需求

在构建研发效能优化机制时,首先需要明确当前研发效能存在的主要问题,例如:

  1. 研发交付质量不高,缺陷率居高不下
  2. 研发进度频繁延误,影响产品上市时间
  3. 研发资源利用率低,存在大量低效无谓的工作
  4. 缺乏客观的研发效能度量指标和手段
  5. 团队士气低落,人员流失率高

在问题分析的基础上,结合公司的战略目标,确定研发效能优化的目标,比如:

  1. 提高产品质量,将严重缺陷率降低30%
  2. 缩短产品研发周期,平均交付时间缩短20%
  3. 提高人均产出,研发资源利用率提升15%
  4. 建立完善的研发效能度量体系,实现全流程数字化管理
  5. 提升团队凝聚力和工作热情,人员流失率降低10%

同时,需要充分理解各利益相关方的需求和期望:

  1. 高层管理者关注公司整体研发效率和产品竞争力
  2. 业务部门关注产品能否快速满足客户需求
  3. 研发人员关注个人成长和技术挑战
  4. 客户关注产品质量和使用体验
  5. 竞争对手关注公司的技术实力和创新能力

只有在全面了解问题,明确目标,洞察需求的基础上,才能设计出切实有效的优化机制。

4.2 设计机制框架

根据 4.1 中确定的目标和需求,设计研发效能优化机制的总体框架。机制应该围绕以下几个方面展开:

  1. 度量体系:建立科学合理的研发效能评估指标,包括质量指标(如缺陷率,测试通过率),速度指标(如需求交付周期,缺陷修复时间),效率指标(如需求吞吐量,代码复用率),以及满意度指标(如客户满意度,员工敬业度)等。

  2. 组织结构:调整组织架构,成立专门的效能优化小组。明确各级研发主管在效能管理中的职责,将效能目标纳入绩效考核。建立高管领导下的跨部门协调机制。

  3. 流程优化:对现有的研发流程进行梳理和优化,包括需求管理,设计评审,代码开发,测试验证,发布部署等各个环节。引入成熟的敏捷开发、精益开发等方法。

  4. 工具支撑:引进或自研效能管理工具,实现需求、任务、缺陷、代码等的全流程跟踪管理和数据分析。提供自动化测试、持续集成等工程化手段。

  5. 文化建设:倡导以结果和价值为导向的工程师文化,鼓励创新和持续改进。加强技术培训和经验分享,帮助员工提升能力。营造开放透明、相互信任的团队氛围。

以上五个方面构成了研发效能优化机制的主要框架,后续需要进一步细化每个方面的具体内容,形成一套科学、系统、可操作的方案。

4.3 征求反馈与优化

在设计出研发效能优化机制的初步框架后,需要广泛征求相关利益方的意见和反馈,包括:

  1. 研发人员: 作为机制实施的主体,研发人员的意见至关重要。通过问卷调查、座谈会等方式,了解他们对指标体系的看法,对流程优化的建议,以及可能遇到的困难和挑战。

  2. 研发管理层: 与研发管理层沟通机制设计的思路和细节,获取他们基于管理实践的反馈和改进建议,确保机制在管理层得到足够重视和支持。

  3. 相关部门: 与产品、测试、运维等部门沟通,了解机制实施对其工作的影响,以及他们对机制的期望和建议。

  4. 外部专家: 寻求外部专家如管理咨询、敏捷教练等的专业意见,借鉴其他企业的优秀实践经验。

在广泛收集反馈的基础上,对机制方案进行系统的优化和改进,使其更加切合组织的实际情况。优化的内容可能包括但不限于:

  1. 调整指标体系,选择更加关键和可度量的指标
  2. 简化优化流程,去除不必要的环节,提高灵活性
  3. 完善配套的激励和考核措施,调动研发人员的积极性
  4. 加强机制实施的过程管理和风险防范

反馈和优化是一个循环迭代的过程,可能需要经过多轮才能最终确定一个相对成熟和可执行的机制方案。

4.4 制定实施计划

在机制方案优化成型后,需要制定详细的实施计划,包括:

  1. 实施步骤: 将机制的实施分解为若干个步骤和阶段(如先试点再推广),明确每个步骤的目标、内容和时间节点。
  2. 责任分工: 明确各个步骤的责任人和参与人,划分具体的工作任务。
  3. 资源准备: 确定实施机制所需的人力、财力、工具等资源,提前进行准备和调配。
  4. 宣传培训: 制定机制实施的宣传方案,让所有相关人员知悉机制的内容和要求。针对关键岗位人员开展必要的培训。
  5. 应急预案: 梳理机制实施可能遇到的风险和问题,制定相应的应对措施和处理流程。

一个详细的实施计划能够指导机制的落地执行,确保按既定的方向和步骤稳步推进,降低实施过程中的混乱和风险。

4.5 执行与监控

按照实施计划,正式启动研发效能优化机制,主要做好以下几点:

  1. 各部门和团队根据流程规范开展具体工作,形成常态化机制。
  2. 严格执行指标度量,定期收集和分析相关数据。
  3. 通过会议、邮件、看板等形式,持续跟踪和传递机制运行的关键信息。
  4. 收集研发人员和相关部门在执行过程中的反馈,及时协调和处理遇到的问题。
  5. 对机制执行过程进行抽查和巡检,对重点环节进行督导,确保执行到位。

4.6 评估与持续改进

  1. 建立评估机制: 制定机制实施成效的评估办法,明确评估指标、周期、方式和责任人。评估指标应该聚焦机制的预期目标,如研发交付及时率,缺陷率,需求响应时间等。
  2. 定期开展评估: 按计划定期开展评估,全面审视机制执行的情况和效果。可采用定量与定性分析相结合的方式,深入剖析机制运行中的问题和不足。
  3. 评估结果应用: 将评估结果形成正式的报告或总结,作为后续优化和完善的重要输入。针对暴露出的问题,及时制定整改方案,落实到责任人。
  4. 持续优化改进: 研发效能优化是一个长期的、动态的过程。要以开放的心态接纳各方的反馈,根据实际效果和环境变化,对机制进行持续的改进和调整。可借鉴业界的最佳实践,定期进行对标学习。
  5. 形成优化闭环: 将优化措施落实到位,形成闭环管理。将成功的经验固化到机制中,并在组织内推广。长期坚持,追求卓越,构建起一套行之有效、持续进化的研发效能优化长效机制。

只有通过持之以恒的评估优化及持续改进,研发效能优化机制才能真正发挥作用,帮助组织不断提升研发效率和质量,增强市场竞争力。同时,这也是一个不断学习和改进的过程,需要组织上下的共同努力和长期坚持。

5 小结

构建机制是一项系统工程,需要从全局出发,综合考虑组织的战略目标、现实问题、资源条件等因素。总体而言,构建过程可分为六个主要步骤:确定问题和目标、设计机制框架、征求反馈与优化、制定实施计划、执行与监控、评估与持续改进。每个步骤都环环相扣,缺一不可。

以研发效能优化机制为例。

在其设计过程中,需要从度量体系、组织结构、流程优化、工具支撑、文化建设、外部合作等多个维度入手,形成一套科学、系统、可操作的方案。方案的制定需要广泛听取各方意见,不断迭代优化,以确保其能够真正解决问题,满足各利益相关方的需求。在实施过程中,更需要全员参与,上下协同,在执行中不断监控,及时发现和解决问题。

研发效能优化不是一蹴而就的,而是一个持续改进的过程。只有建立常态化的评估优化机制,持之以恒地推进,才能让研发效能不断提升,让追求高质高效的理念深植于研发文化之中。这需要组织上下的共同努力和长期坚持。通过构建研发效能优化机制,组织能够不断提升产品质量,加快创新速度,提高资源利用率,增强市场竞争力,实现可持续发展。

在整个过程中,需要研发团队的负责人坚持系统思维、问题导向和以人为本。

关于写年度技术 OKR 的 9 个关键思考点

新的一年了,又到了做规划和 OKR 的时候了。

作为一个技术团队的管理者,此时除了面对业务的诉求,从技术架构、从团队管理、从未来发展应该做些什么呢?

以下是最近一段时间来,个人的思考。

从经营的角度来看,研发团队成本对于软件企业来说是成本的大头,作为团队的负责人需要在满足业务需求的前提下,提高研发团队的产出和产出的价值,同时尽量降低过程中的成本,也就是在之前文章中所说的研发价值。

这里的研发价值可以具象到研发效能这个概念,在我们做技术规划和 OKR 时,底层思考中的研发效能不仅仅是衡量研发资源使用的效果,更进一步,是指研发团队达成既定目标和结果的能力,换句话说,就是提升当前研发团队的核心竞争力。

研发效能不仅包括了技术层面的各种实践,如代码复用、自动化测试、持续集成(CI)和持续交付(CD),还包括了效能度量、流程优化,团队协作、项目管理、需求理解和用户反馈的及时整合等多个方面。

研发效能的核心目的是优化交付的价值链,通过提高效能来缩短产品从构思到市场的时间,提升产品质量,降低开发成本,以及增强对市场变化的响应能力。这不仅能提高客户满意度和用户体验,还能为企业带来更大的经济效益和更强的市场竞争力。

每个企业,每个团队在做规划时,应该是基于现况,基于客观事实来做规划,明确当下最重要,最需要解决的问题是什么,确认目标,一个个去解决。比如当前大家意识层面有所欠缺,那就想办法拉齐认知「共读一本书」;又或者当前研发流程混乱或者效率不高,那就梳理研发流程,把研发的过程一个个掰碎了,揉散了看哪里有问题,该去掉去掉,该优化优化;又或者当前无法看到效能情况,没有体系化的指标和系统支撑,那就去构建,去实践……

各家不同,各有章法,这里我们从研发效能的定义出发,扩展出其要解决的问题,再到具体包含的内容来思考整个过程,不会大而全,也不会特别深入,只是一个思路。

1 概述

在《软件研发效能权威指南》中对于研发效能的定义是指更高效、更高质量,更可靠、可持续的交付更优的业务价值

将其拆解开来,可以分为三个方面:一是高效和交付更优化的业务价值,关注的是价值交付,二是可持续,关注的是能力构建,三是高质量和可靠,关注的是成本控制。延展开来可以分为效能认知、组织结构、效能度量、研发流程、工程体系、架构能力、技术能力、质量管理和稳定性管理九大模块。整体如下图:

图片

2 效能认知

关键词:老板工程、规模化

研发效能是一个从上往下的老板工程,就算是一线的员工想要做并且努力做了,达到的效果也有限。

其一定是实现了规模化后才有着明显的效果,从度量的效果上看,在规模化之后才能更好的发现和解决问题,个体差异在这里会被规模化效应所取代。

研发效能要解决的是三个方面的问题:价值交付、能力构建、成本控制。

  • 价值交付主要关注交付的过程,通过过程中流程的梳理和优化,以及对软件自动化工具的建设提升研发的效能。
  • 能力构建主要关注通过研发能力的构建,保证交付的可持续性。
  • 成本控制主要关注研发过程中产生非正常成本的点,如质量、故障等等。

以上只是概念性的简要的内容,基本上就是开头那张图了,可以把这些逻辑在团队内达成一致,知道全局是怎样的,现在正在哪里。

再深化一些,可以就每个模块做一个指向性的成熟度模型,明确当前在哪里,以及将来要去哪里。强调一点,就算我们做了成熟度模型,我们也并不是追求成熟度模型指标上的成长,这只是一个过程,我们更看重的是研发效能的提升和价值的交付。

3 组织结构

关键词:信息流动、决策、协同

组织结构决定了信息流动、资源分配和决策过程的效率。组织结构是研发效能的基座和架子,一个合适的组织架构可以更好的提升研发的效能。

以研发效能平台落地为例,如果提出需求的人在一个部门,实现需求的人在一个部门,两个部门的目标可能就会有一些不一致的地方,沟通上跨部门沟通的成本也会比较高一些,那这个项目的研发效率就会比较低。

在一个组织内,信息流动的顺畅程度直接影响到研发的响应速度和能力。理想的组织结构应该是信息高度透明和流动性强的结构,这样可以最大限度地减少知识的壁垒和信息的延迟。创建开放的沟通渠道建立跨部门的协作团队是关键,这样能够确保从需求提出到需求实现各个环节都能迅速连接,实现信息的快速传递。

决策的速度和质量在很大程度上取决于组织结构。在一个层级过多的组织中,决策往往需要经过漫长的审批流程。扁平化管理模式有助于缩短决策链条,提高决策效率。在扁平化的组织结构中,决策权下放到更接近实际工作的团队和个人,这样不仅可以加速决策过程,还能提高决策的准确性,因为决策者能够直接获取到一手资料和反馈。任正非有提过:让听得见炮声的人做决策,这个论点在研发效能的提升上也同样有效。

4 效能度量

关键词:可视化、全局思维、机制

说到研发效能,大家都会想到搞一套指标,搞一堆系统,然后各种报告,觉得没有啥用。如果只搞这些,确实没啥用,甚至有些本末倒置。

度量是为了什么?是为了可以看见,是为了消除系统性瓶颈。

因为除度量外的操作都已经融入实际的研发管理工作,或多或少,而度量是一个将这些研发管理工作的成效可视化的过程,让人们更直接的感受到优化后的效果。

效能度量只是研发效能中的一小部分,只是辅助效能提升的一种基础性的模块,我们过去对于其投入较少,缺少体系化的度量,当下要补足这个模块。并且这个模块是我们研发效能提升的眼睛,通过度量实现效能的可视化和研发效能提升过程中的反馈机制。它提供了衡量成果和改进的依据,帮助团队识别问题、跟踪进度,并调整优化策略。

在效能度量过程中,我们会以一种相对科学的方式收集和清洗数据,建立一套和当前团队贴合的指标体系,涵盖项目进度、产品质量、团队效率等各个方面,建立机制定期审视这些指标,并根据数据进行决策和改进。

度量的过程,从传统的大量质量指标,到体系化的效能指标,再到结构化的效能报告,有逻辑,更直观。

在这个过程中,看见系统性的指标只是第一步,根据指标来进行决策和改进才是度量的关键逻辑。也就是说度量只是我们研发效能的开始,是结果的一种呈现,我们所追求不仅仅是这个结果,而是这个结果带来的效能提升和研发团队的价值提升。

在度量时始终需要有全局性思维,不要为了指标而指标,将其变为一个数字游戏,也不要陷入到局部的细节指标中而忽略了为什么要做度量。

注意,度量是有成本的,在实施的时候,不要追求度量的大而全,不要一开始就搞一个完整的度量体系,这是一个长期的渐进式的工作,从业务、产品、开发、QA 各方都需要介入的过程,并且最终需要落地到系统上来。

5 研发流程

关键词:有序、标准、端到端的流程

研发流程是为了确保研发活动有序进行的关键。良好的流程设计能够最大程度地减少不必要的工作,清晰地定义每个阶段的输入和输出,以及相应的质量标准。

如果把软件开发比作一个生产产品的流水线,那么研发流程就类似于产品的生产工艺——它是定义产品从原料到成品的所有转换步骤的详细规划。

工艺的好坏决定了产品的好坏。

在整个软件开发的「生产工艺」中,每一步都不是孤立的,而是与前后过程紧密相连,通过反馈和持续改进来提升最终产品质量。敏捷方法论和持续交付的实践强调了在整个研发流程中不断地评估和调整工艺步骤,以适应变化的需求和市场条件。

从技术团队规划的角度,还是要拆解整个研发流程,或者说拆解整个工艺,引入敏捷开发方法和精益思想,持续迭代流程,以消除浪费,并通过自动化工具或系统减轻重复性工作负担。

我们知道研发的好坏,以及研发的价值往往是由源头决定的,产品需求,甚至业务需求。因此,在我们做研发流程优化的时候,尽量把业务方、产品侧都纳入进来,做到从业务中来,到业务中去,实现端到端的控制和优化

6 架构能力

关键词:复杂度、关系和结构

架构能力关注的是软件架构中的关系和结构,关注的是整个架构的复杂度。而不仅仅是搞个啥架构。

在软件企业发展过程中,架构会随着业务的不断发展而呈现劣化、复杂化等趋势。

我们在架构复杂度提升,规模不断增加、人员不断变化的前提下如何通过对架构的优化实现效能的提升是这里要做的命题。

架构能力的提升包括三个方面:架构规划、架构审查和架构治理。

架构规划是架构能力的首要环节,其必须综合考虑系统的功能需求、性能目标、安全性要求、可维护性及扩展性等多个维度。这种规划类似于建筑领域的城市规划,不仅要考虑当前的建设需求,还要预见未来的扩张和变革。在软件架构的世界里,这意味着设计时要有前瞻性,能够在不牺牲现有系统稳定性的基础上,适应快速变化的业务需求和技术革新。

一个有效的方法是采用模块化设计,即将系统分解为多个相对独立、功能明确的模块。这样不仅有助于降低整体复杂度,还能够使团队能够并行工作,提高开发效率。但是,需要明确一点是不要过度,模块化的结构需要和当前业务状态、团队规模匹配,防止无意义的扩大,从而增加整个系统的复杂度。

架构审查有点类似于医生的定期体检,它可以帮助团队识别潜在的问题,并在问题成为危机之前进行干预。这个过程中,我们可以利用各种架构评估方法,如 ATAM 评估方法(架构贸易分析方法)、CMAM 评估方法(组件建模评估方法或架构评估框架,以确保架构符合业务的目标和制约。

架构审查也可以根据自身企业的情况,构建自身的标准,如类似于成熟度模型之类的来评估当前的架构状态。

在评估审查中,应收集关键利益相关者的反馈,并结合各项指标和用户数据来做出决策。

接下来就是架构治理,架构治理可能涉及到技术栈的变更、新技术的采纳、旧系统的淘汰等。这些调整应该是渐进的,并且与业务战略紧密对齐,确保每一步都朝着增强软件可交付性和业务价值的方向迈进。

这里特别要强调一下关于架构评估过程中对于技术债务的偿还,在快速发展的企业中,这种债务特别明显,因为随着业务的发展,技术债务往往逐渐累积,这对架构的可持续性构成了威胁。技术债务可能源自早期的决策,当时的快速实现为了满足眼前的需求而牺牲了长期的可维护性。

处理技术债务并不总是意味着需要进行大规模的重构,有时候持续的小步改进更为有效。通过持续集成和持续部署(CI/CD)的实践,可以在日常的开发流程中逐步减轻债务负担。此外,编码标准和代码审查可以预防新的技术债务的产生,这对于保持架构整洁和可管理至关重要。

7 技术能力

关键词:复用、标准、前瞻性

技术能力和架构能力相比更关注技术能力本身的上限或边界,是指用技术来提升产品竞争力的能力,如跨端复用能力、技术框架、业务框架、业务组件或能力,其本质是通过构建能力的复用实现能力的提升。

技术能力构建的关键逻辑在于复用性与标准化、以及技术的前瞻性。

复用性意味着开发者可以在多个项目中使用同样的代码或组件,而无需重新发明轮子。通过创建通用的库、框架或服务,组织可以减少冗余劳动,加快开发流程,并降低出错的概率。

而标准化则为这种复用打下基础。它确保了不同团队开发的组件能够无缝集成,无论是内部接口,还是面向外部的 API。标准化还涉及到编码规范、文档标准以及工具链的一致性,这些都是确保技术团队能够高效协作的要素。为了实现这些标准,组织往往需要建立起一套严格的质量保证流程,包括代码审查、自动化测试和持续集成。

复用性和标准化看到的是当下,通过现有业务和技术能力,提升复用率。而技术前瞻性则是面向未来,通过对技术发展的趋势预测,提前布局。

技术前瞻性的构建需要团队的管理者刻意去构建,常用策略包括允许工程师在工作时间探索新技术;建立内部分享会,鼓励知识的交流;甚至与外部研究机构或高校合作,共同进行技术研究项目等等。

同时,奖励那些能够带来创新思路和解决方案的个人和团队。这种机制可以是奖金,也可以是职业发展上的机会。同时,组织应该提供必要的资源支持,如投资先进的工具和技术、提供专业培训等,以确保团队成员能够不断提升自己的技术能力,并把这些能力转化为企业的持续竞争优势。

8 质量管理

关键词:永远的质量、全员参与

质量管理包括过程质量和结果质量(线上质量),最终目的都是结果质量。

质量管理的目的是想通过质量控制减少因为质量问题带来的成本,如果一个产品问题到了用户反馈的程度,那将会卷入技术支持,QA、研发等同学,甚至会有客户成功的同学,将会有一个长长的流程把这些同学串起来以解决问题。如果这个产品问题在最前置开发的时候或者产品需求的时候,将会大大减少成本,提升整个的效率。

其中,过程质量关注的是从产品设计到最终交付整个生产流程的各个环节。控制过程质量的目的是为了确保每一步骤都按照既定标准执行,从而预防质量问题的发生。在软件开发中,这可能会涉及代码审查、持续集成、自动化测试等实践。这些实践能够及早发现问题,防止它们在开发周期后期扩大。

为了提升过程质量,我们都会建立一套完善的质量管理体系,这包括制定明确的质量目标、过程标准以及评估机制。例如,采用敏捷开发模式可以通过短周期迭代确保产品的持续改进和质量控制。通过将开发过程分解为更小的部分,团队可以更快地识别并解决问题,从而降低风险和成本。

结果质量或线上质量主要指产品发到线上环境,直接服务于用户时的表现。这是质量管理最终的评判标准,直接关系到用户体验和产品的市场表现。因此,结果质量的衡量不仅仅是产品交付后的一个阶段,而是一个持续的过程。这要求我们在产品发布后继续监控其性能,收集用户反馈,并根据这些数据不断优化产品。

为了确保结果质量,我们需要采取多种方法来监测产品性能,比如使用应用性能管理(APM)工具监控软件运行状况,或者设置用户反馈渠道收集用户意见。同时,定期进行用户满意度调查也是评估和保障结果质量的有效手段。

质量永远是技术规划或 OKR 的一部分,持续的去优化去实践。

并且质量管理并不只是 QA 部门的责任,而是需要全公司上下共同努力的结果。这要求每个员工都要有质量意识,从每个人的日常工作中都要考虑质量管理。

特别是管理者,是质量管理的关键,管理者需要持续的参与和支持质量管理,通过资源投入,策略制定甚至亲自参与到质量活动中来,以展现我们对质量的承诺。

9 稳定性管理

关键词:多维度、高可用、控制

稳定性管理是成本控制的另一个关键点,每一次稳定性的问题都会对用户产生影响,甚至可能对公司的品牌和财务状况造成长期的负面影响。

关于稳定性管理我们可以从多个维度来解构它的实施路径,一般会包括运维合规、高可用架构治理、变更管控、容量管理、风险管理、故障管理等 6 个方面。

  • 运维合规:运维合规能够确保所有操作都符合既定的政策和标准。这意味着从数据中心的物理安全到云服务的配置,每一个环节都需要规划好并遵循明确的标准和最佳实践。合规化有助于减少人为错误,同时确保系统在面对审计时能够展示其稳定性和安全性。实践中,这常常涉及定期的审计和评估,以确保所有操作都在控制之下。
  • 变更管理:变更管理是确保系统稳定性的关键组成部分。在这个过程中,所有的系统变更——无论是软件更新、硬件替换,还是配置调整——都需要经过严格的审查和测试流程。这是为了确保任何变更不会对现有系统造成不可预测的影响。变更管理的核心在于减少不经意的后果,通过详细的记录、评审、批准、测试和监控变更流程,来提高系统的整体稳定性。
  • 风险管理:风险管理过程涉及对可能影响系统稳定性的潜在风险进行识别、评估和优先排序,并制定缓解措施。这个过程需要不断地进行,因为新的风险总是在不断出现。通过建立一个全面的风险管理框架,组织可以对付潜在的问题,减少未知因素带来的冲击,从而保持系统稳定。
  • 高可用架构治理:高可用架构的设计是为了确保系统即使在部分组件失败的情况下也能继续运行。这通常通过冗余、负载均衡、故障转移和分布式系统设计等技术实现。高可用架构的目标是减少单点失败的可能性,并且在出现问题时能够快速恢复服务,保证系统的连续运行。
  • 故障管理:故障管理关注的是如何有效地识别、响应、记录和分析故障。它包括建立一个透明的过程来处理故障,以及确保足够的资源用于故障恢复和后续的预防措施。通过彻底的根因分析,可以从故障中学习并防止未来的重复,从而提高系统的稳定性。
  • 容量管理:容量管理确保系统有足够的资源来满足日常运行和未来增长的需求。这包括对硬件、软件和服务的需求进行预测和规划,以避免过载导致的性能瓶颈。通过对现有资源的有效管理和对未来需求的精准预测,容量管理能够确保系统即便在负载增大时仍能保持稳定。

10 小结

在实际做规划时,并不需要在年度规划中把所有的项写上,而且也没有这么多的资源来做这个事情。

在选取时规划时主要考虑当前业务所在的生命周期和团队规模。

不同业务生命周期阶段对研发的要求有所差异。在业务启动阶段,研发团队应集中于快速且高质量地满足业务需求的交付。随着业务进入发展阶段,重点转向通过效能指标促进产品功能的标准化和业务能力的沉淀,为规模化复制做好准备。当业务成熟,研发应专注于提升稳定性和效率,降低成本,并通过技术创新寻求新机会。而在业务消亡阶段,关键在于资产的沉淀复用,以保留组织的长期投入价值。

团队规模对研发效能策略同样有显著影响。小型团队,通常规模较小、专注领域单一,应聚焦于提升研发过程效率,而非任务交付量。中型团队面临着更复杂的业务和紧密的合作需求,应将研发效能建设集中在流程和标准化上,以简化协作并确保产出质量。大型团队则需要重视不同小团队之间的协调和合力,注重在宏观层面的业务影响,并聚焦于结果评估和效果衡量。

我们当前需要基于公司战略和方向,根据团队的实际情况,明确资源和目标的匹配度,选取一些当下特别痛的点来突破。以全面的思考为整体技术规划的方向指引,以单点突破的方式逐步推进,从而达到整体研发效能提升的目的。

以上,只是一个思路。

研发效能是不是一个伪命题:关于研发效能的思考

周四下午作为分享嘉宾参加思码逸组织的关于研发效能的技术沙龙,在最后圆桌会议探讨环节,有同学提了一个问题, 研发效能是不是一个伪命题?  现场回答了下,会后也有持续思考这个问题,基于会后的思考,做一个更完整一些的陈述和总结:从研发效能的定义出发,从背后的逻辑出发,从具体的实践方向出发,来看研发效能这个事情。

说到研发效能,大家可能会马上想到度量、指标、流程、CI/CD、代码平台等等东西。

但只是这些吗?为什么要做这些?做了这些有什么用?最终的目的是什么?…… 有很多问题冒出来。

研发效能是什么

看研发效能是什么前我们先看一下效能是什么?

效能是一个衡量资源使用的效果的概念,常用于评价在完成一定任务或达成特定目标时资源(如时间、金钱、原料等)的使用效率。效能高意味着用较少的资源投入获得了较多的产出,或者用最优的方式使用资源以达到最佳的工作绩效。

在商业和管理领域,效能是指组织或个人在达成既定目标和结果的能力。商业和管理领域中的效能更加注重最终的成果而不仅仅是资源的使用。传统意义上的效能只是商业和管理领域效能的一个过程态,但我们当下所追求还是传统意义上的效能,通过这种效能的不断达成,使得组织的效能增加,从而帮助企业更有效地管理资源,提高组织能力,并在市场竞争中保持优势。

回到研发效能是什么,这里我们限定一下范围,主要是软件开发的研发效能,有代码产出的那种研发。对于软件开发来说,主要关注的还是人力成本,或者说是时间成本。后文中的研发效能都指软件开发的研发效能。

研发效能是指通过有效地利用人力和时间资源,持续以最快的速度交付高质量的产品。 这句话可以换成上篇关于研发价值的文章中的公式:

公式:研发的价值 = 单位有效时间内产出的价值 × 有效时间 – 非正常成本 – 正常成本

这是简化的研发价值模型,可以作为理解研发价值创造的基础框架。实际应用中可能还需要进一步的细化和调整,因为价值的计算可能远比这个公式复杂。

研发效能不仅包括了技术层面的各种实践,如代码复用、自动化测试、持续集成(CI)和持续交付(CD),还包括了效能度量、流程优化,团队协作、项目管理、需求理解和用户反馈的及时整合等多个方面。

研发效能的核心目的是优化交付的价值链,通过提高效能来缩短产品从构思到市场的时间,提升产品质量,降低开发成本,以及增强对市场变化的响应能力。这不仅能提高客户满意度和用户体验,还能为企业带来更大的经济效益和更强的市场竞争力。

体系化的提升研发效能

研发效能的提升和优化是一个体系化的工作,是一个多维度、跨职能的系统性工程。包括组织文化、组织结构、技术架构、流程设计、工程系统和度量考核等。

组织文化:创新的基石

组织文化是企业的灵魂,它塑造了员工的行为和思维方式,对研发效能的提升起着至关重要的作用。一个以创新为核心的组织文化,能够激发团队成员的创造力,鼓励他们不断尝试新方法和新技术,甚至在失败中寻找改进的机会。

我们可以通过建立跨部门沟通机制、鼓励知识共享、认可员工创新成果等方式来营造一个开放和协作的工作环境。

在认知层面,特别需要对上达成共识,研发的负责人在领导层面达成一致,能够更好的推动研发效能工作的开展。

组织结构:效能的架子

组织结构决定了信息流动、资源分配和决策过程的效率。在研发效能的提升中,扁平化的管理层级、跨功能的团队配置以及灵活的人员动态管理,都能够促进创新和加速决策过程。

组织结构是提升研发效能的架子,我们可以推动小型化、自治化的团队模式,并通过灵活的项目管理和内部创业机制来激发团队的活力和创新能力。

但这只是一种较为理想的逻辑,实际中我们需要考虑当前组织的情况,人员的水平,公司的文化基因等等,不可一概而论,鞋合不合适只有脚知道

技术架构:效能的核心

技术架构的合理性直接影响研发效能。 一个良好设计的技术架构应当具备高内聚、低耦合的特点,以便于团队成员高效协作,同时保障系统的稳定性和可扩展性。

我们开发过程中会采用微服务、容器化等技术架构,以支持敏捷开发和持续集成/持续部署(CI/CD)等。

当然,微服务、容器化架构和敏捷开发、CI/CD 没有强关联,在实际落地过程中,这些都非必选项,术法落地需要更多的考虑实际的场景和条件

流程设计:效能的流动

流程设计是确保研发活动有序进行的关键。 良好的流程设计能够最大程度地减少不必要的工作,清晰地定义每个阶段的输入和输出,以及相应的质量标准。

我们通过引入敏捷开发方法和精益思想,持续迭代流程,以消除浪费,并通过自动化工具减轻重复性工作负担。

敏捷和精益都是一种落地的方法,需要考虑实际的情况,根据过程中的生产场景细化每个环节的时间和人力消耗,消除浪费。像我们经常用到的需求交付周期、需求吞吐量(单位时间交付需求个数)、在制品数等指标都会用于这个场景的度量。

工程系统:效能的支撑

工程系统是研发效能提升的具体执行层面。它包括代码管理、构建、测试、部署等一系列工程实践,这些都需要通过系统化的工具和方法来支撑。

通过建立统一的开发环境、版本控制系统和自动化测试平台,以及监控和日志分析系统,以提升研发的效率和稳定性。这里提升效率的逻辑在于 通过系统和自动化的方式减少重复成本和认知成本

度量考核:效能的反馈

度量考核是研发效能提升过程中的反馈机制。它提供了衡量成果和改进的依据,帮助团队识别问题、跟踪进度,并调整优化策略。

以一种相对科学的方式收集和清洗数据,建立一套和当前团队贴合的指标体系,涵盖项目进度、产品质量、团队效率等各个方面,建立机制定期审视这些指标,并根据数据进行决策和改进。

度量只是我们研发效能的开始,是结果的一种呈现,我们所追求不仅仅是这个结果,而是这个结果带来的效能的提升和研发团队的价值提升。

最后

最后回答一下研发效能是不是一个伪命题这个问题:研发效能不是一个伪命题。

因为研发效能本质是一个 ROI 的逻辑,是一个提升研发价值和核心竞争力的过程。 作为一个技术管理者,这个提升操作是必须且持续要做的,现在只不过以研发效能这种方式表现出来了。

研发效能是一个多维度问题,需要从组织文化、组织结构、技术架构、流程设计、工程系统和度量反馈等方面共同努力。

组织文化是创新的基石、组织结构是效能的架子、技术架构是效能的核心、流程设计是效能的流动、工程系统是效能的支撑、度量考核是效能的反馈。

每个维度都有其独特的挑战和实践方法,但它们相互关联并共同作用。只有全面考虑这些维度并协同推进,才能够真正提升研发效能,实现快速、高质量的软件交付,并最终为用户和企业创造价值。

研发效能关注的不仅仅是技术和工具的应用,更重要的是人、流程、文化的协同进化,以及这一切如何共同作用于创造价值和实现企业战略目标的大背景下。

研发效能不仅仅体现在直接的经济效益上,它还帮助企业构建了一个可持续发展的技术优势和技术竞争力,培养了一支能够快速适应市场变化和技术进步的高效团队,并且能够不断推动产品和服务向前发展,满足甚至超越客户的期望。