IPD 产品开发涉及大量活动和多个职能角色，如果所有任务都放在同一层级，高层很难识别真正的关键点，执行人员也很难找到自己当前应该完成的工作。因此，研发项目需要建立分层计划：一级解决全流程和关键节点协同，二级解决阶段内各职能之间的协同，三级落实到模块和个人执行。
要点速览：IPD三级计划到底怎么管？
IPD 三级计划可以概括成一条链：一级计划定里程碑 → 二级计划用 WBS 拆关键活动 → 三级计划落到具体任务 → 执行状态逐级向上反馈 → 关键依赖和变更重新影响里程碑。具体来说：
层级 |
主要管理对象 |
核心问题 |
典型负责人 |
一级计划 |
阶段、里程碑、关键交付物 |
项目能否按关键节点交付？ |
项目经理、产品负责人、管理层 |
二级计划 |
阶段活动、工作包、评审、跨部门依赖 |
各职能怎么共同保证里程碑？ |
PDT 核心成员、职能负责人 |
三级计划 |
设计、开发、测试、采购、验证等任务 |
谁在什么时候完成什么？ |
模块负责人、工程师 |
管理三级计划时，最重要的不是把计划拆得足够细，而是建立三种联动：
第一，目标向下分解。 一级里程碑必须能找到支撑它的二级活动和三级任务。
第二，状态向上反馈。 底层任务延期后，要能判断影响的是哪个工作包、哪个里程碑，而不是等项目经理手工汇总。
第三，变更横向传播。 一个关键任务日期变化，要能看到软件、硬件、测试、采购、生产准备等上下游依赖。
以 ONES 为例，可以通过项目计划、甘特图、工作项、里程碑、前后置关系和基线，把这套三级计划模型落到同一套系统中。ONES Project 支持用项目计划创建 WBS，把项目目标逐层分解为计划和工作，并设置里程碑、交付物、前后置关系和计划基线。
一、三级计划失效，通常不是“拆得不够细”
很多企业第一次做多级计划，会把重点放在“分几层”。
例如：
项目
→ 开发阶段
→ 硬件开发
→ PCB 开发
→ 原理图设计
→ 原理图评审
→ PCB Layout
→ PCB 打样……
看起来层级很多，但这仍然不代表三级计划真正建立起来了。
1. 主计划和职能计划是两套数据
典型情况是项目经理维护 Excel 主计划，硬件团队维护一份计划，软件团队在另一套系统里管理迭代，采购又在 ERP 中查看物料。每一份计划单独看都没有问题，一旦出现跨部门依赖，信息就开始断裂。
比如硬件团队知道 PCB 打样推迟了 3 天，但系统测试计划并没有同步变化；采购知道关键器件交期发生变化，但项目经理到周会才知道。计划因此逐渐从“管理项目”退化成“记录项目”。
2. 一级计划出现了大量执行任务
另一种情况是把全部任务直接塞入主计划。结果是一张包含几百甚至上千行任务的甘特图。项目经理能看到很多数据，却很难迅速回答三个真正重要的问题：下一个必须守住的节点是什么？目前哪条依赖最可能影响它？需要谁做决策？
一级计划的价值不是展示全部工作，而是把管理层注意力集中到真正影响产品交付的节点。
3. 三级任务完成了，里程碑却未必能过
例如测试团队的 20 个任务全部标记“完成”，但其中一个关键可靠性问题没有关闭；设计任务完成率达到 95%，但正式设计评审还未通过。如果一级计划只汇总“完成百分比”，很容易得到错误结论。
IPD计划真正需要联动的不是任务数量，而是任务、交付物、评审和里程碑完成条件。
二、三级计划不是三张计划表，而是三个管理视角
三级计划更适合按“阶段—步骤—任务”理解。一级看阶段和里程碑，二级看阶段中的关键活动，三级看具体任务和执行。产品研发可以因此从宏观计划一直穿透到个人工作。
一级计划：管理阶段与关键承诺
一级计划只放真正需要项目级关注的节点，例如：概念阶段完成、计划阶段完成、设计冻结、样机完成、验证完成、量产准备完成、正式发布。
每个节点至少需要四个信息：计划日期、负责人、交付物、完成条件。“6 月 30 日完成 DVT”只是一个日期；更完整的里程碑应该说明：哪些验证报告必须完成、哪些关键问题必须关闭、需要经过什么评审，以及谁有权确认该阶段通过。
这也是为什么里程碑不能只当成甘特图里的一个菱形标记。ONES 官方项目管理能力中，里程碑可以关联交付物、前后置依赖和基线，用于判断阶段性目标是否真正完成。
二级计划：管理跨职能协同
二级计划是很多企业最容易缺失的一层。
一级计划太粗，只告诉大家“什么时候完成验证”；三级任务又太细，一个项目可能有几百上千条。真正决定研发协同效率的，是中间这层关键活动。例如“开发阶段完成”这个一级目标下面，可以拆成：
产品详细设计完成；
硬件设计与样板准备；
软件版本达到联调条件；
模具与结构件准备；
样机装配；
系统集成；
设计验证；
TR 评审。
计划阶段也不只是排几个日期，还可能包含技术可行性验证、DFMEA、产品设计评审、设计检查、成本核算以及软硬件设计等工作。
二级计划承担的就是把不同专业拉到同一产品节奏里。
三级计划：管理具体执行
三级计划继续把二级活动拆成责任明确的执行任务。
例如二级活动“首轮样机完成”，可以继续拆成：结构图纸冻结 → PCB 文件释放 → 关键器件齐套 → PCB 打样 → SMT → 固件烧录 → 结构件到料 → 样机装配 → Bring-up → 初始功能检查。
每一项任务至少应该回答：谁负责？什么时候完成？依赖什么输入？输出什么结果？怎样才算完成？
任务拆到这个粒度后，就已经可以直接进入执行，而不需要工程师再次解释“这个计划到底让我做什么”。
三、第一步：先定里程碑，再做WBS
很多计划做反了：先让各部门列任务，再把任务拼成主计划。
这样做容易得到一张“部门工作清单”，却不一定得到一张围绕产品交付组织的计划。更稳定的顺序是：产品目标 → 阶段 → 里程碑 → 交付物 → WBS工作包 → 具体任务。
1. 先确认一级里程碑
以典型产品研发流程为例，可以沿概念、计划、开发、验证、发布等阶段建立一级计划。概念阶段已经会涉及需求、市场和技术可行性、产品规格以及 DCP/TR 等活动，并通过 WBS 继续拆成执行任务。
因此，一级计划首先确定的是“我们在哪些位置判断项目还能不能继续往前走”。
2. 再围绕交付物拆WBS
WBS 不宜简单按“软件部、硬件部、测试部、采购部”分组。
PMI 对 WBS 的定义本身就强调以交付物为导向，对项目全部范围进行层级分解。这样做的好处，是把容易遗漏的跨部门工作提前暴露出来。比如“完成工程样机”比“硬件部工作”更适合作为工作包。
因为完成工程样机天然会牵引结构、硬件、软件、采购、装配和测试等多个角色。项目经理看到的是一个共同结果，而不是几个部门各自完成了多少任务。
四、第二步：把跨职能依赖画出来
WBS解决“要做什么”，依赖关系解决“为什么这件事现在不能做”。
制造业研发最容易延期的地方，往往不是某个人单独晚了两天，而是一项工作晚了之后，没有及时识别它对后面一连串工作的影响。
例如：
关键器件到料
→ PCB 打样
→ 样机装配
→ 硬件调试
→ 软件联调
→ 系统测试
→ TR 评审
→ 验证阶段
如果“关键器件到料”晚一周，真正需要判断的不是采购任务是否变红，而是：样机还能否如期完成？系统测试是否需要移动？最终是否影响验证里程碑？
因此，二级计划里至少应该显式维护两类依赖。
一类是跨职能依赖，例如硬件输出是软件联调的输入、样机是测试启动的前提。
另一类是关键节点依赖，即某项工作一旦变化，就可能影响一级里程碑。
普通内部小任务不必全部连接成复杂网络。优先把影响阶段交付的关键关系建起来，否则甘特图会很快变成一团难以维护的连线。
ONES Project 可以在甘特图中设置开始—开始、开始—完成、完成—开始、完成—完成等前后置关系，用于表达不同工作的先后约束。
五、第三步：让三级任务状态自动回到主计划
三级计划落地后，最容易重新走回老路的一件事，是要求工程师更新任务，然后要求职能负责人再维护二级计划，最后项目经理再修改主计划。
同一个事实维护三次，计划迟早失真。更合理的方式是：一级计划由项目经理维护目标，二级计划由核心团队管理协同，三级任务由真正执行的人更新；系统负责把执行信息向上汇总。例如：
三级任务“PCB首板调试”延期
→ 二级活动“硬件样机准备”出现风险
→ 与其相关的“系统联调”开始日期受到影响
→ 如果缓冲不足，再影响“DVT开始”这个一级里程碑。
这样项目经理不需要每天逐条查看底层任务，只需要沿风险向下钻取。
ONES 支持将项目计划与工作项或迭代关联，完成从上到下的计划分派以及从下到上的进度反馈，工作项和迭代的进度可以汇总到项目计划。
实际管理时还要注意：不要只用平均完成率判断项目健康度。
一个有 100 个任务的项目，即使完成了 95 个，只要剩下的 5 个都位于关键依赖链上，项目依然可能延期。
因此，一级计划更值得关注：关键里程碑是否变化、关键交付物是否齐备、关键依赖是否延期，以及尚未关闭的问题是否影响阶段准入。
六、第四步：计划变化后，不要直接把日期改掉
研发项目几乎不可能完全按照最初计划执行。
需求变化、技术问题、物料延期、资源冲突都可能导致计划调整。真正的问题不是“能不能改计划”，而是改完以后还能不能回答：
原计划是什么？现在差了多少？为什么差？谁批准了这次调整？
因此，在计划阶段完成、主要范围和节奏得到确认后，应该保存计划基线。
后续执行中，当前计划可以持续反映最新预测；基线则用于衡量偏差。只有范围、重大资源约束或关键目标正式变化，并经过相应决策后，才更新基线。
ONES Project 支持把当前甘特图保存为快照并设置为基线，再将当前计划与基线比较，用于识别哪些工作提前、哪些工作落后。
一个比较实用的变更闭环是：发现变化 → 判断影响链 → 形成调整方案 → 完成决策 → 更新当前计划 → 必要时重设基线。
这样到了项目复盘时，团队看到的不再只是“最终版计划”，而是真正能还原项目为什么延期、问题从哪里开始出现。
七、用 ONES 把三级计划真正落到系统
明确方法之后，再来看工具应该承载什么。
1. 用模板把计划框架固化下来
制造企业的同类产品开发通常具有相对稳定的阶段、评审点和标准活动。
可以把概念、计划、开发、验证、发布等阶段，以及关键里程碑、交付物、标准活动和角色固化到项目模板中。新项目启动时直接复制框架，再根据产品复杂度、人员和日期调整。
这样三级计划不再每次从空白 Excel 开始。
2. 用甘特图建立同一棵WBS
ONES 项目计划可以通过树状结构逐层拆解工作，并使用甘特图展示时间、里程碑和依赖。官方资料明确支持通过项目计划建立 WBS，并逐级拆到可执行工作。
这使同一个项目既可以折叠到一级，只看阶段和里程碑；也可以继续展开到二级活动和三级任务。
从宏观项目规划到具体任务执行，因此可以基于同一套计划结构管理。
3. 把职能执行接回主计划
硬件、软件、测试等团队仍然可以用适合自己的方式执行，不需要为了“统一计划”强迫所有团队使用完全相同的管理粒度。
关键是把执行对象与项目计划连接起来。
软件团队可以管理迭代和需求，硬件团队管理设计任务，测试团队管理验证工作；底层工作状态再向项目计划反馈。这样主计划负责产品节奏，职能计划负责专业执行，两者之间不再靠人工复制数据。
4. 用基线和依赖识别真正的延期风险
三级计划上线以后，项目经理要看的不再只是“哪些任务超期”，而是：
哪些超期任务处于关键依赖链？
它们影响哪个二级工作包？
是否已经影响里程碑？
当前预测与原计划偏差多少？
计划管理因此从“催任务”变成“管理影响”。
FAQ
1. IPD三级计划就是三级WBS吗？
不是完全等同。三级计划强调的是不同管理层级关注什么；WBS强调的是把项目范围逐层拆解成可管理的工作包。复杂产品完全可能存在四层、五层甚至更深的 WBS，但管理上仍然可以归纳为一级看里程碑、二级看跨职能协同、三级看执行。
2. 一级计划应该放多少个里程碑？
没有固定数量。判断一个节点是否值得进入一级计划，可以问一个问题：这个节点延期或失败，是否需要项目负责人或管理层介入？如果答案是否定的，它通常更适合放在二级或三级。
3. 二级计划应该按部门拆还是按阶段拆？
更建议围绕阶段目标和交付物拆，再标记责任职能。如果直接按“软件部计划、硬件部计划、采购部计划”拆，很容易重新形成部门墙。IPD强调跨职能协同，二级计划的价值恰恰是把不同专业围绕同一个产品结果组织起来。
4. 底层任务延期后，要马上调整一级里程碑吗？
不需要。先根据依赖关系判断是否还有时间缓冲，是否影响关键工作以及是否已经进入关键交付路径。只有底层变化确实改变阶段完成预测时，才需要调整一级计划。这也是为什么“延期任务数量”通常不是判断项目健康度的最好指标。
5. 软件团队使用敏捷开发，还能放进IPD三级计划吗？
可以。IPD 主计划负责产品级阶段和里程碑，软件团队仍然可以通过迭代、需求和任务进行敏捷执行。只需要把关键软件版本、联调节点和交付状态与上层产品计划建立联系。这样既保留软件团队的执行方式，也能让产品项目经理知道软件版本是否会影响样机、测试和发布节点。
结语
IPD 三级计划真正要解决的，是一家企业能否把“管理层看到的目标”和“工程师正在做的事情”连接起来。
一级计划用里程碑守住产品节奏，二级计划用 WBS 和关键依赖组织跨职能协同，三级计划把责任落实到具体任务；执行过程中，再通过状态反馈、依赖传播和基线对比，把变化及时带回主计划。
当这条链形成之后，项目经理不必再靠 Excel、周报和一轮轮追问重新拼出项目现状。
ONES 在其中承担的角色，也不是简单提供一张甘特图，而是把里程碑、WBS、工作项、依赖关系和基线放进同一个研发管理体系里，让 IPD 的三级计划从静态计划表变成真正能够持续运转的项目管理机制。
