研发交了设计、采购交了报价、制造说等样机到了再评估，项目还是返工。IPD 里 PDT 要解决的就是这件事：让跨部门团队拿到真正的授权与资源承诺，而不是只交出一张名单和一套流程。

假设一家企业准备推出新的控制终端，外观已经确定，上市日期也已公布。

在例行项目会上，研发反馈说结构设计完成，采购说正在询价，制造说等样机到了再评估。

虽然说各个部门都有进度，项目经理还是不能确认产品是否可以如期上市。

等到试产，问题集中出现，比如：

外壳喷涂不稳定，装配需要反复调整，采购报价也高于预期。

这也是最近负责的一款产品上遇到的问题，这款产品是为国内某传统家电厂设计的方案。

由于成本高于预期，客户要求临时更换指纹模组，而模组尺寸有差别，结构也要同步调整。

再改设计，3D打样做确认，整个项目周期又要往后推。

项目经理只好重新协调时间，请大家优先支持。

在 IPD 流程中，产品开发团队（PDT）承担跨职能的产品开发责任。

判断它是否具备“重量级”，可以看一件具体的事：

当产品目标与部门安排冲突时，这个团队有没有获得解决冲突的授权和资源。

部门墙，常常出现在交接之后

传统的职能分工本身是有价值的：

研发积累设计能力，制造提高工艺水平，采购建立供应资源。

产品越复杂，越需要这些专业能力长期存在。

问题出在各部门只对交出去的东西负责，却没有共同确认下一环节能否使用。

市场把“外观精致”写进需求，研发根据自己的理解确定表面工艺。

制造接到图纸才发现，现有条件下难以稳定控制色差。

到了这个时候，争论很容易变成：需求没有说清，还是设计没有考虑生产？

客户关心的其实是能否买到外观一致、使用可靠的产品。

至于问题落在哪个部门，并不会减少客户的不满。

交接完成，不等于产品目标已经实现。

要查开发周期为什么长，也不能只统计各部门实际工作的天数。

一个设计变更提交以后，等谁答复、在哪个会议上决定、决定之后又返工了多少，这些时间同样进入总周期。

如果主要时间花在等待上，要求工程师把设计再加快一点，改善空间很有限。

团队需要先找出：

哪些决定本可提前做，哪些信息到得太晚，哪些争议始终没有明确的决策人。

一张团队名单，怎样变成共同责任

PDT可以包括市场、开发、采购、供应与制造、技术服务、财务以及质量保障等专业代表。

这些角色进入团队，应当带来可以用于决定的信息。

还是那以上面那款控制终端为例：

市场代表需要解释客户对外观最在意的点是什么，哪些差异能够接受。

开发提出几种可实现的结构与工艺方案，制造评估批量一致性，采购确认供应商是否具备相应能力。

财务把不同方案的投入与成本放在一致口径下比较，服务人员则检查维修时能否拆装、需要保留哪些备件。

质量保障代表要追问，团队凭什么认定风险已经解决，验证是否覆盖真实使用条件。

发现证据不足时，应当能够提出独立意见，而不是为了配合进度替团队做决策。

专业代表参加讨论，是为了形成承诺。

如果采购代表每次都只能说“回去问领导”，团队就仍然需要等待职能线逐层答复。

可行的做法是先明确代表能够确认的事项，以及哪些承诺必须由职能经理批准。

也不必为了凑齐角色，让每个专业都安排一位全职成员。

稳定参与的核心成员负责持续推进，法规、认证或其他专项专家按风险进入评审。

关键是需要某种判断的时候，能够及时找到有能力、有权限的人。

PDT经理能决定什么，必须先写清

让一个人对进度负责，却不给他资源安排和问题升级的渠道，很容易把产品管理变成催办。

PDT经理需要集成各专业承诺，保持产品范围、开发计划与商业目标的一致性。

研发项目经理通常更侧重技术任务和研发交付，两种角色可以由同一人承担，但不能因此省略经营责任。

例如，外壳方案要增加一道加工工序，技术上可以实现，成本和交期却都会变化。

PDT经理应组织团队比较方案，并在授权范围内决定如何调整。

若变化突破已经批准的预算或重大客户承诺，就应提交上一级有权决策的组织。

集成组合管理团队（IPMT）承担产品投资组合和重大阶段商业决策。

它需要判断的是，在新的条件下，这项产品投资是否还值得继续，是否需要改变资源投入和经营预期。

授权要落实到事项，不能只写“全面负责”。

可以逐项说明：谁能调整项目内的工作顺序，什么范围的费用可以直接批准，改变产品范围需要哪些专业确认，出现什么偏差必须升级。

决定之后，也要留下依据和复核条件。

同时，项目授权不能覆盖掉专业底线。

质量、安全及必要的内控要求，仍应按公司制度执行。

团队拥有更强的协调能力，不意味着可以用上市日期替代验证结论。

这也是决策均衡的意义。

各专业把自己的判断摆出来，能够让团队看见单一视角忽略的代价；

有分歧时依授权作决定，而非每个事项都无限期等待全员一致。

并行开发，把哪些工作提前了

并行不意味着所有工作在同一天启动。

在外观方案尚可修改时，让制造参与评估，能够提前发现喷涂和装配的限制；

采购此时核查供应能力，能够避免团队等图纸冻结后才知道关键工艺无人承接。

这样的参与，未必立刻产出正式工装，却可以决定下一步该先验证什么。

比如，团队先制作样件，验证表面处理和装配效果。

若结果不理想，还能在投入模具前比较替代方案。

等到高风险条件有了足够证据，再推进成本更高的准备工作，能够减少后期大范围改动。

技术验证过程中，商业判断也要同步更新。

某种工艺能够达到目标，但良率不理想，报价随之提高。

团队就需要重新检查，这项外观提升是否仍值得投入，还是应该调整方案或目标客户。

产品做成什么，与投入是否划算，需要一起管理。

因此，PDT既要管理产品包，也要维护相应的商业计划。

功能、成本或供货条件发生变化时，不能只更新技术文件，让经营测算仍停留在最初的假设上。

并行能够减少迟到的信息和重复返工，但不能消除必要试验与供应周期。

评估效果时，应当沿关键路径看总历时，同时检查质量和成本，不能把几个部门节省的天数简单相加。

资源和考核，会决定团队的真实优先级

一位关键工程师同时参加两个项目，两个项目都要求本周完成验证。

即便他认同两个产品目标，也不能把同一段时间使用两次。

此时需要公司级的优先级判断。

职能经理提供真实的人员能力和可用时间，项目说明延期后果，再由获得授权的资源协调或投资管理机制作出取舍。

让两位PDT经理私下争抢，最终得到的往往是反复改变的承诺。

团队成立时，可以把关键资源的投入时段和交付任务说清楚。

确需调整时，谁批准、谁评估对其他任务的影响，也应有明确规则。

职能部门仍然承担专业标准、人才培养和资源能力建设。

项目可以提出人员需求和交付评价，但不宜为了眼前进度耗尽专业队伍的长期能力。

绩效评价同样需要双向配合。

采购人员提前发现供应风险，建议采用单价略高但更适合的方案，如果最终只按采购降价考核，他就有理由回避这类建议。

项目评价可以关注承诺兑现、跨专业问题解决和关键交付；

职能评价保留专业质量、知识积累及人才培养。

具体权重应结合岗位和实际投入确定，不能套用一个比例解决所有角色的矛盾。

从一个难决定的事项开始试点

不必先把所有项目都改成重量级团队。

可以选一个跨专业依赖明显的产品，先明确目标范围、核心角色和资源承诺，再挑几项正在拖延的决定验证机制。

例如，控制终端的外壳是否更换工艺。

会前把客户要求、样件结果、供应报价和上市影响放到一起，写出可以比较的方案。

会上确认谁有权决定，哪些条件尚未满足；

会后记录选择、责任人和复核时间。

过一段时间，检查这项决定是否减少了等待，后续是否因为遗漏条件再次推翻。

再把同类事项的等待时间、返工投入和质量结果放在一起比较，才知道改善来自哪里。

产品上市以后，版本维护、备件和遗留问题也需要明确承接。

开发团队不能在完成发布后悄然退出，让服务人员重新猜测当时的设计取舍。

下一次试产评审，制造拿出样件结果，采购确认工艺与供货条件，质量代表指出尚未关闭的验证项。

PDT经理据此确定哪些工作继续、哪些必须等待，超出授权的事项带着方案提交决策。

每个人离开会议时，都知道自己承诺什么、何时交付，以及出现什么情况需要重新做决定。