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 部署到亿级日活的产品中去测试效果。
尴尬定位
当前工作的尴尬定位
在华为昇腾部门做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 时，你的价值就无法被忽视了。
Agile Governance: Balancing IPD and AI Innovation
http://icarus.shaojiemike.top/2025/12/30/Thinking/1-target2chase/career/IPDandAI_Innovation/