项目类型最佳实践：研发团队项目立项入门指南，常见问题

去年帮一家 300 多人的研发组织做流程复盘时，我统计到一个数字：他们全年立项 47 个，年底能清楚说出”当初为什么立这个项、现在验证到哪一步”的只有 11 个。剩下 36 个项目，立项文档都在，但那是给审批人看的，不是给项目组用的。更麻烦的是，其中 9 个项目在立项时就已经注定做不成，只是当时没人有动力说破。

这篇内容我想把研发团队项目立项这件事讲透，不是讲流程模板长什么样，而是讲不同类型的项目该怎么用不同的标准去立、立项会上真正该吵的架是什么、以及那些看起来”规范化”的做法为什么反而在放大风险。内容基于我过去几年在十几家研发团队做流程诊断和工具落地的观察，其中会大量出现一个 320 人规模研发组织的真实改造过程。

一、先说结论：研发立项的本质是一次低成本的不确定性定价

我对立项最核心的判断是：立项不是审批动作，是一次用极低成本换取”提前发现错误”的机会。一个项目如果做到中期才发现方向错了，沉没成本可能是一个团队两个月的人力；如果它在立项会上被问倒，成本只有两小时会议时间。立项的全部价值都藏在这个倍数差里。

所以判断立项流程好不好，只有一个标准：它有没有在使用尽可能低的成本，尽可能早地暴露”这个项目不该做”这件事。如果你们的立项通过率是 100%，那这套流程大概率是失效的，它没有在筛掉任何东西。

1. 立项只需要回答四个问题

我见过太多立项文档，写满了背景、意义、技术方案、里程碑，唯独这四个问题一个都没答清楚。我后来给团队做模板时，直接把其他内容全部砍掉，只留这四问：

• 为什么做：背后的价值假设是什么？如果这个假设不成立，会有什么现象？
• 做到什么程度算成功：验收基线是什么？是数字、是能力、还是”客户签字”？
• 谁在什么约束下做：人力上限、时间上限、必须兼容的既有系统、不能碰的边界。
• 什么时候必须停：触发退出的条件是什么？谁来宣布？

第四问是最容易被跳过、也是最有价值的一问。没有退出条件的立项，本质上是把决策权无限期地交给了执行者，而执行者天然倾向于”继续做下去”。

2. 三种项目类型对应三套完全不同的立项标准

把探索型项目和交付型项目放进同一套立项模板，是这个领域最常见、也最致命的错误。探索型项目的特点是”价值假设未验证”，你不可能要求它给出确定的范围和工期；交付型项目的特点是”外部约束明确”，你反而应该要求它把范围锁死。用同一把尺子量，结果就是探索型项目被逼着编数据，交付型项目被纵容着不锁范围。

注意最后一行”失败的定义”。探索型项目的失败是”没拿到结论”，不是”没做出东西”。这一条如果不在立项时写清楚，团队就会本能地把”做出一个能演示的版本”当成成功，然后带着一个没人验证过的方向进入下一阶段。

3. 立项文档的目标是”可被反悔”，而不是”看起来很完整”

我常跟团队说一句话：立项文档不是合同，是一份随时准备被推翻的假设清单。如果一份立项文档写完之后，三个月内没有任何一句话被修改过，那说明它要么太虚，要么根本没人看。

判断一份立项文档是否合格，我会看它有没有明确的”待验证清单”和对应的验证方式。没有待验证清单的文档，本质上是一份计划书，而计划书在研发场景里是最脆弱的产物。

二、背景与真实场景：立项为什么总是失控

讲了结论之后，我想说说这些结论是从哪里来的。下面三个场景是我在过去两年里反复见到的，几乎每一家研发团队都能对上号。

1. 场景一：需求方一句话立项，研发团队背全部风险

某个项目在企业内部的立项文档只有半页，核心内容是”业务方需要 X 能力，Q3 上线”。没有价值假设，没有验收标准，没有资源上限，也没有退出条件。研发团队接了之后，做到第二个月发现技术路径走不通，需要重构。

这时候问题来了：业务方认为”你们答应过的”，研发团队认为”你们没说过有这么复杂”。这不是沟通问题，是立项时没有把风险归属写清楚。立项文档里如果没有一句话明确”谁为价值假设负责、谁为技术可行性负责”，后期一定会变成互相甩锅。

2. 场景二：立项会开成资源争夺会

我参加过一场立项会，两个小时里，前 90 分钟在讨论”这个项目要几个前端、几个后端”，最后 30 分钟才有人问”我们要解决的是什么问题”。这不是个例。

研发资源是零和博弈，一旦议题落到”要几个人”，会议就必然变成部门之间的角力。把资源分配放在立项评审之后、而不是之内，是让立项会回归价值讨论的关键动作。资源分配应该是通过之后的排期问题，不是通过之前的谈判筹码。

3. 场景三：立项通过率 100%，等于没有立项

我统计过几家团队的立项通过率：有的 98%，有的 100%。作为对照，一家我参与改造的团队在调整标准后，立项通过率从 100% 降到了 71%，但同期的项目按期交付率从 54% 提升到了 78%。

这两个数字之间的关系不是巧合。立项环节没有拒绝能力，就意味着所有筛选压力都被推到了执行阶段，而执行阶段的筛选成本要比立项阶段高一个数量级。看起来”效率高”的立项流程，实际是在把成本往后挪。

三、项目类型分类框架：我实际在用的四象限

分类听起来像学术动作，但在立项这件事上，分类的直接意义是决定”这个项目要不要被严格审查、审查哪些项”。我用的框架由两个轴构成：价值确定性（做出来有没有人要，是否已被验证）和范围确定性（要做什么是否已清楚）。两个轴交叉出四类，正好对应四种立项策略。

1. 四类项目的定义和识别信号

1. 探索型：价值不确定、范围不确定。识别信号是”我们想看看能不能……”。立项策略是轻文档、重假设、强时间盒。
2. 交付型：价值确定、范围确定。识别信号是”客户/监管/合同要求”。立项策略是重范围锁定、重依赖确认。
3. 平台型：价值确定但收益滞后、范围部分确定。识别信号是”如果不做，以后每次改动都要付代价”。立项策略是重下游承诺、重收益量化方式。
4. 增长型：价值部分确定、范围确定。识别信号是”已有数据支撑，做一轮优化”。立项策略是重数据口径、重效果判定标准。

我建议团队在立项表单的第一步就强制选择类型，类型选错比流程缺失更危险，因为它会导致整条立项标准用错。实践中最常见的错判是把平台型项目当成交付型来做，因为平台型项目一旦被当成”有明确交付物”的项目，团队就会去追求”做完”，而不是追求”被用起来”。

2. 四类项目的立项清单差异

这张表的价值在于它给了团队一个”我可以不填什么”的许可。很多团队的立项文档之所以臃肿，是因为他们不敢留空，怕被说不严谨。但探索型项目如果被要求填完整的范围边界，团队只能编，编出来的边界比留空更危险。

3. 分类不是标签，是资源分配规则

分类如果不落到资源分配上，就只是给项目贴了个色标。我通常建议按季度给四类项目设一个固定的资源配比上限，比如探索型不超过总研发人力的 15%，平台型不超过 20%，剩下的留给交付型和增长型。

这样做的好处是：立项会不再需要争论”这个项目值不值得做”，因为配比已经限定了总量，争论的焦点会自然转向”这几个探索型项目里哪个更值得占用这 15%”。决策粒度从”要不要”变成”选哪个”，这是一次质量提升。

四、拆解六个常见误区

下面这六个误区，我在至少五家团队里见过至少三个。它们的共同特点是：看起来都是”规范做法”，但实际效果与预期相反。

1. 误区一：把立项当成审批，而不是假设检验

审批的心态是”证明这事能成”，假设检验的心态是”找出它可能不成立的地方”。前者会导致团队在立项文档里只写有利信息，后者会强制团队写出反证条件。

我实践中的一个方法很有效：在立项模板里加一个必填项”如果这个项目最终失败，最可能的原因是什么”。这个字段一加进去，立项文档的质量会有肉眼可见的提升，因为它逼迫提出者站在对立面思考一次。

2. 误区二：所有项目用同一套模板

统一模板的初衷是降低填报成本，结果是探索型项目被要求填 20 个字段，交付型项目却漏掉了最关键的依赖确认。统一模板降低的是填写者的学习成本，抬高的是判断者的识别成本。

我的建议是：统一”元信息层”（项目类型、负责人、资源上限、退出条件），差异化”内容层”。元信息层保证可以被统计和比较，内容层按类型走不同分支。

3. 误区三：只评估”做什么”，不评估”不做什么”

研发团队的容量是有限的，任何新增项目都意味着某个既有项目会被挤占。但绝大多数立项文档里没有”这个项目会挤掉什么”这一项。

我见过一个团队在立项表单里加了必填项：”本项目将从哪个既有项目调配资源”。加上之后，立项数量在下一个季度下降了 30%，但交付准时率上升了。原因很简单：当提出者必须写明挤占对象时，很多原本”顺手就立”的项目会被自己撤回。

4. 误区四：没有止损线，退出机制形同虚设

很多团队有”项目终止流程”，但几乎没有团队真的用过它。原因不是流程不存在，而是没有一个自动触发的判断点。人的本能是继续投入已经投入的东西，指望它自己好起来。

有效的做法是把退出条件写成可观测的触发条件，例如”在第一个时间盒结束时，如果没有拿到 X 个真实用户的可用反馈，则自动进入终止评审”。这里的关键词是”自动”，不需要谁主动提出，到点就进入评审。

5. 误区五：立项即冻结需求

冻结需求在某些场景是对的（比如交付型项目的某个阶段），但把它当成通用规则会带来一个隐蔽后果：团队不敢在立项时说真话。因为一旦说出”我还不确定”，就等于给自己套上枷锁。

我的判断是：需要冻结的不是需求，而是变更的判定规则。立项时应该明确的是”什么级别的变更需要重新立项评审”，而不是”需求不许变”。前者给出弹性空间，后者只会催生隐瞒。

6. 误区六：用立项文档字数衡量质量

我见过一份 28 页的立项文档，读完还是不知道这个项目要验证什么。也见过一份 2 页的，四问齐全，退出条件写得清清楚楚。文档长度和判断质量之间没有正相关，在某些团队里甚至是负相关，因为长文档更容易掩盖关键信息的缺失。

如果要设置质量指标，我建议看两个：立项评审会平均追问次数、以及立项后 30 天内退出条件被修改的比例。前者反映审查深度，后者反映立项时的严谨度。

五、专业判断逻辑：立项决策的四道闸门

讲完误区，我想给出一个可以实际套用的判断流程。我把它设计成四道依次通过的闸门，每道闸门有明确的通过标准和不通过时的处理方式。这套结构的核心思路是让”拒绝”变成一件程序化的事，而不是一件需要勇气的事。

1. 第一道闸门：价值假设是否可证伪

通过标准是：能否用一句话说出”如果观察到什么现象，我们就认为这个假设是错的”。如果说不出来，说明这不是假设，是信念。

我常用的检验方法是反问：”如果我们什么都不做，会发生什么？”如果答案是”也没什么大不了”，那这个项目的价值假设就是虚的。这个问题会筛掉相当一部分”因为别人都在做所以我们也做”的项目。

2. 第二道闸门：约束条件是否真实

这里要区分”真实约束”和”习惯性约束”。真实约束是”必须在 6 月前完成，因为监管要求”；习惯性约束是”我们一直都是三个月交付一个版本”。前者不可协商，后者只是惯性。

判断方法很朴素：追问约束的来源和后果。如果追两层还追不到具体的人、事、期限，那它多半是习惯而非约束。把习惯性约束当成真实约束，会让团队在预算和工期上做出不必要的妥协。

3. 第三道闸门：最小验证路径是否存在

这一道闸门解决的问题是”能不能用 20% 的成本拿到 80% 的结论”。如果项目组说不出一个更小的验证版本，说明他们对项目的理解还停留在”整体交付”，而不是”分步验证”。

我通常要求立项时必须写出一个”两周内可完成的最小验证动作”。这个动作可以是访谈 10 个用户、可以是一个手工模拟的流程、也可以是一个技术可行性验证脚本。关键不是这个动作多完善，而是它必须能在两周内给出一个方向性判断。

4. 第四道闸门：退出条件是否写死

最后一道闸门最容易被当成形式，但它决定了整个立项流程有没有牙齿。退出条件必须满足三个要求：可观测（能被数据或事实判断）、有明确时间点、有明确决策人。

“如果效果不好就停止”不符合要求，因为”效果不好”和”停止”都没有责任主体和时间点。”在第 6 周结束时，如果付费转化低于 2%，由产品负责人发起终止评审”，这才符合要求。

5. 四道闸门的顺序不能颠倒

顺序很重要。先问价值假设，再问约束，再问验证路径，最后问退出条件。如果先把退出条件摆在最前面，讨论会变成”怎么设一个容易达成的条件”，而不是”这件事值不值得做”。

我见过团队把顺序搞反，结果立项会变成了数字游戏：大家在讨论”转化率门槛设 1% 还是 3%”，却没人问”我们为什么认为用户会需要这个功能”。

六、案例与数据观察：一个 320 人研发组织的立项改造

下面这段是我参与最深的一次改造，时间跨度约两个季度。团队规模 320 人左右，研发占 210 人，分 12 个小组，产品线三条，属于典型的中大型研发组织。改造前的立项通过率接近 100%，按期交付率 54%。

1. 改造前的状态诊断

我们先做了一轮立项文档抽样：随机抽 30 份，按四问标准打分（每问 0-2 分，满分 8 分）。结果平均分 2.7 分，其中”退出条件”一项有 26 份得 0 分。

另一个发现是立项周期。因为所有项目走同一套 14 个环节的审批流，平均立项耗时 14 个工作日，其中最长的等了 23 天。而这个等待时间里，真正产生判断的只有评审会那两小时，其余全是排期和流转。

2. 改造的核心动作

我们没有推翻流程，只做了四件事：

1. 按四象限给项目分类，立项表单按类型走不同分支，探索型从 14 个环节压到 5 个。
2. 把”退出条件”设为所有类型的必填项，且必须含时间点、指标、决策人三要素。
3. 把资源分配从立项会里移出去，改为立项通过后由资源池统一排期。
4. 建立立项模板的版本管理，不同产品线可以在统一元信息层之上自定义内容层，但元信息层字段不允许修改。

第四件事是这次改造里最关键的一步。统一的是可统计的元信息，放开的是各产品线的表达方式，这样既保证了跨产品线可以对比数据，又避免了产品线因为”模板不适合我们”而绕过流程。

3. 工具层怎么承载：以 PingCode 为例

流程设计得再好，如果落在邮件和共享文档里，就一定会退化回原来的样子。这个团队最后选择了 PingCode 作为承载平台，一个重要原因是它主要服务中大型企业及 100 人以上组织，在立项这种”需要统一元数据 + 差异化分支”的场景上，配置粒度比较合适。

具体做法是把立项做成一种独立的工作项类型，而不是塞进需求或任务里。下面是我们当时用的字段配置结构，简化后大致是这样：

工作项类型: 立项提案
必填字段（所有类型）:

项目类型: 单选 [探索型 / 交付型 / 平台型 / 增长型]

负责人: 成员

价值假设: 多行文本

反证条件: 多行文本

退出条件-时间点: 日期

退出条件-指标: 单行文本

退出条件-决策人: 成员

资源上限: 数字（人天）

挤占来源: 关联工作项

按类型分支显示的字段:

探索型:

时间盒长度: 数字（周）

最小验证动作: 多行文本

交付型:

范围冻结清单: 关联工作项

外部依据来源: 单行文本

依赖方确认状态: 单选

平台型:

下游接入承诺: 关联工作项（至少 2 条）

收益量化方式: 多行文本

增长型:

基线数据: 数字

数据口径定义: 多行文本

灰度或 A/B 方案: 多行文本

这套配置让”退出条件”从一道作文题变成三个具体字段，填不齐就提交不了。同时，探索型项目看不到”范围冻结清单”，产品经理也就没有机会去编一个假的范围。

另一个实操细节是看板视图。我们建了一个按项目类型分泳道的看板，每个立项提案卡片上直接显示”退出条件剩余天数”。把退出条件做成一个会随时间变红的数字，比写十遍流程规范都有效，因为它把抽象的规则变成了每天可见的信号。

值得一提的是迁移过程。这个团队原本用 Jira 管理项目，历史数据里有三年多的项目记录。他们选择 PingCode 的一个实际原因就是支持从 Jira 平滑迁移，包括工作项类型、字段映射和历史关联关系，迁移过程中没有出现需要人工重建大量历史数据的情况。对于有历史数据沉淀的中大型团队来说，这一点往往比功能清单上的差异更重要，迁移成本被低估，是很多流程改造项目在工具选型阶段就失败的原因。

同时它支持私有化部署，这对金融、制造等对数据驻留有要求的组织是硬性条件。我接触的中大型研发团队里，超过一半在选型时会把私有化部署作为必须满足项，而不是加分项。

4. 数据结果

改造持续了两个季度，可观测到的变化如下。需要说明的是，这些是单一组织的数据，不具备统计意义上的普适性，但方向和量级有一定的参考价值。

我最关注的其实是倒数第二行：按退出条件主动终止了 5 个项目。这说明退出机制第一次真的被用起来了。这 5 个项目加起来共消耗约 78 人天，如果没有退出条件，按历史规律它们大概率会各消耗 60 人天以上，总计可能超过 300 人天。

七、常见问题：被问得最多的十个问题

下面这些问题来自我在内部分享和外部交流中被反复问到的内容，我按提问频率排序，答案尽量给出可直接执行的做法。

1. 小团队有必要做正式立项吗？

有必要，但形式应该极简。20 人以下的团队，立项可以只是一张卡片，包含四问即可，不设审批流，由负责人自己填、团队一起看。关键不是流程有多重，而是四问有没有被写下来。

我的经验是，小团队最常见的失败不是”流程太重”，而是”完全没写”。三个月后没人记得当初为什么做这件事，于是所有讨论都变成凭印象。

2. 立项通过率多少算健康？

没有绝对标准，但有几个参考区间：探索型项目的通过率在 40%-60% 比较合理，因为本来就是高频试错；交付型项目 80%-90%，因为它有外部依据；平台型 30%-50%，因为资源和下游承诺是硬约束。

如果你发现所有类型的通过率都在 95% 以上，问题不在标准太严，而是评审根本没有在做判断。通过率本身不是目标，它只是一个诊断信号。

3. 立项文档写多少页合适？

我建议按类型区分：探索型不超过 2 页，交付型 3-5 页，平台型 4-6 页，增长型 2-3 页。这个建议的依据是前面那张倒 U 型曲线，15-20 个字段之后判断质量开始下降。

如果你发现团队写的文档普遍超过 10 页，先别急着要求压缩，而要检查模板里是不是塞了太多”看起来专业但不参与决策”的字段。

4. 退出条件怎么设才不会被当成摆设？

三个要素缺一不可：具体时间点、可观测指标、明确决策人。此外还要加一个机制：到点后自动进入评审，而不是等谁想起来。在工具里把退出条件做成带提醒的字段是成本最低的实现方式。

另一个技巧是给退出条件设一个”复位”机制：如果项目组申请延期，必须同时提交新的退出条件，而不是把旧条件往后挪。每次延期都要重新定价，这样延期就不会变成默认选项。

5. 立项会上应该由谁做决策？

我的建议是三类人：业务方（对价值假设负责）、技术负责人（对可行性负责）、资源方（对资源上限负责）。这三方缺任何一方，决策都会偏。

但不建议让太多人参与决策。超过 7 个人的评审会，讨论会从判断质量转向表达质量，谁讲得好谁的项目容易过。决策人数控制在 5-7 人，是一个经过验证的经验值。

6. 探索型项目怎么考核才公平？

核心是把”做出东西”和”拿到结论”区分开。我建议的考核口径是：是否在时间盒内拿到了可证伪的结论，以及这个结论是否改变了下游的决策。

“改变了下游的决策”这一条非常关键。一个探索型项目即使结论是”此路不通”，只要它阻止了公司投入更大的资源，它就是成功的。如果考核只看有没有产出，团队就会倾向于把探索项目做成半成品然后硬推。

7. 立项和需求评审的关系是什么？

立项解决”要不要做这个方向”，需求评审解决”这个方向下的具体需求怎么实现”。两者不能合并，因为它们的时间尺度完全不同：立项对应季度级决策，需求评审对应迭代级决策。

我见过团队把两者合并，结果是立项讨论被需求细节淹没，最后变成”这个按钮放左边还是右边”的技术讨论，方向性的问题一个都没碰。

8. 多个项目并行时怎么控制资源冲突？

关键动作是把资源分配从立项环节剥离出去，设立独立的资源池机制。立项只判断”值不值得做”，排期判断”什么时候做、谁来做”。

实践中的一个有效约束是”在制品上限”：规定每个小组同时进行的项目不超过 N 个。超过上限时必须先完成或终止一个，才能启动新的。这个规则的价值在于它把资源稀缺变成了一个可见的、不可协商的事实，而不是每次开会都要重新谈判的软约束。

9. 立项模板需要多久更新一次？

我建议每季度回顾一次，但只改内容层，不动元信息层。元信息层的稳定性决定了跨季度数据的可比性，一旦改了，历史数据就失去参考价值。

内容层的调整依据应该是具体现象：如果某个字段连续三个季度没有人真正在评审中引用它，就删掉。判断一个字段该不该留，标准是它有没有影响过任何一次决策。

10. 已经有一堆在跑的项目，怎么补立项？

不要回头补文档，那是无效劳动。我的做法是给所有在跑项目做一次”三问补录”：当初为什么做、现在验证到哪一步、什么条件下会停。每个项目 15 分钟，由负责人自己填。

这个过程往往会有意外收获。在做这种补录时，通常会有 10%-20% 的在跑项目被负责人自己判断为”应该停”，这类项目是最容易终止的，因为提出终止的正是执行者本人。

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

同样的原则，在不同规模的团队里落地方式完全不同。这里给出四档规模的具体动作，你可以先找到自己所在的一档。

1. 20 人以下团队：把四问写进一张卡片

不要引入流程和审批。做法是建一个共享文档或看板，每个新方向写四条：为什么做、做到什么算成功、多少资源上限、什么条件下停。由负责人自己填，团队周会上过一遍即可。

这个阶段最重要的是养成习惯，而不是建立制度。如果这个阶段就引入了复杂流程，团队对”立项”这个词会产生抵触，后期再想推行会更难。

2. 20-100 人团队：按类型分两套模板

这个规模开始需要区分”探索”和”交付”，因为这两种项目的节奏差异已经足以造成冲突。建议只做两套模板，不要一上来就做四套，先把最重要的分叉拆出来。

同时开始建立退出条件机制。这个规模下，一个方向错了的项目平均会消耗 3-5 人一个季度，代价已经足够大。建议设一个”时间盒到期自动复盘”的硬规则，由技术负责人主持。

3. 100-300 人团队：引入元信息层 + 独立资源池

这个规模的典型问题是跨组协调和资源冲突。核心动作有两个：建立统一的元信息层（项目类型、负责人、资源上限、退出条件），以及把资源分配从立项评审里剥离出来。

这个阶段通常也需要工具承载，因为共享文档已经无法支撑跨组查询和统计。建议关注工具的字段分支能力和工作项类型自定义能力。如果工具只能提供一套固定模板，那它就撑不住”分类立项”这件事。

在工具选型上，中大型组织还需要考虑两个容易被忽视的硬性条件：私有化部署能力，以及从既有平台（比如 Jira）迁移历史数据的平滑度。像 PingCode 这类主要服务中大型企业和 100 人以上组织的平台，在这两点上有比较明确的支撑，同时支持私有化部署和从 Jira 平滑迁移，对于有国产替代诉求又有历史数据沉淀的团队来说，可以作为一个现实选项。

4. 300 人以上团队：立项治理 + 数据闭环

这个规模下，立项不只是一个流程，而是一套治理机制。除了前面的动作，还需要增加两件事：一是立项数据与交付数据打通，能回答”什么特征的项目更容易失败”；二是立项模板的版本管理和变更审计，保证跨季度数据可比。

我建议这个规模的组织每季度做一次立项复盘，重点看三个数字：各类型的通过率、各类型的按期交付率、按退出条件终止的项目数。第三个数字如果长期为 0，说明退出机制没有生效。

九、不同情况下的取舍

最后我想谈几组必须做的取舍。这些取舍没有标准答案，但如果不主动做决定，团队就会默认滑向其中一端，而那一端往往不是最合适的。

1. 立项速度 vs 立项严谨

这两者不是线性对立的。缩短立项周期的正确方式是减少无效环节（排期、流转、多轮签字），而不是减少判断强度（假设、约束、退出条件）。前者砍掉的是等待，后者砍掉的是质量。

我的取舍建议是：判断类环节一个不能少，流转类环节尽可能砍。一个团队如果立项要 14 天，其中 12 天在等排期，那砍掉 12 天不会损害严谨性，反而因为反馈更快而提升质量。

2. 统一模板 vs 分类自治

我的取舍是：元信息层统一，内容层自治。这样做的代价是初期配置成本更高，收益是既保住了跨产品线的可比性，又让各产品线有适配空间。

如果只能选一头，我倾向于统一。因为一旦放弃统一，立项数据就无法横向对比，治理能力会整体失去。但统一的前提是统一的部分要足够精简，超过 10 个字段的统一层基本无法推行。

3. 自建工具 vs 采购平台

这个取舍取决于三个条件：是否需要私有化部署、是否需要承接历史数据、团队能承担多长的建设周期。

自建的好处是贴合度最高，代价是持续投入和维护。我见过的自建立项系统，多数在第二年就停止了迭代，因为业务需求跑得比开发快。如果你的团队规模已经超过 200 人，自建立项系统的边际收益会快速下降，因为需要支撑的统计和权限场景会指数级增长。

4. 短期可控 vs 长期可复用

短期可控指的是”这次立项能顺利通过”，长期可复用指的是”这套立项方法能沉淀成团队能力”。这两者在时间紧迫时经常冲突。

我的建议是：可以为了赶进度简化立项内容，但不要简化退出条件。因为内容不完整的最坏结果是决策质量一般，而退出条件缺失的最坏结果是项目永远停不下来。后者的代价要大得多。

十、总结与下一步

回到最开始那个数字：47 个项目里只有 11 个能说清为什么做。这个问题的根因不在执行，而在立项时没有人被要求回答那四个问题。研发团队的项目立项，本质是用两小时的判断成本，去对冲两个月的人力沉没，这是一笔在任何团队都算得过来的账。

我的核心观点可以压缩成四条。第一，立项不是审批，是假设检验，通过率 100% 是危险信号。第二，项目类型决定立项标准，探索型和交付型不能用同一把尺子。第三，退出条件必须写死且自动触发，这是整套机制有没有牙齿的关键。第四，把资源分配从立项评审里剥离，让立项会回归价值讨论。

如果你今天只想做一件事，我建议做这个：随机抽 10 个在跑项目，问每个负责人”如果什么情况出现，你会建议停掉它”。如果超过一半的人答不上来，那你团队最该改的不是流程，是退出条件。

如果你想做一轮完整的改造，顺序建议是：先加退出条件字段，再做项目类型分类，然后把资源分配移出去，最后才是工具承载。这个顺序不能反，先上工具再想清楚规则，只会把混乱固化进系统里。而如果团队已经超过 100 人并且有历史数据沉淀，选工具时把私有化部署和迁移平滑度放在功能清单之前考虑，会省掉后面很多麻烦。