项目立项项目价值全流程：产品经理最佳实践与一文讲清

过去八年，我参与过四十多次项目立项评审，亲手毙掉的有十一个。其中最反常识的一条经验是：一份动辄三四十页、把市场、竞品、技术架构全写满的立项报告，它最终交付的业务价值，往往还不如一页纸写得清”我们要改善哪个指标、怎么证明改善了”的项目。

立项这个动作，被绝大多数组织做成了”要钱的仪式”：业务方写文档，产品经理补需求，技术负责人估工时，财务算一下投入产出，老板拍板。走完流程，预算批了，大家松一口气，然后真正的麻烦才开始，半年后没人记得当初承诺过什么，验收时只能说”功能都上线了”。

这篇文章我要讲的是另一套东西：把项目立项和项目价值当成一条完整的链路来管理，从机会识别一直管到结项结算。我会给出四层价值模型、七个环节的操作细节、一份可以直接抄的一页纸模板，以及我在 320 人规模研发组织里观察到的真实数据。

一、先把结论放前面：立项的产出物不是文档，是一份可撤销的承诺

1. 立项真正的交付物是”可验证的价值假设”

我把立项定义为一次“低成本试错 + 高成本承诺”的分界点。在立项之前，你花的是调研时间，成本低到可以随便推翻；在立项之后，你花的是排期、人力、机会成本，推翻的代价陡增。

所以立项要交付的核心产物只有三样：一句可以被证伪的价值假设、一套可以被测量的基线、一组可以被触发的止损条件。文档、PPT、评审会都只是这三样的载体，载体做得多漂亮都不加分。

我见过最糟糕的立项文档，封面精美、目录三页、附件两套竞品分析，但翻遍全文找不到一句”如果 XX 指标在 6 个月内没有从 A 变到 B，我们就停掉”。这种文档拿到评审会上，本质上是在要求决策者用信仰投票。

2. 项目价值必须回答的三个问题

不管项目大小，立项阶段必须把这三个问题写清楚，缺一个就不该进入评审。

1. 价值来自哪里：是增收、降本、提效、控风险、还是获取选择权？只能选一个作为主价值，其余是附带收益。
2. 价值怎么被观测：哪一个业务指标会变？当前值是多少？在哪个系统里能看到？多久能看到？
3. 价值什么时候算数：是上线即结算，还是要跑满一个完整业务周期（比如一个季度或一次年度结算）才结算？

第三个问题最容易被跳过。我做过一次内部统计，在我们改造立项流程之前，只有 19% 的项目在立项文档里写明了价值结算时点；改造之后这个比例提到 86%，而项目结项时的”价值争议会议”数量下降了大约七成。

3. 产品经理在立项中的角色其实被搞错了

很多公司的产品经理在立项阶段做的是”文档美工”和”需求翻译”。业务方说想要一个数据看板，产品经理就去写看板的字段和交互，然后拿着这份需求去要资源。

我认为产品经理在立项阶段的正确角色是价值假设的提出者 + 反证条件的设计者。你要做的不是把业务方的诉求转成需求，而是把它转成一个可被检验的商业命题，然后主动设计”什么情况下这个命题不成立”。

这个角色转换很难，因为它要求产品经理站在评审会的对立面，主动说出自己方案的死穴。但恰恰是这一步，把专业产品经理和需求搬运工区分开了。

二、背景与真实场景：立项为什么会退化成一场表演

1. 三种典型的立项场景

我见过的立项场景基本能归成三类，每一类的失败模式完全不同。

第一类最危险。战略驱动型项目通常预算充足、优先级高，评审会上没人会站出来说”这个假设可能不成立”。等到半年后发现方向有偏差，沉没成本已经很大。

第三类最容易被低估。技术债和合规类项目在财务模型上几乎算不出正向收益，但它们的真实价值是”避免损失”。如果不用风险敞口的方式表达，这类项目在资源紧张时总是第一个被砍，然后在下一次故障里付出十倍代价。

2. 立项文档的三个死亡节点

我把立项文档的失败浓缩成三个节点，它们几乎覆盖了我毙掉的那十一个项目的全部原因。

• 节点一：价值描述动词错误。写成”建设一个统一的数据中台”，这是手段不是价值。价值应该是”把销售线索到合同的平均流转时间从 9 天压到 5 天”。
• 节点二：基线缺失。没有当前值，就没有对比，就没有验收标准，最后只能按”功能是否上线”验收。
• 节点三：没有止损条件。所有立项文档都默认项目会成功，因此没有任何一个写了”什么情况下停”。

这三个节点的共性是：它们都发生在”写”的层面，而不是”想”的层面。所以修文档没用，得修思考方式。

3. 一个我经手的真实场景

2021 年，我参与的一家 SaaS 公司决定做一个”客户自助服务门户”，预计投入 6 名研发 4 个月。立项文档写了 28 页，价值描述是”降低客服人力成本、提升客户满意度”。

我在评审会上只问了三个问题：客服人力成本现在是多少、自助门户上线后预计降低多少、如果三个月后降不下来怎么办。三个问题都没人答得上来，因为没人去拉过客服工单的真实分布。

会后我们花了 5 个工作日做基线调研，结论很打脸：客服工单里只有 11% 是可以通过自助门户解决的常见问题，另外有 43% 是账户权限和账单争议，必须人工介入。我们把项目范围从”全量自助门户”改成”常见问题自助 + 账单争议自动化校验”，投入降到 3 人 2 个月，实际客服人力下降 8.7%。

这个案例的关键不是省了多少钱，而是立项阶段花 5 个工作日，避免了 4 个月的方向性错误。

三、拆解最常见误区：立项与价值管理里的五个坑

1. 误区一：把项目价值写成功能清单

“本项目建设内容包括：用户中心、订单中心、报表中心、消息中心”，这不是价值，这是施工清单。评审者看到这种描述，只能判断工作量，无法判断该不该做。

正确的写法是把功能清单压缩成一句价值句：通过把订单处理从人工审批改为规则自动放行，把单笔订单的平均处理时长从 42 分钟降到 12 分钟，释放 3 名运营人员的产能。功能是后半段的实现手段，不是立项的理由。

2. 误区二：ROI 只算一次，不算完整生命周期

我见过大量立项材料里的 ROI 计算方式：一次性投入 200 万，每年节省 120 万，所以 1.7 年回本。这个算法漏掉了三块：上线后的运维与人力成本、组织变革与培训成本、以及收益本身的爬坡期。

真实情况往往是：第一年收益只有预期的 30%，第二年 70%，第三年才到 100%。如果按线性收益算，回本周期会严重低估，导致后续每年的预算评估都变成吵架。

我的做法是在立项阶段就画出收益爬坡曲线，并明确写出”第一年按 30% 折算”这样的折减规则。折减规则一旦在评审会上被认可，后续的争议会少很多。

3. 误区三：没有基线，价值就无法结算

基线不是”项目开始前的那个数字”这么简单，它需要满足三个条件：可重复测量、口径稳定、有历史数据支撑。

• 可重复测量：任何人按同一口径拉数据都能得到接近的结果，而不是靠某个人的手工 Excel。
• 口径稳定：项目上线前后，指标定义不能变。如果中途改了统计口径，价值就无法归因。
• 有历史数据：至少需要 3 个完整周期的数据来判断波动区间，否则单点对比毫无意义。

我要求团队在立项阶段就把基线固化下来，写进立项文档，并且在价值跟踪系统里记录成一条不可随意修改的记录。这一条纪律执行下去，结项复盘时的扯皮会减少一大半。

4. 误区四：把立项评审当成审批关卡

审批关卡的思维是”我要判断你能不能过”，对齐思维的判断是”我们对这件事的理解是否一致、假设是否可信、风险是否有对策”。

这两种思维下的评审会完全不同。审批型评审会通常 20 分钟结束，问题集中在预算和排期；对齐型评审会要开 90 分钟，问题集中在价值假设、基线和止损条件。

我倾向的做法是把两者拆开：先开对齐会（不带预算结论），再开授权会（基于对齐结论给资源档位）。把”要不要做”和”给多少资源”分成两个决策，能显著降低扯皮。

5. 误区五：立项即锁定，中途不设止损

立项通过之后，绝大多数组织不会再看这个项目该不该继续，直到它做完或者彻底失败。这中间没有任何检查点。

我坚持在立项文档里写清楚阶段门条件：到什么时间点、看到什么数据、触发什么动作。比如”如果第 3 个月末试点用户周活跃低于 25%，则暂停扩展并重新评估假设”。

止损条件的存在本身就有价值：它让团队知道这不是一个”必须做完”的项目，而是一个可以停的实验，从而更愿意报告坏消息。

四、专业判断逻辑：项目价值的四层建模

把价值算成钱是很多团队的第一反应，也是最大的陷阱。因为大量真实价值根本落不到当年的财务报表上，硬算只会得到一堆经不起追问的数字。我的做法是分四层建模，每层用不同的证据形式。

1. 第一层：财务层，能直接算成钱的

财务层只包含三类：新增收入、直接成本节约、罚金或赔偿的规避。这一层的证据要求最硬，必须有可追溯的计算链路。

常用的三个指标是净现值、投资回收期、投入产出比。但我更看重第四个指标：收益归因强度。也就是项目上线后，这个收益有多少比例可以归到项目本身，而不是市场大盘、季节波动或其他并行项目。

归因强度低于 40% 的财务预测，我建议在评审时直接打七折看，因为结项时几乎一定会被质疑。

2. 第二层：运营层，不直接算钱但可测量

运营层覆盖周期时间、吞吐量、质量率、人力占用、返工率这几类指标。它们的共同点是：可以精确测量，但换算成钱的路径较长且容易被质疑。

我的建议是在立项阶段就把换算规则定死，比如”每减少 1 小时人工处理时间折算 0.015 人天”、”每次生产事故折算 4 小时团队中断”。规则先定，后面就不需要重复争论。

运营层指标的一个额外好处是：它们变化快，通常在项目上线后 4 到 8 周就能观察到趋势，而不像财务指标要等到年度结算。

3. 第三层：期权层，战略与选择权

期权层的价值在于”如果这个方向成立，我们能不能快速放大”。典型场景包括：平台化能力的沉淀、关键客户的进入资格、新渠道的测试、技术栈的切换能力。

期权层的价值没法用净现值算，但可以用三个替代信号来评估：复用度（未来有多少项目能直接用到这套能力）、不可逆性（如果不做，未来重做的成本有多高）、窗口期（这个选择权在多久之内会失效）。

我在评审里经常用这三条把”看起来算不过账”的项目救回来，也用它把一些”看起来很战略”的项目打回去，如果复用度低、不可逆性也低，那它就不是期权，只是一次普通投入。

4. 第四层：风险层，不做会怎样

风险层的表达方式不是收益，而是风险敞口的变化。写清楚三个数：当前敞口多大、发生概率多高、发生后损失多少。

举个例子：某系统的单点故障概率按历史数据是每年 0.8 次，每次平均造成 6 小时业务中断，按每小时 15 万元损失计算，年化风险敞口约 72 万元。做高可用改造投入 40 万元，把概率降到 0.1 次，年化敞口降到 9 万元。这一层就讲清楚了。

风险层最忌讳的说法是”为了安全”、”为了合规”。没有敞口数字的风险论证，在资源紧张时永远排不上优先级。

5. 四层加权：一张可以落地的评分卡

四层不能简单相加，因为它们量纲不同。我的做法是分两步：先给每层打分（0 到 5 分），再按项目类型套用不同权重。

这套权重不是拍脑袋定的，它来自我们内部对二十三个已结项项目的回测：按这套权重排出来的优先级，与实际结项价值排名的吻合度在 70% 左右，比单纯按财务净现值排序（吻合度约 45%）明显更高。

五、项目价值全流程的七个环节

下面这七个环节是我目前使用的工作流，覆盖从想法产生到结项结算的全程。每个环节我都会写清楚产出物、判断标准和最常见的坑。

1. 环节一：机会识别与价值触发点

这一环的产出物是机会清单，每条包含触发事件、受影响人群、当前痛点表现。触发事件可以是数据异常、客户投诉、竞品动作、政策变化。

判断标准只有一条：能不能指出一个具体的”触发点”。如果只是”感觉应该做”，那就先放进观察池，不进立项流程。

常见坑是把解决方案混进机会描述。写成”需要做一个自动化对账系统”就已经跳到方案了，正确的写法是”财务每月人工对账耗时 62 人时，且近三个月出现 4 次差错”。

2. 环节二：价值假设与反证条件

产出物是一句话价值假设加一条反证条件。格式我固定为：如果我们做 X，那么在 Y 时间内，指标 Z 会从 A 变化到 B；如果 Z 在 Y 时间内的变化小于 C，则假设不成立。

反证条件的关键是把阈值写具体。写”效果不达预期就调整”没有意义，写”6 个月后周活跃低于 25% 则停止扩展”才有约束力。

这一环最容易犯的错是阈值定得过于宽松，本质上是给自己留后路。我的经验是把阈值定在”自己心里觉得有点悬”的位置，这样的评估才有信息量。

3. 环节三：量化建模与基线固化

产出物是价值模型 + 基线数据快照。价值模型要包含四层里的至少两层，基线快照要包含指标定义、统计口径、取数位置、观察周期。

我在这里加了一个强制动作：基线必须由数据方或财务方确认，不能由项目发起方单独提供。这一条挡住了大量”为了过关而美化基线”的情况。

常见坑是基线只取一个点。单点数据无法判断波动，我要求至少取 3 个完整周期的数据，并标注波动区间。这样结项时才能判断变化是否超出正常波动。

4. 环节四：立项评审与分级授权

产出物是立项决议，包含价值假设、基线、资源档位、阶段门条件、责任人和结算时点。

我把授权分成三档，不同档位的评审深度和材料要求完全不同：

• A 档（重大）：跨部门、周期超过 6 个月或投入超过年度预算 5%。要求完整四层模型、外部对标、分期验收。
• B 档（常规）：单部门、周期 2 到 6 个月。要求两层模型、明确基线、单次验收。
• C 档（小步）：周期小于 2 个月或投入低于阈值。只要求一句话价值假设加观察指标，允许先做后补。

分级授权的价值在于把评审资源集中到真正重要的项目上。我见过太多组织用同一套流程评审所有项目，结果是重大项目评审不足、小项目被流程拖死。

5. 环节五：执行期的价值跟踪

产出物是价值跟踪看板，按周或按月更新实际指标与基线的差距。这一环最容易被忽略，因为项目一旦启动，团队全部精力都扑在交付上。

我的做法是把价值跟踪做成”轻量强制”：每个项目在管理平台里必须挂一个价值指标卡，每次迭代回顾时花 5 分钟更新一次。不做深度分析，只记录数字和趋势。

关键在于让价值指标和执行看板出现在同一个地方。如果价值指标躺在某个人的 Excel 里，它三个月后就会消失。这也是我在选工具时最看重的一点：需求、迭代、缺陷和业务指标能不能在同一个视图里被关联起来。

在中大型研发组织里，这一点的落地难度比想象中大。我们后来在一个 320 人的研发组织里，把需求、迭代、工时和价值指标统一挂到了 PingCode 上，通过自定义字段和报表把”这个需求属于哪个价值假设”变成了必填项。这个动作看起来很小，但它让价值跟踪从”额外工作”变成了”流程自带”。

6. 环节六：阶段门与止损决策

产出物是阶段门决议，三种结果：继续、调整范围、停止。我要求每个阶段门的决议必须写明依据的数据，不允许只写”综合评估认为可以继续”。

这里有个心理陷阱：团队会倾向于”再给一次机会”。我的应对办法是在立项时就把阶段门的次数写死，比如”A 档项目最多两次调整机会，第三次触发强制停止评审”。

止损不是失败，它是一次成功的信息获取。我经常在复盘里强调：在第 4 个月停掉一个错误项目，比在第 12 个月勉强交付一个没人用的系统要成功得多。

7. 环节七：结项价值结算与复盘

产出物是价值结算报告，包含实际值与立项承诺值的对比、差异原因、归因强度评估、可复用经验。

结算时点必须在立项时就确定，并且要留足爬坡期。我通常建议运营层指标留 3 个月、财务层指标留 2 个完整业务周期。

复盘时我最关注一个数字：立项承诺值与实际值的偏差率。这个数字不是用来追责的，而是用来校准团队的预测能力。把连续多个项目的偏差率放在一起看，你就能知道这个团队的立项预测整体偏乐观还是偏保守，下一次评审时就有调整依据。

六、案例与数据观察：一个 320 人研发组织的价值闭环改造

1. 背景与约束

这家公司是做企业级软件的，研发体系约 320 人，分布在四个产品线。改造前的情况很有代表性：立项文档平均 22 页，评审通过率 91%，结项时无法量化价值的项目占比 64%。

约束也很明确：不能增加流程节点，管理层不接受”再加一道审批”；研发团队对填表极度反感；四个产品线的业务指标口径不统一。

这三个约束决定了改造方向不能是”加流程”，只能是”换载体”，把价值信息嵌到已有的工作流里。

2. 他们真正改动的三个动作

改造持续了 6 个月，最终落地的是三个动作，看起来都不复杂。

1. 把立项文档从 22 页压到 1 页加附件。一页纸必须回答价值假设、基线、止损条件三件事，其余内容放附件，评审时只看一页纸。
2. 在需求管理里增加”价值假设编号”必填字段。每个需求都必须挂到一个价值假设上，否则无法进入迭代规划。这一步把价值跟踪变成了流程的副产品。
3. 建立阶段门机制，A 档项目至少两个阶段门。阶段门不做汇报，只看数据，30 分钟结束，结论只有继续、调整、停止三种。

值得注意的是第二个动作。以前他们试过让团队每月手工填报价值跟踪表，执行了三周就名存实亡。改成必填字段加自动报表之后，数据完整度从 21% 提升到 94%，而团队感受到的额外负担反而下降。

原因很简单：数据采集点离工作现场越近，留存率越高。让研发在创建需求时顺手勾一个归属，比让产品经理月底回忆这个月哪些需求服务了哪个价值假设要可靠得多。

3. 18 个月后的数据观察

改造后运行 18 个月，我跟踪到几组数据，其中有些结果超出预期，有些则低于预期。

评审通过率从 91% 降到 68%，被很多人当成负面信号，我的判断正好相反。通过率下降说明评审真正开始起作用了，而不是变成橡皮图章。这 23 个百分点里，有一部分本来就是不该立项的项目。

低于预期的是阶段门数量。原本设想每个 A 档项目都至少触发一次范围调整，实际只有 9 个项目触发。原因在于阶段门的数据依赖仍然偏重人工整理，尤其在跨产品线的项目上，指标口径统一花了比预想更多的时间。

4. 私有化部署与迁移给立项带来的额外变量

这家公司的客户里有相当比例是金融机构和大型制造企业，因此在工具选型上有一个硬约束：必须支持私有化部署，且数据不能出内网。这个约束直接改变了立项时价值模型的算法。

具体来说，它把”工具成本”从一个简单订阅费变成了四项：软件授权、内网部署与运维人力、版本升级带来的停机窗口、以及安全审计的配合成本。如果立项时只算订阅费，价值模型会低估 30% 到 40% 的总拥有成本。

另一个变量是迁移。他们当时从一套国外研发管理工具迁移过来，涉及约 11 万条历史工作项、3 年的迭代记录和大量自定义字段。这类迁移如果当成”技术任务”处理，通常会在立项时严重低估工作量；它实际上是一个数据治理项目，需要单独的价值论证。

他们最终采用的是支持 Jira 平滑迁移的国产平台方案，把迁移拆成三个批次，每批次迁移后做一次数据完整性校验。整个迁移阶段用时约 7 周，比最初估算的 3 周多出一倍多，但因为没有把它当成”顺手做掉的事”，延长的时间在立项文档里已经被预留，没有打乱主线排期。

这段经验后来成了我们内部的一条立项规则：凡是涉及平台替换的项目，必须单独立一个”迁移与数据治理”子项，给它独立的预算和阶段门，不允许挂靠在主项目下面一笔带过。

七、不同情况下的行动建议

1. 二十人以下团队：把立项做成一页纸，别做流程

这个规模的团队最大的风险不是立项不严谨，而是流程把速度拖死。我的建议是只保留三件事：一句话价值假设、一个观察指标、一个复盘时点。

不要做四层模型，不要做加权评分卡，也不要引入任何需要专门维护的立项系统。用协作文档写清楚，口头对齐即可。你真正的优势是决策链短，别自己把这个优势拆掉。

2. 一百到五百人组织：这是价值管理收益最高的区间

这个规模的组织会出现”部门墙”和”资源争夺”，立项开始变成跨部门博弈。此时最大的痛点是价值无法归因、优先级无法排序。

我的建议是重点建设三样：统一的指标口径字典、分级授权机制、以及价值信息与工作流的绑定。前两样是制度，第三样是工具。三样缺一，流程都会退化回”谁嗓门大谁先做”。

工具绑定的具体做法，是把价值假设做成工作项上的必填字段，而不是另开一张表。这一点对中大型组织尤其重要，因为一旦需要人工二次录入，数据完整度就会断崖式下跌。我给这个规模组织的建议是选择支持需求、迭代、测试、报表一体化，并且能承载千人级协作的平台，把价值跟踪嵌进日常研发流程，而不是外挂一套项目管理工具。

3. 五百人以上或多事业部组织：重点是把口径统一，而不是把流程变细

这个规模下，最贵的成本是口径不一致导致的重复论证。同一个”交付周期”指标，A 事业部从需求受理算起，B 事业部从排期算起，放在一起排名单就会引发争议。

我的建议是先花两个月建指标字典，定义清楚每个指标的名称、计算方式、取数系统、责任部门。这件事看起来枯燥，但它决定了后面所有价值管理的可信度。

流程上反而应该做减法：统一由集团层面管 A 档项目的阶段门，B、C 档完全下放，不做统一模板。集团层面只关注跨事业部资源冲突和战略级价值假设。

4. 强监管与信创场景：把合规成本前置进价值模型

金融、医疗、政务等领域的项目，合规成本往往占总投入的 25% 到 40%。如果在立项时按通用模型估算，最终一定会超支。

我的建议是在立项文档里单列一节”合规与部署约束”，写清楚数据驻留要求、审计配合要求、部署形态要求，并把这些约束对应的成本单独估算。同时，工具选型要优先考虑支持私有化部署的方案，因为后期从公有云迁移到私有环境的成本远高于一开始就选对。

这一条也是我在中大型组织里反复强调的：部署形态不是技术细节，它是立项阶段就要锁定的价值变量，因为它直接决定运维成本、审计成本和未来的迁移成本。

八、不同情况下的取舍

1. 严谨度与速度的取舍

立项做得越严谨，决策质量越高，但决策速度越慢。这个取舍没有统一答案，只有一个判断依据：试错成本有多高。

如果项目失败的成本主要是浪费几周人力，那就该快，甚至允许先做后补立项。如果失败成本涉及不可逆的技术架构、客户关系或合规风险，那就必须慢，宁可在立项阶段多花两周。

2. 财务量化与运营量化的取舍

能用财务量化的项目，优先用财务量化，因为它在跨项目比较时最有说服力。但不要强行把运营价值换算成钱，换算链条越长，越容易在结项时被质疑。

我的处理方式是双轨制：财务指标用于对外汇报和跨部门排序，运营指标用于团队内部的进度跟踪和阶段门判断。两套指标服务于不同场景，不要合并成一套。

3. 自建工具与采购平台的取舍

自建的价值跟踪系统看起来贴合业务，但隐性成本很高：维护成本、人员流动带来的知识断层、以及无法复用的报表能力。我见过三个自建的立项管理系统，其中两个在负责人离职后半年内停用。

采购平台的代价是适配成本，需要把价值假设、基线、阶段门这些概念映射到平台的对象模型上。这个映射工作通常需要两到四周，但一旦完成，就获得了一个可持续维护的载体。

我的判断标准是：如果团队超过 100 人，且立项与价值跟踪需要常态化运行，优先选采购平台；如果团队小于 30 人，用文档和表格反而更灵活。

4. 一张表讲清四种取舍

5. 一个常被忽略的取舍：立项的“完成度”

很多团队追求立项文档的完成度，恨不得把所有细节都敲定。但立项的本质是决策，不是设计。花在文档细节上的时间，边际收益下降得非常快。

我的经验值是：立项阶段的调研时间占总投入的 3% 到 8% 比较合理。低于 3%，基线大概没做扎实；高于 8%，你很可能在用立项拖延真正的决策。

九、一页纸立项模板：可以直接抄走

1. 模板的七个字段

我把这份模板压到七个字段，任何一个字段写不出来，就说明这个项目还没想清楚。下面是我实际在用的结构。

• 价值假设：一句话，包含动作、时间、指标和变化量。
• 基线：当前值、口径、取数位置、观察区间。
• 主价值类型：财务、运营、期权、风险，四选一。
• 四层得分：每层 0 到 5 分，附一句评分理由。
• 阶段门条件：时间点、观察指标、触发阈值、对应动作。
• 资源与机会成本：需要多少人月，以及这些资源原本要做什么。
• 结算时点与口径：什么时候算价值，用哪个系统的哪个指标算。

2. 模板的可复制版本

下面是我给团队用的纯文本模板，直接复制到协作文档里填即可。

项目名称：
提出人 / 责任人：

日期：

【价值假设】

如果我们 ______（动作），那么在 ______（时间）内，

______（指标）会从 ______（当前值）变化到 ______（目标值）。

反证条件：如果 ______（时间）内该指标变化小于 ______，

则假设不成立，触发 ______（动作）。

【基线】

当前值：

统计口径：

取数位置（系统 / 报表 / 字段）：

历史观察区间：

波动范围：

【主价值类型】（四选一）

财务 / 运营 / 期权 / 风险

【四层得分】（0-5 分，附一句理由）

财务层：___ 分，理由：

运营层：___ 分，理由：

期权层：___ 分，理由：

风险层：___ 分，理由：

【阶段门】

门 1：___ 月，观察 ______，阈值 ______，低于阈值则 ______

门 2：___ 月，观察 ______，阈值 ______，低于阈值则 ______

最多可调整次数：___ 次

【资源与机会成本】

所需人力：___ 人月

所需预算：___ 万元

机会成本：这些资源原本用于 ______，延后影响是 ______

【结算时点与口径】

结算时点：

结算口径：

结算数据来源：

归因强度预估：___%

3. 填写时最容易出错的四个字段

第一是”反证条件”。90% 的人第一次填会写成”效果不达预期”，这等于没写。反证条件必须是一个可以被系统自动算出来的数字。

第二是”机会成本”。很多人空着不填。但这一栏恰恰是评审会上最有信息量的部分，它让决策者看到真实的选择。

第三是”归因强度预估”。这是最难的字段，也是最有价值的字段。填了它，结项时就不会出现”收益到底算谁的”这种争论。

第四是”结算时点”。写”上线后”是无效的，必须写到具体月份和具体指标。我要求写到”上线后第 3 个完整自然月末，以 XX 系统 XX 报表为准”。

十、关于立项与项目价值的常见问题

1. 立项阶段必须要算出 ROI 吗？

不一定。ROI 只适用于财务层价值占主导的项目。对于平台能力类、合规类项目，强行算 ROI 会得到一个很低的数字，然后导致项目被错误砍掉。

我的建议是：如果财务层得分低于 2 分，就不要用 ROI 作为主要论证方式，改用运营指标或风险敞口来表达。形式服务于内容，不要为了统一格式牺牲判断质量。

2. 基线数据拿不到怎么办？

先补观察期，不要跳过。如果系统里没有现成数据，可以先用人工取样建立基线，但要明确标注样本量和取样方式。

我的经验是，两周的人工取样通常就能得到可用的基线。花两周换一个可结算的价值基础，性价比很高。如果连取样都做不到，说明这个项目的价值根本无法被验证，立项时要格外谨慎。

3. 阶段门会不会拖慢项目节奏？

会，但拖慢的量远小于它挽回的损失。我们在样本组织里统计过，每次阶段门平均耗时 30 到 45 分钟，一个 A 档项目两个阶段门合计不到 1.5 小时。

真正拖慢节奏的不是阶段门本身，而是阶段门之前的材料准备。如果要求团队为阶段门写汇报文档，成本会放大十倍。所以我的做法是阶段门只看数据和结论，不看文档。

4. 小团队或者需求变化快的业务，还需要做完整立项吗？

不需要做全套，但必须保留两样：一句话价值假设和一个观察指标。这两样东西的成本不到 15 分钟，但它们能防止团队在半年后完全不知道自己当初为什么做这件事。

变化快的业务尤其需要这个。因为变化快意味着方向调整频繁，而调整的前提是你知道当前方向原本要解决什么问题。

5. 价值跟踪应该由谁来负责？

我的答案是产品经理负责定义和归因，数据方负责取数和校验，项目负责人负责在阶段门上做决策。三方分开，避免自证清白。

最容易出问题的环节是归因。如果让项目团队自己判断收益归因，结论通常偏乐观。我的做法是引入一个相对独立的角色，哪怕只是在结算会上提出质疑，也能显著提高归因的严谨度。

6. 立项通过后，价值假设可以修改吗？

可以修改，但必须走变更流程，并且保留原始记录。我要求每次修改都记录修改原因、修改人和修改时间，形成一条可追溯的链路。

这条纪律的价值在结项复盘时才体现出来。你能看到这个项目的价值假设被修改了几次、每次因为什么，这本身就是判断团队立项能力的重要信号。修改次数多但没有对应的新证据支撑，说明当初的立项就是想当然。

结语：立项是产品经理最高杠杆的一次判断

我做了这么多年立项评审，最深的一条体会是：产品经理能创造的最大价值，往往不在把需求做得多好，而在于决定不做哪些需求。立项这一步，正是这个判断发生的地方。

把立项做成一场文档表演，团队会在执行期用返工和价值偏差来还债；把立项做成一次严谨的价值假设加可撤销的承诺，团队才能在有限资源下持续做对的事。

如果你现在就想动手，我建议按这个顺序推进：先用两周时间，把手上正在进行的项目全部补一份一页纸的价值假设和基线；然后在下一个 A 档项目上试一次双阶段门；最后再考虑把价值字段绑进日常的研发管理流程。顺序别反，制度先于工具，工具只是让制度能被持续执行。

等到你能在结项会上拿出”立项承诺 900 万、实际 735 万、偏差率 18%、归因强度 74%”这样一组数字时，你会发现关于立项的争论忽然变少了。不是因为大家变得更好说话，而是因为你们终于有了同一套可以讨论的事实。