To B：研发效能产品

在校园内，不论是有组织性的学生团队做产品，还是几个人临时组队研发一款互联网产品，我们都很少会关注整个过程中的研发效率问题。即使关注也更多是关注单点的、个人的产出效率，比如产品经理用哪个工具画图更快；开发同学用什么技术框架更高效，是不是代码不熟练导致开发太慢等等。当然，这是由于在校园内的研发背景下关注研发效能可能显得有些多余：

❝

• 部分校内产品主要满足研发同学练手和提升代码熟练度的需求，研发时间充足
• 产品上线时间往往是由研发同学个人的研发工作效率和排期决定
• 产品研发门槛低且试错成本低
• 开发量小，研发流程单一，业务逻辑简单且不会频繁研发多款产品
• 研发效能关注全局的长期价值，校内研发更多是单点的短期需求

❞

但走出校园，在企业中，研发效能已经是各大企业都开始关注的领域，尤其是在互联网越来越普及，人口红利消失，研发产品门槛越来越低，业务需求变化迅速的今天，研发效能提升、全局交付效率和质量的提升在支撑前端产品、业务快速抢占市场、响应用户需求显得尤为重要。

感受效能提升之美

提升研发效能的方式有很多种，有关注单点研发环节的优化的效率工具，也有关注全局交付效率的研发效能平台。下面简单感受下以下几种方式带来的效能提升：

例 1：技术驱动—前端代码的自动生成

产品经理在做产品原型设计的时候都需要借助产品原型工具来实现产品 UI 界面的设计，以此作为沟通的基础去开展后续的工作。但即使已经有了类似 Axure 和墨刀等原型工具，“画界面“占据的成本依旧不低。

上图展示的是可以将 UI 设计稿，甚至是手画 UI 设计稿转化成目标平台代码的一键自动化生成方案。在上面的例子中，先手绘 UI 界面设计，然后通过Sketch2Code 可以直接转换成目标平台的代码，如果你指定的目标平台是 Web，那就直接生成html，如果你指定的目标平台是 iOS，那就会生成 XCode 的项目，通过编译打包后就可以直接在 iPhone 上安装执行了。这种方式的引入将大幅提升原型构建环节的效率，这种对单点环节的优化也是提升研发效能的表现。

例 2：组织变革—中台赋能前端

“中台”概念近几年非常火，它起源于阿里。上图简单地展示了阿里“大中台 小前台”的组织和业务模式。曾经向一位朋友请教过怎么区分“中台”和“平台”，可能每个人都有不一样的解读，网上也有各式各样的定义。从服务对象来看，“平台”的服务于单点业务，而“中台”通过提供 API 的方式服务于业务前端平台。 在有“中台”之前，一些业务/数据“平台”本身也是做降本增效的事情，集成一些处理业务属性或数据能力，实现复用。而“中台”可以理解为进一步的抽象和实现服务复用，对通用能力在不同层面进行沉淀，并且对外开发能力。从资源共享和能力复用的角度，这样带来的好处是低成本且快速地适应前端业务的创新性变化，提升了需求落地的效率。

例 3：流程主导—流程重组

除了技术主导、组织变革，效率的提升也可以依靠流程重组。没有做任何技术、工具上的变革，仅仅是调整了食材的摆放顺序就实现了整个生产线效率的大大提升。这些复用在一些线上流程同样适用，数字化工具产品并不仅仅是实现传统线下流程的线上化，还做了流程上的重组及优化。

认识研发效能

大家也许听过敏捷开发，但到底什么样的研发算作敏捷其实很难精确定义，研发效能也类似。其实很多复杂概念不是定义出来的，而是逐步演化出来的，在业务、技术、管理理念的驱动下一步步地优化。作为初识者，我们暂且可以大致地理解“研发效能”关注的是企业研发的效率和质量，主要体现在需求从提出到最终落地、成功交付给用户这整个过程的效率和质量。

在校园内我们经历的一款互联网产品从 0~1 的流程大致是：需求分析—>产品方案设计—>UI/交互设计—>开发—>测试—>需求上线。 但在企业中一个研发需求从提交到落地，经历的远远不止这几个状态。每个企业内部需求管理工具（可对需求研发全流程的状态进行管理和跟踪）对于需求经历的中间状态的名称和数目的定义可能不一样，甚至内部不同团队根据各自的需求也会有所差别。

下图举了个例子。我们不需要关注图中具体的状态代表什么含义，我们只需要明确在企业真实情况下，一个产品研发上线需要经历很多状态，在多个角色当中传递，也就避免不了中间一些无效的，不带价值流动的等待环节。

研发管理是一个很早就有的概念，那么研发效能的诞生相比于传统的 IT 管理有什么样的转变，带来什么样的效果？下面从研发效能度量的角度来简单谈谈个人的理解。

❝

传统 IT 管理以优化「局部资源效率」为核心，研发效能提升转变到以「价值流动效率」为核心。

❞

需求落地最终的目标是实现用户价值，则从需求提交到功能上线即可看成一个用户价值流动的过程。研发效能更关注全局的「价值流动效率」，减少不带价值流动的无效等待环节，让用户按期且满意地使用相应的功能。

研发效能-DevOps

谈及研发效能产品，往往会提及甚至直接等同于 DevOps（开发运维一体化）产品，市面上也有很多 DevOps 产品，比如阿里的云效，百度的效率云，腾讯的蓝鲸。所以这里主要简单科普下 DevOps。一个软件从 0~1 交付，大致包括以下几个阶段：需求、规划、代码、构建、编译、测试、发布、部署、运维。

早期的交付模型「瀑布模型」就是顺着这个流程，等每一个阶段的所有工作完成后再进入到下一个阶段，但这样假设项目单向运作是很理想化的，实际随着业务需求增加，交付周期缩短，瀑布式研发模式已经不适用。「敏捷开发」便开始受到关注，简单说就是把大项目分割成小项目，MVP 小步快跑。敏捷开发可以更快发现问题，更快交付到用户受众，团队更快得到用户反馈。但敏捷开发仅关注了开发环节的效率，「DevOps」 的出现开始在此基础上关注运维的瓶颈，提倡开发、测试、运维之间的高度协同，贯穿需求研发全生命周期。

一点感悟

• 产品经理懂些技术不仅仅是为了让开发大哥看得起。首先研发效能这类（服务于技术人员，提高研发效率）B 端产品本身对产品经理有一定的技术知识背景需求，其次懂技术有助于产品合理提需求以及高效沟通。此外产品经理学习技术其实是在培养一种结构化、模块化、流程化、抽象化的思维。特别是在做业务逻辑复杂的 B 端产品，这种技术性思维尤其重要。作为非技术方向，我们只需要半科普性地学习，比如我们可以了解枚举、递推、分治、贪心等一些基础算法思想，但不需要用代码实现。
• 提高效率不仅仅是要考虑工具本身。前面提到的研发效能产品更多的是从工具层面去看产品本身怎么给研发流程赋能提效，但在真实的场景中除了工具本身，还要考虑人（工具使用者）。比如在研发场景中，除了有各种研发效能产品提高效率外，还有通过制定流程规范、代码规范、标准化的技术框架、研发效能文化等等对人的一种约束。