项目价值落地方案：项目成员开展项目立项的流程优化案例解析

2023 年 9 月，我作为外部顾问进入一家 600 人规模的 SaaS 公司，对方给我的第一份材料是一份 27 页的《项目立项申请说明书》。写这份材料的人不是项目经理，而是一位入职刚满 4 个月的后端工程师，因为按当时的流程，谁提出需求，谁就负责把立项书写完。

我问他：这 27 页里，有哪一句是你自己真的相信的？他停了十几秒，说：第三页那个”预计年化收益 480 万元”，是上一版同类项目抄过来的，因为模板里必须填。

那次立项会开了 3 小时 40 分钟，最终结论是”原则通过，需要补充材料”。项目 11 个月后上线，日活只有预期值的 6%。复盘时我们发现，会上被讨论最久的”收益测算”，从头到尾没有一个人做过真实的用户验证。

这就是我想在这篇文章里拆开讲的问题：立项流程最大的浪费，不是耗时长，而是它把所有人的注意力，系统性地引导到了错误的证据上。而项目成员，那些真正在一线接触用户和代码的人，在这个流程里，往往只被允许扮演”材料填写员”的角色。

接下来我会讲清楚三件事：立项流程优化的核心目标为什么不是”更快开始”，而是”更能否决”；项目成员如何在立项阶段获得真实的话语权；以及流程改进为什么总在三个月后回弹，以及怎么用平台把它钉死。

一、核心结论：立项流程要做的是”筛掉不值得做的项目”，不是”让项目快点开始”

先给结论，再给论证。这是我在 7 个立项流程改造项目里验证过、也失败过之后，最确定的一条判断。

1. 我得到的第一条结论：立项流程的合格线是”能否被否决”

判断一个立项流程好不好，不要看它跑得多顺，要看它有没有真的拦下过项目。

我在 2023 到 2025 年间，以顾问或内部负责人身份参与过 7 家组织的立项流程改造：3 家 200 到 800 人的技术公司、2 家制造企业的数字化部门、1 家金融科技公司、1 家跨境电商公司。其中 3 次改造是失败的，失败的表现高度一致：流程更”完整”了，表格更”规范”了，但三个月后所有人又回到了老样子。

复盘时我发现，这 3 次失败都有一个共同点：我们把优化目标设成了”缩短立项周期”，而没有设成”提高立项决策的准确度”。周期确实短了两三天，但立项质量没变，于是流程被当成负担，慢慢被绕过。

2. 通过率是一个反向指标

这是我在这篇文章里最想强调的一条反常识判断：如果一个组织的立项通过率长期高于 90%，那么它的立项流程几乎一定是在走形式。

逻辑很简单。立项的本质是在信息不完整的情况下，对”这件事值不值得投入资源”做一次判断。如果每次判断的答案都是”值得”，要么是这个组织运气好到不真实，要么是这个判断根本没在筛东西。

我在 4 家数据可比性较强的样本组织中，观察到一个稳定的负相关：最终立项通过率越低的团队，结项时的价值达成度评分反而越高。原因不复杂，他们真的把”不做”当成一个合法结论。

3. 立项流程必须同时承担的三个功能

我把立项流程的功能拆成三层。多数团队只做了第二层，第一层和第三层基本空缺，所以流程看起来在运转，实际上没有产出决策价值。

• 第一层：价值假设的显性化。把”我们相信用户会因为 X 原因选择这个功能”写成一句可以被证伪的话。注意是”可证伪”，不是”听起来合理”。
• 第二层：资源承诺的边界确认。明确投入多少人、多久、什么时间点做第一次检查。这一层是大多数流程唯一在做的部分。
• 第三层：失败的可回退设计。事先写清楚在什么条件下终止、终止时怎么收尾、已经产生的资产（代码、数据、用户认知）如何复用。

第三层是区分”流程”和”形式”的分水岭。一个没有提前写终止条件的立项，本质上不是立项，是承诺。

4. 一个反直觉的推论

基于上面的三层结构，可以推出一个反直觉的结论：立项流程优化的第一优先级，是让”否决”变得便宜，而不是让”通过”变得容易。

当否决的成本很低，不需要重新排期、不需要重新走一遍材料、不会被认为是”阻碍业务”，决策者才会真的用否决权。而当下否决的成本很高时，所有人都会选择”有条件通过”，把判断推迟到执行阶段，把风险留给未来。

二、背景还原：那份 27 页的立项申请说明书是怎么写出来的

回到开头那家 SaaS 公司。我需要把这件事的完整链路讲清楚，因为它几乎是我见过的立项流程问题的标准样本。

1. 事件时间线

我把当时的关键节点还原了一下，方便你对照自己组织的情况。

整条链路消耗了约 43.5 人时，其中真正产生决策价值的可能不到 3 人时。剩下的人时，花在了把数字从一个文档搬到另一个文档，以及在一场没有假设验证的会上讨论这些数字是否”合理”。

2. 项目成员在立项流程里的真实位置

那位后端工程师在整个过程中的角色，是”信息搬运工”。他被要求提供工时估算、技术方案概要、风险清单，但他从来没有被问过一个更重要的问题：以你对现有系统了解的程度，这个功能在架构上会不会变成一个长期的负担？

这个问题只有他答得出来。但流程里没有这个字段。

我在调研中统计过一个细节：在 5 家组织的立项模板里，”技术可行性”一栏的填写说明全部是”请评估实现难度与工时”。没有一家问”这个方案会不会让未来的迭代变慢”。前者是排期问题，后者是价值问题。

3. 我见到的四种立项流程形态

把 7 个样本归纳一下，基本落在四种形态里。你可以对照看自己组织接近哪一种。

4. 改造前的典型基线

我想先给一组基线数据，因为后面讲改造效果时需要对照。这组数据来自 3 家规模在 200 到 800 人之间、改造前处于”表单审批型”的样本组织，取改造前 6 个月的平均值（数据已脱敏，属于我个人的观察样本，不是行业统计）。

• 立项平均周期：11.4 天
• 立项材料平均页数：27 页
• 立项会平均时长：142 分钟
• 单项目立项投入人时：43-48 人时
• 立项后 30 天内需求变更率：31%-41%
• 结项时价值达成度评分（5 分制，业务方与交付方双评）：2.8-3.0

注意最后一组数字。立项投入接近 46 人时，而结项时的价值达成度评分不到 3 分。这个投入产出比，比很多被立项会否决掉的项目还要差。

三、六个常见误区：为什么”更完整的立项流程”往往更差

这一章是我在复盘时最有挫败感的部分。下面六个误区，我在自己的项目里至少犯过四个。

1. 误区一：把立项当成资源申请

资源申请的逻辑是”我要 3 个人、8 周时间”。价值假设的逻辑是”我判断用户在某个场景下会因此改变行为，如果两周后数据显示没有改变，我们就停”。

两者的差别在决策依据上。资源申请型的立项，评审时争的是”3 个人够不够”；价值假设型的立项，争的是”这个判断成不成立”。前者讨论的是执行效率，后者讨论的是方向正确性。方向错了，效率越高损失越大。

2. 误区二：用文档完备度替代决策质量

这是最常见的替代性错误。因为”这份材料写得全不全”容易判断，”这件事值不值得做”很难判断，所以流程天然会滑向易判断的那个。

表现之一是模板越来越长。我见过一份立项模板包含 43 个必填字段，其中 11 个是”如无不填”，那为什么还要放在那里？

3. 误区三：审批节点越多越严谨

审批节点的真实作用，是把决策责任分散到多个角色身上。责任一旦分散，就没有人对判断结果负责。

我统计过一次：在一家 3 级审批的组织里，被问到”这个项目当初为什么通过”时，3 位审批人给出的答案分别是”业务方坚持”、”技术评估没问题”、”上面同意的”。没有一个人的答案涉及价值判断本身。

4. 误区四：项目成员只被允许提供工作量

这一条直接关系到本文标题。项目成员在立项阶段的输入，被压缩成了一个数字：人天。

但实际上，一线成员掌握着三种稀缺信息：真实的技术债状态、用户的直接反馈、以及”我们上次做类似事情时踩过的坑”。前两种在立项会上几乎从不出现，第三种通常只存在于老员工的记忆里。

5. 误区五：立项通过即流程终点

没有回看机制的立项，本质上是一次无法校准的判断。你不知道自己当初的判断准不准，也就无法改进判断能力。

我在一家公司做过一个小实验：要求所有项目在结项时填一行”立项时写的假设是否成立”。三个季度后，他们的立项通过率从 92% 降到了 67%，而结项价值达成度从 2.9 升到了 3.6。变化的原因不是流程改了，而是评审者开始知道自己的判断会被回看。

6. 误区六：用页数、字数衡量立项质量

这条几乎不需要解释，但它非常普遍。当立项材料字数成为一个被观察的指标时，所有人都会去凑字数。

下面这张图是我在一家 400 人公司里，按六个误区的典型表现统计的”平均返工耗时”。返工指的是因该误区导致的材料重写、会议重开、方案重做。

四、专业判断逻辑：最小可决策信息集与角色分离

讲完问题，讲我认为可行的解法。这一章是整篇文章的方法论核心，也是我在改造中反复调整后保留下来、真正跑得通的部分。

1. 立项决策真正需要回答的三个问题

把所有立项材料压缩，评审需要回答的其实只有三个问题：

1. 我们相信会发生什么？（假设）
2. 如果发生了，对我们意味着什么？（价值）
3. 如果没发生，我们怎么知道、什么时候知道？（验证与终止）

这三个问题答不清，材料写 50 页也没用。答清了，一页纸就够。

2. 最小可决策信息集（MDIS）的六个字段

基于这三个问题，我设计了一个”最小可决策信息集”，实际落地下来是六个字段。它的设计原则是：多一个字段都要能说清它改变了哪个决策。

注意第三和第四栏的填写人是”核心执行成员”，不是项目经理。这是本文标题里”项目成员开展项目立项”的具体含义：不是让成员写更多材料，而是让他们填两个真正需要专业判断的字段。

3. 终止条件怎么写才有用

我见过大量写成”如果效果不及预期则终止”的条件，这种写法等于没写，因为”不及预期”没有主语。

（1）必须带时间点。“上线后第 6 周”而不是”上线后”。

（2）必须带数值和口径。“周活跃使用率低于 8%（口径：目标用户群中每周至少使用 2 次的账号占比）”。

（3）必须事先指定谁来看这个数。没有指定人的条件会自动失效。

我建议的写法示例（这是我在实际项目中用过的模板，可以直接改）：

终止条件：

检查点：上线后第 6 周（含灰度期）

判断指标：周活跃使用率，口径 = 目标用户群中每周使用≥2次的账号占比

终止阈值：低于 8%

观察窗口：连续 2 周

决策人：业务负责人（数据由数据组在每周一 10:00 前提供）

终止动作：停止后续迭代投入，保留已完成的数据管道与标签结构，转入下一个假设验证

写得这么细，不是为了形式，是为了让”终止”这个动作在发生时不带有情绪成本。当条件是事先约定的，停止就不是失败，而是流程正常运转。

4. 角色分离：谁检查完备性，谁判断价值

这是我在失败两次之后才想清楚的一点：必须把”信息完备性检查”和”价值判断”拆给不同的角色。

前者是事务性工作，检查六个字段是否填了、格式是否对、数据源是否标注。这个工作可以交给流程协调人，甚至可以由系统自动完成。

后者是决策工作，判断这个假设是否值得投入资源验证。这个工作只能由对这个业务结果负责的人来做。

混在一起的后果是：决策者花了大量时间在检查字段是否填全，而不是在判断假设是否成立。这就解释了为什么很多立项会开 2 小时以上，却没有任何实质分歧。

5. 不同项目类型的字段权重不一样

需要说明的是，六个字段不是等权重的。项目类型不同，决策关注的字段也不同。我在改造中会按类型调整权重，避免所有项目走同一套标准。

五、案例与数据：一家 600 人 SaaS 公司的”一页纸预立项 + 30 分钟决策会”

这一章讲完整案例。之所以选这家公司，是因为它的改造幅度最大、数据跨度最长（改造前 6 个月 + 改造后 12 个月），而且踩过的坑最有代表性。

1. 改造前的流程

就是第二章里描述的那套：全员填模板、三级审批、立项会 140 分钟以上。我进场时他们刚经历完一次失败的项目，管理层对”立项流程”的意见非常分裂，一派认为要更严，一派认为干脆取消。

2. 五个改造动作

我们没有一次推翻，而是分三步走，最后落地成五个动作。

1. 把立项拆成”预立项”和”正式立项”两段。预立项只需一页纸、六个字段，由提出人和核心执行成员共同完成，目标是把假设说清楚，不涉及资源承诺。
2. 把审批改成”单点 + 异议触发”。默认由业务负责人单点决策，只有当技术负责人或数据方主动提出异议时，才升级到决策会。
3. 把决策会压缩到 30 分钟，且只讨论分歧。没有分歧的项目不进会。有分歧的项目，会前 24 小时把分歧点写清楚，会上只针对分歧讨论。
4. 引入”立项后 30 天变更率”作为流程质量指标。这个指标的逻辑是：如果立项时信息是准的，30 天内的需求变更应该很少。
5. 建立”立项-结项”对照。每个项目结项时必须回填立项时的假设是否成立，由数据方核对，不用自评。

3. 改造后的数据

下面是改造前 6 个月与改造后 12 个月的平均值对比。需要说明：这个样本受到同期业务节奏变化的影响，不能完全归因于流程改造，但趋势足够清晰。

这里有一组看起来矛盾的数据需要解释：一次通过率上升了 35 个百分点，但最终通过率下降了 33 个百分点。

这不矛盾。一次通过率上升，说明材料质量变好了，不再需要反复补充，所以效率提升了。最终通过率下降，说明筛选变严格了，更多项目被否决，但否决不是在上会时临时拍脑袋，而是在预立项阶段通过终止条件的设置就自然筛掉了。

4. 工具层：为什么流程改进会在 3 个月后回弹

这是我必须单独讲的一段，因为它是我前两次失败的直接原因。

在那两次失败里，我们把新流程写成了文档，做了培训，前两个月执行得很好。第三个月开始，新入职的成员不知道有这套流程，老成员在赶进度时跳过预立项直接开工，PMO 拿不到数据也就无法监控。流程的载体是文档和记忆，而不是系统，所以它会随着人员流动和进度压力自然衰减。

很多团队其实已经在用某项目管理工具承载需求和任务，但只用到了看板功能。立项信息散落在 IM 聊天记录、在线文档和邮件里，形成不了可查询、可对比、可回溯的数据。这种情况下，流程改进的成果是存不住的。

5. 用平台把闭环钉死

那家 600 人公司最终选择把六个字段做成工作项属性，落到项目管理平台里。他们评估时的一个关键要求是：立项、执行、结项三个阶段的数据必须能自动串起来，而不是靠人工整理。

具体做法上，他们把六个字段做成必填属性，并设置了三类视图。

立项工作项字段配置（示意）：

value_hypothesis 文本，必填，限制 200 字以内

validation_method 文本，必填，需关联指标定义

min_investment 数值，必填，单位：人日

tech_constraint 单选，必填，选项：无长期负担 / 需重构 / 引入新依赖

kill_criteria 文本，必填，需包含时间点与阈值

asset_reuse_plan 文本，选填，终止时变为必填

视图配置：

立项池视图：按技术约束分组，快速识别同架构影响的项目聚集

分歧待决视图：异议标记为"待决策"的项目，按提出时间排序

立项-结项对照视图：立项时假设 与 结项结论 并排展示

流程质量视图：立项后 30 天需求变更率，按季度趋势展示

他们最终选择的是 PingCode。选它的原因有三个，都是实际评估中出现的硬约束。

第一是字段与流程的可配置程度。立项六个字段需要作为工作项的强制属性，并且要能被视图筛选、被度量报表引用。PingCode 在这方面的自定义能力足够支撑，不需要外挂额外的表单系统。

第二是度量能力。这家公司最看重的是”立项后 30 天需求变更率”这个指标，它需要把立项时间、变更记录、工作项状态变化关联起来算。如果平台只能出任务完成率这类基础报表，这个指标就只能靠人工季度整理，那流程很快会再次失效。

第三是私有化部署。他们的立项材料里包含未公开的产品路线、客户名单和预算数字。对于中大型企业来说，立项数据本身就是敏感数据，把预算、客户、技术架构评估放在公有云上，很多公司的安全与合规部门不会放行。PingCode 支持私有化部署，这一点在他们的评估中权重很高。

另外还有一个背景原因值得一提：这家公司原本用的是 Jira，历史项目里沉淀了三年多的立项记录和结项数据。做”立项-结项对照”必须要有历史基线，如果迁移时这些数据丢了，纵向对照就无从谈起。他们评估时明确要求历史项目的自定义字段和状态流转记录能平移到新平台，这一点也是最终选型的关键参考。

需要说清楚适用边界：PingCode 主要服务中大型企业及 100 人以上组织。如果你是 30 人以下的团队，这套字段配置和度量体系是过重的，用轻量的任务工具加一张共享表格就够，强行上系统反而会增加负担。

6. 数据对照带来的一个意外收获

改造后第 10 个月，他们做了一次立项-结项对照的横向分析，发现了一个此前从未注意到的规律：被标记为”引入新依赖”的项目，其结项价值达成度平均比”无长期负担”的项目低 1.3 分。

这个结论在以前是拿不到的，因为”技术约束”这个判断从来没有被结构化记录过。这也是我坚持让核心执行成员填写这个字段的原因，它不是给技术负责人看的，它是给未来的自己看的。

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

这一章给具体动作。我按组织规模和项目类型分组，你可以直接对号入座。

1. 按组织规模：四档不同的立项流程配置

先说一个原则：立项流程的复杂度应该与组织的信息传递成本成正比，而不是与管理层的重视程度成正比。

2. 按项目类型：三种不同的处理方式

（1）探索型项目。六个字段全部必填，最小投入应该显著小于完整交付所需资源。如果最小投入算出来接近完整交付，说明这个假设没法被低成本验证，应该重新设计验证方式。

（2）交付型项目。价值假设通常已由合同或客户确认，可以简化。重点放在”技术约束”和”最小投入”两个字段，因为交付型的风险主要在排期和架构。

（3）合规型项目。取消终止条件字段，改为”合规边界与违规处置”。因为这类项目通常不可终止，写终止条件是自欺欺人。

3. 项目成员自己能立刻做的四件事

如果你是一位普通项目成员，看完这篇文章想马上做点什么，下面四件事不需要任何人批准。

1. 在下一次立项讨论里，主动问一句”我们怎么知道这个假设不成立”。这个问题会自然把讨论从资源拉回到验证。
2. 把”技术约束”写成一句话结论，而不是工时。例如”这个方案会让订单查询链路多一次跨服务调用，后续每次改价都需要同步改动两个服务”。
3. 记录上一次类似项目的实际结果。不需要正式的复盘文档，一条带数据的记录就够。这类信息在立项会上非常稀缺。
4. 在立项材料里保留你的原始判断，不要为了显得保守而修改措辞。如果判断被否决，把否决理由记下来，这是你个人判断力校准的唯一途径。

4. 管理者该让出的三件事

（1）让出”完备性检查”。这件事交给流程协调人或系统自动校验，不要占用决策者的时间。

（2）让出”必须给结论”的压力。允许”暂缓”成为一个正式结论，并明确暂缓后需要补充什么信息。很多无效通过是因为”暂缓”在流程里没有出口。

（3）让出”立项会必须全员发言”的形式。没有分歧的项目不需要发言，有分歧的项目只需要分歧双方说清楚。

七、不同情况下的取舍

这一章讲取舍。所有流程设计都是权衡，没有普适最优解。我把四组最常见的取舍摆出来，每组给出我的判断条件。

1. 轻流程 vs 重流程

轻流程的收益是决策快，代价是高度依赖人的判断力，一旦关键人离开，判断标准就会漂移。重流程的收益是标准一致，代价是周期长、成本高，而且容易退化成形式。

我的判断条件是：看你的业务是否处在假设变化快的阶段。如果核心假设半年内可能推翻，用轻流程，因为重流程赶不上变化。如果核心假设长期稳定（例如合规、基础设施），用重流程，因为一致性比速度更重要。

2. 统一模板 vs 分层模板

统一模板的好处是可比性强，跨项目能做横向分析。分层模板的好处是每个类型关注点更准，填写负担更小。

我的经验是：字段统一，权重分层。也就是六个字段对所有项目都保留，但不同项目类型在决策时的关注权重不同，并且这个权重应该被明确写在评审规则里，而不是靠评审人临场判断。这样既保住了横向可比性，又避免了对无关字段的无效讨论。

3. 工具自动化 vs 人工判断

可以被自动化的部分：字段完备性校验、指标口径统一、变更率计算、立项-结项对照匹配、超期提醒。

不能被自动化的部分：假设是否值得验证、技术约束是否构成长期负担、终止后的资产是否有复用价值。

这里有一个容易犯的错：把”能被自动化的部分”做完就以为流程优化完成了。实际上自动化的价值恰恰是把人的时间释放出来，去做那些不能被自动化的判断。如果自动化之后决策者的时间没有转移到判断上，那自动化只是让流程跑得更快，没有让它变得更准。

4. 严进 vs 快试

严进的逻辑是”想清楚了再做”，快试的逻辑是”用最小成本去验证”。这两者不冲突，但会争夺同一批资源。

我的判断标准是可逆性。如果这件事做错了可以低成本撤回（改一个配置、下线一个功能），用快试。如果做错了会产生长期负担（引入架构依赖、签下长期合同、产生合规风险），用严进。

很多人把这条标准用反了：在可逆的事情上反复论证，在不可逆的事情上快速决策。

八、90 天落地路线与结语

最后给一条可执行的路径。这是我在最近两次改造中用的节奏，不需要一次性推翻现有流程。

1. 90 天三阶段

（1）第 1-30 天：只做一件事，把六个字段加到现有立项材料里。不改流程、不改审批、不改会议。目的有两个：让项目成员开始填”技术约束”和”资产复用”，以及收集一批真实填写样本。

这个阶段的预期是：填写质量普遍不高，这很正常，不要在这个阶段做纠偏培训。

（2）第 31-60 天：拆出预立项，把审批改成单点决策加异议触发。这一步会遭遇最大阻力，主要来自中层管理者对”失去审批权”的担忧。应对方式是把”异议触发”的通道做得足够显眼，让异议权被真实使用几次。

（3）第 61-90 天：建立立项-结项对照，并把它放到平台里自动匹配。这一步是让整个流程自我维持的关键。对照机制一旦运转，”立项时随便写写”的成本就会上升，填写质量会自然提升。

2. 我的核心观点总结

回到标题。项目价值落地的起点不在执行阶段，在立项阶段，但绝大多数组织把立项做成了资源申请的仪式，而不是价值假设的检验。

三条我认为最反常识、也最有用的判断：

• 立项通过率高不是好事。如果每次都通过，说明这个流程没有在筛任何东西。
• 项目成员不该被要求写更多材料，而该被要求填更少但更难的字段。“技术约束”和”失败后资产复用”这两栏，只有他们答得出来。
• 流程改进必须落到系统里，否则三个月后一定回弹。文档和记忆承载不了流程，只有数据能。

3. 下一步你可以做什么

如果这篇文章只让你记住一句话，我希望是这句：下一次立项讨论时，问一句”我们怎么知道这个假设不成立”。

这个问题不需要流程改造，不需要系统，不需要任何人批准。但它会立刻改变讨论的性质，从”这件事怎么做”转向”这件事该不该做”。

如果团队反馈不错，再往下走两步：把六个字段加到现有材料里，把终止条件写成带时间点和数值的句子。等到填写样本积累到二三十个，你会开始看到一些此前从未出现在立项会上的规律。

那时候再考虑流程和平台的事，会顺利得多。因为到那时，需要说服的人已经不是管理层，而是被数据说服的自己。