标签归档:研发管理

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

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

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

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

研发效能是什么

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

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

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

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

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

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

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

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

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

体系化的提升研发效能

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

组织文化:创新的基石

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

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

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

组织结构:效能的架子

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

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

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

技术架构:效能的核心

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

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

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

流程设计:效能的流动

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

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

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

工程系统:效能的支撑

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

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

度量考核:效能的反馈

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

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

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

最后

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

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

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

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

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

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

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

思考:如何让研发的价值更大

当你成为一个技术团队的管理者时,就会经常会被老板问到,研发的价值在哪里?如何让研发的价值更大?现在的研发团队和行业内相比效率/能力/水平怎么样?如此种种……

每个公司每个技术团队的管理者都有自己的逻辑来回答这个问题,因为这是带团队的核心逻辑之一,且各有缘法。

今天这篇文章不是想准确的回答这个问题,也不是标准答案,只是这些问题最近引发的一些个人思考。

先抛两个公式:

公式一:研发的价值 = (业务价值 + 技术价值) – 非正常成本 – 正常成本

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

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

总体来看,让价值更大在于攻守,如何攻,如何守,攻就是提高产出价值,守就是减少成本。

在攻的方面,提高产出价值包括提高业务价值和技术价值。我们都知道业务需求是做不完的,如何在做不完的业务需求里面产出更大的价值, 关键点在于业务需求本身的价值和业务价值生效的时间,将具有更大价值的业务需求更快的上线是提高研发侧业务价值的主体逻辑。当然,需求上线后可能还有 bug 之类的,这个我们作为守的那部分来聊。

提高业务价值

提高业务价值的主体逻辑包括两层意思,一个是更大价值的业务需求,另一个是更快的上线。

更大价值的业务需求我理解为做重要的事情,实际上是我们对于事项的一个优先级排序。对于重要的事情分两个阶段,一个是确定事项前的判断,一个是事项确定后的判断,确定前的判断有以下要点:

  • 战略和期望:这是一个前期非常重要的判断项,公司层面的战略、技术长期规划,老板对这个组织的期望等等
  • 业务影响和目标价值:直白的说,看这些事项对业务目标的达成情况的影响,对收入增长的影响,对于 NPS 这些的影响等等
  • 第三方约束和风险:比如已经签了合同的,有截止时间要求的,比如一些严格的技术风险,或者稳定性的问题等等

基于以上这些我们有了一个对事情的判断,但是当这些事情过滤后对于一个管理者来说,还需要做的一个重要性的判断是资源。

资源是最后一个项,是一个相对后期的项,看我们在人力、时间,财务资源上投入多少,这个是过程态中我们要持续看的,根据这些来看我们个人和团队的精力如何分配等。资源需求较大的事项,即使重要性较高,也可能因为资源的限制而需要降低优先级。

在明确了事项的优先级后,下一步就是更快的上线了,更快的上线从研发管理的角度可以分为三个层面,研发流程、工程系统、团队协作和沟通。

  1. 研发流程

    • 精简流程:优化开发到上线的流程,减少不必要的步骤,以加快从需求到部署的时间。可以有一个系统来看每个流程阶段的时间花费,如果没有系统用表格顶一下也行。具体落地指标可以看平均需求交付周期、每流程交付时间等
    • 敏捷实践:采用敏捷方法论,如 Scrum 或 Kanban,以小批量、快速迭代的方式推进项目。在实际落地过程中可以以需求吞吐量、平均需求交付周期、每需求人力成本等。
  2. 工程系统

    • 系统工程化建设:投资于自动化测试、持续集成(CI)、持续部署(CD)等工程系统,以提高开发和部署效率。
    • 技术架构优化:根据业务需求,对技术架构进行持续优化,确保其支持快速增长和变化,并降低长期维护成本。
  3. 团队协作和沟通

    • 跨部门协作:促进开发、运维、产品和其他相关部门之间的沟通,确保需求的快速流转和问题的及时解决。
    • 沟通机制:建立高效的沟通机制,包括定期会议、即时通讯工具和项目管理软件,确保信息流通畅通。
    • 团队授权:赋予团队更大的决策权,使得团队能够快速作出决策,而不必每一项都上报等待批准。

以上是业务价值,将具有更大价值的业务需求更快的上线是核心逻辑。

提高技术价值

对于技术价值而言,逻辑略有不同,技术价值在将更大价值的技术更快的上线的基础上, 需要坚定不移的持续投入和有规划的稳步建设

持续投入是指在资源方面,特别是人力资源方面,需要在业务需求紧张的情况下保障技术需求的投入资源占比。

有规划的稳定建设是指在保障系统稳定的前提下,有规划的对技术架构进行优化,明确技术发展路线图,按照既定的规划逐步实施技术改造和优化,确保每一步都有明确的目标和时间表。

提高有效时间内的价值

从公式二:单位有效时间内产出的价值 × 有效时间 来看,要提高研发价值,需要提高单位有效时间内产出的价值以及提升有效时间。那么如何提高单位有效时间内产出的价值?

一个是从业务层面,将具有更大价值的业务需求更快的上线,另一个从人的层面,提高单兵能力,因为研发最终是要落在人身上,强化单兵能力,对于提升整个团队的有效时间内的产出有极大地促进作用,单兵能力的高低能决定团队总体效能的高低。

至于提升有效时间,从研发管理角度来看一个是以机制形式保障研发的开发投入时间,如研发静默时间,在静默时间不允许插入非写代码相关的事项;

另一方面是以目标为导向,推动团队集中精力专注于某个目标的达成,如小黑屋之类的,当然,其本质上是延长工作时间,也就在一定程度上提升了有效时间,此法慎用,除非文化本来如此,能留下来的是能接受这种文化的人。

以上是攻的角度,也就是提高产出价值来思考,从守的角度来看,更多提就是减少成本,这里主要是减少非正常成本。

减少非正常成本

非正常成本是指在生产和运营过程中由于管理不善、技术失败、人为疏忽或外部因素导致的超出正常开支的成本。这些成本通常不是生产或提供服务的必需开支,而是由于各种非计划事件造成的损失,可以以某种方式减少或规避。

这里的非正常成本我的理解包括以下的部分:

1. 项目延期和需求变更

项目延期和需求变更会导致增加额外的人力成本,延迟了需求的上线时间,可能导致业务损失或风险发生。我们一般可以通过更精细的项目管理来减少延期,通过正式的变更控制流程,评估变更的必要性和影响,以控制变更带来的成本。

2. 技术难题

当在项目过程中遇到了预料之外的技术挑战和难题,可能会导致项目停滞,以至研发团队无法按时完成项目,需要额外的研发投入或影响产品需求计划等。

我们一般在项目开始前对技术难题进行充分调研和风险评估,如果是在项目中遇到了,快速协调资源解决,甚至是请外部的专家来解决,从内部来看,提升现有团队人才梯队,提升团队成员能力,让成为技术难题的项越来越少是更优的解决方案。

3. 产品缺陷

产品缺陷我们通常称之为线上 BUG,当一个线上 BUG 出现后就会有一个流程串起一批人来解决,这个成本比在更前置的开发阶段或测试阶段发现并解决的成本更高,甚至会影响到用户的使用和口碑。

我们一般是通过代码审核、自动化测试、生死用例、showcase 等各种流程和机制来保障和提升产品的质量,同时对于已经出现的问题,使用缺陷管理系统,确保所有缺陷被记录、跟踪并及时处理。

4. 过度设计

过度设计是指在开发过程中投入的工作远超过解决问题所需的程度,这通常体现在过于复杂的系统设计、不必要的功能,或过早优化的代码上。涉及到开发、维护和产品质量三方面,这种过度设计会导致更多的开发和测试时间,更复杂的维护工作,以及可能降低的产品质量。

在设计时尽量遵循  KISS(Keep It Simple, Stupid) 原则 ,避免不必要的复杂性。

5. 历史债务

技术债务是指由于短期内的快速开发和决策,而在长期内需要支付的额外工作。例如,为了赶项目进度,团队可能会选择快速但不完美的解决方案,而不是花费更多时间来寻找更好的解决方案。

为了解决技术债务,可能需要进行代码重构或重新设计系统,这将带来额外的开发和测试时间。此外,技术债务可能会降低开发团队的生产力,例如,如果代码质量低,团队可能需要花费更多的时间来理解代码、修复错误和添加新功能。

我们一般是要将历史债务管理起来,识别和记录技术债务,并制定计划逐步解决,同时在新项目中避免产生新的技术债务。

6. 线上故障

线上事故对于任何技术团队来说都是一种非常严重的非正常成本

这类事故可能会对用户产生直接的影响,包括用户体验降低、数据丢失、服务中断等。这不仅可能导致用户对产品或服务的信心降低,甚至可能导致用户流失。此外,严重的时候,线上事故还会导致公司的资产损失。

为此,我们需要建立全面的监控系统,及时发现并响应线上故障,同时制定灾备计划和故障恢复策略,以减少故障影响,并对每次故障进行事后分析,总结教训并采取预防措施避免未来的重复。

在我们的研发过程中,持续的减少以上的非正常成本是提升整体研发价值的守的逻辑。

除此之外,我们还需要考虑整体系统的复杂度,用持续优化对抗世界的不确定性。

康康说:老板要的无非是「人少活好效率高」

换句话说是成本低质量高产出多,而质量高也是为了成本低,只不过和人少的成本相比是不一样的成本。

老板看的还是 ROI

研发管理之基于代码的研发效能度量

在研发管理中,如何准确评估研发人员的效能一直以来都是一个挑战。传统的评估方式大多依赖于观察软性技能的表现,如问题的跟进实时性、反馈的有效性、推动事情的能力,以及解决技术问题的能力。然而,对于研发人员而言,他们的代码质量和效率往往是最直接、最硬性的评价标准。而代码很多时候是看不到的,特别是当团队规模到达一定数量的时候。

代码的质量和开发效率是研发同学工作的核心。好的代码不仅要能完成预设的任务,也要易于理解、修改和测试,以便其他开发者在未来能够维护和改进。代码的质量和开发效率可以直接反映开发人员的技术能力和专业知识。因此对于一个研发管理者来说,要想掌控一个团队的情况,从代码出发,从代码量和代码质量来度量是一个不可或缺的角度。

为何要度量代码?

代码是软件产品的基础,深入理解代码可以帮助我们更好地了解产品的健康状况、性能状况和维护情况。更重要的是,通过深入分析代码,我们可以发现代码中可能存在的问题和改进点,以便提前发现并解决问题,降低项目风险。基于代码的研发效能度量为我们提供了一个量化、可度量的评估标准,从而使我们能够更科学、更有效地管理和优化研发过程和研发分工。

基于代码的度量是什么?

基于代码的研发效能度量是一种通过对代码及代码提交进行深入分析和理解,从中洞察出可能存在的问题和改进点,以提高研发效率和产品质量的方法。这涉及到代码质量分析、代码性能分析、代码测试分析、代码维护性分析以及技术债务分析等多个方面。

从实际落地来说,基于代码的研发效能度量通常涉及到以下几个方面:

  1. 代码质量:这是衡量代码健康状况的重要指标。

    • 代码复杂度:例如,使用圈复杂度(Cyclomatic Complexity)或 Halstead 复杂度(Halstead Complexity)度量代码的逻辑复杂度。
    • 代码规范性:如代码是否遵循了 PEP 8(Python编程规范)或其他语言的编程规范。
    • 代码重复率:如通过工具(如 SonarQube 或 PMD )检测代码的重复部分,计算代码重复率。
    • 用例覆盖率:如使用工具(如 JUnit 和 Cobertura )运行单元测试和集成测试,计算用例覆盖率。
    • 注释覆盖率:SonarQube 等工具可以分析出代码覆盖度
  2. 开发活动:这是了解开发团队工作模式的重要度量。

    • 提交频率:如通过 Github 或其他版本控制系统统计每个开发人员的提交频率。
    • 代码修改频率:如统计某段代码或某个文件被修改的频率,以理解代码的稳定性。
  3. 问题和缺陷:这是评估代码质量问题和风险的关键度量。

    • 缺陷密度:例如,通过错误跟踪系统(如Jira或Bugzilla)统计缺陷数量,然后除以代码行数,计算缺陷密度。
    • 问题解决时间:例如,统计从发现问题到解决问题的平均时间,了解团队的响应效率。

以上就是基于代码的研发效能洞察的主要组成部分。这些度量有助于我们理解代码的健康状况、开发过程的效率,以及代码质量的问题和风险。需要注意的是,这些度量并不能全面反映研发效能,还需要结合具体的项目情况和团队情况进行分析。

基于代码的研发效能度量如何实施

将以上的这些组成部分、时间、人、项目、团队这些结合起来就是一个基本完整的基于代码的研发效能分析系统。

做基于代码的研发效能洞察无非是回答如下的 2 类问题:

  1. 做了什么,做了多少
    • 你的团队做了什么,做了多少
    • 你的团队成员做了什么,做了多少
    • 每个成员在团队中的水平处于什么样的水平,有没有特别突出的(多或少)
  2. 做得怎么样
    • 你的团队的代码质量如何
    • 有没有比较突出(好或坏)的成员
    • 有没有共性的质量问题

要想回答这些问题,基于代码层面,通过代码度量研发的研发效能,影响力产出,代码质量等,拿到客观的数据度量到人、团队、项目。

我们做代码的洞察实施简化后可以有 4 步:

1.引入工具或系统:将代码这个盒子打开,看到度量后的数据。这里当然会有一个问题分析、行业方案对比的过程。

  1. 机制化跟进:需要有一个组织来承接事项,无组织即无成果。结合管理人员的机制化跟进,根据度量的数据和系统的指标,以某个时间间隔来做洞察,发现问题。
  2. 整体洞察:从下往上,形成整体效能的洞察,根据发现的问题,明确代码产出的问题点和能衡量状态的指标。
  3. 复盘:以 3 个月以一个区间来盘点指标和问题,清晰团队/项目的变化。

基于代码的研发效能度量的优势与挑战

当我们引入某些工具或系统来做了基于代码的度量或洞察后,可以得到如下的一些东西:

  1. 全面的代码质量管理:通常能够全面地对代码质量进行管理,包括代码质量分析、代码审查等。
  2. 技术债务管理:通常提供了一种有效的方式来管理技术债务。
  3. 提高团队效率:通过对代码的持续分析和审查,可以帮助团队提高效率,减少错误和问题。
  4. 提供具有洞察力的数据和报告:通常能够提供具有洞察力的数据和报告,帮助团队更好地理解代码质量和研发效能。

以上是一些好的方面,但是也有一些不好的点:

  1. 需要一定的学习和适应:对于新的系统和工具,团队成员可能需要一段时间来学习和适应。
  2. 可能存在一定的成本:这类系统通常需要付费使用,这可能会增加公司的开支。
  3. 可能与现有的流程和工具不兼容:如果团队已经有了自己的流程和工具,那么使用新的系统可能会导致一些兼容性问题。
  4. 安全或隐私问题:如果系统是基于云的服务,这意味着代码需要上传到外部服务器进行分析。这可能会引发一些安全和隐私问题。一般我们选择通过私有化部署来解决,但是成本会更高一些。

最后,随着时间的推移,可能会出现「面向指标编程」的情况。这通常发生在过度重视某些度量标准并以此作为主要驱动开发的团队或组织中。这些度量标准可能包括代码行数、问题数、提交频率、测试覆盖率等。

这样可能会带来一些问题:

  1. 优化错误的指标: 有时,开发同学可能会在不影响或甚至损害总体产品质量的情况下优化这些指标。比如,如果过度关注代码行数,开发者可能会写出冗长和复杂的代码来增加代码行数。
  2. 忽视质量和实用性: 过度关注指标可能会导致开发者忽视代码质量、可读性、可维护性和实用性。例如,开发者可能编写无实际价值的测试,只是为了提高测试覆盖率。
  3. 鼓励短视行为: 如果某些指标被用作评估性能或提升的基准,开发者可能会采取短期行为来满足这些指标,而忽视了长期的技术健康状况。

为避免「面向指标编程」,作为团队的管理者应该谨慎选择和使用度量标准。应该选择那些能反映出代码质量、可维护性和实用性的指标,并且要注意平衡多个指标,避免过度优化某一个指标。同时,要培养一个开放的团队文化,鼓励开发同学关注长期的技术健康状况,而不仅仅是满足短期的指标。