导入 IPD 流程为何要从僵化开始？本文把视角从流程执行转向权力关系：纸面规则与实际规则并行，跨职能团队担结果，但职能部门仍保留实际控制权，决定走完了却未必生效——僵化的真正用意，是让新决策关系在旧组织里先取得效力。

研究和实践 IPD 这么多年，有一句话，我一直没有完全想明白：

先僵化、后优化、再固化。

先学会，再改进，最后把有效的做法留下来。

这层道理本身并不难理解，可我始终有个疑问：

既然引入 IPD 是为了更好地响应市场、提高产品开发效率，为什么起点偏偏叫「僵化」？

如果已经看到了不合理的地方，又为什么不能先改？

仅仅用「还没学会走，就不要想着跑」来解释，总觉得少了一层。

前端时间看到一篇关于权力本质的文章，我才把这个问题重新接了起来。

过去我的注意力更多放在流程如何执行，现在我开始看见它背后的另一件事：

一套新的决策关系，究竟怎样在旧组织里获得效力。

下面是我从这个角度，对「先僵化」的一次重新理解。

图1：纸面规则与实际规则并行，跨职能团队承担结果，职能部门仍保留实际控制权。

流程走完了，决定还没有生效

不妨先设想一个产品项目。

公司已经成立了 PDT，也就是跨职能的产品开发团队。

研发、市场、采购、制造等部门都有人参加，有项目计划，有评审会议，也有完整的流程文件。

只看组织图和交付件，你很难说它缺了什么。

现在，客户提出一项需求变更。

团队把市场收益、开发工作量、采购影响和上市时间放在一起讨论，决定先保住当前版本的交付，把新增功能放到下一版本。

从产品整体来看，这是一次有理由的取舍。

但会议结束以后，事情没有按这个决定往下走。

• 销售负责人认为客户不能得罪，要求工程师先做起来；
• 研发负责人发现另一项工作更急，把原先承诺给项目的人抽走；
• 采购代表虽同意了计划，却还要回去等部门负责人确认。

如果会上的同意，只代表「我个人理解了」，并不代表所承担的任务和资源承诺能够兑现，那么这场会议最多形成了一份建议。

签字再齐全，也不会自动改变会后谁有权重新排任务、抽人员、改优先级。

此时，再要求项目负责人加强沟通，当然也许能把这一次事情推过去。

他可以多解释几遍，争取一位领导支持，或者请熟悉的同事帮忙。

但下一次冲突出现，仍然需要重新寻找这些支持。

产品能否推进，依赖的是他这次协调成功了没有。

一项决定还要经过多少次没有写在流程里的批准？

有些批准并没有正式名称。

它表现为迟迟不给人、暂时不安排采购、需要再向领导汇报。没有人明确否决，事情却无法继续。

谁能够使一个已经形成的决定一直等待，谁就仍然保留着一部分实际控制权。

这样看，流程的确运行了，只是运行的是两套不同的规则。

• 纸面上，跨职能团队对产品负责；
• 实际工作中，关键取舍仍要分别得到职能部门的许可。

横向团队承担了结果，却没有获得与这个结果相匹配的行动空间。

如果把这种停滞全部归为执行力不足，接下来很容易做错事：

增加催办，补充表格，再安排一轮流程培训。

参与者可能把新规则记得更清楚了，但他们仍然不知道，当两套要求发生冲突时，究竟应该服从哪一套。

交给团队的，要是一份真正的授权

读到权力那篇文章时，打通我疑问的，正是这一层。

在这里讨论权力，不必把它想成某个人的威风。

把它放进一个产品项目，问题可以很具体：

谁可以决定需求取舍，谁可以承诺资源，已经承诺的资源能否被单方面撤回，出现分歧之后由谁裁决，以及这个决定会对参与者产生什么约束。

这些问题的答案，构成了流程能够生效的条件。

流程图可以把一次决策安排在某个节点，却不能仅靠画上一个方框，就让旧的审批关系自动退出。

所以，我现在理解的「先僵化」，在组织层面有一个关键任务：

通过有力的授权和保障，让原先分散在职能部门的部分产品决策权，进入跨职能的决策体系，并先按照这套分工运行起来。

不能一遇到具体争议，就允许所有人退回原来的部门关系里重新决定。

流程的执行纪律仍然重要，只是需要问清楚，纪律究竟在维护什么。它不能只维护表格填写完整，还应维护谁有权作决定、谁必须兑现承诺。

这份授权，也绝不意味着把所有权力交给 PDT 负责人。

图2：IPMT 与 PDT 的双向承诺，管理层承诺支持，团队承诺交付，缺一不可。

投资管理团队与开发团队的关系：

• IPMT 负责相应的业务计划、机会评估和产品组合，委托 PDT 提出方案、执行获批的开发工作；
• 双方通过契约，确认 PDT 对产品的承诺，也确认 IPMT 将提供的支持。

这里很值得注意的是，承诺有两个方向。

团队承诺把事情做成，管理层也承诺给予支持。

如果只留下前半句，把后半句理解为「你自己去协调」，责任就很容易被下放，资源却没有随之安排。

放回前面的假设项目，至少需要说清楚：

• 在已经批准的产品目标、预算和计划范围内，哪些取舍由团队完成；
• 什么样的变化需要升级到投资决策层；
• 部门提供哪些人、投入多长时间；
• 如果遇到新的优先事项，按什么机制重新分配。

这和给团队一句「充分授权」很不一样。

销售可以继续带来客户信息，也应该对商机判断负责，但不能凭一项客户承诺，就在团队之外悄悄改掉产品计划。

研发部门仍然需要管理人员能力、技术积累和资源供给，但已承诺的项目投入发生变化时，应让影响进入共同的决策。

专业上的把关同样不能被取消。

一个技术风险能不能接受，一项质量要求能不能放松，不能因为项目负责人着急上市，就一概服从他的判断。

哪些属于不可越过的底线，哪些可以在评估之后作商业取舍，应事先明确，并保留对应的专业意见和升级渠道。

跨职能团队的意义，是让不同专业的判断能够进入同一次产品取舍。

把职能部门压到只剩领任务，或者把团队负责人变成另一个什么都管的领导，都会丢掉这种集成的价值。

团队内部也需要决策规则。

哪些事项由负责人听取意见后决定，哪些需要指定角色共同确认，分歧超过什么范围就必须升级，都应事先约定。

跨职能并不意味着每件事都要等所有人满意。

如果谁都有否决权，却没有人需要在明确时限内作出取舍，部门间的等待只是被搬进了团队内部。

还有一个容易被忽略的地方：人坐进了团队，评价他的规则有没有变化？

假如一个成员按产品计划完成了重要工作，却因为没有优先响应部门临时任务而影响绩效，那么下一次，他会怎样安排自己的时间？

不需要推测他的觉悟，只要看看两种选择分别承担什么后果，就能理解其中的压力。

因此，调整的还包括项目表现如何进入绩效评价、部门如何因能力支撑而获得认可，以及资源承诺未能兑现时由谁解释原因。

一个人收到的任务、可以使用的资源和最终被评价的依据，需要尽量对得上。

这里确实发生了权力重分配，也必然改变一些人的工作方式。

但职能负责人的价值并没有因此消失。

相反，稳定提供合适的人、解决共性技术问题、培养下一批骨干，需要长期投入。

如果这些工作没有被看见，只要求他们放弃项目控制权，却仍用旧指标考核他们，阻力就不能简单归为不愿配合。

第一场分歧，才开始检验「先僵化」

新规则写清楚以后，最难的部分才刚刚出现。

继续看那个假设项目。

销售希望马上增加功能，PDT 认为这会打乱已批准的计划，双方把分歧提到了更高层。此时，领导可能很容易作出一个看似务实的决定：

这一次比较特殊，先答应客户，后面的流程再补。

单看这件事，领导也许有充分的业务理由。

问题在于，这个决定是通过已约定的机制调整计划，还是完全绕过了那套机制。

图3：分歧时刻的两种处理路径

是否启用约定机制，决定了新规则能否真正生效。

如果每次遇到强势的部门、重要的客户或紧急的任务，都可以重新寻找一位领导口头批准，那么团队很快就能学会一种做法：

在正式会议里表达意见，在会议之外寻找最终决定。

所谓授权，也就只有在没有分歧的时候才有效。

而没有分歧的时候，恰恰最不需要检验权力归属。

我理解的「强力」，主要应该用在这里。

• 最高层需要明确，新体系已经获得授权的事情，不能因为某位负责人不习惯就被架空；
• 部门之间谈不拢的问题，也不能长期留给项目负责人靠私人关系解决。

这甚至意味着，领导需要先约束自己。

过去，直接叫来一个熟悉的工程师安排任务，可能很方便。

新机制建立以后，这个习惯同样要接受检查：这项安排影响了哪个已承诺的项目，谁评估代价，谁有权重新确定优先级？

如果只有普通成员需要遵守流程，职能负责人和更高层可以随时绕过它，组织就会收到两个相反的信号。

文件说明哪套规则应当有效，领导的日常行为则说明，哪套规则在关键时刻更有用。

但维护新规则，不等于每一次都必须支持 PDT 的意见。

团队可能判断错误，客户的需求也可能确实发生了重大变化。

授权要求的是让有权作决定的人，基于充分信息承担决定，而不是让某个角色永远赢。

回到需求变更，管理层可以决定接受新需求，同时批准相应的资源和计划变化，记录其对成本与交付的影响。

这样做改变了原方案，却没有撤销决策机制。

相反，如果只要求团队既满足新增需求、又保持所有原承诺不变，冲突就只是被压回了执行端。

同样，提出异议也不该被直接理解成维护部门利益。

制造负责人指出方案难以批量生产，财务指出投入已经超出批准范围，研发指出关键人员承诺发生重叠，这些信息可能正是团队需要的。

组织需要限制的是绕过共同决策、拒不兑现已经确认的安排，同时给专业异议保留说清楚的机会。否则，「先僵化」会逐渐变成不能报告坏消息，问题暂时安静下来，却要在后面付出更大的代价。

从这个角度看，强力保障与充分讨论可以同时存在。

决定之前把不同立场和实际约束摆出来，决定之后在授权范围内执行；

新事实出现时，按约定的方式申请变更。

参与者不必一直同意彼此，但要知道意见分歧在哪里结束，下一步行动从哪里开始。

这也不要求企业一夜之间完成所有权力调整。

完全可以先选择一条产品线、一个代表性项目，明确试点范围，把需要的职责、支持和决策规则配齐。

范围可以小，范围内的承诺却需要真实，不能让试点团队拿着一张名义授权书，逐个部门讨要配合。

执行能力也要跟上。团队负责人是否能作商业判断，成员是否理解自己的代表职责，争议上升后有没有人及时处理，都会影响试点质量。赋权之后缺少这些支持，出现的混乱就不能全部用「再坚持一下」来解释。

所以，这里的先后是一种运行前提，不是机械的日程顺序。

授权设计、流程设计和能力准备可以同步推进。需要先站住的是：进入试运行后，组织承认哪一套决定，并愿意承担让它生效的成本。

有了真实运行，才谈得上优化

到这里，我才觉得「后优化」有了一个具体的对象。

如果新团队从未获得完整授权，每次决策都被会外的部门意见重新改写，那么试运行中观察到的延误，究竟来自新流程，还是来自旧权力关系？

两者混在一起，就很难评价这套机制是否有效。

比如，一项变更等了很久。

往前追，可能发现评审频率确实不适合当前业务，也可能发现材料一直没有齐备，还可能发现团队已经作了决定，只是资源迟迟没有到位。

它们看起来都是「流程慢」，需要改的地方却不相同。

在新规则下相对完整地运行一段时间，价值就在于把这些差别显露出来。

记录不该只有会议开了几次、文件交了几份，还应包括决定什么时候形成、什么时候开始执行，中间在哪里等待，等待又由什么造成。

• 如果权限划得太窄，低风险事项也要层层上报，可以在有证据的基础上扩大团队授权；
• 如果信息总在评审时才暴露，可以改变前置准备和参与方式；
• 如果同一项判断被两个环节重复完成，也可以调整评审分工。

图4：授权设计与观察点的关系——左边的规则越清晰，右边的数据才能告诉你要改什么。

这些改进不只是表格增减，决策权的边界本身也可以成为优化对象。

重要的是，调整要通过明确的程序形成新的共同规则。

某个部门不愿放弃原来的审批，便以「符合实际」为理由把它加回来，并不能自动算作优化。

同一家公司里的产品，也未必适合完全相同的活动密度。

新平台开发与成熟产品的小改动，风险、依赖和不确定性都不同。

把裁剪条件讲清楚，可以让流程更贴合工作；

让每位负责人临时判断自己可以跳过什么，则会重新制造不一致。

理解权力这一层，并不会使我轻视流程设计。恰恰相反，输入条件、决策依据、责任角色和变更路径，都要写得足够清楚。否则，授权虽然给了，参与者仍然只能猜测边界，在每个具体问题上重新谈判。

授权解决的是能不能作决定，好的流程还要帮助人把决定作对、作得及时。

这两件事缺了任何一件，团队都难以持续承担产品结果。

前者需要组织承认，后者需要信息、专业能力和运行反馈。

再往后，才是固化。

如果一种新的安排，只有在变革负责人每天盯着、最高层不断提醒的情况下才能维持，那它还没有成为稳定的组织能力。

换一位项目负责人、调走一位关键骨干，原来的做法就回来，说明经验仍然留在人身上。

固化需要把经过验证的安排落实到岗位职责、资源计划、绩效评价和实际工作系统里。

谁负责，谁参与，谁作决定，什么时候需要升级，都应该有可以查到、可以交接的依据，而不只存在于某几个人之间的默契。

系统配置也要跟着检查。文件已经取消的部门审批，如果在工作流里仍然是必经节点，成员最终还是要回去求签字。

反过来，团队确实需要承担的决定，如果没有相应的权限和记录位置，也很容易被口头协调取代。

连修改规则这件事，也应当有明确的责任人。

什么时候复盘，依据什么调整，新的版本怎样通知相关角色，原来的要求如何退出，都需要有人维护。固化以后仍然可以改，只是不用每遇到一个新情况，就让整套组织关系重新回到讨价还价的起点。

现在再看「先僵化」，我的疑问落到了一个更具体的地方：

当新的跨职能团队作出一个不符合某个部门意愿、却在自身授权范围内的决定时，组织是否承认它，并让它真正发生。

只有这个问题得到了回答，后面的优化，才是在改进一套已经运行起来的机制。