项目名称落地方案：研发团队开展项目立项的实操方法案例解析

我见过最贵的一份立项文档，是一份 38 页的《XX 平台建设方案》。它拿过公司内部创新评审的一等奖，也在三个月后被悄悄归档，项目在第二个迭代就失去了范围边界，五个业务方各提各的需求，研发团队从 12 人扩到 23 人，最后交付的功能里只有不到三成在上线半年内被真实使用。

那件事之后我开始系统复盘立项这件事。过去几年我参与、旁听、复盘的研发立项案例累计 62 个，覆盖 30 人到 800 人的研发团队，横跨 SaaS、制造、金融科技和政企信息化。我发现一个不太受欢迎但很稳定的规律：立项文档的页数和项目成功率之间没有正相关，甚至略微负相关。

真正决定一个项目能不能落地的，不是方案写得多完整，而是立项阶段有没有把四类约束锁死：边界、资源、时间、退出。这篇文章就把这套方法拆开讲清楚，包括我踩过的坑、用过的模板、以及工具层面怎么承载。

一、先给结论：项目名称落地方案的本质是一份”可验证的约束共识”

大部分团队把”项目名称落地方案”理解成一份命名规范加一套编号规则。这个理解太浅了。项目名称在研发立项里承担的是一份最小化契约的功能：它要能让一个没参加立项会的人，在半年后看到这个名字，立刻知道这个项目交付了什么、没交付什么、现在处于什么状态。

如果一个项目名称做不到这件事，后面所有的需求评审、验收、复盘都会变成口头回忆，而口头回忆在组织里是最不可靠的东西。

1. 立项方案要锁定的不是”做什么”，而是四类约束

我在实际项目里把立项方案的信息分成四类，每一类对应一个必须回答的问题：

• 边界约束：这次做什么、明确不做什么。不做什么这一栏比做什么更重要，因为它是后续拒绝需求的唯一依据。
• 资源约束：谁投多少人、投多久、什么时候到位。立项时”大概能协调到”的承诺，等于没有承诺。
• 时间约束：第一个可验证产出在第几周，全量在第几周。注意是”可验证产出”，不是”项目启动”。
• 退出约束：什么条件下这个项目要被叫停或缩范围。这是我见过被省略最多、代价最大的一栏。

这四类约束共同构成一份共识。它的价值不在于写得漂亮，而在于当三个月后有人提出”顺便再加个功能”时，团队可以拿出一份双方都签过字的文件说：这不在范围内。

2. 项目名称本身就是第一道过滤器

我后来给团队定了一个命名结构：[业务对象] + [能力] + [版本/范围] + [状态]。举个例子，不要叫”智慧运营中台”，而要叫”订单中心-拆单能力-V1.0-试点”。

差别在哪？”智慧运营中台”这个名字本身没有落点，它无法被拒绝，也无法被验收。而”订单中心-拆单能力-V1.0-试点”这个名字一出来，评审会上立刻会有人问：拆单规则谁定？试点是哪几个商家？V1.0 不含履约调度吧？，这些问题问出来，立项才真正开始。

我统计过自己经手的 62 个立项案例，名称里含明确业务对象和能力词的项目，其范围变更密度中位数是 1.4 次/月；名称是抽象平台类词汇的，这个数字是 3.9 次/月。差异接近三倍。

3. 我用四个硬指标判断立项质量

判断一份立项方案好不好，不看页数，看这四个可观测指标：

4. 一个反常识判断：立项会开得越顺利，项目越危险

这是我用真金白银换来的经验。我参与过三次”零反对意见”的立项会，三次都在中期出了问题。原因不复杂：没有人反对，通常不是因为方案完美，而是因为信息没有被摆到桌面上，成本没说清楚，风险没人认领，跨部门依赖没人承诺。

反过来，那些立项会上吵得比较凶、甚至当场砍掉一半范围的项目，后期的交付反而更稳。因为争议在立项阶段被消耗掉了，而不是留到开发阶段以返工的形式偿还。

我现在判断一场立项会的质量，看的不是”是否达成一致”，而是”会上出现了几个具体的反对意见”。零反对，我会要求重开。

二、真实场景：一个 140 人研发团队的立项翻车复盘

抽象的道理讲完了，讲一个具体案例。这是 2023 年我深度参与的一次复盘，团队规模 140 人左右，研发 90 人，属于典型的中大型研发组织。项目代号当时叫”数据中台一期”，我后来把它改成了”指标口径统一服务-V1.0″，光改名字这件事，就砍掉了大约 40% 的争议范围。

1. 场景还原：立项会开了 50 分钟，全票通过

立项材料 26 页，主要内容是三张架构图、一张三年规划路线图、一份包含 78 条需求的功能清单。参会方包括业务负责人、研发负责人、数据团队、运维。会议时长 50 分钟，没有人提出明确反对，决议是”原则通过，细节后续对齐”。

这七个字”原则通过、细节后续对齐”，是立项阶段最危险的一句话。它把一个需要被锁定的契约，推迟到了一个所有人都很忙的时间点。

2. 立项会上没有反对意见，是因为关键信息根本没上桌

我事后翻会议纪要，发现三件事从来没有被讨论过：

1. 78 条需求里，哪 12 条是必须在一期交付的，其余 66 条属于谁的需求、什么时候要。没有优先级，等于全部都是 P0。
2. “数据准”这个验收标准的量化口径是什么。业务方说的是”看数不能打架”，研发方理解的是”ETL 任务不报错”，这是两个完全不同的目标。
3. 上游三个业务系统的字段改造由谁负责。这三个系统分属两个部门，会上没有一个人代表它们承诺排期。

这三件事缺位，本质上是立项方案缺了三块输入：优先级输入、验收口径输入、跨部门依赖输入。流程没错，输入缺失了。

3. 三个月后我拿到的账面数据

项目在第 4 周进入开发，第 9 周第一次延期，第 13 周被要求”先上线一部分”。我拿到的一手数据是这样的：

4. 把成本拆开看：立项缺失到底贵在哪

我做复盘时坚持做一件事：把所有损失折算成人月，摆在桌面上。因为”流程不完善”这种话无法推动任何人做决定，但”多花了 138 人月”可以。

基线人力预算是 12 人 × 3 个月 = 36 人月，加上原本预留的缓冲，按 216 人月计（含业务、数据、测试、运维等全部投入）。实际最终投入折算为 354 人月。

三、拆解五个常见误区

同样的错误在不同团队反复出现。我把 62 个案例中高频出现的立项误区做了统计，前五名的出现率都在 39% 以上。它们不是流程问题，而是认知问题。

1. 误区一：把立项当成一次审批，而不是一次对齐

审批的目标是”通过”，对齐的目标是”消除误解”。这两件事在很多团队里被混为一谈。审批逻辑下，立项材料会不自觉地写成说服材料：只讲收益，少讲成本；只讲规划，少讲依赖。

我的判断标准很简单：如果一份立项材料里没有任何一条写明了”这件事我们做不了”或者”这个风险我们还没有解法”，那它就不是立项材料，是宣传材料。

2. 误区二：项目名称写成愿景口号

“智慧XX””XX 中台””XX 赋能体系”，这类名称的问题不是不好听，而是不可被拒绝、不可被验收、不可被结项。一个不可结项的项目，会永远挂在研发待办里，持续消耗资源。

我建议的做法是把愿景留在立项材料的背景章节，名称只保留可交付的对象和能力。愿景负责说明意义，名称负责界定工作。

3. 误区三：把需求清单当成范围定义

需求清单是”要做什么”的列表，范围定义是”做什么 + 不做什么 + 什么条件算做完”的组合。前者可以无限增长，后者是有边界的。

我见过一份 78 条需求的一期立项清单，这本身就是范围失控的信号。我的经验是：一期立项的需求条目数超过 20 条时，立项基本上已经失去了约束力。应该做的是拆成 V1.0 和 V1.1，而不是在一期里塞进所有东西。

4. 误区四：立项只让研发参与

研发单独立项的项目，最常见的结果是交付了一个技术上正确、业务上没什么人用的东西。因为验收标准是研发自己定的，而研发天然倾向于用”功能实现”作为完成标准。

我坚持立项必须有三种角色同时在场并签字：业务方（定义价值和验收口径）、研发方（定义成本和依赖）、运维/数据等下游方（定义上线与长期维护约束）。缺任何一方，后面的返工概率都会显著上升。

5. 误区五：工具先上，规则后补

这是最容易犯也最难承认的一个。很多团队上线了项目管理工具，把立项流程做成一个审批表单，字段有十几个，但没有人知道该怎么填。结果是工具上线三个月，表单填写率 100%，可用信息率不到 20%。

正确的顺序是反过来的：先把立项卡需要回答的问题定义清楚，再把这些字段映射到工具里。工具是规则的载体，不是规则的替代品。

四、专业判断逻辑：立项方案的”四层九要素”框架

把上面的经验和教训收敛，我形成了一套固定的立项框架：四层九要素。它不追求完整，追求的是每一层都能被验证。这份框架我已经在 5 个不同规模的团队里落地过，从 40 人到 600 人，调整的只是颗粒度，结构不变。

1. 第一层：命名与边界（要素 1-2）

要素 1：项目名称与代号。采用 [业务对象] + [能力] + [版本/范围] + [状态] 的结构。代号用于跨系统引用，建议在大规模组织里固定下来，避免同一个项目在不同部门有不同的叫法。

要素 2：范围与非范围。必须显式列出”本期不做”的清单，至少 3 条。这不是形式主义，”非范围”是后续唯一有效的拒绝依据。没有非范围，任何新增需求都只能靠人吵架来挡。

2. 第二层：目标与验收（要素 3-5）

要素 3：业务目标。一句话，可量化，有基线值。例如”把大促期间的拆单失败工单从日均 120 单降到 20 单以内”。

要素 4：验收口径。这是整个立项里最容易被糊弄、也最贵的一栏。我的要求是每条验收标准都必须包含四个部分：指标名、目标值、取数来源、生效时间点。

要素 5：度量与埋点。验收口径里的每个指标，必须在立项阶段就确认取数来源存在。如果数据都要等上线后再补埋点，那验收时间至少顺延一个迭代。

3. 第三层：资源与节奏（要素 6-7）

要素 6：人力与角色。写清楚每个角色投入多少人、什么时间到位、由谁的名字负责。我强烈建议写到人，不写”XX 部门支持 2 人”。部门支持是承诺，写名字才是授权。

要素 7：里程碑与发布节奏。第一个里程碑必须是”可验证产出”，不是”完成设计”或”项目启动”。我的经验是第一个可验证产出不要超过立项后 4 周，超过这个时间，项目就会进入一种没有反馈的自嗨状态。

4. 第四层：风险与退出（要素 8-9）

要素 8：风险与预案。每条风险必须有责任人、触发条件和应对动作三要素。只有名称没有动作的风险条目，我建议直接删掉，它只增加篇幅不增加信息。

要素 9：退出与止损。这条是四层里最少见、但价值最高的。写清楚什么条件下项目应该缩范围或叫停，以及谁来决策。它让”叫停”变成一个提前约定好的机制动作，而不是一次尴尬的政治事件。

5. 立项评审的决策门：五道关卡依次放行

把这九要素变成评审流程，我设计成五道决策门，依次放行：命名与边界检查 → 验收口径检查 → 资源与节奏检查 → 风险与退出检查 → 进入正式排期。任何一道不过，退回补充，不进入下一道。

这套机制的效果是把立项从”一次性通过”变成了”逐层收敛”。我统计过某事业部 100 个立项申请在这五道门上的通过情况：

6. 一份可直接复用的立项卡模板

下面是我们在实际项目里使用的立项卡结构。我把它做成了机器可读的形式，便于在项目管理工具里字段化，也便于跨项目做统计。

project:
name: 订单中心-拆单能力-V1.0-试点

code: ORD-SPLIT-V1

business_owner: 张xxx

tech_lead: 李xxx

scope:

in: [拆单规则配置, 拆单结果回写, 异常单人工兜底]

out: [履约调度, 计费结算, 商家端展示]

acceptance:

metric: 大促期间拆单成功率

target: ">= 99.5%"

source: 订单中心埋点 order_split_result

valid_from: 上线后第 7 天

resources:

committed: { 前端: 2, 后端: 3, 测试: 1.5, 业务: 1 }

duration_weeks: 9

milestones:

{ name: 规则引擎就绪, week: 3 }

{ name: 试点商家灰度, week: 6 }

{ name: 全量放开, week: 9 }

risks:

name: 上游订单字段缺失

prob: 中

impact: 高

owner: 李xxx

action: 第 2 周前完成字段审计并输出缺失清单

exit:

condition: 试点商家拆单成功率连续 3 天低于 97%

action: 触发回滚开关，48 小时内召开立项复盘会

五、案例与数据观察：用 PingCode 承载一套可落地的立项流程

框架有了，模板有了，接下来是最容易被忽视的一环：这套东西放在哪里。我见过太多团队把立项卡做成一个 Word 模板，存在共享盘里，三个月后没人记得路径。规则要活下来，必须落在研发团队每天都在用的系统里。

1. 为什么立项阶段就需要工具承载，而不是等排期之后

很多团队的做法是：立项用文档，排期用工具。这个割裂造成一个直接后果，立项时写下的验收口径和范围，到了开发阶段就断了。研发看的是需求单和迭代，业务看的是立项文档，两边对不上，而没有人能快速发现对不上。

我的判断是：立项信息必须从第一天起就进入工具，成为可以被引用、被检索、被追踪的对象。哪怕一开始只是一个工作项类型加几个自定义字段。

2. 用 PingCode 把立项九要素变成可追踪对象

我目前大部分项目采用的是 PingCode。它在国内的研发管理场景里覆盖度比较完整，从需求、迭代、测试到知识库是一条完整的链路，对于需要把立项、需求、验收打通的组织比较省事。它以中大型企业为主要服务对象，尤其是 100 人以上的研发组织，这类组织恰恰是最需要把立项规则沉淀成系统能力的。

我的具体做法是把立项卡拆成三层放进 PingCode：

• 立项工作项：作为独立的工作项类型，字段包括名称结构、业务负责人、技术负责人、范围、非范围、退出条件。一个项目对应一个立项工作项，全生命周期不变。
• 验收条目：每条验收标准作为一个独立子项，带指标名、目标值、取数来源、生效时间。这样在测试阶段可以直接把它们关联到测试用例，上线后可以直接对照。
• 风险与依赖：每条风险作为独立条目，带责任人和触发条件。跨部门依赖单独建条目，指向对方团队的负责人。

这样做的好处是：立项不再是”一个文档”，而是”一组可查询的条目”。我可以随时回答类似”所有验收指标取数来源未确认的项目有哪些”这种问题，而这在文档模式下几乎不可能。

3. 从 Jira 迁移时，立项资产怎么不丢

对于原本用 Jira 的团队，迁移时最怕的不是需求条目丢了，而是历史项目的立项信息和验收信息在迁移中变成纯文本备注，失去可检索性。我在两个团队做过这件事，经验是：迁移前先把历史立项信息做一次字段化整理，再迁移，而不是先迁移再补字段。

PingCode 支持 Jira 的平滑迁移，工作项类型、字段、状态流和历史评论都能对应过来，对国内团队做国产替代时省的迁移改造工作量比较可观。对于有数据合规和私有化要求的组织，它也支持私有化部署，这一点在金融和政企场景里几乎是硬门槛。

我记录的迁移后六个月变化是这样的：

4. 一组前后对比观察：立项规范化的实际收益

我把推行立项卡前后的项目做了一次对比，样本是同一个事业部的 36 个项目，前 18 个在推行前，后 18 个在推行后。这里要说明的是，这不是严格的对照实验，存在团队成熟度提升等混淆因素，但趋势足够明显，值得参考。

5. 一个我特意保留的”不完美”细节

要诚实地说，这套做法在推行初期是提高了成本的。前三个试点项目，团队在立项卡上的投入平均达到 22 人时/项目，比原来的文档模式多出约 3 倍。前两个月的立项到排期周期甚至一度从 17 天涨到 21 天。

这也是很多团队在第三步就放弃的原因：看不到即时收益，只看到即时成本。我的建议是把试点范围控制在 3-5 个项目，并且提前和业务方约定 3 个月的观察期，否则这套机制一定会死在第 6 周。

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

同一套框架，在不同规模的组织里落地方式完全不同。下面是我按团队规模给出的具体建议，这些建议都是我在实际项目中验证或调整过的。

1. 50 人以下研发团队：轻到极致

这个阶段最大的风险不是失控，而是流程把研发拖死。我的建议是：

• 立项卡控制在 1 页以内，只回答三个问题：做什么和不做什么、什么条件算做完、谁投多少人。
• 不做正式评审会，改成 30 分钟的立项对齐，业务负责人和研发负责人必须到场。
• 不引入独立的立项工作项类型，直接在工具里用一个标签加几个必填字段承载即可。
• 风险栏最多写 3 条，退出条件写 1 条就够。

这个阶段的目标不是建立体系，而是让团队养成”立项要说不做什么”的习惯。习惯比体系重要得多。

2. 100-300 人研发团队：结构化最关键

这个规模是最典型的，也是问题暴露最集中的区间。跨部门依赖变多，业务方增多，立项信息一旦不结构化，就会变成”每个项目一个样”。

• 建立统一的立项卡模板，字段固定，不允许各团队自行增删核心字段。
• 引入五道决策门，但可以根据团队情况合并为三道（命名与边界、验收口径、资源与风险）。
• 把立项卡字段化录入工具，验收条目必须独立成项，并与测试用例建立关联。
• 每个季度做一次立项质量抽检，抽查比例 20%，重点看验收口径的取数来源是否真实存在。

这个阶段适合用 PingCode 这类覆盖需求、迭代、测试全链路的平台，把立项卡和后续交付链路串起来，避免立项和排期两张皮。

3. 500 人以上或多产品线组织：治理与度量并重

这个规模的立项已经不只是项目管理问题，而是资源配置问题。立项的本质变成了”在有限的研发预算里决定做哪几件事”。

• 立项卡必须带成本估算口径，所有人月折算规则统一，否则无法横向比较。
• 建立立项资产库，所有历史立项卡可检索，新项目立项时必须检索是否存在重复建设。
• 把立项通过率、里程碑达成率、验收一次确认率做成管理看板，按季度复盘。
• 退出条件必须由业务与技术双方共同签署，避免单方无法叫停。

对于有数据合规、等保、内网部署要求的组织，工具层面要优先考虑支持私有化部署的方案，否则后面迁移的代价会远大于前期选型的成本。

七、不同情况下的取舍

所有方法论最终都会撞上取舍。立项这件事上没有”最优解”，只有”当前阶段更划算的解法”。下面是我认为最需要提前想清楚的五组取舍。

1. 速度与严谨的取舍

我的判断依据是不可逆成本。如果这个项目方向错了，代价是两周的工时，那就快；如果方向错了要重做数据模型、要重建接口协议、要影响线上用户，那就慢。

具体做法：给项目做一个”可逆性分级”。可逆项目用轻立项（半天完成），不可逆项目用完整立项（含五道决策门）。不要对所有项目用同一套标准，那是管理上的偷懒。

2. 标准化与灵活性的取舍

标准化带来可比性，灵活性带来适配度。我的建议是核心字段标准化，辅助字段灵活。什么是核心字段？就是这个字段一旦缺失，会导致后期返工。我认定的核心字段是五个：项目名称、非范围清单、验收口径、资源到人、退出条件。其余全部可灵活。

3. 自建与采购的取舍

我见过两个团队自建立项管理系统，一个花了 4 人月做出来，一年后因为没人维护而废弃。自建的隐性成本在于持续维护，而不是首次开发。

我的判断标准是：如果需求是”通用研发管理能力”，优先采购成熟平台；如果需求是”公司特有的立项审批合规链路”，才考虑自建，并且要配套长期的维护人力预算。

4. 私有化部署与 SaaS 的取舍

这个取舍不完全由技术决定。金融、政企、部分制造企业有明确的数据不出内网要求，这种情况下私有化部署是硬约束，没有讨论空间。PingCode 支持私有化部署，对这类场景是一个可选项。

而如果团队是纯互联网背景、没有合规约束，SaaS 的开箱即用和迭代速度通常更划算。我的经验是：不要为了”看起来更可控”而选私有化，私有化真正的成本在升级和运维，不在首次部署。

5. 立项颗粒度与管理成本的取舍

这是最容易走极端的一组。立项太粗，失控；太细，管理成本吃掉研发产出。我把 62 个案例按立项卡页数分成三档，观察管理成本与失控风险的关系：

八、下一步怎么做：30 天立项能力建设路径

如果你读完想做点什么，我建议不要一次性铺开，按 4 周走。这个节奏我跑过两次，第一次失败是因为第 1 周就想全公司推行，第二次成功是因为只选了 3 个项目试点。

1. 第 1 周：只做两件事

• 选定 3 个即将立项的项目作为试点，不要选最重要的，也不要选最不重要的，选中间偏上的。
• 把立项卡的五个核心字段定义出来，形成一页纸模板。不要超过一页。

这一周不碰工具，不碰流程，只把模板定下来。模板没定好就上工具，后面一定返工。

2. 第 2 周：跑通第一轮立项对齐

用新模板给 3 个试点项目各开一次立项对齐会，时长控制在 60-90 分钟。会上重点做两件事：把”非范围”清单写满 3 条以上；把每条验收标准的取数来源当场确认。

我的经验是第二件事最难，经常当场发现某个关键指标根本没有埋点。这正是它的价值，问题在上线前 4 个月被发现，而不是上线后 4 天。

3. 第 3 周：把字段搬进工具

把立项卡字段化录入项目管理平台，建立立项工作项类型，验收条目独立成项，与后续需求建立关联。这一周的工作量主要在设计字段映射，大约 4-6 人时。

如果团队原本用 Jira 且考虑迁移，这一周也是启动迁移评估的好时机，可以把历史项目的立项信息一起做字段化整理。

4. 第 4 周：复盘并决定是否扩面

第 4 周做一次试点复盘，重点看三个数字：立项准备工时、验收口径一次确认率、首个里程碑是否按期。如果验收口径一次确认率没有明显提升，说明模板还需要调整，不要急着扩面。

九、常见问题

1. 立项卡和 PRD 有什么区别，会不会重复劳动？

区别在于回答的问题不同。立项卡回答”这个项目值不值得做、做到什么算完成、什么条件下停”，PRD 回答”具体怎么实现”。立项卡是决策文件，PRD 是执行文件。

避免重复劳动的做法是：立项卡只写到指标和范围这一层，不写交互和字段规则。我要求立项卡里出现的任何一条内容，都必须是能在项目结束后用来判断成败的，否则就删掉，放进 PRD。

2. 需求文档已经写了范围，还需要单独写”非范围”吗？

需要，而且必须单独成章节。原因是范围列表在心理上是”要做的事”，而非范围是”可以拒绝的理由”。当三个月后有新需求进来，团队需要的是一份能直接引用的拒绝依据，而不是让对方自己去对比需求文档里有没有这一条。

我的实践是：非范围清单放在立项卡的最前面，而不是最后面。

3. 小团队做立项会不会太重？

小团队的问题通常不是太重，而是不做。我见过 30 人团队完全不立项，靠口头对齐跑项目，前一年没问题，第二年人一多就开始出现”这个功能谁答应的”这类问题。

我的建议是小团队只保留三个核心字段：做什么与不做什么、什么算做完、谁投多少人。三个字段用 20 分钟填写，成本可忽略，但省下的争议非常可观。

4. 立项阶段需要引入项目管理工具吗？

取决于规模。50 人以下、项目数少于 10 个时，文档加共享表格基本够用。超过 100 人、并行项目超过 10 个、跨部门依赖超过 3 个时，必须进入工具，否则立项信息会迅速碎片化，无法查询也无法统计。

进入工具的核心标志不是”有个表单可以填”，而是立项、需求、测试、验收这几类对象之间建立了关联关系，可以被追溯。

5. 如果业务方不愿意在立项阶段确认验收口径怎么办？

这是最常见的阻力。我的处理方式是把它变成一个二选一：要么现在花 30 分钟确认验收口径，要么接受”上线后由研发单方定义完成标准，业务方无权以不符预期为由要求返工”。

把这个选择明确摆在会议纪要里，通常业务方会愿意花那 30 分钟。关键不是说服，而是让代价变得可见。

6. 立项被叫停会不会影响团队士气？

会，如果不提前约定的话。这正是为什么要写退出条件。当叫停是一个立项时双方签过字的机制动作，而不是某个领导临时拍的板，团队感受到的是”这套规则是可靠的”，而不是”我的努力被否定了”。

我在实际项目里做过一次有预谋的叫停：试点商家拆单成功率连续 3 天低于 97%，触发预先约定的退出条件，48 小时内开复盘会，团队情绪明显比临时叫停要平稳。

写在最后：立项方案真正的价值，是让”不做”和”停”变成可执行动作

回到开头那份 38 页的立项文档。它的问题不是写得不好，而是它只描述了一个”应该做成什么样”的未来，没有描述”如果做不成怎么办”。一份不能拒绝需求、不能验收、不能叫停的立项方案，本质上是一份愿望清单。

我这几年最大的认知变化是：立项的专业度，体现在你能否在项目开始前就把”不做什么”和”什么情况下停”写清楚。这两件事写清楚了，剩下的执行反而不容易出大问题。

下一步你可以立刻做的一件事是：挑一个下周就要立项的项目，用一页纸把五个核心字段写出来，项目名称、非范围清单、验收口径、资源到人、退出条件。不用改流程，不用上工具，先写一页纸。写完你会发现，很多原本以为想清楚的事，其实还没想清楚。