开头先说个真实场景。前两年我在一家做智能硬件的公司帮他们推行新版IPD流程流程文件改到第5版了培训也办了好几场台上的人讲得眉飞色舞台下的人听得连连点头。结果第一个正式项目刚启动马上就乱了概念阶段的决策材料拖了两周才凑齐计划阶段各个部门各写各的前后对不上评审会上吵了两个小时也没吵出结论。项目负责人跟我说了一句话刘工流程文件大家都看了但真到干活的时候谁也不知道第一步该找谁。我当时就意识到问题不在流程文件写得不够细也不在大家不认真而是缺少一次真正的IPD流程预演也就是标题里提到的那个词——Dry Run。很多人第一次看到IPD5.1_Dry_Run这个说法会有点懵5.1是流程的版本号Dry Run翻译过来就是干跑、彩排、实弹演习式的试运行。这套东西在流程变革的圈子里不算新鲜但真正把它用到位、用出价值的团队并不多。这篇文章我就拿IPD5.1版本里的概念阶段和计划阶段当例子把Dry Run到底怎么设计、怎么组织、最容易踩哪些坑一次讲透。1. IPD5.1_Dry_Run先把这个名字拆开说清楚1.1 IPD的全景地图概念和计划阶段处在什么位置IPD的全称是Integrated Product Development集成产品开发内核其实不是开发两个字而是投资。它把产品开发当成一笔需要算清楚的投资每个关键节点都要回答一个问题这笔钱还值不值得继续投下去。标准IPD流程把产品从想法到退市切成六个阶段概念阶段、计划阶段、开发阶段、验证阶段、发布阶段、生命周期管理阶段。每个阶段之间有一个非常重要的关卡叫DCPDecision Check Point决策评审点。阶段和阶段之间不是时间上的先后关系而是决策上的层层递进。概念阶段的出口叫概念决策评审CDCP过了这个评审意味着公司愿意正式立项成立团队往里面投第一笔资源。计划阶段的出口叫计划决策评审PDCP过了这个评审等于公司把资源、预算、人力的承诺全部落实下来产品正式进入开发。你可以把概念阶段理解成要不要做计划阶段理解成具体怎么做、花多少钱做、谁来做两个阶段合在一起决定了一个产品80%的命运。IPD5.1这个数字本身没有太多玄机它就是流程文件的版本号。但版本号到5.1通常说明这套流程已经在实际项目中迭代过多次经历过大量的模板修订、角色梳理和接口定义不像1.0版本那样只有原则没有操作细节。换句话说到了5.1这个成熟度流程本身的问题已经比较少了真正的问题出在人和组织身上这也是为什么需要Dry Run来兜底。1.2 为什么Dry Run最该聚焦在概念和计划阶段Dry Run的模式其实可以套在任何一个IPD阶段上但我个人强烈建议如果资源有限优先做概念和计划阶段的预演。原因是这两个阶段有一个共同特征跨部门协作密度极高。开发阶段和验证阶段的流程逻辑相对线性研发、测试、制造各干各的接口清楚。而概念和计划阶段所有部门几乎是在同一张桌子上同时工作——市场部要出需求分析研发要出技术方案财务要出成本模型采购要出供应商策略制造要出可制造性评估。这些活动对标准IPD的跨部门团队要求很高需要把每个角色的输入输出时间点、依赖关系、模板格式全部对齐。很多团队在流程文件里写得清清楚楚市场部在第2周输出需求文档研发部在第3周完成技术可行性。但真到项目里市场部的需求文档格式是10年前的研发部看不懂研发部的技术方案又用了一堆内部术语财务没法从中提取成本数据。这些问题只有在真正把流程跑一遍的时候才会暴露。Dry Run干的事情就是在正式项目启动前用一个模拟的假项目把这些断点提前撞出来让团队在低风险环境里完成磨合。1.3 Dry Run和培训、试点的本质区别不少公司搞过IPD培训也搞过试点项目然后声称自己做过Dry Run了。这里我必须较个真三者的目的完全不一样。形式核心目的产出物典型问题培训让学员理解流程概念听课记录、考试分数听懂和会做是两回事试点项目在真实项目中验证流程一个完成的产品项目出问题时不知道是流程问题还是执行问题Dry Run在模拟场景中逼近真实操作偏差清单、模板修订、角色调整容易被做成情景剧而没有真实压力培训解决的是知不知道的问题试点解决的是能不能用的问题Dry Run解决的是用起来顺不顺的问题。三者可以搭配使用但如果公司只做了前两步那第一步最容易被跳过去。我见过太多企业IPD推行失败不是败在流程设计而是败在第一个正式项目被当成了试点发现流程不好用后又退回到老路上。与其这样不如先用Dry Run把流程里的雷排干净。2. 概念阶段是一次商业论证不是开几次会2.1 概念阶段的输入、输出和评价标准概念阶段的起点通常是一个模糊的市场机会。可能来自产品线的年度规划可能来自客户痛点的深度访谈也可能来自技术部门预研出来的新能力。这些输入汇聚在一起概念团队要回答一个问题我们要不要为这个机会正式立项。概念阶段的标准输入包括三块战略规划层面的产品路标、从市场收集回来的原始需求、以及技术预研的可行性结论。而概念阶段的核心输出只有一件就是项目章程Charter加上一份支撑决策的概念DCP评审材料。Charter这个东西很多公司理解为立项申请报告其实它的分量要重得多。一份合格的Charter至少包含六块内容产品定义与目标客户、目标市场容量与竞争格局、产品包需求清单、候选概念方案与技术路线、初步的业务计划含财务测算、以及风险与依赖分析。写Charter的过程本质上就是把市场机会翻译成商业命题的过程。评价一份Charter做得好不好IPD里有一套通用的判断框架我习惯把它简化成四个问题差异化这个产品跟竞争对手比凭什么能赢市场规模这个市场值得投入吗天花板有多高可行性以我们现有的技术和资源做得到吗时机现在不做会怎样明年做还来得及吗这四个问题任何一个回答不清楚概念DCP都不应该过关。但在实操中很多团队把概念阶段压缩成销售部拉个需求清单、研发部写个技术方案、领导开会拍个板这不叫概念阶段叫拍脑袋阶段。2.2 概念阶段的四步主流程IPD5.1的概念阶段主流程可以拆成四个连续的活动每一步环环相扣。第一步市场与需求分析。把散落的需求收敛成结构化的产品包需求常用工具是**$APPEALS**它拆解了客户购买产品的八个要素价格、可获得性、包装、性能、易用性、保证、生命周期成本、社会接受度。很多团队用$APPEALS只是套个模板把格子填满就算完事这是典型的错误用法。正确的用法是每个要素都要有客户访谈数据支撑并且要和至少三家主要竞争对手做对比打分。只有这样后面写差异化定位的时候才有依据不是编故事。第二步初始业务计划。这一步的产出不只是一张财务预测表而是一份完整的商业逻辑。市场细分、目标客户画像、渠道策略、定价策略、竞争应对策略、财务测算、风险识别缺一不可。这里我特别想说一句财务测算不要只做一张表要有基准场景、悲观场景、乐观场景三套。IPMT在评审的时候最忌讳看到单一数字因为单一数字没法判断测算的置信度。第三步概念与技术方案。研发团队在需求明确的基础上提出候选的产品概念和技术路线。注意IPD强调候选而不是唯一——概念阶段应该有至少两个可选方案并通过技术评审TR进行筛选最后选择一个收敛进入Charter。第四步概念DCP。汇总前面的所有材料提交IPMT决策。DCP不是会签每个成员要在会前完成材料预审会上基于评估表逐项打分最后形成明确的同意、有条件同意或否决的结论。有条件同意要写明条件项和验证时间。2.3 概念阶段在Dry Run中被揪出的典型问题概念阶段的Dry Run我做过不止一次每次跑完都会发现一些流程文件里完全看不出来的问题。第一个常见问题$APPEALS分析成了市场部一个人的作业。需求分析本该是市场、研发、服务、销售联合完成的事但一进入实际操作市场部往往把访谈数据一贴草草填完表格就发给其他部门确认其他部门回一句没意见。Dry Run中会暴露一个很尴尬的场景研发看完需求分析后问这里面的性能指标我们目前只能做到一半你们知道吗市场部一脸错愕——没有人提前跟他们对过技术边界。解决的办法是流程文件里明确需求分析必须经过一个关键需求联合评审会市场部和研发部共同签字确认。第二个常见问题业务计划里的财务测算是拍脑袋的。售价、销量、开发费用、毛利率几个关键数字完全对不上。比如销量规划做了50万台一年但市场容量分析里整个细分市场的容量只有30万台这就是明显的逻辑硬伤。Dry Run的价值就在这里预演过程中独立的观察员会专门核对数据之间的逻辑链条帮你把这种低级错误揪出来。第三个常见问题概念DCP的评审材料在预演中第一次被做成能看的版本。很多公司的概念DCP材料此前根本没有模板各写各的汇报风格千奇百怪。Dry Run会把所有材料格式统一并且明确每一页PPT要回答什么问题。这个工作看着琐碎实际上是最能提升决策效率的改变。IPMT成员普遍很忙整齐划一的评审材料能帮他们快速找到关键信息。3. 计划阶段把做什么翻译成怎么做3.1 计划阶段的分工与主流程概念DCP通过后公司会正式任命**PDTProduct Development Team产品开发团队的核心成员由PDT经理LPDT**牵头把产品带入计划阶段。很多公司对计划阶段有个误解以为计划阶段就是研发画架构、写排期。这完全不对。计划阶段的目标是把概念阶段确定的业务计划细化成一份端到端的可执行计划——不只是研发计划而是包括市场计划、采购计划、制造计划、服务计划、质量计划、财务计划在内的完整体系。每个部门都要回答接下来的开发阶段我要做什么、花多少钱、占用多少人、什么时候交付什么。计划阶段的主流程从Plan Kickoff计划启动会开始经过需求细化、系统设计、各领域计划编制、集成与评审最后到计划DCP收口。这条链路看着简单实际是IPD操作中最容易卡壳的一段。原因在于各个领域计划之间的依赖关系极其复杂采购计划依赖研发的BOM清单制造计划依赖采购的物料交付周期服务计划依赖产品的安装部署设计。任何一个环节延迟整个计划的齐套性就完蛋。3.2 端到端计划的五大组成部分一份合格的计划阶段产出我用五大件来概括。第一件进度计划。这是最基础的部分核心是WBS工作分解结构。WBS要分解到什么粒度一般情况下关键路径上的任务至少细化到两周以内关键里程碑要明确到天。做WBS的常见误区是研发自己闷头写写完发给其他部门同步。正确的做法是从上到下游走一遍让每个任务的负责人自己认领并承诺完成时间这样才能得到有承诺度的排期。第二件资源与费用计划。这里讲的资源不只是钱还包括研发人力、测试设备、实验室资源、市场推广预算。IPD强调资源承诺也就是说每个部门的资源计划必须由该部门的老大签字承诺。在Dry Run预演中我最常看到的问题是资源计划列出了需求但没有任何人对这些需求做过确认连资源部门自己都不知道这个项目要用他们的人。第三件质量计划。包括质量目标、关键质量指标、技术评审点TR安排、测试策略。质量计划不是QA一个部门的事研发要参与制定验证策略制造要参与制定生产过程的质量控制点。第四件采购与供应计划。梳理物料清单、识别长周期物料、确定供应商定点策略、评估单一供应风险。很多硬件项目在开发阶段走得顺最后却死在物料供应上就是因为计划阶段没有把长周期物料的采购风险识别出来。第五件制造与服务准备计划。包括可制造性分析、产线规划、工装夹具开发、售后服务方案、备件策略。这一块最容易被忽略但一旦产品进入验证阶段制造和服务没有准备好整个项目的上市节奏都会被拖垮。3.3 计划DCP评审会的最后一关计划DCP通过后项目就拿到了开发阶段的通行证公司上下会按照计划承诺的资源进行投入。所以计划DCP的评审严格程度应该远超概念DCP。评审材料在内容上比概念DCP更细化在逻辑上要保持一致。有一个检查方法我给不少团队用过把两份材料放在一起逐项对比——市场容量的数字有没有变目标客户的画像有没有变开发周期从概念到计划是压缩了还是拉长了成本结构有没有重大偏离每一项变化都必须有明确的解释。如果概念阶段说开发周期是10个月到了计划阶段变成14个月但IPMT没有收到任何预警那说明两个阶段之间的信息传递是断的。计划DCP的结论同样分三种通过、有条件通过、不通过。有条件通过时必须把条件写清楚谁来跟进、什么时候完成验证、验证结果向谁汇报。有条件通过不等于勉强放行很多失控的项目都是从有条件通过开始一步一步滑向深渊的。4. 一次完整的Dry Run怎么组织七个步骤4.1 第零步确定预演的目标和场景任何一次Dry Run动手之前先要把目标和场景定义清楚。目标决定了预演的深度和广度场景决定了预演的真实感。Dry Run的目标通常有三种一是验证流程设计本身的合理性适合刚完成流程大版本改版的场景二是帮助新的PDT团队快速进入角色适合第一次组建的团队三是检验流程文件和配套模板的可操作性适合流程已经运行但问题较多的阶段。一次Dry Run可以同时覆盖多个目标但重点不要超过一个否则预演会变成一场没有焦点的大杂烩。场景选择上我的经验是选一个中等复杂度、带点刺的模拟项目而不是套用某个已经成功的真实项目。用真实项目做场景有一个陷阱——大家会不自觉回忆起当时是怎么干的甚至反驳我们上次不是这么处理的。更推荐的方式是虚构一个项目但给它注入真实的约束比如供应链成本比行业平均高20%、某个核心芯片的供应商产能有限、目标市场的准入认证周期比预想的长。这些约束会在预演过程中逼着团队去执行真正的分析方法而不是走过场。4.2 组建预演小组并分配角色Dry Run的参与人员不能只是流程编写组的成员也不能只是管理层。我的建议是让未来真正要在这个流程里干活的人来当演员——他们是第一批使用者也是第一批检验者。标准角色清单如下预演总指挥对整个Dry Run过程负责通常由项目管理办公室PMO负责人或IPD流程Owner担任。预演小组模拟一个完整PDT包括PDT经理、市场代表、研发代表、采购代表、制造代表、服务代表、财务代表、质量代表。每个角色最好有真实对应部门的人来扮演。IPMT模拟委员由公司高层或资深业务负责人扮演负责在预演的DCP节点做决策。观察员这是最关键的配置。观察员不参与具体执行只记录流程操作中的问题、时间消耗、角色职责不清、模板不适用的环节。观察员要单独给出一份《偏差报告》不能由预演小组自己写自评报告否则容易文过饰非。4.3 按时间轴推演并记录偏差Dry Run不等于开会讨论它应该有明确的时间轴。以概念阶段加计划阶段的双阶段预演为例我通常安排5到6个工作日按以下节奏推进工作时间预演内容关键产出第1天上午预演启动会发布场景、讲解流程、明确纪律预演章程第1天至第2天按流程走完概念阶段产出Charter初稿$APPEALS分析、初始业务计划第3天上午模拟概念DCPIPMT表决记录第3天至第4天按流程走完计划阶段各领域编制计划五大计划文档第5天上午模拟计划DCPPDCP表决记录、条件清单第5天下午复盘会对比偏差记录、确认整改行动项偏差清单、整改计划推演过程中观察员要严格按偏差记录卡来跟踪问题。记录卡的字段包括偏差描述、所属流程活动、严重级别阻断/严重/一般、建议整改方式、责任人。这个记录卡直接决定了Dry Run之后流程改不改、怎么改所以必须在预演过程中实时记录不能靠事后回忆。4.4 产出物与复盘Dry Run结束后至少要有三份交付物第一份是偏差清单这是最核心的产出。清单要分类整理对应到具体的流程文件条款。比如WBS模板中缺少采购导入物料的检查项、概念DCP材料模板没有要求填写差异化对比表这些都是常见的典型项。第二份是模板修订记录。预演中用过的所有模板都要回收观察员会评估模板是否好用表格字段是否清晰填写负担是否合理。模板修订是所有流程改进中性价比最高的一个动作因为模板是流程落到操作层面的最后一步。第三份是行动项清单。每一条行动项要有明确的落实责任人和完成时限。我的经验是在一次Dry Run后至少需要2到4周的整改窗口期再安排一次规模较小的复验只验证整改项是否闭环不用把整个流程再从头跑一遍。5. Dry Run实战中的六个坑我踩过的都在这5.1 坑一场景设计得太顺预演变成了情景剧这是新手组织者最容易犯的错。为了让预演好看场景设计得无比完美客户需求清晰、技术方案成熟、供应链没有瓶颈、竞争对手反应迟缓。结果整个预演变成了按剧本念台词的情景剧大家其乐融融地过完了全程偏差清单上只留下了寥寥几行无关痛痒的格式修改建议。正确的做法是在场景里埋地雷比如定义背景时说明某主要竞品在两个月前发布了低价版本、某一核心物料存在独家供应风险、目标市场的认证机构近期提高了测试标准。这些地雷会逼着概念阶段的需求分析更谨慎逼着计划阶段的采购计划做双轨准备。这才是一次真正的压力和偏差试验。5.2 坑二重讨论轻产出会开完了东西没写完Dry Run过程中各组讨论很热烈方案对撞很精彩但一天下来该更新的模板文件一个都没动。这个问题我几乎每次都会遇到。原因在于参与者潜意识里还是把它当会议而不是工作。破解方法有两条一是每个阶段结束时必须交付可检查的文件——哪怕是手写的草稿上面要有决策日期、负责人签字二是每个半天的预演以产出物演示收尾各角色拿着写好的材料上讲台讲5分钟讲不清楚就算没有产出。这种交付压力一旦建立起来大家的投入度立刻不一样。5.3 坑三决策环节缺人DCP评审变成了临时救场第一次组织Dry Run时我邀请IPMT模拟委员时大家都答应了但真到概念DCP和计划DCP当天总有几个人临时有事缺席导致决策环节变成来了的几个人随便聊几句。这直接传递了一个错误信号流程里的决策是可以随意对待的。后来我做了两个调整第一把DCP模拟环节安排在预演流程的黄金时间而不是临近结束的疲劳时段第二提前一天单独给IPMT模拟委员发材料包明确要求他们会前完成预审会上要有质疑式提问。让高层参与者在预演中体验一次严格、专业的DCP评审他们才会在真实项目中用同样的标准要求团队。5.4 坑四只改模板不改职责问题换个马甲继续出现偏差清单里有一类高频问题——某流程活动没有人牵头、某输出物没有Owner。这类问题如果只通过调整模板来解决下次换个场景还会以别的形式冒出来。我经历过一次概念阶段的需求评审会流程文件上写由市场部组织但市场部认为需求必须由研发来提研发又觉得市场才是需求Owner两个部门互相推最后预演卡在环节切换处整整半天。后来我们改了流程文件的措辞明确市场部为需求评审会组织方研发部为技术可行性评估责任方两个角色不能由同一人兼任同时更新了RASIC矩阵才解决。所以每次Dry Run复盘除了改模板一定要同步检查角色职责矩阵看问题是不是出在职责边界上。5.5 坑五预演时间拖太长团队疲劳后动作变形有些团队把Dry Run当成一次全员大练兵一口气排了三天概念、三天计划中间还有各种专题讨论到后面两天大家的专注度明显下降观察员记录的偏差数量反而越到后来越少——不是没问题是大家懒得记了。Dry Run的紧凑感很重要。时间太短跑不完时间太长会失真。以概念加计划双阶段为例5个工作日是合理区间其中还应该适当留出晚上和周六不加班的时间让大家休息。要让参与者始终保持适度的紧张感最好的办法是把每个环节的产出时间卡死形成节奏感。5.6 坑六没有独立观察员所有问题都被内部消化最后这个坑是最隐蔽的。有些团队组织Dry Run时没有设置观察员依靠参与者自己反馈问题。结果就是所有被反馈上来的问题都是参与者觉得说出来很体面的问题真正的流程痛点、部门间冲突、模板难用到爆全都被内部消化掉了。独立观察员的价值在于他们没有角色包袱——不需要维护自己部门的形象不需要为自己的表现辩护。他们只对一件事负责记录问题。如果组织者有资源最好是让IPD推进办公室中不直接参与本次流程运行的同事来但当如果实在没有独立人手至少要把记录职责和参与职责分开不允许既参与预演又自己记录自己的问题。6. 一些关于后续迭代的体会IPD5.1的Dry Run做完之后团队通常会形成一个共识流程文件里的每一步只有真正跑起来才知道好不好用。这个认识本身就是最大的收获。但Dry Run不是一次性的流程是活的组织结构会调整市场环境会变化产品形态会演进每一轮流程版本更新后都值得再做一次聚焦的预演只是不必每次都从头到尾跑全量针对变更点做小Dry Run就够了。我个人还有一个习惯每次大版本的Dry Run结束后我会把偏差清单中的常见问题TOP10整理出来做成一张团队内部的一页纸贴在每个PDT经理的办公桌旁边。比如概念阶段最容易被挑战的四个财务数字问题、计划阶段最容易漏掉的三个接口交付物——这些从预演中提炼出来的实战教训往往比几百页的流程文件对项目的帮助更大。最后再分享一个小技巧如果你们公司是第一次做IPD流程的Dry Run我建议不要贪全先把概念阶段单独拿出来跑一次两周时间足够。跑完一轮再决定要不要扩大到计划阶段。把一次预演做得小而透远比做得大而浅有价值。 IPD5.1流程预演（Dry Run）实战指南：概念与计划阶段如何落地
开头先说个真实场景。前两年我在一家做智能硬件的公司帮他们推行新版IPD流程流程文件改到第5版了培训也办了好几场台上的人讲得眉飞色舞台下的人听得连连点头。结果第一个正式项目刚启动马上就乱了概念阶段的决策材料拖了两周才凑齐计划阶段各个部门各写各的前后对不上评审会上吵了两个小时也没吵出结论。项目负责人跟我说了一句话刘工流程文件大家都看了但真到干活的时候谁也不知道第一步该找谁。我当时就意识到问题不在流程文件写得不够细也不在大家不认真而是缺少一次真正的IPD流程预演也就是标题里提到的那个词——Dry Run。很多人第一次看到IPD5.1_Dry_Run这个说法会有点懵5.1是流程的版本号Dry Run翻译过来就是干跑、彩排、实弹演习式的试运行。这套东西在流程变革的圈子里不算新鲜但真正把它用到位、用出价值的团队并不多。这篇文章我就拿IPD5.1版本里的概念阶段和计划阶段当例子把Dry Run到底怎么设计、怎么组织、最容易踩哪些坑一次讲透。1. IPD5.1_Dry_Run先把这个名字拆开说清楚1.1 IPD的全景地图概念和计划阶段处在什么位置IPD的全称是Integrated Product Development集成产品开发内核其实不是开发两个字而是投资。它把产品开发当成一笔需要算清楚的投资每个关键节点都要回答一个问题这笔钱还值不值得继续投下去。标准IPD流程把产品从想法到退市切成六个阶段概念阶段、计划阶段、开发阶段、验证阶段、发布阶段、生命周期管理阶段。每个阶段之间有一个非常重要的关卡叫DCPDecision Check Point决策评审点。阶段和阶段之间不是时间上的先后关系而是决策上的层层递进。概念阶段的出口叫概念决策评审CDCP过了这个评审意味着公司愿意正式立项成立团队往里面投第一笔资源。计划阶段的出口叫计划决策评审PDCP过了这个评审等于公司把资源、预算、人力的承诺全部落实下来产品正式进入开发。你可以把概念阶段理解成要不要做计划阶段理解成具体怎么做、花多少钱做、谁来做两个阶段合在一起决定了一个产品80%的命运。IPD5.1这个数字本身没有太多玄机它就是流程文件的版本号。但版本号到5.1通常说明这套流程已经在实际项目中迭代过多次经历过大量的模板修订、角色梳理和接口定义不像1.0版本那样只有原则没有操作细节。换句话说到了5.1这个成熟度流程本身的问题已经比较少了真正的问题出在人和组织身上这也是为什么需要Dry Run来兜底。1.2 为什么Dry Run最该聚焦在概念和计划阶段Dry Run的模式其实可以套在任何一个IPD阶段上但我个人强烈建议如果资源有限优先做概念和计划阶段的预演。原因是这两个阶段有一个共同特征跨部门协作密度极高。开发阶段和验证阶段的流程逻辑相对线性研发、测试、制造各干各的接口清楚。而概念和计划阶段所有部门几乎是在同一张桌子上同时工作——市场部要出需求分析研发要出技术方案财务要出成本模型采购要出供应商策略制造要出可制造性评估。这些活动对标准IPD的跨部门团队要求很高需要把每个角色的输入输出时间点、依赖关系、模板格式全部对齐。很多团队在流程文件里写得清清楚楚市场部在第2周输出需求文档研发部在第3周完成技术可行性。但真到项目里市场部的需求文档格式是10年前的研发部看不懂研发部的技术方案又用了一堆内部术语财务没法从中提取成本数据。这些问题只有在真正把流程跑一遍的时候才会暴露。Dry Run干的事情就是在正式项目启动前用一个模拟的假项目把这些断点提前撞出来让团队在低风险环境里完成磨合。1.3 Dry Run和培训、试点的本质区别不少公司搞过IPD培训也搞过试点项目然后声称自己做过Dry Run了。这里我必须较个真三者的目的完全不一样。形式核心目的产出物典型问题培训让学员理解流程概念听课记录、考试分数听懂和会做是两回事试点项目在真实项目中验证流程一个完成的产品项目出问题时不知道是流程问题还是执行问题Dry Run在模拟场景中逼近真实操作偏差清单、模板修订、角色调整容易被做成情景剧而没有真实压力培训解决的是知不知道的问题试点解决的是能不能用的问题Dry Run解决的是用起来顺不顺的问题。三者可以搭配使用但如果公司只做了前两步那第一步最容易被跳过去。我见过太多企业IPD推行失败不是败在流程设计而是败在第一个正式项目被当成了试点发现流程不好用后又退回到老路上。与其这样不如先用Dry Run把流程里的雷排干净。2. 概念阶段是一次商业论证不是开几次会2.1 概念阶段的输入、输出和评价标准概念阶段的起点通常是一个模糊的市场机会。可能来自产品线的年度规划可能来自客户痛点的深度访谈也可能来自技术部门预研出来的新能力。这些输入汇聚在一起概念团队要回答一个问题我们要不要为这个机会正式立项。概念阶段的标准输入包括三块战略规划层面的产品路标、从市场收集回来的原始需求、以及技术预研的可行性结论。而概念阶段的核心输出只有一件就是项目章程Charter加上一份支撑决策的概念DCP评审材料。Charter这个东西很多公司理解为立项申请报告其实它的分量要重得多。一份合格的Charter至少包含六块内容产品定义与目标客户、目标市场容量与竞争格局、产品包需求清单、候选概念方案与技术路线、初步的业务计划含财务测算、以及风险与依赖分析。写Charter的过程本质上就是把市场机会翻译成商业命题的过程。评价一份Charter做得好不好IPD里有一套通用的判断框架我习惯把它简化成四个问题差异化这个产品跟竞争对手比凭什么能赢市场规模这个市场值得投入吗天花板有多高可行性以我们现有的技术和资源做得到吗时机现在不做会怎样明年做还来得及吗这四个问题任何一个回答不清楚概念DCP都不应该过关。但在实操中很多团队把概念阶段压缩成销售部拉个需求清单、研发部写个技术方案、领导开会拍个板这不叫概念阶段叫拍脑袋阶段。2.2 概念阶段的四步主流程IPD5.1的概念阶段主流程可以拆成四个连续的活动每一步环环相扣。第一步市场与需求分析。把散落的需求收敛成结构化的产品包需求常用工具是**$APPEALS**它拆解了客户购买产品的八个要素价格、可获得性、包装、性能、易用性、保证、生命周期成本、社会接受度。很多团队用$APPEALS只是套个模板把格子填满就算完事这是典型的错误用法。正确的用法是每个要素都要有客户访谈数据支撑并且要和至少三家主要竞争对手做对比打分。只有这样后面写差异化定位的时候才有依据不是编故事。第二步初始业务计划。这一步的产出不只是一张财务预测表而是一份完整的商业逻辑。市场细分、目标客户画像、渠道策略、定价策略、竞争应对策略、财务测算、风险识别缺一不可。这里我特别想说一句财务测算不要只做一张表要有基准场景、悲观场景、乐观场景三套。IPMT在评审的时候最忌讳看到单一数字因为单一数字没法判断测算的置信度。第三步概念与技术方案。研发团队在需求明确的基础上提出候选的产品概念和技术路线。注意IPD强调候选而不是唯一——概念阶段应该有至少两个可选方案并通过技术评审TR进行筛选最后选择一个收敛进入Charter。第四步概念DCP。汇总前面的所有材料提交IPMT决策。DCP不是会签每个成员要在会前完成材料预审会上基于评估表逐项打分最后形成明确的同意、有条件同意或否决的结论。有条件同意要写明条件项和验证时间。2.3 概念阶段在Dry Run中被揪出的典型问题概念阶段的Dry Run我做过不止一次每次跑完都会发现一些流程文件里完全看不出来的问题。第一个常见问题$APPEALS分析成了市场部一个人的作业。需求分析本该是市场、研发、服务、销售联合完成的事但一进入实际操作市场部往往把访谈数据一贴草草填完表格就发给其他部门确认其他部门回一句没意见。Dry Run中会暴露一个很尴尬的场景研发看完需求分析后问这里面的性能指标我们目前只能做到一半你们知道吗市场部一脸错愕——没有人提前跟他们对过技术边界。解决的办法是流程文件里明确需求分析必须经过一个关键需求联合评审会市场部和研发部共同签字确认。第二个常见问题业务计划里的财务测算是拍脑袋的。售价、销量、开发费用、毛利率几个关键数字完全对不上。比如销量规划做了50万台一年但市场容量分析里整个细分市场的容量只有30万台这就是明显的逻辑硬伤。Dry Run的价值就在这里预演过程中独立的观察员会专门核对数据之间的逻辑链条帮你把这种低级错误揪出来。第三个常见问题概念DCP的评审材料在预演中第一次被做成能看的版本。很多公司的概念DCP材料此前根本没有模板各写各的汇报风格千奇百怪。Dry Run会把所有材料格式统一并且明确每一页PPT要回答什么问题。这个工作看着琐碎实际上是最能提升决策效率的改变。IPMT成员普遍很忙整齐划一的评审材料能帮他们快速找到关键信息。3. 计划阶段把做什么翻译成怎么做3.1 计划阶段的分工与主流程概念DCP通过后公司会正式任命**PDTProduct Development Team产品开发团队的核心成员由PDT经理LPDT**牵头把产品带入计划阶段。很多公司对计划阶段有个误解以为计划阶段就是研发画架构、写排期。这完全不对。计划阶段的目标是把概念阶段确定的业务计划细化成一份端到端的可执行计划——不只是研发计划而是包括市场计划、采购计划、制造计划、服务计划、质量计划、财务计划在内的完整体系。每个部门都要回答接下来的开发阶段我要做什么、花多少钱、占用多少人、什么时候交付什么。计划阶段的主流程从Plan Kickoff计划启动会开始经过需求细化、系统设计、各领域计划编制、集成与评审最后到计划DCP收口。这条链路看着简单实际是IPD操作中最容易卡壳的一段。原因在于各个领域计划之间的依赖关系极其复杂采购计划依赖研发的BOM清单制造计划依赖采购的物料交付周期服务计划依赖产品的安装部署设计。任何一个环节延迟整个计划的齐套性就完蛋。3.2 端到端计划的五大组成部分一份合格的计划阶段产出我用五大件来概括。第一件进度计划。这是最基础的部分核心是WBS工作分解结构。WBS要分解到什么粒度一般情况下关键路径上的任务至少细化到两周以内关键里程碑要明确到天。做WBS的常见误区是研发自己闷头写写完发给其他部门同步。正确的做法是从上到下游走一遍让每个任务的负责人自己认领并承诺完成时间这样才能得到有承诺度的排期。第二件资源与费用计划。这里讲的资源不只是钱还包括研发人力、测试设备、实验室资源、市场推广预算。IPD强调资源承诺也就是说每个部门的资源计划必须由该部门的老大签字承诺。在Dry Run预演中我最常看到的问题是资源计划列出了需求但没有任何人对这些需求做过确认连资源部门自己都不知道这个项目要用他们的人。第三件质量计划。包括质量目标、关键质量指标、技术评审点TR安排、测试策略。质量计划不是QA一个部门的事研发要参与制定验证策略制造要参与制定生产过程的质量控制点。第四件采购与供应计划。梳理物料清单、识别长周期物料、确定供应商定点策略、评估单一供应风险。很多硬件项目在开发阶段走得顺最后却死在物料供应上就是因为计划阶段没有把长周期物料的采购风险识别出来。第五件制造与服务准备计划。包括可制造性分析、产线规划、工装夹具开发、售后服务方案、备件策略。这一块最容易被忽略但一旦产品进入验证阶段制造和服务没有准备好整个项目的上市节奏都会被拖垮。3.3 计划DCP评审会的最后一关计划DCP通过后项目就拿到了开发阶段的通行证公司上下会按照计划承诺的资源进行投入。所以计划DCP的评审严格程度应该远超概念DCP。评审材料在内容上比概念DCP更细化在逻辑上要保持一致。有一个检查方法我给不少团队用过把两份材料放在一起逐项对比——市场容量的数字有没有变目标客户的画像有没有变开发周期从概念到计划是压缩了还是拉长了成本结构有没有重大偏离每一项变化都必须有明确的解释。如果概念阶段说开发周期是10个月到了计划阶段变成14个月但IPMT没有收到任何预警那说明两个阶段之间的信息传递是断的。计划DCP的结论同样分三种通过、有条件通过、不通过。有条件通过时必须把条件写清楚谁来跟进、什么时候完成验证、验证结果向谁汇报。有条件通过不等于勉强放行很多失控的项目都是从有条件通过开始一步一步滑向深渊的。4. 一次完整的Dry Run怎么组织七个步骤4.1 第零步确定预演的目标和场景任何一次Dry Run动手之前先要把目标和场景定义清楚。目标决定了预演的深度和广度场景决定了预演的真实感。Dry Run的目标通常有三种一是验证流程设计本身的合理性适合刚完成流程大版本改版的场景二是帮助新的PDT团队快速进入角色适合第一次组建的团队三是检验流程文件和配套模板的可操作性适合流程已经运行但问题较多的阶段。一次Dry Run可以同时覆盖多个目标但重点不要超过一个否则预演会变成一场没有焦点的大杂烩。场景选择上我的经验是选一个中等复杂度、带点刺的模拟项目而不是套用某个已经成功的真实项目。用真实项目做场景有一个陷阱——大家会不自觉回忆起当时是怎么干的甚至反驳我们上次不是这么处理的。更推荐的方式是虚构一个项目但给它注入真实的约束比如供应链成本比行业平均高20%、某个核心芯片的供应商产能有限、目标市场的准入认证周期比预想的长。这些约束会在预演过程中逼着团队去执行真正的分析方法而不是走过场。4.2 组建预演小组并分配角色Dry Run的参与人员不能只是流程编写组的成员也不能只是管理层。我的建议是让未来真正要在这个流程里干活的人来当演员——他们是第一批使用者也是第一批检验者。标准角色清单如下预演总指挥对整个Dry Run过程负责通常由项目管理办公室PMO负责人或IPD流程Owner担任。预演小组模拟一个完整PDT包括PDT经理、市场代表、研发代表、采购代表、制造代表、服务代表、财务代表、质量代表。每个角色最好有真实对应部门的人来扮演。IPMT模拟委员由公司高层或资深业务负责人扮演负责在预演的DCP节点做决策。观察员这是最关键的配置。观察员不参与具体执行只记录流程操作中的问题、时间消耗、角色职责不清、模板不适用的环节。观察员要单独给出一份《偏差报告》不能由预演小组自己写自评报告否则容易文过饰非。4.3 按时间轴推演并记录偏差Dry Run不等于开会讨论它应该有明确的时间轴。以概念阶段加计划阶段的双阶段预演为例我通常安排5到6个工作日按以下节奏推进工作时间预演内容关键产出第1天上午预演启动会发布场景、讲解流程、明确纪律预演章程第1天至第2天按流程走完概念阶段产出Charter初稿$APPEALS分析、初始业务计划第3天上午模拟概念DCPIPMT表决记录第3天至第4天按流程走完计划阶段各领域编制计划五大计划文档第5天上午模拟计划DCPPDCP表决记录、条件清单第5天下午复盘会对比偏差记录、确认整改行动项偏差清单、整改计划推演过程中观察员要严格按偏差记录卡来跟踪问题。记录卡的字段包括偏差描述、所属流程活动、严重级别阻断/严重/一般、建议整改方式、责任人。这个记录卡直接决定了Dry Run之后流程改不改、怎么改所以必须在预演过程中实时记录不能靠事后回忆。4.4 产出物与复盘Dry Run结束后至少要有三份交付物第一份是偏差清单这是最核心的产出。清单要分类整理对应到具体的流程文件条款。比如WBS模板中缺少采购导入物料的检查项、概念DCP材料模板没有要求填写差异化对比表这些都是常见的典型项。第二份是模板修订记录。预演中用过的所有模板都要回收观察员会评估模板是否好用表格字段是否清晰填写负担是否合理。模板修订是所有流程改进中性价比最高的一个动作因为模板是流程落到操作层面的最后一步。第三份是行动项清单。每一条行动项要有明确的落实责任人和完成时限。我的经验是在一次Dry Run后至少需要2到4周的整改窗口期再安排一次规模较小的复验只验证整改项是否闭环不用把整个流程再从头跑一遍。5. Dry Run实战中的六个坑我踩过的都在这5.1 坑一场景设计得太顺预演变成了情景剧这是新手组织者最容易犯的错。为了让预演好看场景设计得无比完美客户需求清晰、技术方案成熟、供应链没有瓶颈、竞争对手反应迟缓。结果整个预演变成了按剧本念台词的情景剧大家其乐融融地过完了全程偏差清单上只留下了寥寥几行无关痛痒的格式修改建议。正确的做法是在场景里埋地雷比如定义背景时说明某主要竞品在两个月前发布了低价版本、某一核心物料存在独家供应风险、目标市场的认证机构近期提高了测试标准。这些地雷会逼着概念阶段的需求分析更谨慎逼着计划阶段的采购计划做双轨准备。这才是一次真正的压力和偏差试验。5.2 坑二重讨论轻产出会开完了东西没写完Dry Run过程中各组讨论很热烈方案对撞很精彩但一天下来该更新的模板文件一个都没动。这个问题我几乎每次都会遇到。原因在于参与者潜意识里还是把它当会议而不是工作。破解方法有两条一是每个阶段结束时必须交付可检查的文件——哪怕是手写的草稿上面要有决策日期、负责人签字二是每个半天的预演以产出物演示收尾各角色拿着写好的材料上讲台讲5分钟讲不清楚就算没有产出。这种交付压力一旦建立起来大家的投入度立刻不一样。5.3 坑三决策环节缺人DCP评审变成了临时救场第一次组织Dry Run时我邀请IPMT模拟委员时大家都答应了但真到概念DCP和计划DCP当天总有几个人临时有事缺席导致决策环节变成来了的几个人随便聊几句。这直接传递了一个错误信号流程里的决策是可以随意对待的。后来我做了两个调整第一把DCP模拟环节安排在预演流程的黄金时间而不是临近结束的疲劳时段第二提前一天单独给IPMT模拟委员发材料包明确要求他们会前完成预审会上要有质疑式提问。让高层参与者在预演中体验一次严格、专业的DCP评审他们才会在真实项目中用同样的标准要求团队。5.4 坑四只改模板不改职责问题换个马甲继续出现偏差清单里有一类高频问题——某流程活动没有人牵头、某输出物没有Owner。这类问题如果只通过调整模板来解决下次换个场景还会以别的形式冒出来。我经历过一次概念阶段的需求评审会流程文件上写由市场部组织但市场部认为需求必须由研发来提研发又觉得市场才是需求Owner两个部门互相推最后预演卡在环节切换处整整半天。后来我们改了流程文件的措辞明确市场部为需求评审会组织方研发部为技术可行性评估责任方两个角色不能由同一人兼任同时更新了RASIC矩阵才解决。所以每次Dry Run复盘除了改模板一定要同步检查角色职责矩阵看问题是不是出在职责边界上。5.5 坑五预演时间拖太长团队疲劳后动作变形有些团队把Dry Run当成一次全员大练兵一口气排了三天概念、三天计划中间还有各种专题讨论到后面两天大家的专注度明显下降观察员记录的偏差数量反而越到后来越少——不是没问题是大家懒得记了。Dry Run的紧凑感很重要。时间太短跑不完时间太长会失真。以概念加计划双阶段为例5个工作日是合理区间其中还应该适当留出晚上和周六不加班的时间让大家休息。要让参与者始终保持适度的紧张感最好的办法是把每个环节的产出时间卡死形成节奏感。5.6 坑六没有独立观察员所有问题都被内部消化最后这个坑是最隐蔽的。有些团队组织Dry Run时没有设置观察员依靠参与者自己反馈问题。结果就是所有被反馈上来的问题都是参与者觉得说出来很体面的问题真正的流程痛点、部门间冲突、模板难用到爆全都被内部消化掉了。独立观察员的价值在于他们没有角色包袱——不需要维护自己部门的形象不需要为自己的表现辩护。他们只对一件事负责记录问题。如果组织者有资源最好是让IPD推进办公室中不直接参与本次流程运行的同事来但当如果实在没有独立人手至少要把记录职责和参与职责分开不允许既参与预演又自己记录自己的问题。6. 一些关于后续迭代的体会IPD5.1的Dry Run做完之后团队通常会形成一个共识流程文件里的每一步只有真正跑起来才知道好不好用。这个认识本身就是最大的收获。但Dry Run不是一次性的流程是活的组织结构会调整市场环境会变化产品形态会演进每一轮流程版本更新后都值得再做一次聚焦的预演只是不必每次都从头到尾跑全量针对变更点做小Dry Run就够了。我个人还有一个习惯每次大版本的Dry Run结束后我会把偏差清单中的常见问题TOP10整理出来做成一张团队内部的一页纸贴在每个PDT经理的办公桌旁边。比如概念阶段最容易被挑战的四个财务数字问题、计划阶段最容易漏掉的三个接口交付物——这些从预演中提炼出来的实战教训往往比几百页的流程文件对项目的帮助更大。最后再分享一个小技巧如果你们公司是第一次做IPD流程的Dry Run我建议不要贪全先把概念阶段单独拿出来跑一次两周时间足够。跑完一轮再决定要不要扩大到计划阶段。把一次预演做得小而透远比做得大而浅有价值。