项目目标流程与规范：研发团队项目立项入门指南关键指标

2023 年 4 月，我参与过一家 SaaS 公司的项目复盘会。那个项目从立项到叫停一共烧了 7 个人 4 个月，约合 1080 人天。复盘时大家翻出立项材料，发现首页写的目标是”提升客户续约率”，但整个立项文档里没有任何一句话说明”提升到多少、在什么时间点、由谁验证”。更麻烦的是，当初评审会上 11 位与会者，有 6 位在会上明确表示”这个目标太虚”，但没人要求修改，因为流程上”评审通过”只需要主持人点头。

这个项目不是死于技术难题，而是死于立项当天就已经埋下的模糊。本文要谈的就是这件事：研发团队做项目立项，目标该怎么定、流程该怎么走、规范该写多细、关键指标该盯哪几个。我把自己从 2019 年到 2024 年经手的 6 个研发团队（规模从 28 人到 300+ 人）的立项数据做了脱敏汇总，并结合其中一次完整的 Jira 到国产平台迁移的实践，把可复用的判断逻辑写清楚。

一、先给结论：立项不是审批动作，而是把不确定性提前定价

大多数研发团队把立项理解成”走个流程、拿个编号、领资源”。这是根源性的认知偏差。立项真正的产物不是一份文档，也不是一个审批记录，而是一份被显式写下来、可以被推翻的假设清单。假设清单越具体，项目后期的返工就越少；假设清单越模糊，项目就越容易在中期变成”谁都说不清要做什么”的泥潭。

1. 立项真正的产物是”可被推翻的假设清单”

我在 2021 年带过一个 60 人的研发中台团队，当时我们做了一个实验：同一个项目，让两个平行的需求方分别写立项材料。A 组按公司原有模板写，B 组被要求把所有判断句改写成”我们假设……如果这个假设不成立，我们就……”的句式。结果 A 组的材料有 14 页，B 组只有 5 页，但 B 组在项目执行到第 6 周时主动叫停了一个方向，理由是”日报自动化率提升假设不成立，实际用户根本不用这个入口”，节省了大约 260 人天。

这件事让我确认了一个判断：立项文档的价值不在篇幅，而在它能不能暴露出”哪些是假设、哪些是事实”。写”我们要做一套统一的报表中心”，这是事实陈述，无法验证；写”我们假设财务、销售、客服三个部门每周各有 2 小时以上在手工汇总数据，如果实际低于 30 分钟，这个项目就该降级”，这才是假设，可以被推翻，也值得被投入资源去验证。

所以我在后续所有团队里推行的第一条立项规范就是：立项文档里，凡是没有数据来源的判断句，都必须改写为”假设 + 验证方式 + 失效条件”。这一条改变了很多东西。

2. 目标、流程、规范三者的分工必须分清

我见过最多的混乱，是把目标、流程、规范混成一锅粥。这三件事各有分工，混在一起就会互相拖累。

• 目标回答”做成什么样才算成功”，它必须可验证、有时间边界、有明确的责任人。目标写不清楚，后面所有流程都是空转。
• 流程回答”谁在什么节点做什么决定”，它解决的是决策效率和责任归属，而不是内容的正确性。流程再完美，也救不了一个模糊的目标。
• 规范回答”什么样的立项材料算合格”，它是一组质量门槛，比如必须包含失效条件、必须有基线数据、必须标注依赖方。规范是”入场券”，不是”指导手册”。

三者关系如果用一个比喻：目标是目的地，流程是路线图，规范是驾照考试。很多团队的问题是路线图画得极细，但没人检查目的地是否真实存在。我在 2022 年接手一个 150 人研发组织时，他们的立项流程有 11 个审批节点，看起来极其严谨，但立项文档里 63% 的目标无法被第三方验证。这是典型的”流程繁荣、目标贫瘠”。

3. 立项质量对后期返工成本的影响是可以量化的

下面这组数字来自我在 2022 年到 2024 年间跟踪的 43 个研发项目，按立项质量评分分组后的中位数对比。需要说明的是，这是主观评分（由 3 名非项目成员独立打分取中位数）与工时数据的关联观察，不是随机对照实验，结论仅供决策参考，不具备严格因果推断效力。

我要特别强调低分组 48% 这个数字。它的含义不是”近一半的工作白做了”，而是近一半的工作发生在方向被推翻之后的重做。这是最贵的一类浪费，因为它同时消耗了工时、团队信任和管理层的耐心。而这三个分组的差别，在立项当天就已经决定了大半。

二、真实场景：我亲历的三次立项流程改造

抽象结论容易说，但真正难的是它落在具体团队里长什么样。下面这三个场景我都亲自参与过，规模、行业和工具链各不相同，但它们暴露的问题出奇一致。

1. 场景一：80 人团队用一份 Word 模板立项，半年后 40% 项目失控

这是 2020 年的一家做企业服务的公司，研发 80 人，分 5 个小组。当时的立项方式是：需求方填一份 12 页的 Word 模板，发邮件给技术负责人和产品负责人，两人回复”同意”就算立项通过。整个过程没有编号，没有统一登记，也没有立项后的跟踪。

我做了一次回溯盘点，发现那半年里实际上启动了 31 个项目，但项目管理工具里只有 19 个在跟踪，剩下 12 个处于”没人知道现在什么状态”的灰色地带。更严重的是，这 31 个项目里有 14 个的目标描述是”优化””完善””提升”这类动词，没有一个带具体数值和验证时间。

我们当时的改造动作很小，只有三条：第一，所有立项必须在项目管理工具里建条目，没有条目就不算立项；第二，目标描述必须包含一个可测数字和一个验证时间点；第三，立项时指定一名”失效条件负责人”，负责在假设被证伪时提出叫停。就这三条，半年后项目失控率从 40% 降到 15% 左右。这个例子里最关键的不是模板改了，而是”必须进工具”这条硬约束，它把立项从邮件里的口头承诺变成了系统里可查询的记录。

2. 场景二：从 Jira 迁移到 PingCode 后，立项流程被重构成三个模板

2023 年我参与了一个 107 人研发团队的平台迁移项目。他们原来用 Jira 管理研发，工作流高度自定义，有 27 种 issue 类型和 40 多条自定义字段。搬到 PingCode 之后，我们借这次迁移做了一件在旧系统里做不动的事：把立项流程拆成三个标准化模板。

为什么在旧系统里做不动？因为自定义工作流太灵活，每个小组都在自己的项目空间里发明了一套字段命名，跨组汇总时口径完全对不上。PingCode 支持私有化部署，这让我们可以把统一的字段模型和权限模型一次性下发，而不是让各组自由发挥。同时它支持从 Jira 平滑迁移，历史 issue、字段映射和工作流状态都能对应过来，这减少了团队对”换系统等于丢掉历史数据”的抵触，这一点在百人以上组织的迁移里非常关键。

三个模板分别是：探索型立项（目标是验证一个假设，允许失败，资源上限明确）、交付型立项（目标是按约定范围交付，有时间和质量硬约束）、技改型立项（目标是降低某项成本或风险，必须有前后对照指标）。这三种项目的立项材料结构、评审深度和跟踪节奏都不一样，用同一套模板会同时伤害效率和严谨度。

3. 场景三：多产品线集团的立项委员会如何避免变成橡皮图章

2024 年我观察过一家 300+ 人规模、有 4 条产品线的公司。他们的立项委员会每月开一次会，一次审 8 到 12 个项目，每个项目 15 分钟。问题很明显：15 分钟里委员会根本来不及判断技术方案，最后只能看”资源够不够”，于是评审实质上演变成了资源争夺会。

他们后来做的事是把评审分两段：异步预审 + 同步决策。异步预审要求立项方在会前 3 天把所有材料提交到系统里，委员会成员用打分表逐项打分（目标清晰度、边界、依赖、风险、退出条件五项，各 1 到 5 分），会前就被打上”不通过”的项目不需要占用会议时间。同步会议只讨论两类项目：分数在临界区间的，以及分数高但资源冲突的。这样单次会议能处理的决策量从 8 个提升到 22 个左右，同时实际讨论深度反而提升了。

他们的委员会主席说了一句话我印象很深：“评审会最贵的成本不是会议时间，而是让一群高管习惯了在信息不足时点头。”这句话基本概括了所有立项流程失败的根本原因。

三、拆解七个常见误区

下面这七条都是我反复在复盘会上遇到的真实问题，不是从教科书里抄的。每一条我都补上了”为什么这么想是错的”和”替代做法是什么”。

1. 把 OKR 直接抄成项目目标

这是最常见的错误。OKR 里的 O 是方向性的，KR 是季度级别的结果指标，它们描述的是”组织希望在哪个方向变得更好”，而不是”这个项目要做成什么”。一个季度 KR 通常会由 3 到 5 个项目共同贡献，直接把它当成某个项目的目标，会导致责任无法界定。

我见过一个典型例子：季度 KR 是”新客转化率从 8% 提升到 12%”，然后一个做后台配置工具的项目把它原样抄成自己的项目目标。问题是这个项目只负责把配置耗时从 4 小时降到 30 分钟，转化率的提升还依赖销售话术、定价和落地页。项目上线后配置耗时确实降了，但转化率没动，于是项目被评为”未达成目标”。这是目标设定的错位，不是执行的失败。

替代做法：项目目标必须写成”本项目可控变量 + 期望变化幅度 + 验证方式”。比如”把新客户首次配置耗时从 4 小时降到 30 分钟以内，以 20 个新客样本的中位数为验证口径”。

2. 把排期当计划，把甘特图当承诺

排期回答的是”什么时候做完”，计划回答的是”怎么保证做得完”。我在 2021 年见过一个项目，甘特图排得非常漂亮，16 个里程碑精确到天，但没有任何一行写”如果依赖的上游接口延迟两周怎么办”。结果上游真的延迟了三周，整个排期直接作废。

排期之所以不可靠，是因为它建立在”所有前置假设成立”的前提下，而立项阶段恰恰是假设最多、验证最少的时候。一份合格的计划至少要有三件事：关键路径、最可能延迟的依赖项、以及每个里程碑的判定标准。缺了第三项，里程碑就只是一堆日期。

3. 只写”要做什么”，不写”不做什么”

范围蔓延几乎总是因为立项文档只定义了范围，没有定义非范围。我在 2022 年做过一次统计，在 26 个延期项目中，有 21 个的延期原因可以追溯到”中途加入了原本不在立项范围内的需求”。

有效的做法是在立项文档里专门写一节”本项目明确不做的事”，并且要求至少三条。这一节写得越具体，后期挡需求时越有依据。比如”本期不做移动端适配””不接入第三方支付””不改造历史数据迁移逻辑”。这三句话能挡掉后面至少 20 个变更请求。

4. 评审通过不等于共识达成

这是最隐蔽的一条。评审会上的”通过”往往只代表”没人强烈反对”，不代表”所有人理解一致”。我在一次项目中期对齐会上做过一个实验：让立项评审会上投过赞成票的 9 个人，各自用一句话写下项目目标。9 个人写出了 7 种不同的表述，其中 3 种在关键指标上互相矛盾。

要打破这个假象，最有效的做法是”反向复述”：评审结束时，随机点 2 到 3 名与会者，用自己的话说一遍项目目标和成功标准，其他人确认或纠正。这个动作只需要 5 分钟，但能暴露出大量理解分歧。

5. 指标全是结果指标，没有过程指标

结果指标（如营收增长、转化率、客户满意度）的问题是反馈太慢，通常要一个季度才能看到。等到看到时，项目已经花掉大半预算。立项时必须同时定义一组过程指标，用来在中期判断”我们是否在正确的轨道上”。

比如一个做内部效率工具的项目，结果指标可以是”人均手工操作时间下降 40%”，但过程指标应该是”周活跃使用率””单次任务平均点击次数””用户主动反馈数”。这三类过程指标能在项目进行到第 4 周时就给出方向性信号。

6. 立项没有退出条件

没有退出条件的项目，实际上是把”是否继续”的决策权无限期推迟了。我观察到的现象是：没有明确退出条件的项目，平均存活时间是有的项目的 2.3 倍，但产出价值反而更低。因为它们的资源不会被及时释放，而资源池是有限的，这会挤压新项目的空间。

退出条件要写得可执行，不能是”如果效果不好就停”。”效果不好”是主观的，无法触发动作。合格的写法是”如果在第 8 周结束时，目标用户中周活跃使用率低于 15%，则项目转入维护模式，释放 2 名开发人力”。

7. 流程规范写成了 30 页制度文件

我见过一个团队的立项规范，整整 32 页，包含 11 个审批节点、7 类表单、5 种评审会议。这份文件发布后 3 个月，我抽查了 12 个新立项项目，合规率只有 25%。原因很简单：没人愿意为了启动一个项目读完 32 页文件。

规范的合理长度应该以”一个新人在 20 分钟内能读完并照着做”为上限。超过这个长度，就应该拆成”核心强制项”和”可选参考项”。核心强制项控制在 5 条以内，其他全部变成工具里的默认模板和提示。

四、专业判断逻辑：立项四问与五道闸门

前面讲了问题和案例，这一节给一套我自己在用的判断框架。它不追求理论完备，追求的是”当场能用”。四问负责判断值不值得立项，五道闸门负责判断立项材料够不够格。

1. 第一问：这个项目不做会怎样

这个问题专治”看起来很重要但说不清为什么重要”。如果回答是”也没太大影响，只是会落后一点”，那这个项目大概率应该降级为常规迭代而不是独立立项。真正值得立项的事情，通常能说清楚”不做的话，某个具体指标会在某个时间点恶化到什么程度”。

我在实践中会要求立项方用一句话回答：“如果不做，我们会在什么时间点、因为什么原因、损失什么具体的东西？”回答不上来的，先去做需求验证，不要立项。

2. 第二问：成功的样子能不能被第三方验证

“第三方”指的是不参与这个项目的人。如果只有项目组自己知道”我们成功了”，那这个成功是不可信的。合格的验证标准应该满足：数据口径公开、采集方式可复现、判定时间点明确。

举个例子，一个项目说”提升内部协作效率”，这是无法被第三方验证的。改成”把跨部门需求流转的平均响应时间从 26 小时降到 8 小时以内，数据取自工单系统的首次响应时间戳，在第 12 周统计连续 4 周的中位数”，这就可验证了。

3. 第三问：谁是最终用户，谁承担失败成本

这两个问题经常被混在一起。最终用户是使用产品的人，承担失败成本的是为项目结果负责的人，两者往往不是同一批人。如果这两个角色在立项时都没有明确，项目在中后期一定会陷入”没人愿意为结果负责”的状态。

我建议在立项材料里显式写两行：最终用户是 [角色]，验证方式是他们完成 [具体动作] 的比例；失败成本承担者是 [姓名/角色]，他们需要承担的后果是 [具体后果]。第二行看起来有点残酷，但它能显著提高立项的严肃性。

4. 第四问：什么时候必须停

这个问题就是退出条件。我把它单独作为”四问”之一，是因为它在实际立项中最常被跳过。写退出条件的技巧是把它绑定到”时间点 + 可观测指标 + 具体动作”这三要素上。

有一个反直觉的经验：退出条件写得越具体，项目反而越容易获得批准。因为审批人最怕的不是失败，而是”失败了还不知道什么时候该收手”。一个敢于写明退出条件的立项方，通常也会被认为更靠谱。

5. 五道闸门：价值闸、边界闸、资源闸、风险闸、退出闸

四问解决的是判断方向，五道闸门解决的是判断准入。每一道闸门设置 1 到 3 个具体的检查项，全部通过才能立项。我在 150 人以上的团队里用这套结构，效果比较稳定。

这五道闸门里，我判断性价比最高的是资源闸和退出闸。资源闸逼迫立项方说出机会成本，这会自然筛掉一批”什么都想要”的项目；退出闸则让资源池保持流动性。价值闸和边界闸虽然重要，但在实践中比较容易通过培训改善；资源闸和退出闸涉及利益分配，阻力最大，也最需要制度支撑。

五、关键指标体系：立项阶段该盯的十二个指标

指标体系最容易犯的错是”什么都想量”。我在一个团队里见过 38 个立项相关指标，结果没人看。下面这 12 个是我在多轮迭代后留下的，分成四组，每组 3 个指标，覆盖质量、进度、成本和健康度。

1. 质量组：目标清晰度、假设数量、非范围条数

目标清晰度用最简单的打分制：目标中是否包含可测数字（+2 分）、是否有验证时间点（+2 分）、是否有验证口径说明（+1 分），满分 5 分。低于 3 分的立项申请直接退回。我在 6 个团队里推行这个打分后，平均目标清晰度从 2.1 分提升到 4.3 分，用时大约 3 个月。

假设数量指立项文档中明确标注为”假设”的条目数。这个指标不是越多越好，而是”0 个”很危险。经验上，一个中等复杂度项目的合理假设数量在 4 到 9 条之间。少于 4 条，通常意味着立项方没有认真想不确定性；多于 15 条，说明需求本身还没收敛。

非范围条数是范围蔓延的预防指标。我建议的基线是至少 3 条，复杂项目至少 6 条。这个指标的值可以直接和后期变更次数做相关性观察。

2. 进度组：立项周期、决策等待时长、里程碑偏差率

立项周期指从提交申请到正式立项的天数。这个指标容易被误读成”越短越好”。实际上，周期过短（比如 2 天以内）通常意味着审查不充分，周期过长（比如超过 30 天）则说明决策链路有阻塞。我在实践中发现，7 到 15 天是比较健康的区间，它给了异步预审留出时间，又不会让立项方等到失去耐心。

决策等待时长是立项周期的细分拆解，指材料齐备后到拿到决策结果的等待时间。这个指标往往暴露组织问题而非流程问题。我遇到过一个团队，立项周期平均 26 天，其中 19 天是”等待某位负责人有空看材料”。这类问题无法靠改流程解决，只能靠分级授权。

里程碑偏差率是立项后第 4 周开始采集的指标，计算方式是实际完成时间与计划时间的差值除以计划时间。前 3 个月偏差率超过 30% 的项目，需要重新审视立项时的假设是否成立。

3. 成本组：人天投入、机会成本占比、返工人天

人天投入必须按角色拆分，而不是只记总数。因为”3 个后端 2 个月”和”1 个架构师 + 2 个后端 2 个月”的成本结构完全不同，尤其是当架构师是稀缺资源时。

机会成本占比是我最推荐但也最难采集的指标，指的是为这个项目而暂停或延后的其他项目所损失的价值占比。采集方式是资源闸环节强制填写”被挤压的项目名称及预估影响”。这个指标的功能不是精确计算，而是让决策者意识到”立项永远是有代价的”。

返工人天是立项质量的滞后指标。我会把它拆成两类：需求理解偏差导致的返工、技术方案错误导致的返工。前者指向立项问题，后者指向执行问题，混在一起就看不出原因。

4. 健康度组：僵尸项目率、退出条件触发次数、资源回收率

僵尸项目率是我判断一个研发组织治理水平的首选指标，定义是”连续 4 周无实质进展且无明确叫停决定的项目数占总项目数比例”。健康值应该在 5% 以下。我见过最高的一个团队是 23%，那意味着近四分之一的资源卡在了没人管的项目里。

退出条件触发次数看起来是个”负面指标”，但我的判断恰恰相反：一个立项体系如果整年没有触发过一次退出条件，说明退出条件写得不够具体，而不是项目都很成功。合理的状态是每年有 10% 到 20% 的项目因触发退出条件而调整或终止。

资源回收率指项目终止或降级后，释放的人力在多长时间内被重新分配到新项目。这个指标反映的是组织的资源流动性。回收周期超过 3 周，说明资源调度机制有瓶颈。

六、数据观察：一个 107 人研发团队的立项改造实录

这一节讲一个完整案例。它是我参与最深、数据也最完整的一次，团队规模 107 人，4 个研发小组 + 1 个架构组，业务是企业级软件的持续交付。所有数据都是脱敏后的区间值，不涉及具体商业信息。

1. 改造前的数据基线

2023 年初的基线是这样的：立项无统一入口，各小组用各自的文档模板；立项后无跟踪机制，项目状态靠周会口头同步；近 12 个月内启动的项目中，有 27% 无法说清当前进展；平均立项周期 3 天，但立项后 3 个月内的需求变更中位数是 14 次。

最能说明问题的是这个数字：在他们当时的 41 个在跟踪项目中，有 11 个已经连续 6 周没有任何代码提交或文档更新，但也没有被叫停。这就是典型的僵尸项目，占比接近 27%。

2. 三个模板 + 五道闸门的落地方式

我们没有从制度入手，而是从工具配置入手。具体动作分三步：

1. 统一立项入口：在平台上建立独立的”立项”工作项类型，与”需求””任务””缺陷”区分开，所有立项必须在这里创建，字段包括目标、验证口径、非范围清单、假设清单、退出条件、资源来源。
2. 模板化三个场景：探索型、交付型、技改型各有独立的必填字段组合。探索型必须填假设清单和资源上限；交付型必须填范围、非范围和质量标准；技改型必须填前后对照指标。
3. 闸门自动化：五道闸门里的三项可以通过字段校验自动完成，目标清晰度评分、非范围条数、退出条件完整性。不满足条件的立项条目无法流转到”已批准”状态。

这里有一个细节值得说：他们最终选择把立项管理放在 PingCode 上，一个重要原因是支持私有化部署。这家公司的业务涉及客户数据处理，立项材料里会出现客户名称和业务量级，放在公有云上需要额外的法务审批流程，反而拖慢立项速度。私有化部署让数据边界问题一次性解决。

另一个关键因素是从 Jira 的平滑迁移。他们此前在 Jira 上有 4 年多的历史数据，约 8.6 万个 issue。如果迁移需要重新录入或者只能保留部分字段，团队会本能地抵触，历史上”换系统”在研发团队里是敏感话题。实际迁移过程中，字段映射和工作流状态对应关系基本能覆盖，这让迁移本身没有成为立项改造的阻力，这两个项目是并行推进的。

3. 一个具体的立项条目长什么样

下面是一份改造后的探索型立项条目的简化结构示例，字段名做了泛化处理，但结构和必填约束是真实的：

项目名称: 客户数据导出链路提速
类型: 探索型

目标: 把 10 万行数据导出的 P95 耗时从 47 分钟降到 12 分钟以内

验证口径: 生产环境真实租户抽样 20 次，取 P95，第 10 周统计

现状基线: 2023-03 生产监控 P95 = 47 分钟，样本 63 次

假设清单:

假设瓶颈在序列化环节而非数据库查询（验证：单环节埋点，第 2 周）

假设目标租户数据量集中在 5 万-15 万行区间（验证：抽样统计，第 1 周）

假设导出功能月活跃租户少于 40 个，因此可以接受短暂降级（验证：埋点，第 1 周）

非范围清单:

本期不做导出格式自定义

本期不做并行分片超过 8 路的优化

本期不改造历史归档数据的导出

退出条件: 第 4 周结束时，若单环节埋点显示序列化耗时占比低于 20%，

则项目降级为常规优化，释放 1 名后端人力

资源来源: 从"报表中心重构"项目借调 1 名后端，该项目顺延 3 周

风险 Top 3:

生产环境无法复现目标租户的数据分布（缓解：提前搭建影子库）

埋点本身带来 3%-5% 性能开销影响结论（缓解：采样率设为 10%）

借调人力在项目中途被抽回（缓解：约定 8 周内不抽调）

这份材料大概 400 字，填起来不到 20 分钟。它的价值在于：如果第 2 周埋点发现瓶颈不在序列化，项目立刻可以降级，而不是花 6 周做完才发现优化方向错了。

4. 改造后 6 个月的关键指标变化

我要诚实说明一点：这组数字里，改善最明显的是僵尸项目率和需求变更次数，这两项主要靠”统一入口 + 非范围清单 + 季度盘点”实现，与工具选型关系不大。工具在这里的作用是降低执行成本，而不是创造改善。如果流程设计本身有问题，换任何平台都不会有本质变化。

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

没有一套立项规范适合所有团队。下面按规模和组织形态分五种情况给出建议，每一条都标注了”最先做的一件事”，因为大部分团队没有精力同时改五件事。

1. 20 到 50 人团队：先解决”进没进系统”

这个规模的团队最大问题通常不是流程不严谨，而是立项根本没有记录。项目靠群聊和口头约定启动，两个月后没人记得当初为什么做。

最先做的一件事：建立唯一立项入口，哪怕只是在现有的项目管理工具里加一个工作项类型。不用设计复杂字段，只用五个：目标、验证口径、非范围、退出条件、负责人。这五个字段填完大概 10 分钟。

这个阶段的建议是不要设评审委员会。20 到 50 人的团队，评审会只会变成每周一次的同步会，成本高于收益。用异步方式即可：负责人填完，技术负责人和产品负责人各看一眼，48 小时内无异议即视为通过。

2. 50 到 150 人团队：建立分级授权

这个规模是最尴尬的区间，人多了但还没到需要委员会的程度。核心矛盾是决策集中在一两个人手里，形成瓶颈。

最先做的一件事：按资源规模分级授权。比如占用人力少于 30 人天的项目，由小组负责人批准；30 到 150 人天的，由研发总监 + 产品负责人共同确认；超过 150 人天或跨 3 个以上小组的，才上升为集体决策。

我在 107 人那个团队的实践是：分级授权后，只有 18% 的项目需要上升到最高决策层，其余 82% 在 48 小时内完成决策。这直接解决了”决策等待时长”这个瓶颈指标。

3. 150 人以上或多产品线：设委员会但必须配套异步预审

到了这个规模，资源冲突是常态，必须有一个集中决策机制。但集中决策最大的敌人是信息不足，所以异步预审是必需品而不是可选项。

最先做的一件事：建立标准化打分表并强制会前提交。五个维度各 1 到 5 分，会前 3 天提交，低于阈值的不进入会议议程。这一步能把会议时间从”讨论该不该做”转移到”讨论怎么协调资源”。

另外建议设置一个固定的季度盘点机制，专门处理僵尸项目。我见过的最有效做法是：由 PMO 或项目管理办公室每季度输出一份”连续 4 周无进展”的项目清单，要求每个项目的负责人在 5 个工作日内给出继续或终止的决定，逾期未回复的自动转入暂停状态。

4. 外包与交付型项目：目标定义要更刚性

这类项目的特殊性在于验收标准通常在合同里，所以立项的核心不是”要不要做”，而是”范围边界和验收口径”。这类项目最大的风险是范围蔓延导致的成本倒挂。

最先做的一件事：把验收标准拆解成可测量的清单，并明确哪些项属于基线范围、哪些属于变更范围。同时要建立变更的成本换算规则，比如”任何新增需求都按人天折算，累计超过合同额 10% 时启动商务重新谈判”。

这类项目我建议立项周期可以更短，但非范围清单要更长，至少 8 到 10 条。因为客户方的探索性需求会持续出现，非范围清单是最有效的挡板。

5. 出海与合规敏感场景：数据边界必须在立项时确认

如果项目涉及用户数据、跨境传输或者行业合规要求（如金融、医疗），立项阶段就必须把数据边界写清楚。这类问题上，后期补救的成本远高于前期确认。

最先做的一件事：在立项材料里增加”数据流向说明”一节，标明哪些数据会离开生产环境、存放在哪里、由谁访问。对于这类场景，支持私有化部署的工具链会有明显优势，因为它把数据和流程放在同一套可控边界内，减少了立项时的法务往返。

我在 2023 年见过一个项目因为立项时没写数据流向，开发到第 5 周才被安全团队叫停，重新设计存储方案花了 3 周。这 3 周完全可以通过立项时的一页说明避免。

八、不同情况下的取舍

前面讲的是”该做什么”，这一节讲”必须放弃什么”。任何立项体系都是在几组矛盾中做选择，不承认矛盾的存在，规范就会变成形式主义。

1. 规范强度与决策速度的取舍

这是最根本的一组矛盾。规范越强，决策越慢，但后期确定性越高；规范越弱，启动越快，但返工风险越大。我的判断是：这个取舍不应该由组织统一决定，而应该由项目类型决定。

探索型项目应该偏向速度，因为它本身就是用低成本换取信息，规范过强会让探索失去意义。交付型项目应该偏向规范，因为它的成本结构和交付承诺都很刚性。技改型项目介于两者之间，重点在于前后对照指标必须清晰。

我在实践中会用一个简单规则：探索型项目的目标清晰度门槛设为 3 分，交付型设为 4 分，技改型设为 4 分且必须包含基线数据。同一套流程，不同门槛。

2. 指标数量与数据可信度的取舍

指标越多，看起来管理越精细，但人工采集的指标越多，数据可信度越低。我在一个团队见过 38 个立项指标，抽查后发现其中 14 个的填报数据与实际情况明显不符，原因是填报人不知道该怎么算。

我的建议是：人工采集的指标不超过 5 个，其余全部自动化采集。自动化采集的前提是工具链能提供数据，这也是为什么立项管理和研发过程管理放在同一平台上会更有优势，数据不需要跨系统搬运，口径也不会因为人工转录而失真。

如果工具条件不具备，宁可把指标砍到 5 个以内，也不要采集一堆不可信的数字。错误的指标比没有指标更危险，因为它会引导错误的决策。

3. 自研工具链与商用平台的取舍

我在不同团队里两种方案都经历过。自研的好处是贴合度高、可以按需定制；坏处是维护成本高、能力边界窄、人员流动后容易失维。商用平台的好处是能力成熟、迭代稳定；坏处是可能需要调整流程去适应平台。

我的判断标准是团队规模和业务差异化程度。50 人以下、业务标准化程度高的团队，自研工具链几乎没有性价比，因为维护成本会持续侵蚀研发产能。150 人以上、有特殊合规或流程要求的团队，可以在商用平台基础上做集成和扩展，但完整的自研通常也不划算，除非研发工具本身就是业务的一部分。

对于需要私有化部署、或者有历史数据迁移包袱的团队，选择支持平滑迁移和私有化部署的平台能显著降低切换成本。这类决策在立项阶段就应该明确，因为它影响后续所有项目的管理方式。

4. 集中立项与分级授权的取舍

集中立项的好处是全局视角、资源冲突容易发现；坏处是决策慢、容易形成瓶颈。分级授权的好处是快、责任清晰；坏处是可能出现局部最优、整体次优。

我的经验阈值是：当每月的立项申请超过 15 个时，纯集中决策一定会成为瓶颈。这时应该引入分级授权，但要配套两件事：一是统一的字段和评分标准（否则分级后口径会散），二是季度级别的全局资源盘点（否则局部最优会累积成整体问题）。

还有一个容易被忽略的取舍：分级授权意味着放弃一部分决策质量的统一性，这个代价必须被接受。我见过一些团队名义上做了分级授权，但每个决策还是要向上报备，结果是既没获得速度，又增加了流程层级。这是最差的一种状态。

九、下一步该怎么做

写到这里，我想回到开头那个烧掉 1080 人天的项目。它真正的问题不是目标定得高，而是没有人被要求把”提升客户续约率”翻译成一句可被验证的话。所有参与者在评审当天其实都感觉到了不对劲，但流程没有给他们一个必须说出口的位置。

这就是我认为立项规范最核心的价值：它不是用来增加审批层级的，而是用来给”说真话”创造一个制度性的位置。目标清晰度打分、非范围清单、退出条件，这三件事之所以有效，是因为它们把模糊变成了一种必须被指出的状态，而不是可以被默许过去的状态。

关于关键指标，我的独特判断有三条，都是从实际数据里磨出来的：

• 立项周期不是越短越好，而是应该落在 7 到 15 天的区间。低于 7 天通常意味着审查不足，高于 15 天通常意味着等待而非审查。但要警惕一种情况：周期很长但返工依然很高，这说明流程只是增加了等待时间，没有增加审查质量。
• 退出条件触发次数为 0 是危险信号，不是好消息。一个健康的立项体系，每年应该有 10% 到 20% 的项目因触发退出条件而调整。如果整年一次都没触发，要么条件写得太宽泛，要么没人敢执行。
• 僵尸项目率是衡量研发治理水平的第一指标。它同时反映了立项质量、跟踪机制和资源流动性三个维度的问题。如果一个团队只能看一个指标，我会建议先看这个。

如果你现在就要动手，我建议的下一步动作顺序是这样的：

1. 本周内，统计一下你团队当前的僵尸项目率：连续 4 周无实质进展但未被叫停的项目占比。这个数字会告诉你问题的严重程度。
2. 两周内，在你的项目管理工具里建立一个统一的立项条目类型，只包含五个必填字段：目标、验证口径、非范围、退出条件、资源来源。不要设计更多字段。
3. 一个月内，选三个新立项做试点，按本文的三要素结构（可测数字 + 验证时间点 + 验证口径）来写目标，观察第一个月的需求变更次数是否低于团队平均水平。
4. 一个季度内，建立季度盘点机制，对僵尸项目强制要求”继续或终止”的书面决定，逾期自动转入暂停。
5. 半年内，根据数据决定是否需要分级授权，以及是否需要把立项管理与研发过程管理放在同一平台上以降低指标采集成本。

最后提醒一件事：立项体系的改造最忌讳一次性推翻重来。我见过的成功案例，无一例外都是先加一条硬约束（比如”不进系统不算立项”），跑三个月拿到数据，再用数据说服团队接受第二条。制度是靠数据长出来的，不是靠文件推下去的。