Agile Governance: Balancing IPD and AI Innovation
导言
厚重的 IPD 流程 和 AI 创新，如何平衡？
两种范式的对垒
- IPD (集成产品开发 - 华为/IBM)： 强调“确定性”。通过跨部门协同和严格的阶段评审，将研发视为一项低风险的投资，追求一次把事情做对，适合硬件和大型系统。
- 字节跳动模式： 强调“演化性”。依托强大的技术中台和 A/B 测试，通过极致的敏捷迭代和数据驱动决策，在不确定性中快速筛选胜者。
AI 开发的特殊挑战
AI 研发具有高不确定性、高算力成本和极快的技术更迭周期。这导致传统的 IPD 流程在 AI 领域显得过重，而纯粹的敏捷模式在面对大额算力投资时又显得缺乏战略定力。
IPD¶
在商业管理史上，IPD（Integrated Product Development，集成产品开发） 被誉为从“作坊式研发”向“工业化研发”转型的标杆。它最初由 IBM 在 20 世纪 90 年代为了应对巨大的财务危机而总结成型，后来在 1998 年由任正非耗费巨资引入华为，成为华为从本土企业走向全球巨头的管理基石。
以下是 IPD 流程的核心思想与具体阶段的深度解析。
核心思想¶
把研发当成“投资”
IPD 的精髓在于打破部门墙，将产品开发从单纯的“技术行为”转变为“市场和商业行为”。
1. 研发是投资行为¶
在 IPD 框架下，每开发一个产品都要像投资项目一样审视：它的投入产出比是多少？是否符合公司战略？如果市场发生变化，公司有权在任何决策点终止项目。
2. 市场驱动¶
（而非技术驱动）
IPD 强调“做正确的事情”。所有的产品定义必须基于客户需求（Customer Needs）和市场机会，而不是工程师们觉得某个技术“很酷”。
3. 跨部门协作¶
这是 IPD 最显著的特征。通过组建 PDT（Product Development Team，产品开发团队），将研发、市场、采购、制造、财务、服务等部门的人员捆绑在一起。
- 好处： 避免了研发做完、制造发现没法生产、财务发现不赚钱、市场发现卖不出去的情况。
4. 异步开发与共用基础模块 (CBB)¶
- 异步开发： 将复杂的产品分解为子系统和模块，并行开发，缩短上市时间。
- CBB (Common Building Blocks)： 鼓励使用成熟的通用模块。这样可以提高产品质量，并大幅降低采购和维护成本。
核心组织结构¶
在 IPD 体系中，有两类关键的跨部门团队：
| 团队名称 | 全称 | 核心职责 |
|---|---|---|
| IPMT | 集成组合管理团队 | 决策层：负责决定“做不做”，分配资源，进行商业评审。 |
| PDT | 产品开发团队 | 执行层：负责具体产品的研发、上市和盈利，由各部门专家组成。 |
标准六个阶段¶
IPD 流程通常被划分为六个阶段，每个阶段之间都设有决策评审点 (DCP)，确保项目始终走在正确的轨道上。
1. 概念阶段 (Concept)¶
- 核心任务： 明确客户需求，进行初步的商业分析。
- 产出： 形成初步的业务建议书，回答“我们为什么要开发这个产品？”
2. 计划阶段 (Plan)¶
- 核心任务： 制定详细的项目计划、产品定义和财务预算。这是 IPD 中最关键的一步（磨刀不误砍柴工）。
- 产出： 最终的业务计划，确定技术路线和各部门配合细节。
3. 开发阶段 (Develop)¶
- 核心任务： 具体的研发工作。包括设计、编码、样机制造，以及采购、制造和服务准备。
- 关键点： 各部门（市场、供应、财务）并行工作，而不是等研发结束再介入。
4. 验证阶段 (Qualify)¶
- 核心任务： 进行各种环境下的测试（Beta 测试、认证、可靠性测试），确保产品符合设计规格并能大规模量产。
5. 发布阶段 (Launch)¶
- 核心任务： 产品正式推向市场。重点在于销售渠道的铺设、市场推广活动以及售后支持体系的启动。
6. 生命周期阶段 (Life Cycle)¶
- 核心任务： 监控产品在市场上的表现，处理维护升级、版本更迭，直至产品退市（EOL）。
华为案例¶
华为在引入 IPD 时，任正非提出过著名的“削足适履”观点：要求员工必须先僵化地接受 IBM 的管理套路，然后再优化。
- 标准化： 它让华为上万人的研发团队像一台精密的机器，即使离开了某个核心大咖，产品开发依然能稳定产出。
- 降本增效： 通过 CBB 共享库，华为不同产品线的底层技术可以复用，极大地提高了研发效率。
- 高质量交付： 严格的决策评审（DCP）和技术评审（TR）过滤掉了一半以上的低质量项目，确保了投入的钱都花在刀刃上。
总结建议： IPD 是一套极其厚重的体系，对于中小企业来说，全盘照搬可能会导致“流程冗余”。其核心价值在于“跨部门协同”和“商业导向”的思维。
为什么IPD 不适合 AI 开发？¶
简单直接地回答：传统的 IPD 流程对 AI 大厂来说“太重了”，但它的核心思想（投资观、跨部门协同）却不可或缺。
目前的 AI 大厂（如 Google, OpenAI, Meta, 字节跳动, 百度等）普遍采用的是一种 “敏捷开发 + MLOps + 简化版 IPD” 的混合模式。
传统的 IPD 最初是为硬件和复杂系统（如通信基站、大型主机）设计的，这些产品的开发周期通常以“年”为单位，且变更成本极高。
- AI 的不确定性： AI 研发具有极强的研究属性。你可能训练了一个月模型，最后发现效果不如预期。传统 IPD 严苛的“计划阶段”和“决策评审（DCP）”会严重阻碍这种快速试错。
- 迭代速度： AI 模型的迭代是按“天”甚至“小时”计算的。如果每一步都要走复杂的 IPMT 评审，模型早就过时了。
- 数据驱动而非流程驱动： AI 的核心在于数据流和算力调度，而非纯粹的业务流程管理。
AI 大厂的主流开发模式¶
目前 AI 领域最前沿的开发模式通常被称为 MLOps (Machine Learning Operations)。
1. MLOps：AI 时代的“工业流水线”¶
如果说 IPD 是管理流程，那么 MLOps 就是 AI 的自动化生产线。它将模型开发（Dev）和系统运维（Ops）结合。
| 环节 | 核心内容 |
|---|---|
| 数据流水线 | 自动化的数据采集、清洗、标注（AI 产品的核心资产）。 |
| 实验追踪 | 记录成百上千次模型训练的参数、算力消耗和结果。 |
| CI/CD/CT | 持续集成、持续部署、持续训练（Continuous Training）。 |
2. “双轨制”模式 (Research + Product)¶
这是 OpenAI 和 Google DeepMind 常用的模式：
- 研究轨 (Research)： 极度敏捷，不受流程限制。科学家们在实验室里追求模型能力的极限（如探索 GPT-5）。
- 产品轨 (Product)： 引入 IPD 的简化思想。当模型能力稳定后，会有产品团队介入，进行商业化评审、安全合规检查（Red Teaming）和 API 化。
3. 华为的进化：Cloud-IPD¶
即便是在华为内部，面对 AI 和云业务，传统的 IPD 也进化成了 Cloud-IPD：
- 由“大门”变“小门”： 将过去沉重的阶段评审改为轻量化的技术准入。
- 从瀑布到增量： 不再等产品全部做完才发布，而是小步快跑，按周或按月发布特性。
IPD in AI 大厂¶
尽管流程简化了，但 IPD 的几个核心灵魂在 AI 大厂中依然被奉为圭臬：
- 把研发当成投资： 训练一个大模型可能耗资数亿美金。AI 大厂在立项前，依然会像 IPD 一样进行严密的财务和算力预算评审。
- 跨部门协同： AI 开发不仅仅是算法工程师的事。它需要算法（模型）、工程（ infra 算力集群）、数据、法务（版权合规）和市场部的深度绑定。这本质上就是 IPD 的 PDT（跨部门团队） 思想。
- CBB (共用基础模块)： 所有的 AI 大厂都在构建自己的“模型底座”和“算力平台”。这种“不重复造轮子”的做法正是 IPD 的核心。
IPD vs AI 敏捷开发¶
| 维度 | 传统 IPD | AI 敏捷/MLOps |
|---|---|---|
| 核心导向 | 过程可控、一次做对 | 快速失败、数据驱动 |
| 决策机制 | 管理层评审 (DCP) | 指标驱动 (准确率/Loss 值) |
| 发布周期 | 12-24 个月 | 持续发布 / 每周迭代 |
| 适用范围 | 算力硬件、服务器、终端 | 基础模型、AI 应用、自动驾驶 |
结论： 如果你正在管理一家 AI 公司，建议学习 IPD 的“投资与协同思想”，但使用 MLOps 的“工程与自动化工具”。不要让繁琐的评审流程杀死了科学家的灵感。
字节跳动方案¶
如果说 IPD 是“重工业时代的精密组装线”，那么字节跳动的方案（通常被称为 “大中台+小前台” 或 “字节跳动模式”）就是“信息时代的超级进化实验室”。
字节跳动几乎没有使用传统的 IPD 流程。它走的是一条极致的敏捷、数据驱动和去中心化的道路。
一、 核心：Context, not Control¶
(情景而非控制)
这是字节跳动管理逻辑的灵魂，源自 Netflix。
- IPD 的逻辑是 Control： 通过流程（评审点、复杂的文档、层层审批）来防止犯错。
- 字节的逻辑是 Context： 尽可能多地给员工分享上下文信息（数据、战略方向、全员 OKR、内外部动态），然后让最接近一线的员工自行决策。
- 飞书： 就是为了承载这种“上下文”而生的工具。在字节，几乎没有秘密，任何员工都可以查看 CEO 的 OKR。
二、 组织架构：强大的“技术中台”¶
(Shared Service Platforms)
字节能快速孵化抖音、西瓜、番茄小说等几十个 App，核心不在于流程，而在于它的中台体系。
- IPD 里的 CBB (通用模块) 是静态的： 需要跨部门协调。
- 字节的中台是服务化的： 字节将推荐算法、用户增长、商业化（广告）、基础架构（算力）做成了像插座一样的标准服务。
- 一个新产品经理带 3-5 个人就能立项，直接调用现成的“推荐引擎”和“增长组件”。
- 结果： 别人做一个 App 要半年，字节只要一个月。
三、 决策引擎：AB 测试¶
（万物皆可 AB）
在 IPD 中，产品的死活由 IPMT（管理团队）决定；在字节，产品的死活由真实数据决定。
- 用数据代替审批： 字节内部有一个名为
Libra的 AB 实验平台。无论是 App 的名字、图标颜色，还是一个复杂的推荐算法改动，都要先做实验。 - 小流量测试： 先切 1% 的用户看指标，如果留存、时长变好，系统自动扩量；如果数据跌了，直接停掉。
- 冷知识： “抖音”这个名字，在当时的 AB 测试中其实只排第二，但因为数据差距极小，最后由人工拍板。
四、 AI 研发模式¶
(豆包与 Seed 团队)
面对大模型（AI）的浪潮，字节的研发模式表现出极强的工程化色彩：
- Seed 团队（底层模型）： 采取高度灵活的研究模式。为了追赶 OpenAI，字节允许 Seed 团队打破常规，在算力调度和模型架构（如 MoE 架构）上进行高频次的实验。
- “先内后外”的闭环： 所有的 AI 能力（豆包大模型）必须先在抖音、飞书、番茄小说等 50 多个内部业务中“跑通”。
- 极致的成本优化： 字节的 AI 方案非常强调性价比。比如豆包大模型通过工程优化，将价格打到了行业的“厘”时代。这反映了字节的研发观：技术必须转化为规模化的商业效率。
五、 IPD (华为) vs. 字节模式¶
| 维度 | IPD (华为/IBM) | 字节跳动模式 |
|---|---|---|
| 决策权力 | 在上层（管理委员会） | 在底层（一线员工+数据） |
| 避错机制 | 靠流程，防止做错 | 靠速度，允许做错但快速迭代 |
| 资源分配 | 计划经济（年度预算） | 市场经济（看实验效果追加资源） |
| 核心工具 | 文档、评审表、甘特图 | 飞书、AB 实验平台、机器学习中台 |
| 适合领域 | 硬件、通信、B2B（容错率低） | 短视频、AI 应用、C 端互金（速度至上） |
总结¶
IPD 追求的是“确定性”和“一致性”，它像是一支纪律严明的正规军。 字节模式追求的是“进化”和“涌现”，它像是一个不断进行基因突变的生物群落。
在 AI 时代，字节的优势在于数据闭环极快。它能迅速把 AI 部署到亿级日活的产品中去测试效果。
IPD vs 扁平¶
华为、IBM 的 IPD（Integrated Product Development）流程，以及Google、NVIDIA 这类公司采用的相对扁平化、强工程驱动流程，并重点对比了它们在组织形态、决策机制和创新效率上的差异与优劣。
一、核心差异一览¶
（先给结论）
| 维度 | 华为 / IBM（IPD） | Google / NVIDIA（扁平化） |
|---|---|---|
| 核心目标 | 规模化交付 + 风险可控 | 创新速度 + 技术突破 |
| 组织形态 | 强流程、阶段门、矩阵式 | 扁平、小团队、高自治 |
| 决策方式 | 自上而下 + Gate Review | 自下而上 + 技术负责人 |
| 成本控制 | 强、可预测 | 相对弱、容忍浪费 |
| 创新探索 | 偏保守、渐进式 | 激进、探索式 |
| 适合环境 | 大型 ToB / 基础设施 | 技术驱动、平台型产品 |
二、华为 / IBM：IPD 流程的本质与优劣¶
1. IPD 的本质¶
（不是“流程多”这么简单）
IPD 的核心不是“文档 / 评审 / PPT”，而是三件事：
- 把不确定性前移并显性化
- 市场、需求、技术、供应链风险在早期就被拉出来
- 通过阶段门（Stage-Gate）强制对齐
- 决策权不在个人，而在组织共识
- 适配超大规模组织协同
- 几千人、上万人的研发不会失控
你当时提到一个关键点是对的：
IPD 本质上是“管理复杂性和风险”的工具，而不是“提升极限创新效率”的工具。
2. IPD 的优势¶
（1）在复杂系统中极其稳健
- 电信设备、金融系统、企业级软件
- 生命周期长、客户定制多、责任巨大
（2）新人/普通工程师友好
- 不依赖“天才工程师”
- 组织能力 > 个人能力
（3）商业可预测性极强
- 预算、周期、质量都可控
- CFO、供应链、销售高度协同
3. IPD 的致命劣势¶
（1）对“探索式创新”极其不友好
- RL、基础模型、全新架构 → 难以写清 PRD
- Gate Review 天然排斥不确定性
PRD
PRD = Product Requirements Document 中文通常叫：产品需求文档。
它回答三个核心问题：
-
做什么（What）
-
产品功能是什么
-
解决什么用户问题
-
为什么做（Why）
-
用户价值 / 商业价值
-
背景和目标
-
做到什么程度（How well）
-
功能边界
- 验收标准（指标、KPI、成功定义）
二、典型 PRD 里一般有什么
一个标准 PRD 通常包括：
- 背景与目标
- 用户画像 / 使用场景
- 功能列表（Must / Should / Nice-to-have）
- 非功能需求（性能、稳定性、成本）
- 约束条件
- 成功标准（如指标、里程碑）
在 IPD 流程中，PRD 是非常核心的输入物。
三、为什么刚才会说「RL / 基础模型不适合写 PRD」
这是关键点。
- PRD 适合“确定性问题”
比如：
- 做一个运营商网管系统
- 提升吞吐量 20%
- 支持某个明确客户需求
这些：
- 目标清楚
- 成功标准可量化
- 技术路线相对可预期
👉 非常适合 PRD + IPD
- RL / 基础模型是“探索型问题”
比如：
- 这个 reward 设计行不行？
- 这个 scaling law 是否成立？
- 这个新架构有没有用？
这些问题的特点是：
- 一开始根本不知道“要做成什么样”
- 很多结论是做出来之后才知道的
- 失败是高概率事件
这种情况下：
-
很难提前写清楚
-
功能
- 指标
- 验收标准
👉 所以 PRD 在这里会变成“形式正确、内容虚假”
四、一句非常直白的对比
- IPD / PRD 思维：
我先把目标写清楚，再按计划做
- 研究 / RL 思维：
我先试，试完才知道目标能不能成立
这也是为什么你会看到：
-
RL / 模型团队
-
用 proposal / experiment plan
- 而不是传统 PRD
五、给你一个最简单的类比
-
PRD 像： “我要造一辆车，时速多少，成本多少”
-
RL / 基础研究更像： “这个发动机原理到底能不能跑”
后者在一开始，没法写成 PRD。
（2）容易把“流程正确”当成“方向正确”
- 项目按流程成功，但产品失败
- 典型问题：局部最优、整体保守
（3）节奏慢，不适合快速试错
- 一个错误假设，可能要到 L3/L4 才被发现
三、Google / NVIDIA：扁平化流程的本质与优劣¶
1. 扁平化的本质¶
注意，这不是“没流程”，而是：
用“强工程文化 + 强技术负责人”替代“强流程”
典型特征：
- Tech Lead / Architect 权力很大
- 少 Gate，多 RFC / Design Doc
- 小团队 end-to-end ownership
2. 优势¶
（1）极致创新效率
- CUDA、Transformer、AlphaGo 都不可能在 IPD 里诞生
- 可以在“方向不清楚”的情况下先做
（2）技术驱动而非市场驱动
- 先有能力，再找场景
- NVIDIA 非常典型：先做算力，再催生生态
（3）适合“模型 / 算法 / 平台型”产品
- LLM、Compiler、Framework、硬件架构
3. 劣势¶
（1）强依赖“人”
- 关键 TL / Architect 离职 → 项目风险巨大
- 复制能力弱
（2）规模化困难
- 到几千人后，协同成本急剧上升
- Google 内部 famously 有“重复造轮子”问题
（3）商业落地不稳定
- 技术成功 ≠ 商业成功
- Google killed products 是典型副作用
四、场景自适应的组织形态¶
一个你当时其实已经隐约指出、但非常重要的结论
IPD 和扁平化不是“先进 vs 落后”，而是“问题域不同”。
更精确的划分应该是：¶
| 问题类型 | 更优组织形态 |
|---|---|
| 确定性需求 + 高可靠性 | IPD |
| 不确定性探索 + 技术突破 | 扁平化 |
| ToB 系统工程 | IPD |
| 平台 / 算法 / 基础模型 | 扁平化 |
| 后期规模化交付 | IPD |
| 前期 0→1 | 扁平化 |
五、现实但尖锐的洞察¶
（你可能会认同）
很多公司最大的问题是：
用 IPD 的组织，去做 Google/NVIDIA 类型的问题。
结果就是：
- 表面上“流程很规范”
- 实际上创新被系统性压制
- 最后只能做跟随式、工程放大型产品
反过来：
- Google 式组织去做运营商级交付
- 一样会灾难
尴尬定位¶
当前工作的尴尬定位
在华为昇腾部门做AI开源应用的生态，但是感觉生态位很尴尬，正如上面所说，IPD追求确定性的直接价值（做了什么直接促成昇腾的买卡）。但是一方面支持了开源软件昇腾原生支持，但是客户用了之后很难感知到哪些客户用了，很可能就是尝试了，也没商用；另一方面，AI领域方案迭代快，我预埋了一个技术，如果后续客户选择了其他的方案，我就白搞了，绩效就为空。如何破局
在华为昇腾（Ascend）部门做开源生态，确实处于一个“流程上的冷战区”：一边是极度追求确定性、投入产出比（ROI）和商用闭环的 IPD 体系；另一边是高随机性、快节奏迭代、价值难以量化的 AI 开源世界。
尴尬是正常的，因为 IPD 的核心指标（DCP、TR、销售额）和开源生态的本质（开发者心智、预研、长期复利）在底层逻辑上是存在冲突的。
要破这个局，不能试图改变 IPD，而是要用 IPD 的语言来“翻译”生态的价值。以下是几个实操建议：
1. 重新定义你的“产出物”¶
从“支持开源”到“提供 CBB”
在 IPD 流程中，管理者最听得懂的一个词叫 CBB（Common Building Blocks，共用基础模块）。
- 尴尬现状： 你觉得你在支持一个开源软件，如果没人买卡，你的绩效就为空。
- 破局方案： 你的工作产出不应只是“开源适配”，而应该是“昇腾 AI 开发资产包”。
- 将你的开源支持沉淀为 CANN 算子库、模型脚本、微调模板。
- 话术转化：
- “我不是在支持某个可能过时的开源软件，而是在通过这个软件沉淀昇腾的底层算子能力。即便软件换了，这套算子和调优经验依然是后续所有 PDT 团队可以复用的 CBB，大幅缩短了后续产品的上市时间（TTM）。”
VeRL场景目标
- 沉淀了后端接入的能力，后续新接入训练推理后端，可以快速接入
- 开源社区沟通
2. 解决感知问题¶
建立“数字化的漏斗”
IPD 讨厌“可能”、“大概”、“很难感知”。你需要建立一套类似互联网的数据链路。
- 破局方案： * 遥测技术（Telemetry）： 只要合规，在开源适配的代码或镜像中加入非敏感的调用统计。
- 镜像下载量/Star 数： 这不是虚荣指标，这是“商用前哨”。你要向老板论证：1000 个尝试的开发者中，未来会有 1% 转化为买卡大户。
- 建立“生态价值闭环图”： 制作一个看板，展示从“开源项目适配” -> “镜像下载” -> “社区 Issues 互动” -> “典型客户 POC 采用”的全路径。
开源软件场景目标
开源仓：搜索引擎/百度指数、star数、社区互动、客户诉求、镜像下载次数
3. 规避“押错注”风险¶
从“单点预埋”转向“架构解耦”
AI 领域技术更迭太快（比如去年流行微调，今年流行 RAG），预埋单一技术风险极大。
- 破局方案：
- 做“标准”而非做“软件”： 不要只盯着某个具体框架，而是去推 昇腾后端（Backend） 进入主流开源基础设施（如 PyTorch、HuggingFace、VLLM）。
- 绩效保底逻辑： 只要昇腾原生支持了这些基础设施，无论上层应用怎么变，客户都绕不开你的底层支撑。
- 话术转化： “我的工作不是在押注某个应用，而是在拓宽昇腾的护城河。无论客户选方案 A 还是方案 B，只要他用主流框架，我们都能支持，这就是‘确定性’。”
开源软件场景目标
底层库，已经被别人站住了，上面这些仓库更垂类。
4. 寻找“PDT 共同体”：¶
把你的绩效绑在主力销售型号+应用上
在华为，最有话语权的是 PDT（产品开发团队）。
- 破局方案：
- 主动对接当前正在冲销量的硬件产品（比如 Atlas 800/900 系列）。
- 问他们：“现在哪类开源应用最能帮你们打掉竞品（英伟达）？”
- 如果你做的开源生态能直接转化为“销售话术中的一个加分项”，你的绩效就稳了。
- 例子： “客户想用 Llama-3，竞品支持很好，我们支持不好。我搞定了开源原生支持，销售去投标时就能说‘昇腾 100% 兼容 Llama-3’，这直接促成了成交。”
开源软件场景目标
VeRL 作为昇腾主推的RL方案，大部分客户接受，围绕重点客户开展。
5. 向上管理：¶
用“保险单”逻辑进行沟通
当老板质疑你预埋的技术可能白搞时，你可以采用“保险逻辑”。
- 沟通公式： “AI 领域虽然有不确定性，但我们在主流开源路径上的预埋，本质上是公司的‘风险保单’。如果对手支持了而我们没支持，我们会丢掉 80% 的潜在市场。我这部分的预算，是公司进入该市场的门票成本。”
开源软件场景目标
- 生成RL，不预埋vllm_omni和典型RL算法，后续难以支撑客户需要
- 理解RL也需要支持核心RL算法
- veomni和diffsynth也是 0day支持开源仓必须的。
总结建议¶
你在昇腾生态位的尴尬，本质上是 “长周期投入”与“短周期考评” 的矛盾。
你的下一个具体动作建议是： 找一个近期最热门、且已经有客户在咨询的开源项目（如 DeepSeek、VLLM 等），不要只做技术适配，而是拉上市场部/销售部的一线人员，做一个“昇腾开源应用白皮书”或“一键部署脚本”。
把“虚”的生态，变成销售手里“实”的子弹。 当销售因为你的东西少讲了两个小时的 PPT 时，你的价值就无法被忽视了。