IPD落地指南：从六阶段流程到DCP/TR评审与重量级团队

一年里我大概会被问到几十次：能不能把你那套IPD的PPT发我一份？每次我都发，但每次都补一句——你要是只想下载90页PPT，那大概率学不会IPD。因为IPD真正的门槛从来不在文档，而在评审怎么开、决策怎么拍板、组织怎么转起来。

这篇不打算再刷一遍教科书定义，直接聊IPD体系的主流程和操作细则：六个阶段每个节点的抓手是什么，DCP和TR两类评审怎么分工，所谓重量级团队怎么从纸面落到日常，最后给一个中小团队能直接抄的裁剪版落地模板。适合正在做研发管理改进的朋友，也适合被老板塞了一份九十页PPT、不知道下一步该干嘛的流程负责人。

1. 先别急着翻那90页PPT：IPD到底在治什么病

很多人拿到厚厚一册流程手册，第一反应是看模板、看表格、看审批流，其实这恰恰是学IPD最容易走偏的地方。IPD不是一套表单工具，它是在治企业研发管理的三个老毛病。

1.1 传统研发团队的三个典型顽疾

第一个是“火车头式开发”。需求、方案、测试、上市全压在研发项目经理一个人身上，市场和制造只在最后环节被通知“接车”。结果产品做出来了，卖点不清晰，工艺不可行，成本高出预算一大截，所有问题都在集成测试阶段集中爆雷。

第二个是“大厨依赖”。核心技术攥在几个资深专家手里，项目计划不是根据目标和资源排的，而是根据某个专家的空闲档期排的。这个专家一旦被别的项目拉走，整个产品进度就塌方。我见过不少公司的产品开发其实是在给三五个人排日历，很危险。

第三个是“加班式救火”。因为没有阶段性的检查标准，问题藏得很深，等发现的时候已经来不及了，只能靠冲刺、加班、加人。看起来大家都很努力，实际上是系统性地把质量、成本、可服务性这些要素全部让位给了“先做出来再说”。

这三个毛病的共性是什么？底层是职能化分工加串行流程。每个部门每天都在做自己“正确”的事，但连起来看，系统结果是错的。IPD要改变的不是某个人怎么干活，而是产品从 idea 到退市这条链路上，谁在什么时候、基于什么证据、做什么决定。

1.2 IPD的三根支柱：流程、评审、组织

把IPD拆到底，支撑逻辑就三根柱子。

第一根是结构化阶段流程。产品开发不再是一个黑箱，而是被切成概念、计划、开发、验证、发布、生命周期六个阶段。每个阶段有明确的目标、交付物和退出标准，阶段之间的界限是清晰的。

第二根是阶段门决策。每一个关键阶段结束，不是研发自己说“差不多了”，而是由经营决策团队来做投资评审：这个项目值不值得继续投钱、投人，是继续、调整还是终止。这一条让产品开发从“技术活动”变成了“投资行为”，这是IPD一个很核心的思维转换。

第三根是重量级团队。市场、研发、采购、制造、服务的人在项目一开始就进入固定团队，而不是在某个节点被拉来“配合一下”。他们带着各自领域的责任参与决策，不是来旁听的。

这三根支柱缺一根，IPD都会变形。只做流程没有决策，就是纸面文章；只做评审没有重量级团队，评审就像外行在审内行；只搭组织没有流程，那就是开不完的会。

1.3 一个容易误解的点：IPD是加法，还是减法？

很多管理者以为IPD是“增加流程”“增加文档”，推行以后被研发人员骂“天天写PPT”。我得说句公道话：IPD在理想状态下，文档不是变多了，而是变准了。原来那些隐性的、靠人肉传递的信息，被转换成几个关键评审点上必须呈现的证据；原来那些无休止的改来改去，被前置决策消掉了大半。你感觉流程变重，其实是在为早期的判断失误买单。

所以学IPD的第一课，不是背阶段和名词，是理解它的目标结构：把经营节奏从“等产品出来再算账”改成“每个阶段都算一次账”。

2. 六个阶段的操作细则：每个节点到底抓什么

IPD主流程说起来就六段，但每一段往里走，操作细节差别很大。我按实战中容易出问题的位置逐个拆。

2.1 概念阶段：一份Charter是怎么炼出来的

概念阶段的核心交付物是Charter（项目任务书），相当于这个项目的“创业计划书”。判断一个Charter写得好不好，不看页数，看五个问题答没答清楚：

• 做什么：产品定义和范围边界是什么，不做哪些事也要明确；
• 卖给谁：目标细分市场、目标客户、核心购买动机是什么；
• 凭什么赢：差异化价值点、竞争格局、我们凭什么能切进去；
• 要多少资源：大致投入范围、关键依赖、周期预期；
• 值不值得投：商业价值、财务预期、风险概要。

实操当中最常见的坑是Charter写成PRD，全是功能描述，没有商业判断。技术团队很容易把“解决方案”当成“项目定义”，一上来就讨论用什么架构，而市场和财务维度一片空白。

Charter由谁写也有讲究。严格来说，它应该由PDT核心组共同起草，市场代表牵头客户需求部分，研发代表负责技术可行性，财经代表做初步测算，采购和制造代表评估供应与工艺约束。单靠产品经理一个人憋出来的Charter，基本是研究部门视角。

还有一条经验：信息不完整不可怕，可怕的是假装完整。我会要求在每个未知项后面写明“待验证状态”，概念评审时不追问答案，只追问验证计划。这样得到的信息比一份表面上无懈可击的PPT可靠得多。

2.2 计划阶段：PDCP评审前必出的三张表

概念通过之后进入计划阶段，这里是IPD流程中“最烧脑的一段”。因为你要在还没有大规模投入开发之前，把方案、资源、财务、供应都拉到可执行的颗粒度。

到计划决策评审点（PDCP）之前，至少要交出三张硬货：

第一张是项目计划表。一级计划要落到阶段和里程碑，二级计划要落到具体模块。我不太强调要精确到天，但至少每个里程碑要有明确完成标准和负责人。没有这种结构，后面开发阶段一延期，你会说不清楚到底延在哪。

第二张是资源承诺表。这是很多公司推行IPD时最先崩的地方。资源表上不能只写“研发XX人天”，要点到人头：每个核心岗位是谁，什么时间投入，投入比例多少，后备是谁。部门负责人必须在评审会上当面确认这张表，不是项目经理自己填的。如果你发现某个关键岗位的人员在三个月后已经被另一个项目锁定，早发现早处理，省得到开发阶段再抢人。

第三张是财务测算表。NPV净现值、IRR内部收益率、回报周期这些指标即便估得粗，也得有一个版本。财务测算最好不要由技术负责人拍脑袋，而应该由财经BP或财务代表搭模型，哪怕数据粗糙，逻辑也要专业。

我曾经用一个比喻帮助团队理解这两个阶段的区别：概念阶段是决定“去哪个鱼塘钓鱼”，计划阶段是决定“用什么饵、下几根竿、准备多久、预期收多少鱼”。鱼塘没选对，后面多努力都白搭。

2.3 开发与验证阶段：用技术评审控制成熟度，而不是靠等

进入开发阶段，最容易犯的错误是一口气做完全部功能再去验证。正确做法是把技术成熟度拆成若干检查点，也就是TR评审。TR1-TR3解决概念和方案层的技术可行性，TR4-TR5验证子系统与原型，TR6则是产品化就绪。

说直白一点：TR点看的不是“做完了吗”，而是“你现在是不是有足够证据证明技术风险可控”。很多项目在开发阶段大量消耗时间，不是因为工程师水平不行，而是因为系统架构冻结得太晚。模块间接口一直在变，每个人都在对着一个移动靶开火。

我建议在开发阶段前30%的时间窗口内完成架构和关键接口冻结，之后原则上只做增量优化。这个节奏感，得靠TR点持续拉动。验证阶段也一样，别走“做完再验”的老路。在功能完成到一定比例就开始内部试用、外部Beta，尽量早地让真实用户碰真实产品，那个阶段收集到的信息会影响后面的返工成本，而且反馈速度越快，修正成本越低。

2.4 发布与生命周期：上市不是终点，退出机制同样重要

发布阶段的操作重点不只是“搞一场发布会”，而是“准备好规模化交付的能力”。发布评审要检查试点客户验证结论、市场渠道准备度、供应产能爬坡计划、服务支持体系是否到位。这些没有准备好，哪怕产品体验不错，也会死在交付环节。

生命周期阶段被很多公司忽略，基本没人管。但IPD体系里这个阶段是完整闭环的关键。老产品什么时候停止销售、停止服务、停止备件供应，需要预先定义退出条件。我见过不少公司的产品线立项逻辑混乱，很大一个原因就是资源被大量半死不活的老产品占用，新产品反而拿不到人。定期的生命周期审视，本质上是让产品组合持续保持健康度。

下面是六阶段的主流程对照，方便你在做细则时直接参考：

3. 评审点怎么开才不像“加班批斗会”：DCP与TR的分野

很多公司推行IPD，推着推着就变成一个魔幻场景：会议室坐了一屋子人，从早上九点吵到下午六点，最后结论是“再研究一下”。之所以会这样，通常是把两类性质完全不同的评审搅在一起了。

3.1 决策评审是投资行为，技术评审是成熟度检查

DCP（Decision Check Point）是业务决策评审，核心问题是：这个项目值不值得继续投、以什么力度投，是继续、调整还是终止。参加者是具备经营决策权的IPMT成员，他们对商业结果负责。

TR（Technical Review）是技术评审，核心问题是：产品的技术风险是否可控，是否满足预先定义的技术成熟度标准。参加者是技术专家和相关领域的代表，他们对技术判断负责。

关键操作原则是：不要在DCP上纠缠技术细节，也不要在TR上替业务做决定。如果你们公司每次决策评审都会陷入技术方案争论，大概率是TR环节该审的没审透，把风险一直往后带，最后只能到DCP让一群负责人用最不擅长的方式临时判断。反过来，如果TR评审上有人反复问“这个产品能卖多少量”，那说明评审角色已经错位了。

3.2 一次合格评审会的基本开法

我每次帮企业搭评审制度，都会先立这么几条很实在的规矩：

• 材料最晚提前48小时发出。现场不许脱稿讲PPT，只回答大家对材料的问题。没有提前看到材料的人，提出的意见只能作为“补充输入”，不能变成“评审结论”。
• 材料里必须有一页“决策摘要”。写清楚本次会议需要决策什么、每个选项的利弊、明确建议和不同意见。这一页的存在会倒逼提案人把问题想清楚，光这一点就能减少三成无效会议。
• 会议上按角色发言，不按级别发言。IPMT成员代表各自领域，市场开口之前先给数据，研发开口之前先给风险清单，制造开口之前先说工艺验证状态。谁也不能用“我觉得”代替证据。
• 结论必须输出五个要素：决策结论、核心理由、可接受的风险范围、明确责任人、下次检查时间。没有这五要素的会议记录，一律视为无效会议。

3.3 两个常见的“评审污染”怎么纠偏

第一个污染是把评审变成批斗会。根源是TR没把风险暴露干净，DCP成员到了会上发现一堆技术问题，于是开始当面审代码、审方案。纠偏的方法是提升TR的严肃性。我给团队定过一个标准：TR结论如果是“有条件通过”，这个条件必须写成“解除条件+责任人+完成时限”，缺少任何一项就视为不通过。用这个标准逼着技术团队把该验证的提前验证，而不是带着半成品上评审会。

第二个污染是把所有评审都变成流程仪式。会议开完了，纪要在邮件里，然后就没人再追踪。评审结论必须进项目管理系统，形成行动计划。我见过的优秀PDT项目经理，都有一个习惯：评审会上只认口头承诺，散会之后48小时之内一定会把行动计划发给相关人确认责任矩阵，这叫评审闭环。

这里有一条我特别想强调的经验：评审会最重要的产物不是结论，而是“决策记录”。三个月后项目遇到困难时，团队能翻出当初为什么这么决策、当时接受了什么风险、谁拍的这个板。这会极大减少事后扯皮，也是公司组织记忆的一部分。

4. 重量级团队不是墙上挂图：IPMT与PDT如何真实运转

IPD落不了地，第二号原因（第一号是评审走过场）就是组织没有跟着变。很多公司画了一张漂亮的重型团队架构图，实际上还是职能部门的延伸，名字改了，行为没改。

4.1 IPMT：经营决策团队必须真金白银拍板

IPMT，集成组合管理团队，可以理解为公司内部的一个微型“投资委员会”。它不是各部门派代表出席的联席会议，而是一个对产品组合商业成功负责的经营决策机构。

IPMT成员通常是产品线总经理、研发负责人、市场负责人、供应链负责人、财经负责人。开会的频率一般每月一次，核心动作是做三件事：给项目排序、给资源分钱、给瓶颈拍板。

操作细节上有一个指标很关键：IPMT单次会议评审的项目数量不要超过5到8个。超过这个数，讨论深度必然下降，评审就会变成走流程。项目再多，就先在清单层面用规则删一轮，进会议室的一定是被筛选后真正需要决策的项目。

4.2 PDT核心组：跨部门的人要“身在曹营心在曹营”

PDT（Product Development Team）是实际干活的重量级团队。核心组一般由项目经理LPDT、市场代表、研发代表、采购代表、制造代表、服务代表、财经代表组成。这些成员在组织关系上仍然属于各自的职能部门，但在业务运行上对PDT负责。

这里最难的是考核权。如果代表们的绩效主要还由职能经理打，那他们在PDT里就会当“传声筒”，而不是“决策者”。我的建议是：从推行IPD的第一天起，将产品相关代表的考核权重切一部分给业务线，具体比例可以参考企业成熟度，但至少要占到30%到50%。没有这条，重量级团队永远轻不起来。

4.3 LPDT：一位携带经营责任的项目经理

LPDT（Lead PDT，产品开发团队负责人）是所有流程文件里最容易被低估的角色。他不是传统意义上的“高级工程师兼职做计划”，而是一个带着经营目标上场的内部创业者。

LPDT要有明确的授权：能跨部门要人，能对项目预算内开支行使调度权，能按计划节点对代表提出工作要求。如果没有拿到这些授权，LPDT只是高级项目协调员，是靠刷脸推动项目运转的。反过来，LPDT对IPMT也要兑现承诺：按计划完成交付、按预算控制投入、按商业计划达成目标。

4.4 一个可复用的例行会议节奏

团队组建起来以后，会议节奏一定要固定下来。我用过的一个有效节奏是这样：

• 每周一次PDT例会：只看本周计划偏差、风险动态、跨部门待办，30到45分钟结束，不写长报告；
• 每两到四周一次IPMT项目审视会：逐个看关键项目的健康度，决定资源仲裁和优先级调整；
• 每个里程碑一次正式评审（DCP或TR）：按前述五要素输出决策记录。

会议输出不用追求精美，一张A4纸就够了：项目名、当前状态、本月要完成的三个关键动作、需要IPMT决策的事项、延期风险是否升级。这张A4纸能坚持一年，差不多比90页PPT管用十倍。

5. 从90页PPT到本公司的细则：中小团队如何裁剪式落地

如果你所在的公司不是几千人的大厂，没有足够的管理冗余去支撑完整IPD体系，别硬套。IPD是一套可以去适配的框架，关键是把骨架稳住，肉身可以慢慢长。我基于实操经验给一个最小落地集的建议。

5.1 必须保留的四件事

无论团队多小，下面四件事建议先立起来：

1. 每个产品有唯一的经营负责人（LPDT/产品经理）。他要对商业结果负责，而不是只对“上线”负责。
2. 项目切成阶段，阶段边界有明确的“继续/终止”决策点。哪怕只切成“立项、开发、发布”三段，也比没有门强。
3. 每个关键阶段有一份标准交付物。不追求厚，追求关键问题答清楚了：目标客户、价值主张、资源需求、财务预期、风险清单。
4. 每周一次固定例会，看偏差和风险，形成行动项跟踪。

先做这四件事，你就拥有了IPD的核心动作：有人负责、有节奏、有门禁、有复盘。至于CBB公共模块复用、异步开发这些高级玩法，等团队大于100人、项目线多于三条的时候再逐步补课也不迟。

5.2 两周内可以启动的行动清单

很多人的状态是“想推IPD，但不知道第一周干嘛”。给你一个能直接照抄的两周行动清单：

• 第1-2天：画出当前产品开发的主流程，不理想化，就画现在实际怎么走的，特别标出“哪些环节从没人负责”和“哪些问题总是等到快上市才发现”。
• 第3-4天：选一个正在进行的真实项目当试点。一定不要从流程再造开始，要从一个真实项目开始。
• 第5-7天：给试点项目补两份材料：一页纸项目章程（回答做什么、卖给谁、凭什么赢、要什么资源、值不值得投），一张资源承诺表（核心人头点到名）。
• 第8-10天：组织第一次阶段评审。注意不是过进度，是过“是否应该继续投”的决策。
• 第11-14天：把评审结论和行动项录进系统，约定下次评审时间和需要补齐的证据清单。

两周跑完，你就拥有了一份自己公司的“操作细则第一版”。它可能粗糙，但它不是别人PPT里的通用话术，而是针对你们真实项目的判断规则。

5.3 推行中最容易出现的三种变形

变形一：只要文件，不要决策。项目组花大量精力把模板填得整整齐齐，到了评审会决策人却全部弃权，没人敢说“终止”。这种情况我会建议设立一条规矩：每个决策项必须给出选项和推荐意见，弃权一律视为“不通过”，倒逼责任落位。

变形二：只评审，不追踪。会议开完了，行动项没下文。要解决这个，不是靠管理者的记忆，而是靠机制：行动计划进入项目管理工具，下次评审先刷新上次的行动项状态，没完成的列为第一优先级讨论。

变形三：试点成功就急着全线铺开。试点通过后，通常应该让第二、第三个项目跟上，而不是一下子把全公司几十条项目线全纳入新体系。节奏太快，组织习惯跟不上，新流程就会变成表格式表演。

5.4 一套适合自建细则的最小模板

最后给你一个可以直接复制成表格的“操作细则雏形”。不需要90页，一页A4纸就能启动：

这张表你可以按公司实际情况改字段，但不要改骨架。骨架就是：每一个阶段有明确责任人、有明确交付物、有明确的继续或终止门槛。有了这三样，任何公司的研发管理都能在两个月内看到明显变化。

我个人在实际操盘IPD落地时的体会是：能走远的，几乎都不是从“下载PPT”开始学的，而是从一张A4纸主流程加一个试点项目开始的。如果你手里已经有一份90页PPT，别从第1页开始啃，先拿最后两页的流程总图和评审点清单，对照你们正在做的一个真实项目改出一版细则。改着改着，你就知道哪些话是替你公司写的、哪些话只是话术。到那时候，那份PPT里真正有价值的东西，才会对你开口说话。