标签归档：研发管理

如何打造 AI-Native 软件产品研发组织

如果一个团队真的想做 AI-Native 研发组织，第一步是改组织契约：谁可以让 AI 产出代码，谁对代码负责，什么质量底线不能退，什么流程可以砍，什么流程必须更重。

AI 现在太会写代码了，但是这就会导致一个问题：它把「产出代码」这件事的成本做到很低，低到组织里原本那些靠角色边界、流程延迟、评审机制勉强维持的质量平衡，突然失效了。

过去一个 PM 提需求，前端写页面，后端写接口，测试回归，整个链条慢，但慢本身也是一种摩擦力。现在 PM 自己就能把页面跑起来，AI 一下午能写出几十个组件，速度是上去了，但系统开始更脆弱了。

先说 AI-Native 组织不是什么。 AI-Native 组织它不是「让所有人都开始写代码」，也不是「研发岗位会被提示词工程师替代」。

它是把软件组织里的逻辑重排。

以前文档是入口，代码是结果。现在代码变成入口，文档变成派生物。 以前角色按工种切，PM、设计、前端、后端、测试各守一段。现在角色要按责任切： 谁定义业务闭环，谁维护系统护栏，谁提供稳定契约，谁为线上事故买单。

今天我们先聊组织契约，再聊角色重构，然后再把一条研发流水线拆开聊聊。

组织契约

没有组织契约，AI 进团队只会把烂流程放大。

合理预期

在某些 Demo 场景，或者脚本类场景，10 倍是一个合理的预期。 但是对于一个组织来说，10 倍是一个不科学的场景，因为在组织里面，在产品研发过程中，写代码并不是整个生产过程中最耗时的部分。

所以，我们要先摈弃一个幻觉：不要拿 10 倍产出当目标。

AI 在研发组织里的收益区间，我一直认为是 1.5 到 2 倍，高质量前提下的 2 倍。为什么呢？ 因为代码生成速度和有效交付速度不是一回事。AI 能把编码阶段压缩掉一大块时间，但需求澄清、边界判断、异常处理、联调、测试、观测、回滚，这些成本不会自动消失。很多时候还会更高。

如果团队盯着 10 倍，结果一般都一样：PR 数量暴涨，代码体积暴涨，Review 质量下降，线上回归问题增加，半年后开始集中还债。这就是技术债积累速度第一次超过了团队消化速度。

所以合理预期应该写进团队共识里：我们追求的是 2 倍高质量交付，不追求 10 倍低质量代码喷射。

所有权

每个 AI 输出都必须有所有者。

谁发起生成，谁提交 PR，谁 approve merge，这中间可以分层，但最终必须落到一个明确的人身上。这个人要能够面对一句话：如果这段代码挂上你的名字，你愿不愿意负责。要是答案是否定的，这段代码就不该进主干。

这条规则听起来像废话，实际上很多团队做不到。因为 AI 会制造一种错觉：代码好像不是谁写的，是系统吐出来的。人变成了搬运工。只要团队接受这种错觉，质量就开始漂移。一个有所有权的流程大概是这样：

  • PR 模板里要求声明 AI 参与范围
  • 提交人对业务正确性负责
  • Reviewer 对工程质量负责
  • 合并人对上线风险负责

责任可以分工，但责任不能悬空。

质量顺序

质量第一，数量第二。

团队如果不显式声明这一点，默认会被 AI 拖向另一个方向：先铺功能，再补治理。这个方向对 demo 团队成立，对正式业务组织通常是灾难。因为 AI 特别擅长快速补齐显性功能，却不擅长主动建立长期维护结构。它会顺着需求走，不会替你守架构。

AI 时代必须把一些以前属于「好习惯」的东西升级为「强制门槛」，也就是我们之前经常强调的规范，流程等等，如测试、监控、CI/CD、单测等等。

  • 没有测试，不进主干
  • 没有异常处理，不进主干
  • 没有监控埋点，不进主干
  • 没有 feature flag，不上线
  • 不能被 reviewer 解释清楚的代码，不 merge

当代码供给能力暴涨时，质量约束必须同步加码，否则系统会很快从可控变成不可控。

交付代码

传统产品研发里，PRD 是上游，代码是下游。这个模型的问题大家都熟：PRD 经常过期，设计稿和实现偏移，字段定义藏在飞书文档、接口平台、聊天记录和前端代码里，最后没有一个地方是真正可靠的。

AI-Native 组织里：代码作为唯一源，文档从代码反向提取。

从代码出发

现在 PM 借助 Codex、Claude Code（最近又有同事被封号了）、Cursor 这类工具，已经可以生成带交互的页面、Mock 数据、状态流转，很多场景下甚至能直接把核心业务路径跑通。既然这样，就不要再让 PM 先写一份长 PRD，再让研发去猜什么叫「列表为空时的引导态」。让页面先跑起来，再从页面反推需求定义，效率和准确率都更高。

这里有个好处：讨论变得具体了。

以前评审会上大家讨论一句文档描述，脑子里各自渲染不同 UI。现在把页面摆出来，点击路径、字段结构、交互反馈、错误提示都变成可观察对象。对齐成本直线下降。后端也不需要看十页文字说明，只要看这个页面最终需要什么数据结构，就知道接口该怎么供给。

文档反向生成

代码是唯一真相源，不等于不要文档。让文档变成派生物，而且是自动派生物。

流程大概如下：

  1. PM 先生成并跑通前端页面，带 Mock 数据
  2. AI 从页面代码、组件 props、Mock schema 中逆向提取字段说明、交互流程、状态机描述
  3. PM 对这份自动生成的文档做人审
  4. 后端按确认后的 JSON Schema 或 TypeScript Interface 实现接口
  5. 联调时再根据真实契约让 AI 回写文档

这样处理后，文档不再是一个独立维护成本很高的系统，而是代码的视图层。它可以读给人看，但它的源头来自真实实现，而不是空想。

建议把接口契约标准化为 JSON Schema 或 TypeScript Interface

角色重构

AI-Native 组织可能会有一些角色的变更，但是也可能会裁掉一些角色，因为我们是重写角色边界。如果当前人不合适，或者适应不了，就需要换，否则就会变成打造新组织过程中的阻碍。

很多人讨论这件事喜欢走两个极端。一个极端是「以后人人都是全栈」。另一个极端是「AI 只会替代初级岗位，核心角色不变」。这两个判断都不够准确。

真正发生的变化是：低门槛生产能力下放，专业门槛上移。简单说，更多人能做出东西，但真正有价值的岗位，会向规范制定、质量兜底、系统抽象和复杂问题处理集中。

PM 变成产品工程师

在这个新组织中，变化最大的角色是 PM。

过去 PM 的主要输出物是 PRD、流程图、原型图和口头解释。现在这些东西很多都可以收敛成一个交互可运行的页面。于是 PM 的角色自然往「产品工程师」移动：他不再只描述需求，他直接构造需求的运行形态。

但这里一定要说清楚，PM 写了前端代码，不等于 PM 变成前端工程师。PM 的责任边界还是业务逻辑，不是工程治理。

PM 需要对什么负责：

  • 用户路径是否闭环
  • 页面状态是否完整
  • 文案、条件、分支、空态是否符合业务预期
  • Mock 数据结构是否表达真实业务语义
  • 生成代码是否遵守团队规定的基础组件和样式约束

PM 不需要对什么负责：

  • 全局状态架构是否优雅
  • 包体积是否最优
  • 路由切换是否引入副作用
  • 渲染性能是否达标
  • 工程抽象是否可复用

这些后者还是需要专业前端要接住。

问题不是让 PM 承担更多，而是让 PM 把过去停留在文档层的业务表达，直接推进到代码层。这样整个团队拿到的是可执行的业务定义，不是抽象说明书。

设计师变成立法者

设计角色也会变。

当 PM 可以直接借助 AI 生成页面时，设计师如果还把大量时间耗在单页面高保真稿上，投入产出比会快速下降。更有价值的位置，是维护设计系统和机器可消费的样式规范。

设计师的工作重心会变成：

  • Design System
  • 样式 token
  • Visual QA

也就是把颜色、间距、字体、圆角、阴影、组件状态、可访问性规范，从设计稿资产转化成代码和配置资产。比如 Tailwind config、CSS variables、组件规范、图标集、交互动效约束。这些东西一旦进入 AI 生成上下文，PM 或其他角色在生成页面时就不容易跑偏。

说白了，设计师从「画每一张图」转向「制定法律」。立法做得越完整，AI 和 PM 生成的页面越像一个系统，而不是一堆拼起来的截图。

前端变成守门员和重构者

前端是最容易被误读的角色。很多人看到 PM 可以生成页面，就开始下结论：前端会被干掉。实际情况通常相反。前端从体力活里解放出来之后，工程价值反而被放大了。

因为 PM 生成的页面，最常见的问题不是「长得不对」，而是「能跑但脆」。

可能会有大量这类代码：

  • 一个组件里塞满请求、状态、渲染、事件处理
  • loading、error、empty 三种状态缺两种
  • useEffect 依赖写错
  • 切页面回来状态丢失
  • 没有 abort controller，快速切换导致竞态更新
  • 表单校验只校 happy path
  • 直接把 mock 字段名写死在视图层，后续接口一改全炸

这些问题不是 PM 能解决的，也不是 AI 自己会主动解决的。前端真正的工作变成三块：

第一块，Review。
不是审美式 review，也不是找缩进。重点看稳定性、边界条件、状态管理、组件职责、可维护性。

第二块，Refactor。
把单文件逻辑拆成组件、hooks、domain service，把团队组件库接上，把状态流收敛，把重复逻辑抽掉。这个过程需要持续迭代，做到团队规范中，给到 PM 生成的上下文中。

第三块，Integration。
把 Mock 替换成真实 API，处理鉴权、缓存、错误回退、重试、并发、路由守卫、埋点、监控。

这个阶段的前端，更像体验架构师和质量守门员。

后端变成能力供应商

后端角色也会收缩：提供稳定、安全、确定性的能力边界。

如果前端页面能更快被构造出来，后端的价值就不在于「接收一份文档然后写 CRUD」，而在于把系统能力以 API 或 Tools 的形式稳定暴露出来。尤其是 AI Agent 场景下，后端实际上在扮演工具供应商。

后端重点关注四类问题：

  • 契约稳定性
  • 权限与安全
  • 幂等性与确定性
  • 可观测性与审计

前端、PM、Agent 都可能直接消费这些能力。一旦接口设计漂、错误码混乱、鉴权模型含糊，整个上层生成式开发就会持续返工。AI 会把不稳定接口的问题放大得很明显，因为它极度依赖上下文中的确定性。

流程重构

只讲角色变化不够，需要把研发流程改成适合 AI 的形状。下面是一版比较能落地。

需求具象

第一阶段，需求不再先写成长文档，而是先具象成可运行页面。

PM 独立生成前端

PM 拿着明确业务目标，直接在受控环境里生成页面代码。这个页面至少要包含：

  • UI 布局
  • 基本交互
  • 主要状态流转
  • Mock 数据
  • 核心校验逻辑
  • 空态、错误态、加载态

特别强调最后三项。很多团队让 PM 生成页面，只盯着主流程，结果页面演示时很漂亮，一联调全是坑。空态、错误态、加载态必须在这个阶段一起生成，否则后面每一轮都要补票。

禁止黑盒交付

PM 生成页面这件事，最怕黑盒。也就是只看效果图对不对，不管代码是否落在团队跑道上。

所以团队必须先准备好脚手架和护栏。比如：

  • 必须使用指定组件库
  • 必须使用既定样式 token
  • 必须遵守目录结构
  • 必须使用指定的数据获取模式
  • 必须输出可运行测试脚本
  • 必须带 feature flag 接入点

否则 PM 生成的代码看似完成任务，实际是给前端制造二次工程。

不要让 PM 从空白页面开始提示 AI，而是给一个完整的基础模板，再让 AI 在模板内填充。这个模板的价值极高，它决定了团队是让 AI 在高速公路上开车，还是在野地里乱冲。

契约握手

第二阶段，前端页面和后端能力正式握手。

前端反定义接口

以前是后端先定义接口，前端去适配。现在很多场景可以反过来：前端页面里需要什么数据结构，先自然长出来，再把这份结构抽取成契约。

这里的关键点是「自然长出来」之后，必须立刻标准化。不能停留在 JS 对象字面量和口头描述。最好直接生成：

  • JSON Schema
  • TypeScript Interface
  • 字段说明
  • 校验规则
  • 错误码预期
  • 状态迁移说明

做到这一步，后端看到的就不是「我要一个用户列表接口」，而是一个明确的数据契约：字段、类型、可空性、分页、排序、过滤、异常响应、鉴权要求，全都摆明。

这一步会明显减少沟通损耗。后端可以少看很多无效文档，直接围绕契约开发。

后端提供确定性能力

后端接手后，不建议只机械实现接口。要借这个机会把系统能力做成稳定工具层。

如果团队本身就在做 Agent 或工作流系统，这里更应该统一成 Tools 注册机制，而不是散落一地的临时 API。因为未来调用这些能力的，未必只有前端页面，还有内部 Agent、自动化流程、运营工具、甚至外部合作系统。

后端在这一阶段最常踩的坑有几个：

第一，返回结构不稳定。
今天 success 返回 data，明天又套一层 payload。前端 AI 生成代码时非常怕这个，会反复产生错误适配。

第二，错误码语义不清。
鉴权失败、参数错误、资源不存在、限流、业务冲突全都混成一种 message，联调体验很差。

第三，幂等性缺失。
AI 驱动的调用链经常会重试，如果创建类接口没有幂等控制，很容易重复写入。

第四，缺少审计。
AI 或 PM 直接驱动系统能力时，操作路径更分散，审计日志不能省。

联调瓶颈

真正的瓶颈通常出现在第三阶段：联调、测试、排雷。

到这一步，很多团队会发现：AI 把前半段提速提得很猛，但最后这段并没有自动消失，甚至更重。因为前面生成得越快，后面积累的隐患越多。

Review 的重点

前端 reviewer 在这一阶段要非常克制。不要把 review 做成审美比赛，也不要上来就要求所有代码重写一遍。真正该看的，是那些会直接影响稳定性和维护成本的问题。

我会把检查项固定成一张表，至少覆盖这些内容：

  • 异步请求是否有取消机制
  • Loading、Empty、Error 状态是否完整
  • 表单提交是否防重入
  • 路由切换是否会遗留脏状态
  • 全局状态有没有被随意污染
  • 组件职责是否过载
  • 是否接入统一埋点与异常上报
  • 是否存在明显重复逻辑
  • 是否绕过设计系统直接手写样式
  • 是否引入不必要依赖

这样做的好处是，review 从个人经验驱动变成组织标准驱动。AI 时代 PR 量会明显增加，没有标准化检查单，review 质量一定掉。

测试和验收左移

如果团队已经允许 PM 直接交付前端页面，那测试必须同步左移。否则生成速度越快，测试越像消防队。

谁生成页面，谁至少生成对应的 E2E 测试脚本。这个要求不算过分。因为页面交互路径是 PM 最熟的，AI 根据这些路径生成 Playwright 或 Cypress 脚本，命中率通常不低。

在生成代码时，PM 已经完成了第一次的验收。

测试左移不是为了把测试岗位干掉，而是为了把最贴近业务逻辑的验证提前到需求具象阶段。后面的 QA 才能把精力放在组合场景和系统回归上。

发布保险

第四阶段是发布与可观测性。这在 AI-Native 组织里是核心流程。

因为一旦允许更广泛的人群借助 AI 产出代码，线上报错率几乎一定会上升。组织必须提前接受这个现实，然后把监控和发布控制建好。

前端监控

前端监控一定要上，而且要够细。

至少需要这些能力：

  • 错误堆栈捕获
  • Source map 还原
  • 用户会话回放
  • 性能指标采集
  • 接口失败聚合
  • 版本维度对比

像 Sentry、LogRocket 这类工具的价值，在 AI 场景下会更高。因为当报错出现时，你可以把错误堆栈、用户操作轨迹、接口上下文直接喂给 AI，让它先生成修复建议，再由责任人确认。这种协作模式对定位简单问题很有效，尤其是 UI 状态错乱、边界遗漏、类型不匹配这类故障。

但不要误解成「有了 AI 修 bug 就轻松」。线上修复的难点从来不只是生成 patch，而是确认根因、评估影响面、决定是否回滚、验证是否引入新问题。这些仍然要靠工程纪律。

灰度发布

Feature Flag 在这个模式里几乎是必需品。

原因不复杂：当业务页面大量由 PM + AI 参与生成时，组织需要一个足够便宜的试错阀门。否则每次上线都把全量用户暴露在新逻辑下，风险太高。

把 Feature Flag 从「重要功能才加」提升为默认机制。尤其是下面这些场景必须强制：

  • 新页面替换旧页面
  • 新流程替换旧流程
  • 高价值转化路径
  • 涉及支付、权限、数据修改的动作
  • 首次由非传统研发角色主导产出的功能

灰度期间要明确看哪些指标，不要只看有没有报错。还要看：

  • 转化率变化
  • 页面停留时长
  • 关键按钮点击率
  • 表单提交成功率
  • 接口失败率
  • 用户退出路径

这些数据能帮助团队判断问题究竟出在代码稳定性，还是业务交互本身。

基建先行

前面这些流程能否跑起来，核心在于基建。没有基建，AI-Native 组织会迅速退化成提示词手工作坊。

可以先建三类基础设施。

护栏脚手架

这是第一优先级。

它包括：

  • 项目模板
  • 目录规范
  • 统一组件库
  • 设计 token
  • 数据获取封装
  • 表单与校验约定
  • 埋点和监控 SDK
  • 测试模板
  • CI 预设规则

这套东西是整个组织 Harness 的部分。

Prompt 资产

很多团队低估了 Prompt Library 的价值。实际上，当非工程角色也开始产出代码时，提示词模板本身就是组织资产。

可以把高频场景沉淀成标准模板，比如：

  • 列表页生成模板
  • 表单页生成模板
  • 详情页生成模板
  • 多步骤流程模板
  • 异常状态模板
  • E2E 测试生成模板
  • 文档反向提取模板
  • 重构任务模板

这些模板不是为了追求文风统一，而是为了把团队积累的工程约束嵌进去。你希望 PM 每次生成页面都自动包含 loading、error、empty、feature flag、埋点、测试入口，那就别靠口头提醒，直接写进模板。

CI/CD 闸门

AI 时代，CI/CD 不能只是跑个 lint。它必须承担质量闸门职责。

最低限度我会要求：

  • Lint
  • Type check
  • Unit test
  • E2E smoke test
  • Bundle size 检查
  • 安全扫描
  • 依赖合规检查
  • 自动化预览环境
  • 灰度发布流水线
  • 一键回滚

如果团队现在连这些都没有，先别急着搞 PM 交付前端代码。真把口子放开了，组织会先被事故教育一遍。

常见误区

这是几个最常见的误区。

把 AI 当外包

这是第一类坑。很多团队使用 AI 的方式，本质上和用廉价外包没区别：把需求甩出去，拿回代码，自己不理解也不维护。

这个模式短期可能看起来很省，长期一定出问题。因为系统复杂度没有消失，只是被包进了你看不懂的代码里。等线上出事，你会发现团队没有形成任何新的内生能力。

只提速前半段

第二类坑是，只提速需求到页面这一段，不提速后面的治理、测试、发布、观测。结果就是项目看板前面一片绿，最后两列全堵死。

AI 会把组织瓶颈照得更亮。以前慢慢暴露的问题，现在两周就能堆出来。你不改后半段流程，前半段越快，堵得越严重。

容忍脏代码，也容忍脆弱代码

我能接受 PM 生成的代码不够优雅。变量命名一般、文件拆分普通、抽象层次一般，这些问题都能后续治理。真正不能接受的是脆弱代码：没异常处理、没监控、没测试、状态流断裂、提交会重复、接口失败直接白屏。

脏和脆是两回事。组织必须把这条线划清楚。

用 AI 替代判断

第四类坑最隐蔽。团队开始迷信 AI 给出的架构建议、重构建议、性能建议，仿佛它给出了答案，工程判断就可以省掉。

这是错的。AI 非常适合提供候选方案、加快实现、缩短试错周期，但它不拥有系统上下文，不承担线上责任，也不会为半年后的维护成本买单。架构判断、边界判断、风险判断，最终还是人做。

最后

如果一定要用一句话概括我对 AI-Native 软件研发组织的理解，那就是：把代码生产普遍化，把工程责任集中化。

前者意味着更多角色可以直接参与构造软件。PM 可以交付可运行页面，设计可以把规范直接编码，后端可以把能力做成工具供全组织消费。后者意味着系统质量不能民主化。责任必须更清晰，护栏必须更强，发布必须更克制，观测必须更细。

「PM 交付前端代码」这件事很容易被包装成一个新故事。真落地时，它首先是工程纪律问题，然后才是工具问题。团队如果没有建立所有权，没有把代码当唯一真相源，没有把契约、测试、监控、灰度这些基础设施补齐，这条路大概率会走成一场持续返工。

反过来，如果这些条件具备了，AI 确实会把组织推到一个新阶段。PRD 不再是那份总会过期的文档，代码本身就是需求表达。角色不再围着工种转，而是围着责任和系统边界重组。研发流程不再把大量时间浪费在翻译需求上，而是更早进入真实问题：契约、质量、异常、性能、发布。

这才是我理解的 AI-Native。

以上。

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

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

说到研发效能，大家可能会马上想到度量、指标、流程、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