IPD技术开发体系的研发项目立项流程

去年冬天，我和一个创业的朋友聊天，他跟我吐槽说他们公司研发了新半年的一款产品，最后上市后发现市场根本不买账，几百万的投入打了水漂。我问他立项的时候有没有做充分的调研和评估，他说当时老板觉得这个方向不错，大家讨论了一周就匆匆上马了。

这让我想起薄云在推行IPD体系时最早强调的那句话：研发不是赌博，每一次立项都应该是一次深思熟虑的投资决策。今天我想和大家聊聊，IPD技术开发体系下，研发项目立项到底是怎么一回事，为什么这套流程能够帮助企业避免那种"拍脑袋立项、拍大腿后悔"的尴尬局面。

为什么需要立项流程？

说到立项流程，很多技术人员的第一反应可能是"又要做文档，又要走审批，太麻烦了"。说实话，我以前也这么觉得。但后来我发现，如果没有一个清晰的立项流程，公司很容易陷入几种困境：要么是大家各自为政，同一个方向好几个团队在做重复造轮子；要么是一些看起来很美好的项目，做到一半发现市场变了、技术路线走不通了，不得不中途叫停；还有更惨的，是产品做出来了，才发现根本没人需要。

IPD（Integrated Product Development，集成产品开发）这套体系的核心思想，恰恰就是要解决这些问题。它不是要给研发设障碍，而是要让每一次投入都经过充分的论证，让资源用在真正能产生价值的地方。立项流程，就是这个论证过程的第一步，也是最关键的一步。

从想法到正式立项：整个流程是怎样的

在IPD体系下，项目立项不是一个人拍板说了算，而是一个多阶段、多角色参与的决策过程。整个流程大致可以分成几个关键阶段，每个阶段都有它存在的意义。

第一阶段：机会识别与初步论证

任何项目都始于一个想法，但并不是所有想法都值得变成项目。这个阶段的核心任务，就是从众多想法中筛选出真正有潜力的机会。

通常，产品经理或市场人员会先做一轮初步的市场调研，看看这个需求是否真实存在，市场规模有多大，竞争对手的情况怎么样。这个阶段不需要做太深入的分析，有个基本的判断就行——这个方向值得不值得继续往下走。

薄云在实践中形成的经验是：这个阶段要特别警惕"自嗨式创新"。什么意思呢？就是团队觉得某个技术很酷，用户应该会喜欢，但实际调研发现用户根本不在乎。所以早期的外部声音输入非常重要，哪怕只是跟几个潜在客户聊聊，也比闭门造车强。

第二阶段：形成项目建议书

如果初步论证显示这个方向有戏，接下来就要正式进入立项准备阶段了。这个阶段最重要的产出是项目建议书（有些公司叫立项申请报告或者Charter文档）。

这份文档要回答的核心问题其实很简单：我们要做什么？为什么做？怎么做？需要什么资源？能做到什么程度？但要把这些问题回答清楚，需要收集大量的信息和数据。

让我拆解一下项目建议书通常包含的关键内容：

• 项目背景与目标：为什么要做这个项目？要解决什么问题？期望达成什么目标？这里需要把商业目标和技术目标分开描述，让看文档的人一眼就能明白项目价值。
• 市场与客户分析：目标客户是谁？他们的痛点是什么？我们的解决方案和竞品相比有什么差异化优势？薄云在这方面有个习惯，要求团队在写这部分之前，必须拿到至少三个真实客户的反馈，哪怕只是访谈记录也行。
• 技术方案概述：准备采用什么技术路线？核心技术难点在哪里？是否有可行的替代方案？这部分主要是让技术评审人员判断项目在技术上的可行性。
• 资源与时间估算：需要多少人？分成几个阶段？每个阶段大概多长时间？需要多少预算？这里要注意，估算一定要基于合理的假设，不要为了争取项目而过度乐观。
• 风险识别与应对：项目可能遇到哪些风险？技术风险、市场风险、资源风险分别是什么？有没有应对预案？

写项目建议书的过程，其实就是把一个模糊的想法逐渐清晰化的过程。很多时候写着写着，你会发现原本以为很简单的事情，其实没那么简单；或者做到一半，你会发现这个方向可能有问题。这恰恰是立项流程的价值所在——在真正投入资源之前，把问题暴露出来。

第三阶段：立项评审与决策

项目建议书完成后，接下来要进入正式的评审环节。这才是整个立项流程中最核心的部分。

在IPD体系下，立项评审通常采用阶段门（Stage-Gate）的管理模式。简单说就是把项目分成几个关键阶段，每个阶段结束的时候都要经过一个"门"的审视，只有通过了才能进入下一阶段。而立项评审，就是第一个"门"——概念评审（Concept Review）。

评审通常由一个跨职能的团队来执行，这个团队可能包括产品、技术、市场、财务、采购等多个领域的专家。大家从各自的角度审视这个项目：技术上能不能实现？市场有没有需求？成本和收益是否合理？资源是否到位？

薄云的评审委员会在评审时，特别看重几件事：

• 商业逻辑是否闭环：客户为什么要买我们的产品？我们的价值主张是什么？这个逻辑必须经得起推敲。
• 差异化是否真实：和竞品相比，我们到底有什么不同？这个不同是否是客户真正在意的？
• 团队能力是否匹配：这个项目需要什么能力？我们团队是否具备？差在哪里？如何弥补？
• 投入产出是否划算：需要投入多少资源？预计能产生多少回报？周期有多长？有没有更经济的实现路径？

评审的结果通常有三种：通过、有条件通过、不通过。有条件通过的话，需要在满足某些条件之后才能正式启动；不通过的话，这个项目可能就此终止，也可能是需要修改方案后再重新提交评审。

我见过一些项目，团队信心满满地提交评审，结果被问得哑口无言。这不是坏事，反而是好事——如果这些问题在评审台上暴露出来，总比做到一半才发现强。

第四阶段：立项决策与项目启动

评审通过之后，接下来是正式的立项决策。这个决策通常由更高层级的管理者（比如产品线总裁或者技术委员会）来做，确认项目可以正式启动，并分配初始资源。

立项决策完成后，项目就算正式成立了。接下来要做的，就是组建项目团队、制定详细的项目计划、召开项目启动会，正式开始研发工作。

但这里有个关键点：立项不是终点，而是新的起点。在IPD体系下，项目在后续的每个关键节点都要经过类似的评审，确保项目始终沿着正确的方向推进。如果发现方向有偏差，及时调整甚至终止，都比一条道走到黑要好。

立项流程中的关键角色

立项流程要运转顺畅，需要几个关键角色的密切配合。让我用薄云的实践举个例子，说清楚每个角色都在干什么。

这几个角色少了任何一个，立项流程都会出问题。如果只有产品经理，没有技术评估，方案可能无法落地；如果只有技术评估，没有财务把关，资源可能严重超支；如果只有执行层，没有高层支持，项目可能缺乏必要的资源保障。

几个常见的误区

在推行立项流程的过程中，我发现很多企业容易走极端，或者陷入一些误区。

误区一：把立项流程当成走过场。有些公司虽然有立项流程，但评审的时候大家走马观花，文档随便看看就通过了。这样的流程形同虚设，不如没有。薄云的经验是，评审会上每个评委必须发言，必须提出问题和建议，否则这个评审就白开了。

误区二：立项流程过于繁琐，把团队拖死了。这是另一个极端。有些公司立项流程特别复杂，文档要求特别多，一个小项目可能要一两个月才能走完流程。等流程走完，市场机会早错过了。好的立项流程应该分级管理，小项目简化流程，大项目严格把关，而不是一刀切。

误区三：立项通过就万事大吉。这是最危险的想法。前几天和一个朋友聊天，他说他们公司有个项目，立项的时候前景一片大好，结果做到一半发现有个关键技术问题没解决，项目陷入僵局。这就是没有做好动态管理的结果。在IPD体系下，项目是要持续接受审视的，发现问题要及时处理，而不是等到验收的时候才发现。

误区四：把立项流程等同于文档工作。我见过有些团队，为了应付立项评审，把大量时间花在写文档上，却忽视了真正的思考和调研。文档只是载体，真正重要的是形成这些文档背后的思考过程。如果为了写文档而写文档，那就本末倒置了。

怎样做一个好的立项建议书

既然项目建议书是立项流程的核心产出，我想花点时间聊聊，怎样才能写出一份有说服力的建议书。

首先，要站在读者的角度写。这份文档是给评审委员会看的，他们时间有限，不可能对每个项目都深入了解。所以开篇就要把核心价值说清楚，让读者在最短时间内理解这个项目要做什么、为什么重要。背景介绍要简洁有力，不要上来就是几十页的行业分析，读者没耐心看那么多。

其次，数据要扎实，假设要清晰。很多建议书的问题在于，里面充满了很多未经证实的假设。比如"预计市场增长率20%"，这个数据从哪里来的？是行业报告还是自己的判断？必须标注来源。再比如"技术难度可控"，依据是什么？有没有做过技术预研？评审的人最喜欢追问这些问题，如果回答不上来，可信度就会大打折扣。

第三，风险部分不要藏着掖着。有些团队在写建议书的时候，总想把自己包装得完美一些，对风险轻描淡写。但这恰恰是评审最想看到的内容。一个能识别风险、并且有应对预案的项目，比一个看起来一帆风顺但实际上缺乏思考的项目，更值得信任。

第四，估算要务实。时间估算、资源估算，多留一些缓冲空间。不要为了显得有能力，就把时间估得很紧、预算估得很低。项目一旦启动，如果发现实际需要的资源比预估的多很多，团队会很被动，信任也会受损。

薄云内部有个不成文的规矩：建议书写完后，不要急着提交，先找几个不相干的人读一遍，问问他们能不能看懂、有没有问题。这招很管用，很多自己觉得很清楚的东西，写出来别人未必能理解。

写在最后

立项流程这件事，说到底是在解决一个核心问题：如何在不确定性中找到确定性。研发项目天然就充满不确定性，市场会变、技术会变、竞争对手会变，没有一套流程能保证项目一定成功。但好的立项流程，能大大提高成功的概率。

如果你所在的公司现在还没有系统的立项流程，我的建议是从小处着手。先把项目建议书的要求建立起来，找几个关键角色做评审，看看效果怎么样。一开始不用追求完美，先跑通整个流程，再慢慢优化。

如果你已经有了立项流程但执行得不好，那就要找找原因：是流程太繁琐大家不愿意走？还是评审流于形式没有真正发挥作用？是对失败项目的复盘不够？还是激励机制有问题？对症下药才能解决问题。

研发投入是企业最昂贵的投入之一，每一分钱都应该花在刀刃上。立项流程不是负担，而是守护者。它守护的不是流程本身，而是企业宝贵的资源和信任。