从IPD实践者到研发体系架构师：用第一性原理重思流程本质

做IPD相关工作这些年来，我最大的一个感触是：市面上关于IPD的抱怨，多半不是IPD错了，而是我们把一个思考体系用成了操作手册。很多研发管理者的职业路径，是从“跑IPD流程”开始的：填模板、组织评审、追文档、盯计划，这套动作熟练以后，就容易产生一种错觉——自己对研发体系已经很懂了。可一旦换一家公司、换一个产品场景，原封不动的流程突然失效，团队开始抵触，决策层开始质疑，那时候才会意识到，自己掌握的只是流程的形，而不是体系的魂。

这篇文章是“从IPD实践者到研发体系架构师”系列的第一篇。我不打算先讲某个模板怎么做、某类评审怎么开，而想把底层的思考方式先立住：怎么用第一性原理去还原IPD，以及IPD和产品创新本源之间的关系到底是什么。这个话题适合两类人：一类是正在一线执行IPD、但总觉得“流程很重、效果一般”的实践者；另一类是被要求去搭体系、做裁剪、搞变革的研发管理者。你会发现，IPD里大量看似复杂的东西，追到源头其实都能用很朴素的经济学和管理学问题来解释。

1. IPD越用越重，问题出在把流程当成了体系

1.1 我自己曾卡在“流程优化者”的层级

把IPD实践者的成长路径粗略分一下，大概是三个阶段：流程执行者、流程优化者、体系设计者。

流程执行者关心的是“这一步怎么做”，评审材料怎么组织、文档命名怎么规范、TR和DCP分别要过哪些输入；流程优化者开始关心“怎么做更好”，会去压缩环节、合并评审、减少多余签字、提升项目周转效率；而体系设计者关心的是“这一步为什么存在”，会追问流程背后究竟要给哪个决策提供什么信息，这个信息能不能用更低成本的机制获取，如果不能，那流程本身就应该被重构。

我自己在第二个阶段停留了很长时间。当时我做过一个很得意的动作，把某个中型项目在计划阶段的内部评审从三次压到一次，理由是重复评审浪费时间。压缩之后，项目流程确实变快了，表格数量也降下来了，但团队并没有因此变得更轻松。后来复盘才发现，问题出在我动了流程的“形”，却没有动支撑决策的证据链。原来三次评审看起来冗余，实际承担着不同的信息收敛功能：第一次是技术方案自检，第二次是跨领域拉通需求，第三次才是跟商业目标对齐。省掉两次会议之后，这些对话并没有消失，而是变成了数不清的会前电话和临时沟通，成本从显性变成了隐性。

从那之后我得到一个教训：一个没见过体系全貌的人去优化流程，大概率是按下葫芦浮起瓢。

1.2 三个信号说明你正在被流程反噬

实践者要判断自己所在的组织是真在用IPD，还是正在被IPD拖着走，我建议你观察三个信号。

第一个信号，评审材料越来越精美，评审结论越来越模糊。一套几十页的胶片，图表完整、配色统一，但评审结束之后，项目组根本说不清楚IPMT到底批了什么、不批什么。如果一场评审会开完，结论只是“会后再看”“再补充一下数据”，那说明这套体系已经退化成过场表演了。

第二个信号，没人说得清某份文档的读者是谁。你问工程师为什么写这份文档，他大概率会说“流程要求”“模板里有”。再问一句“这份文档写完谁看？看完会做什么决定？”很多人答不上来。这不是工程师的问题，是流程设计者早就忘了文档的服务对象。

第三个信号，跨部门协作只发生在评审会上。IPD之所以强调跨部门团队，本意是让研发、市场、采购、制造、服务在关键节点之前就把信息对齐。如果一个组织只在会议桌上第一次见面，说明结构化并行工程根本没有建起来。会上讨论的往往不是方案，而是立场。

把IPD用成今天这个样子，不能全怪组织执行力不够，很多时候问题出在引入IPD时就直接把“流程和模板”当成了体系本身。

1.3 “流程就是体系”的认知怎么来的

这个认知偏差其实有很现实的原因。IPD被引入国内企业时，通常伴随大量可交付的文档模板、评审要素表和流程文件，项目团队看到什么就学什么，自然而然就会把“照着模板写、按着流程走”理解为IPD的全部。

另一个原因是，不同背景的人对“体系”的理解差异非常大。研发背景的管理者容易把IPD理解成一套工程方法，市场背景的管理者容易把它理解成一套需求分析方法，财务背景则更关心投资回报。为了让大家有一个共同语言，最后大家能对准的，往往不是抽象原则，而是那些看得见摸得着的流程文件。

还有一层原因是决策文化的惯性。很多企业过去是老板拍板、研发执行，IPD要求的是基于事实和数据的集体决策，这个改变要比流程文件难得多。如果不改变决策文化，流程跑得再完整，也只是把过去的“一言堂”包装成了“评审会”。

所以我的看法是，IPD显得重，并不一定是它真的重，而是很多组织在用最重的方式，去掩盖最轻的思考。

2. 回到产品创新本质：IPD为什么值得存在

2.1 产品创新失败，往往不是输在点子，而是输在因果链断裂

从第一性原理出发，你首先得回答一个问题：产品创新这个事，原本要解决什么？

大多数企业的产品创新，并不缺好点子。很多公司的邮件里、走廊上、技术交流会上，随处都能听到有趣的想法。真正稀缺的，是让点子顺利走完从创意到现金流的完整因果链。这条链有三段：第一段是价值假设链，要回答“谁会买单、他为什么买单、我们能帮他解决什么非解决不可的问题”；第二段是技术实现链，要回答“这个东西能不能做出来、以什么成本做出来、靠什么供应链做出来”；第三段是资源配置链，要回答“到底有没有合适的人和钱，在正确的时机投入到这件事上”。

新品失败很少是某一环单独出问题，更多的是三段链条没有形成闭环。一个极具创意的产品，可能死在商业假设不成立；一个市场机会明确的项目，可能毁在技术实现迟迟无法收敛；一个技术和市场都对的产品，也可能因为公司资源被其他优先级更高的项目占住而错失窗口期。

IPD之所以值得存在，本质上是提供了一套方法，尽量不要让上面任何一条链条断裂。

2.2 用第一性原理拆IPD，能拆到三个不可再分的目的

所谓第一性原理，简单说就是抛开行业里已经形成的套路，去问“这件事最底层、最不可再分的目的到底是什么”。按照这个思路去拆IPD，我发现不管流程怎么设计、模板怎么变化，最终都要服务于三个基本目的。

第一个目的，是在信息永远不完整的情况下，尽量做高质量的投资决策。IPD把产品开发当作投资行为，但现实是你在项目前期永远不可能拿到完整信息。这时候组织的挑战，不是等所有信息齐了再决策，而是要知道在哪个时间点、用什么样的信息颗粒度、做什么层的决策，同时保留后续纠偏的可能。这直接决定了评审点和阶段划分为什么是现在这个样子。

第二个目的，是让复杂的创造性协同产生秩序。做产品不是一个人单打独斗，研发、市场、采购、制造、服务各自有各自的专业逻辑。创造性的工作天然不喜欢约束，但如果没有接口纪律，各干各的，最后整合时必然爆发系统性混乱。IPD的结构化流程，本质上是在创造力和协同成本之间找一个平衡点。

第三个目的，是把组织学习的成果固定在流程中。一个人踩过的坑，如果没有机制转化成团队的共同认知，那就只能靠后来人重新踩。IPD里的技术评审、经验教训总结、文档资产沉淀，都是为了让项目团队的经验能够跨项目复用。

这三个目的，一个管方向、一个管协同、一个管积累，缺一个IPD都会变形。

2.3 产品创新本源里，藏着IPD每个阶段存在的理由

理解了链条和目的，你再回过头去看产品创新的本源，会发现几个基本事实。

第一个事实是，需求不是简单“调研”出来的，而是在约束条件中“筛选”出来的。客户告诉你的痛点未必是他愿意付费的痛点，调研问卷里说喜欢新功能的人，真到下单时往往选择最便宜成熟的方案。IPD之所以设置概念阶段，就是因为它承认，创新早期的需求是模糊的、甚至互相矛盾的，必须经过概念筛选才能收敛成一个可开发的产品定义。这个过程不能省，省了后面所有阶段都会返工。

第二个事实是，创新必须并行，但并行需要严格的接口纪律。市场团队不可能等研发完全做完再启动推广设计，制造团队也不可能等设计冻结之后再考虑工艺。很多项目延期，不是某一环节慢，而是环节之间从来没有对接口做过定义。IPD的异步开发模式，就是通过阶段化、模块化、接口规范化，让不同专业团队能在不同时间启动、在约定接口处对齐。

第三个事实是，企业的问题不是缺项目，而是缺容量。每一家公司的资源都有限，什么项目该投、什么项目该砍，不是单个项目团队能回答的，必须站在投资组合层面看。IPMT这类集成组合管理团队之所以存在，就是要在全局视角下决定资源流向，而不是被最有嗓门的项目经理牵着走。

把这几个本源事实摆出来，你会发现IPD的六个阶段不是某个顾问凭空设计出来的行政流程，而是为了让产品创新链条上的关键不确定点都有人负责、有决策机制把关。

3. 六大阶段与评审闸门：每道闸门背后都是一道经济学题

3.1 从概念到生命周期，每个阶段演的是同一出戏

只要讨论IPD，就绕不开它的阶段划分和评审点。常说的六个阶段是概念、计划、开发、验证、发布、生命周期。很多实践者把这些阶段当成行政性步骤，仿佛走完了就代表项目推进了一个里程碑。但换个视角看，每个阶段之所以存在，都对应着一种“信息状态变化”。

概念阶段，你的信息少得可怜，只有一个模糊的市场感觉和技术方向，这时候要做的不是写详细方案，而是验证“这到底是不是一个机会”；计划阶段，你已经决定要投入了，但还没有正式大规模开发，这时候要回答的是“我们用什么样的方案、什么样的资源计划来抓住这个机会”；开发阶段，你开始真金白银地投人投钱，要让方案变成现实；验证阶段，你得向市场证明这个产品真的可用、可造、可服务；发布阶段，你要把产品规模推向市场，追求商业结果；生命周期阶段，则要回答这个产品什么时候退出、怎么退出。

在主流IPD框架里，商业决策点并不会在六个阶段末平均出现。典型的设置是：概念阶段末有概念决策评审（CDCP），计划阶段末有计划决策评审（PDCP），验证阶段末有可获得性决策评审（ADCP），生命周期阶段末有生命周期终止决策评审（LDCP）。开发阶段通常不放独立的商业决策关口，而是用技术评审来把关，直到ADCP再把商业视角重新拉回来。

这张表可以帮助你理解每个决策点的真正意图：

如果你所在的公司规模较小，完全可以根据业务需要做裁剪，比如把CDCP和PDCP合并简化。但无论怎么剪，你都要保留这些决策功能，否则就等于在商业上闭着眼睛开车。

3.2 DCP管商业成色，TR管技术成熟度，两者不能混

一提到IPD里的评审，大家最容易混淆的两个概念就是DCP和TR。DCP是Decision Checkpoint，商业决策评审点，参与者通常是IPMT级别的经营团队；TR是Technical Review，技术评审点，参与者是技术线和跨部门的技术专家。

这两者的关系，打个比方：DCP像投资人在问创业者“我还要不要继续投钱”，而TR像总工程师在问“技术方案到底行不行，产品到底成不成熟”。前者看的是商业风险，后者看的是技术风险，两者不能互相替代。很多组织出问题，就是让技术专家在DCP上拍板商业问题，或者让管理层在TR阶段纠缠技术细节，两拨人都干了自己不擅长的事。

在标准框架里，TR从概念阶段就介入了。TR1关注需求是否清晰，TR2关注系统设计是否合理，TR3关注详细设计能否支撑开发，TR4关注样机能否满足规格，TR5关注小批量验证结果，TR6关注产品是否具备上市条件。TR的结论作为DCP的重要输入，但它不能替代商业决策。一个技术完全成熟的产品，也可能因为市场时机不对而被终止；一个技术还有风险的产品，也可能因为商业价值足够高而选择继续投入测试。正因为如此，评审会的信息设计一定要分开。

3.3 一次有质量的评审，只围绕六个问题展开

看了太多低效的评审会之后，我在自己参与的体系设计里，会把评审要回答的问题收敛成六个。不管PPT里写了多少页，最终决策层要问的就是这六件事：

第一，我们验证了哪个最重要的客户问题？证据从哪里来？这里要的是“客户访谈记录”“购买行为数据”这类实证，而不是“市场普遍认为”这种无主意见。

第二，市场空间和竞争状态比起立项时变了没有？很多项目立项时的数据很漂亮，真正到评审时外部环境早已变化，但项目组还在用半年前的假设糊弄人。

第三，技术上最大的风险是什么？有没有不可逆的成本已经发生？所谓不可逆成本，是指那些一旦投入就无法收回的钱，这个问题直接决定止损点应该设在哪。

第四，商业模型和资源计划是否仍然成立？立项时算的账，到了现在的信息量下还能不能兑现？如果不能，缺口在哪里，谁能补上？

第五，如果今天必须做一个决定——继续、重定向、还是终止——你会选哪个，为什么？这个问题逼着每个人亮明立场，而不是停留在“再观察观察”。

第六，这个决策由谁负责？后续在什么时间点重新审视？没有责任人的决定等于没有决定。

这些问题看起来朴素，但它们是评审这件反人性的事里最难的部分，因为它要求管理者承认不确定性、承认自己可能看走眼。

4. Charter不是立项报告，而是写给决策层的投资契约

4.1 从模糊机会到Charter，中间发生了什么

热搜里经常有人搜“IPD charter范例”，说明这是IPD落地里大家普遍认为最难的交付物之一。要写出一份好的charter，你得先知道它从哪里来。

在产品规划阶段，公司看到一个市场机会，但此时一切都还很模糊。随后项目进入概念阶段，PDT团队开始做市场调研、客户访谈、竞争分析、初步技术评估，把原始机会一点点变成一个可评估的产品构想。概念阶段的核心交付物之一，就是charter——在很多公司里它被翻译成“产品任务书”或“项目任务书”。Charter写完后提交给IPMT做概念决策评审，通过后项目才被授权进入计划阶段，获得相应的人员和资源承诺。

所以charter在体系里的位置很特殊：它是产品从“机会探索”转向“正式开发投资”的第一份关键文件。它既不是产品的详细设计文档，也不是市场部门的宣传方案，更不是写给研发人员的任务交底书。

4.2 Charter在商业本质上是一份“投资契约”

我对charter的理解是：它就是项目团队写给决策层的一份投资契约。团队通过这份文件向公司要资源，同时承诺自己会交付什么样的商业结果；公司通过审批这份文件，授予团队在授权范围内推进项目的权力。

既然是契约，就必须有约束力。契约里要写清楚这几点：我们相信哪个机会是真的，我们要为哪群人解决什么问题，我们凭什么认为我们能赢，我们要花多少钱、花多长时间，如果出现什么情况我们应该收手。

我把charter的底层决策要素归纳成五个。

机会假设：目标客户是谁，他们有什么未被满足的问题，市场规模有多大，这个机会窗口期有多长。这部分回答“为什么做”。

产品价值主张：我们要做什么形态的产品，解决什么问题，跟现有方案相比强在哪。这部分回答“做什么才能赢”。

可验证的范围：第一批交付到底包括哪些特性，明确不做什么。范围失控是IPD项目延期和亏损的头号原因。

技术与交付风险：最大的不确定性在哪个环节，有没有备选方案，什么信号出现后我们必须调整方向。

商业契约：需要多少资源，里程碑怎么排，财务测算是什么，止损条件是什么。这部分回答“公司能得到什么、可能输掉什么”。

如果charter在这五个要素上有任何一个含糊，就不要怪后续的计划阶段失控，因为源头就没把话说清楚。

4.3 一份有决策力的Charter，章节骨架可以这样搭

我不会给你一个固定模板去填，因为不同业务场景下细节千差万别。但如果你需要动手写，我建议认真对待这份结构骨架，每一节都要回答一个决策层关心的问题。

一页纸摘要：用最短篇幅讲清楚项目是什么、要多少资源、预期什么结果。这页是给没有时间细读的高层看的，如果连这页都读不出结论，说明思考还没到位。

市场机会与客户问题：不要写成行业趋势报告，要聚焦到具体客户群和具体痛点，并且给出证据来源。没有证据支撑的内容在评审会上就会被质疑。

竞争与替代方案：客户现在用什么方式解决这个问题？我们有什么独特优势？替代方案其实不只是竞品，还包括客户“什么都不做”的状态。

价值主张与产品定义：产品边界是什么，核心特性是哪些，什么是明确不做的。价值主张要站在客户视角说“我得到什么”而不是站在产品视角说“我有什么”。

商业模式与财务测算：收入模型、成本结构、盈亏平衡点、投资回收期，这些数字必须和商业假设穿在一起。

技术可行性与关键风险：有没有卡脖子的技术点，知识产权状态如何，关键物料和供应链是不是有保障。

项目范围与目标特性：定义第一批发布的功能包，明确优先级排序，避免计划阶段重新撕扯。

资源需求与时间线：要多少人、要哪些角色、预计做到什么里程碑，资源需求最好能对应到具体阶段。

风险控制与退出止损：列出最可能让项目失败的三件事，每件事的触发信号是什么，触发之后组织做什么决策。

请求批准事项：明确告诉IPMT，你需要在什么时间点前拿到什么授权，这就是契约的落款处。

在每一节的适当位置标注“证据来源”会非常加分。标注不出来就诚实写“目前假设，待验证”，这比用含糊其辞包装出一个虚假的确定性要强得多。

4.4 写Charter最容易踩的几个坑

第一个坑，是把市场分析写成了一份行业报告。动辄几十页的大环境分析、市场规模增长曲线，这些内容对决策没有直接帮助。真正有价值的市场分析，必须落到“所以我们选择这个细分市场”这个结论上。

第二个坑，是把价值主张写成了功能列表。“更强性能、更多接口、更高可靠性”听起来是对的，但你得说清楚这些功能帮客户省了什么钱、赚了什么钱。客户买的不是功能，是功能带来的结果。

第三个坑，是害怕承认不确定性。很多项目组担心写风险会吓跑决策层，于是把一切风险都写成“可控”“有预案”。等到计划阶段风险真爆发的时候，决策层发现自己被蒙在鼓里，信任危机就出现了。好的charter敢于把最糟糕的情况摆上桌面，同时给出应对思路。

第四个坑，是没有提前让评审人读材料。如果一场CDCP会议，大家现场才开始翻charter，那这次评审的质量不可能高。机制上必须要求：材料提前三天发出，评审人带着明确意见来开会，会上只讨论分歧和关键判断。

5. IPD文档体系真正要捍卫的东西：让证据链完整可见

5.1 文档数量失控，是IPD落地最常见的次生灾害

聊到IPD，绕不开“文档特别多”的槽点。尤其在引入IPD的企业里，你随便打开项目管理系统，都能看到成百上千份交付物，需求文档、设计文档、测试报告、变更申请、会议纪要、评审记录，一层套一层。

很多实践者都问过我同一个问题：这些文档真有必要吗？我认为这个问法本身需要修正。真正该问的不是“文档有没有必要”，而是“文档服务了哪个决策”。一份文档如果没有服务的决策对象，就算写得再规范，它也只是仓库里的库存；反过来，一份文档如果直接影响关键决策，哪怕格式再朴素，它也有不可替代的价值。

文档之所以成为IPD的重灾区，是因为模板思维盛行。培训老师一讲“概念阶段要输出charter，计划阶段要输出XX文档”，企业就把这些当成一个都不能少的清单，完全忽略了文档和决策之间的因果关系。一开始大家还按需裁剪，后来为了应付审计、为了显得体系完整，干脆把模板库越扩越大。最后文档不再是思考的载体，而变成了行政上的负担。

5.2 文档体系的分层，要从“读者”而不是“阶段”出发

我在帮企业梳理IPD文档体系时，习惯按照读者和决策层级把文档分三层，而不是简单按阶段去排列。决策级文档是给IPMT这类商业决策层看的，核心是charter、DCP汇报材料；技术级文档是给TR评审组和跨部门技术专家看的，核心是需求规格、系统设计、测试报告；执行级文档是给项目团队自己看的，核心是项目计划、风险管理、状态跟踪。

这套分层的价值在于，它迫使你思考每个文档的作用范围。文档不是写得越多越好，而是要让每一层级的读者，只看到他做判断所需的信息，不要让一个做技术评审的专家去翻市场战略报告，也别让一个投资决策委员会去纠缠详细设计文档。

我再多解释一句为什么很多企业照搬先进实践时，文档会失控。头部企业在导入IPD时确实沉淀了非常完整的文档体系，几十个角色、上百种文档、严格的审批链。这种体系适合万人规模的研发组织，但当它被搬到几百人的公司时，如果只是按照人员数量同比缩小模板数量，大概率不是缩出一套精简体系，而是缩出一套缺胳膊少腿的障碍物。正确的裁剪原则不是按团队规模，而是按“决策需要”。公司没有产品线投资组合决策，就不需要那套复杂的组合管理文档；公司没有全球上市计划，就不需要为区域营销准备全套物料模板。先确认组织有哪些决策要做，再决定需要哪些文档来支撑，这才是架构师该有的思路。

5.3 判断一篇文档该不该写的硬标准

在帮团队做评审和文档体系建设时，我经常会提一个很硬的标准：如果这份文档丢了，会不会有某个决策因此做错？如果答案是“不会”，那这份文档大概率可以用一页纸备忘录甚至一次会议纪要来代替；如果答案是“会”，那么哪怕写起来很痛苦，也要把文档写清楚，因为它的价值不在于存档，而在于让决策者掌握做出正确判断的证据。

面向一个具体决策的文档，我建议采用三段式结构：结论先行，把需要决策的事项和推荐结论放在最前面；然后铺证据与假设，把支撑结论的数据、案例、来源都列出来，推断所依赖的假设也要单列；最后写相对上一版的变化与悬而未决的问题。这看起来简单，但很多项目文档写不清楚，就是在“结论—证据—假设”之间来回游走，让读者自己去拼图。

有一类现象最常见：文档越写越长，数据越来越多，但读者读完之后依然不知道“要批什么、不批什么”。出现这种情况时，问题往往不是沟通表达能力不行，而是作者根本没有把决策问题想透。文档只是暴露了思考的混沌。

6. 从“会跑流程”到“能搭体系”：架构师视角的三大转变

6.1 把整个体系画成一页纸，你会看到意想不到的冗余

从IPD实践者走向研发体系架构师，我记得最清楚的一个转折点，是我第一次尝试把公司整个研发体系画在一页纸上的时候。没有Excel，没有流程软件，就用一张大白纸和一堆便利贴，从机会发现画到产品退市，每个阶段旁边标注谁做决策、需要什么输入、产出什么输出、有哪些角色参与。

这个过程远比想象中痛苦。一开始画完全是流程图上每阶段顺序排列，看不出问题；等到把“决策角色”和“文件流”叠加上去，我发现自己公司里跑着一套“幽灵流程”。比如某个技术评审其实做了三次，第三次唯一增加的，是由一个并不直接参与项目的领导签了个字；又比如有两份文档，名字不同、模板不同，但填进去的内容几乎一模一样，只是分别送到了两个管理部门。

这种问题，只有当你把体系当成一个整体去审视时才会暴露。习惯在一线跑流程的人，往往只看到自己负责的那段路，路上的坑都认识，但不知道这条路整体往哪走。架构师的第一项基本功，就是拥有一个“上帝视角”的剖面图，哪怕它只是简化的一页纸。

6.2 裁剪IPD的正确姿势：按创新场景适配，而非按公司大小

很多公司老板一听说IPD，立刻会问：我们规模小，是不是不适合？这个问题本身问偏了。IPD合不合适，不取决于公司大小，而取决于你做的产品创新是什么类型。

我把研发场景粗略分为三类，适配策略完全不同。

成熟市场的渐进式创新，比如一个已经卖了三代的硬件产品继续升级迭代。这种场景下需求相对清晰、客户群明确，最大的风险不是方向错了，而是效率太低。对策是把概念阶段的很多活动轻量化，直接基于上一代产品的市场反馈形成需求清单，把资源重点放在计划和验证阶段，保证不犯错、不延期。

其次是全新市场或全新品类的突破式创新。这种场景下市场是新的、客户是新的，甚至连产品形态都没有参照物。最怕的不是风险高，而是拿渐进式产品的流程去套，压制了探索空间。这种项目在概念和计划阶段要放重兵，允许团队多轮试错，一直到商业假设收敛后才进入重投入的开发阶段。

第三类是平台和技术预研。平台项目的周期长、投资大、客户是内部产品线而不是外部市场，套产品开发的阶段评审往往鸡同鸭讲。成熟的做法是单独建立技术成熟度评估机制，让平台项目配合产品组合按节奏释放，而不是拿单一产品的立项标准卡死自己。

所以，我不太喜欢“瘦身版IPD”这个说法，因为它暗示只要模板少一点、文档少一点，就适合中小公司。真正该做的是针对创新场景重排决策逻辑。一个全新产品项目哪怕公司只有五十人，该做的市场验证也不该省；一个成熟产品迭代哪怕公司有五千人，也没必要每次都从零做概念研究。

6.3 想做体系架构师，先积累自己的“原理库”

很多人以为研发体系架构师要背很多流程模板，其实恰恰相反。市面上能买到的IPD流程资料有大量参考案例，真有需要时你可以拿到各种版本的流程文件，但真遇到一个没有现成答案的新场景，你会立刻发现，靠“借鉴模板”是走不通的。

真正能支撑架构师走远的，是一套属于自己的原理库。原理库里装的不是某个公司的评审节点长什么样，而是更底层的因果判断：比如“当不确定性高时，决策点要前置”“当信息不可逆成本高时，要增加阶段门”“当多个专业领域需要并行时，接口规格就必须先于开工前定义”。你积累的这类判断越多，裁剪流程时就越有底气。

练习方式上，我建议每做完一个项目，复盘时不只问结果好不好，而要多问两个问题：流程在哪个环节帮助我们避了雷？流程在哪个环节制造了等待？你会发现不同项目里的答案惊人地一致，而那些反复制造等待的环节，往往就是体系中最值得被重构的地方。

还有一个更有效但也更考验人的训练，是找机会参与别人的IPD建设。自己公司的流程你已经熟到看不见了，去一个陌生的业务环境，能逼你重新面对“这个体系到底在设计什么”的原问题。哪怕只是帮忙做一次流程体检，收获都远比在自家体系内打转要大。

最后说一点个人体会。很多年前，一位工程师在评审会间隙对我说过一句话：“你们这套流程，让我把一半时间拿来填表格。”这句话我记了很多年。后来我设计任何流程改动，都会先问自己：如果我是那个被要求写文档的工程师，我能从这件事里获得什么价值？只有当流程让最底层的工程师也能借助它更好地做判断、更早地暴露风险时，IPD才真正变成了研发体系的架构，而不是流程办公室的负担。