学了再多IPD依然推不动？十年IPD咨询复盘

IPD不只是一套研发流程，它本质上是围绕产品商业成功，重构组织权责与资源调度的一套机制。这一点，我们在过往大量的变革咨询实践里感受很深。

做IPD咨询以来，我见过很多初创期小而美的企业，等发展到一定规模后，管理者有了更大的野心，项目越做越多，研发团队的规模也越来越大。麻烦也随之而来，几个部门的人扯头皮抢资源，动辄数月研发出来的产品也达不到市场预期，这些都很常见。

单纯靠加强项目管理或加大研发投入，其实很难从根本上解决问题。
前些年我服务过一家制造业客户。这家企业早期项目不多，但核心部门的负责人个人能力很强，产品迭代速度也快，所以整体的市场收益还算不错。

后来企业逐渐上了规模，随着订单增多、产品线增加，问题就慢慢暴露了出来。

在实际研发中，他们的项目团队成员都归各自的职能部门管，热门项目大家都争着抢着要做，利润薄点儿的项目人手却长期不足。而且不少项目的研发投入非常大，推向市场后的收益却远达不到预期。

所以当高管团队接触到IPD后，第一反应是先组织内部的负责人研读资料，尝试自行梳理流程。前前后后推进了大半年，局面依旧没有改善。内部推行碰壁后，高管才意识到，也许光内部学习IPD的理论框架还不够。

我到这家企业现场摸排情况后，先帮客户梳理了一套新的组织架构和权责机制，将原有的项目资源分配规则做了重构。后续也是持续协助客户落地完善整套IPD体系。

复盘来看，这家企业存在的问题，很多企业也都遇到过。

第一个问题是认为靠理论IPD很容易落地。

我相信抱有这种想法的企业绝对不是个例。早年华为在推进IPD变革的时候，也走过这样一段弯路。当时华为内部的团队拿到IBM以及PACE相关的材料，组织内部骨干闭门自学，在理论层面大致理解了IPD的框架，但真正动手落地的时候，却发现推进效果远达不到预期。

在经历过后，大家才慢慢意识到，单纯依靠书本自学很难完成变革，就像通过看书学游泳，只看懂动作要领，并不代表你下水后就能顺畅地游起来。

第二个是不打破组织惯性。

要知道，一个组织里长期运行形成的惯性很难依靠内部力量打破，部门之间盘根错节的利益和固有习惯，会形成很强的内部阻力。所以IPD变革真正的难点，更多在于组织层面的调整。
很多企业做流程变革时，习惯顺着现有组织架构去裁剪流程，流程跑不通就不断打补丁，最后流程就变成了一些面子功夫。真正的变革逻辑应该反过来，需要根据业务与流程的要求倒推组织变革，打破组织惯性，才能有更大的活力与可能。

第三个是团队离客户太远。

设计产品的产品经理不直接对接一线客户，缺少市场体感，这就导致最初的产品构想一般都是拍脑袋拍出来的。在公司岗位分工中，原本岗位细化是为了实现更专业、更垂直的分工，结果演变成各管门前雪。

这样的结果就是产品经理只埋头雕琢产品功能，并不知道如何获得商业成功，也不知道产品要如何吸引客户。脱离市场的产品，再好的技术设计，最后也很难转化成切实的商业价值。

第四个是过度放权。

自古封疆大吏，最容易拥权自重。放到企业里也是同理，当年那些和董事长一起打江山的元老，现在也都手握各个职能部门的大权。

但过度放权到职能部门，很容易滋生个人英雄主义，各个职能团队只盯着自己部门的指标，反而很少关注产品整体层面的商业价值。另外，资源被部门把持，公司层面想要做跨项目、跨产品线的全局调度变得十分困难。

想要解决这个问题，就要把过去职能主导研发的模式，调整成职能部门与项目团队并行的机制。
职能部门，也就是原有的各职能专业部门，主要负责人员的培养、技术沉淀与专业能力建设，持续向产品线输送合格的人才。这部分的考核重心都应该放在人员资源利用率和专业能力的建设上。而各个项目团队是创造价值的关键，就应该掌握资源的使用权与项目指挥权，对产品的商业成功负责。

这样职能部门不再是资源的垄断者，项目团队也不再是处于有责无权的状态。团队在此基础上再推行IPD的话，就会更顺畅些。