项目背景怎么做？项目负责人落地方案：项目立项从0到1

项目背景写得含糊，是立项被驳回最常见的单一原因。我陪跑过 60 多次立项评审，一次通过的立项书里，背景部分平均只占 1.5 页，但它决定了后面 20 页有没有必要写下去。反过来，被要求”回去再想想”的立项书，八成问题都出在背景：不是写得太短，而是写成了行业趋势科普，评审看完知道行业在变，但不知道我们公司为什么现在必须花钱。

这篇文章不讲理论框架，讲的是我自己在评审现场看到的、被追问的、被打回的那些真实片段。我会把”项目背景”拆成一个可执行的动作序列：从 0 到 1 立项，项目负责人到底该在哪里找证据、按什么顺序写、什么时候该停下来不再补材料。

如果你是项目负责人、PMO、研发负责人，或者正在准备一份 100 人以上组织的正式立项书，这篇文章里的模板、评分卡和取舍表可以直接拿去用。我也会用 PingCode 这类面向中大型企业的研发管理平台作为案例载体，说明在不同立项类型下，背景部分该怎么写才站得住。

一、先给结论：项目背景不是”背景介绍”，而是立项的决策锚

先把结论放在前面：项目背景的唯一职责，是让决策者在 3 分钟内完成一次判断，这件事现在不做，代价是否可接受。它不是叙事，是论证；不是铺垫，是锚点。一篇合格的背景，读完应该让评审产生”这确实得做”的结论，而不是”听起来挺有道理，但我们再研究研究”。

我见过最典型的两份立项书：第一份背景写了 2 页，讲了行业数字化转型趋势、国家政策、同行都在做，结果被问”所以呢”；第二份背景只有 600 字，写的是”上季度研发交付延期 11 次，其中 7 次根因是需求变更无留痕，客诉工单同比涨 43%，按每单 1.2 万元成本折算，直接损失约 86 万元”，评审 12 分钟就过了。差别不在文笔，在于后者把背景写成了决策依据。

1. 项目背景真正要回答的三个问题

第一，为什么是现在。不是”行业趋势如此”，而是”再往后拖 6 个月会发生什么”。拖延成本是最有力的背景素材，也是最常被忽略的一项。

第二，不做会怎样。评审最怕的立项书，是只讲做了之后多好，不讲不做会损失什么。收益是概率，损失是事实，事实比概率更容易推动决策。

第三，为什么是这件事，不是别的。这一条决定你的立项会不会被排到明年预算表最后一行。如果背景里没有出现过”我们评估过 A 方案和 B 方案，最终选择 C”，评审就会替你问出这个问题。

2. 我判断一份项目背景是否合格的四个硬标准

• 可追溯：每一个数字都能指到来源。来自工单系统、财务台账、访谈记录还是抽样测算，必须写明。数量级数字不带来源，等于没有数字。
• 可证伪：背景里描述的现状，别人拿数据能推翻你。如果一句话谁都无法验证，它对评审毫无价值。
• 有代价：至少有一处明确写出”不做”的量化成本，包括显性成本（人力、赔付、返工）和隐性成本（机会窗口、合规风险）。
• 有边界：说清楚这件事的约束条件，预算上限、团队人数、上线窗口、合规要求。没有边界的背景，会让评审觉得你想做的是一个无限项目。

3. 可以直接套用的三段式结论模板

我在实际陪跑中常用一个三段式结构，写起来快，读起来短，评审也容易抓重点。它把背景压到 500 字以内，剩下的细节全部移到附件。

【现状与代价】
过去 6 个月，研发交付延期 11 次（来源：交付周报 2024-W12 至 W36），

其中 7 次根因确认为需求变更过程无留痕（来源：根因分析记录 RD-2024-037）。

由此产生客诉工单 218 单，同比 +43%（来源：客服工单系统月度报表），

按每单平均处理成本 1.2 万元折算，直接成本约 86 万元。

【窗口与约束】

Q1 将上线两个客户侧合规审计要求，若审计前无法提供需求变更全链路记录，

将影响至少 3 家客户的续约谈判。约束：预算上限 60 万元，团队不新增编制，

上线窗口不得晚于 3 月 15 日。

【结论与选项】

建议立项建设研发过程可追溯能力。备选方案对比：

A 方案（自研轻量模块）周期 5 个月，超窗口；

B 方案（现有工具配置优化）无法满足审计留痕要求；

C 方案（引入支持私有化部署的研发管理平台）周期 6 周，满足要求。

这个模板的价值在于，它把背景、约束和方案选择三件事压进了一页纸。多数立项书失败，不是因为信息不够，而是因为信息没有被组织成判断条件。

二、真实场景复盘：一份被驳回三次的立项书长什么样

这是我 2024 年跟过的一个项目，客户是一家 800 人规模的制造企业，项目负责人是研发中心的流程经理。立项主题是”研发过程管理平台建设”，报的是 70 万元预算、6 个月周期。这份立项书被驳回了三次，每次驳回的原因都完全不同，我把它完整记了下来。

1. 第一次驳回：背景写成了行业科普

初版背景有 2 页半，开头是”随着数字化转型深入推进，制造业面临前所未有的挑战”，接着引用了三段行业报告，还配了一张”全球研发管理软件市场规模”的增长曲线。评审只问了一句：“这份背景里，哪一条是只有我们公司才有的？”

这句话问到了要害。行业趋势谁都能写，它不是背景，是环境。背景必须回答”本组织在这个环境中处于什么位置、因此受到什么具体影响”。行业报告可以放在附件，正文最多保留一句作为参照基准。

2. 第二次驳回：证据链断在执行层

第二版改了方向，写了很多痛点：需求变更频繁、版本发布混乱、测试用例散落、缺陷回流严重。问题在于全是形容词，没有一个能查到出处的数字。评审里负责质量的副总问：”你说缺陷回流严重，返工率是多少？数据是从哪里导出来的？”

项目负责人当场答不上来。这就是证据链断裂：他知道问题存在，但没有把问题变成可核对的事实。背景里的每一个形容词，都应该有一个数字兜底；每一个数字，都应该有一个系统来源。后来他从工单系统、缺陷库和周报里补了 6 个指标，背景才第一次有了骨架。

3. 第三次驳回：没有说清楚”不做会付出什么代价”

第三版的证据已经比较扎实，但仍然被卡住。这次是财务负责人提出的问题：”你说的这些问题，我们已经存在三年了，为什么今年一定要解决？”

这句话是立项评审里的经典杀招。它要的不是理由，是时间窗口。项目负责人后来补了两条：一是客户侧审计将在次年 Q1 执行，要求提供需求变更的完整追溯记录；二是现有工具的服务合约在次年 5 月到期，续约价格上浮约 30%，如果在此之前完成迁移，可以省掉一次重复投入。

这两条一加进去，立项通过。不是因为方案变好了，而是因为”不做的代价”第一次被写清楚了。没有时间窗口的立项，永远排在别人的时间窗口后面。

4. 通过版本长什么样

最终通过的背景部分只有 900 多字，结构是这样的：

1. 一段现状描述，含 3 个可追溯数字（交付延期次数、返工率、客诉工单量）
2. 一段代价折算，含显性成本与隐性成本两条计算路径
3. 一段窗口说明，含审计节点与合约到期节点
4. 一段约束条件，含预算上限、人力约束、上线时间红线
5. 一段方案对比，含 A/B/C 三个选项与排除理由

整份立项书 14 页，背景只占 1 页，附件 9 页全是数据导出截图和访谈记录。评审用了 22 分钟通过。对比前三次平均 55 分钟的扯皮时间，差异主要来自背景是否把决策所需的信息前置。

三、拆解六个高频误区

下面这六条，是我在评审现场反复见到的模式化错误。它们不是写作技巧问题，而是判断逻辑缺位。我把每一条对应的”评审真实反应”也一并列出来，方便你对照自查。

1. 误区一：把背景当介绍，不当论证

典型表现是”为了提升研发效率，我们计划建设……”。这句话是目标，不是背景。评审想知道的是当前效率是多少、损失在哪里、为什么现有手段解决不了。判断方法很简单：把背景里所有的”我们要做”换成”我们不做会怎样”，如果句子不成立，说明你写的是目标而不是背景。

2. 误区二：只写痛点，不写代价

痛点和代价是两件事。痛点让人同情，代价让人决策。”需求变更混乱”是痛点，”因变更无留痕导致的返工每季度消耗 420 人天，折合人力成本约 63 万元”才是代价。代价必须能被财务口径验证，否则很容易被归到”业务部门的主观感受”。

3. 误区三：目标与背景脱节

背景里讲的是交付延期，目标里写的却是”建成统一研发管理平台”。中间缺了一个转换：平台建成之后，延期的哪一部分会被消除、消除多少。评审会抓住这个缝隙追问关联性。背景里出现的每个问题，都应该在目标里有一个对应的量化改善项。

4. 误区四：忽略约束条件

很多立项书故意不写约束，想先把项目批下来再说。这在 100 人以上的组织里几乎必然失败，因为预算、安全、合规、采购四个部门各有一票否决权。主动写约束反而是加分项：它说明项目负责人已经做过可行性推演，而不是凭空要资源。

5. 误区五：数据来源不可追溯

“据不完全统计””业内普遍认为””大约有三分之一”，这类表述在评审现场基本等同于没有数据。我的建议是：宁可用一个小而准的数字，也不要一个大而虚的数字。比如”抽样 120 个工单，其中 43 个与变更无留痕相关”就比”约 35% 的工单因此产生”更有说服力，因为前者可以被复核。

6. 误区六：把方案塞进背景

背景讲问题，方案讲解法。把解决方案提前写进背景，会导致两个后果：一是评审会绕过问题直接质疑方案细节，讨论失焦；二是当方案被否时，整份立项书都要重写。正确的顺序是：背景建立必要性，目标建立可衡量性，方案在必要性成立之后再展开。

四、专业判断逻辑：五层证据结构

把背景写扎实，靠的不是堆材料，而是按固定顺序补齐五层证据。这五层是我在 60 多次评审中归纳出来的稳定结构，缺哪一层，评审就会在哪一层追问。顺序不能乱，因为上层证据决定下层证据是否值得收集。

1. 战略层：为什么是现在

这一层回答时机问题。可用的证据包括：年度经营目标中的相关条目、客户合同里的履约条款、行业监管节点、竞品动作、内部战略调整。关键在于把”外部趋势”翻译成”我方的具体时间点”。比如”数据安全监管趋严”不是战略层证据，”客户 A 的合同附件要求在明年 Q1 审计中提供变更留痕记录”才是。

2. 业务层：谁在受损，损失多少

业务层要明确受益人、受损人和受损金额。我通常要求项目负责人至少写出三类受损方：一线执行者（耗时增加）、中间管理者（协调成本）、外部客户（体验或合规受影响）。每一类都要有可量化的损失口径，哪怕只是抽样测算。

3. 执行层：现有流程卡在哪一步

这一层最容易被敷衍。写”流程不顺畅”没有意义，要写清楚具体卡点：需求变更从提出到落地平均 4.2 天，其中等待审批占 2.8 天；缺陷从发现到分派平均 11 小时，其中 6 小时消耗在人工确认归属模块。卡点越具体，后面方案的必要性就越不需要解释。

4. 约束层：预算、人力、时间、合规

约束层的写法有技巧：不是简单列限制，而是给出”在约束下能做到什么”。例如”预算上限 60 万元、不新增编制、3 月 15 日前上线”，紧接着写”在上述约束下，可行路径只有两条，分别是……”。这会让评审觉得你在解决问题，而不是在提要求。

5. 反证层：为什么不是别的方案

反证层是决定立项能否快速通过的关键，也是最常缺失的一层。它要求你主动排除替代方案，并说明排除理由。理由必须是硬约束（时间、合规、成本、能力），不能是偏好。评审最容易接受的不是”这个方案最好”，而是”在约束下其他方案行不通”。

6. 评分卡：给项目背景打分

我一般用下面这张评分卡做自查，每项 0-5 分，总分 25 分。低于 18 分的立项书，我建议不要上会，先补材料。这个标准比较硬，但能显著降低被反复退回的概率。

五、PingCode 场景下的项目背景怎么写：三类立项的实战拆解

研发管理类的立项，背景写法与业务系统立项有明显差别：证据大多藏在研发工具链内部，需要从工单、缺陷库、代码仓库、流水线日志里提取。下面三类是我在中大型企业里见得最多的立项类型，都以 PingCode 这类面向 100 人以上组织的研发管理平台作为落地载体来说明。PingCode 支持私有化部署，也支持从 Jira 平滑迁移，因此在国产替代类立项中经常出现在候选名单里。

1. 场景一：研发效能治理型立项

这类立项的触发点通常是”交付延期变多、质量波动加大”，但项目负责人往往一上来就写”要建统一平台”。我建议的背景写法是先做一次基线测量，用 4 个指标把现状钉死：需求交付周期、需求变更率、缺陷逃逸率、版本发布频率。

举个例子，某 1200 人规模的软件企业，基线测量结果是：需求平均交付周期 34 天，需求变更率 41%，缺陷逃逸率 18%，月均发布 1.7 次。这四个数字一摆出来，评审立刻能判断问题严重程度。接下来再写代价：按每延迟一天折算的合同违约风险敞口、按逃逸缺陷折算的线上修复成本。这样背景就有了因果链，而不是”感觉效率不高”。

这类立项在方案层通常需要覆盖需求、迭代、测试、缺陷、发布、度量这几条主线。选型时我会特别看两点：一是能否把度量指标直接落到工作项上，而不是另做一套报表系统；二是能否支撑多团队、多产品线的组织建模，因为 100 人以上组织的研发结构通常已经分层了。

2. 场景二：Jira 平滑迁移与国产替代型立项

这类立项的背景最容易踩坑，因为很多人直接把”国产替代”当成了理由。但在评审现场，”国产替代”只解决政治正确性，不解决必要性。真正让立项通过的，是迁移窗口和迁移成本的量化。

我参与过的一个案例是：某 500 人研发组织，存量 Jira 中有 1200 个工作项、37 个工作流、18 个自定义字段、240 条 JQL 保存的过滤器，另外还有 6 个活跃的第三方插件。背景里最重要的不是”我们有 1200 个工作项”，而是”如果迁移方案不能自动转换这 37 个工作流，人工重建的工时估算约为 190 人天，且迁移期间历史数据的追溯关系会中断”。

把这句话写进背景，评审的关注点会立刻从”要不要换”变成”迁移方案靠不靠谱”。这正是立项负责人想要的效果。PingCode 在这类场景里的价值点，是支持 Jira 的平滑迁移能力，能把工作项、工作流、字段映射一次性处理，从而把背景里那个 190 人天的风险项压下去。

背景写法上，我建议列一个迁移评估表，把迁移对象、数据量、映射复杂度、风险等级、验证方式五列写清楚。这张表本身就是背景附件最有说服力的一页。

3. 场景三：私有化部署与数据合规型立项

这类立项在金融、制造、能源等行业非常常见，触发点通常来自客户审计要求或内部安全规范。背景写法的关键在于区分”合规要求”和”合规成本”：前者是约束，后者才是决策依据。

举个我见过的真实情形：某企业因为两家客户在续约谈判中提出了研发数据不得出境的要求，需要在 4 个月内完成研发管理系统的私有化部署。背景里最关键的一句话不是”客户有合规要求”，而是”若无法在续约前提供私有化部署证明，两家客户的续约谈判将暂停，涉及合同金额约 1400 万元”。

私有化部署的选型评估，我一般看四项：部署形态是否支持完全内网、升级路径是否可离线、备份与容灾方案是否可审计、以及授权模式是否按组织规模而非按活跃用户计费。PingCode 支持私有化部署，在这一类立项里属于比较典型的能力匹配对象，尤其适合 100 人以上、对数据驻留有明确要求的组织。

背景里还应该有一项常被忽略的内容：退出成本。写清楚如果三年后要更换系统，数据能否完整导出、导出格式是否开放。这一条写在背景里，会显著提升评审对项目负责人专业度的评价。

4. 数据观察：背景写得厚，落地真的更快吗

我跟踪过 23 个研发管理类立项项目，把它们按背景证据完整度分成两组：一组是评分卡 18 分以上，另一组是 18 分以下。结果差异比我预想的更大。

高分组的平均立项周期是 19 天，低分组是 47 天；高分组的平均首次上线时间是立项通过后 7.2 周，低分组是 12.6 周。低分组延迟的原因不是实施能力差，而是立项阶段没解决的问题在实施阶段重新爆发：范围反复变动、约束条件后置暴露、方案被要求重新论证。

这组数据印证了我一直坚持的判断：项目背景的工作量不会消失，它只会在立项阶段或实施阶段出现。在立项阶段花 3 天补证据，通常能省掉实施阶段 3 周以上的返工和扯皮。这是我认为背景写作投入产出比最高的一条经验。

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

项目背景的详细程度不是越高越好，它应该与组织规模、决策链条长度、项目风险等级匹配。我在实际操作中按四档来处理，每一档的材料厚度、评审形式和证据要求都不同。

1. 20 人以下：一页纸立项，重点是”说清楚不做什么”

小团队不需要正式立项书，但需要一页纸的对齐文档。这一页里最重要的是窗口和边界，因为小团队最大的风险是”什么都想做”。背景部分写 3-5 句话即可：现状一句、代价一句、时间窗口一句、约束一句。不用做方案对比，但要说清楚这个季度不做什么。

2. 20-100 人：三页纸立项，重点是证据可追溯

这个规模开始出现部门墙，背景里的数字必须能查到来源，否则跨部门沟通会变成互相质疑。建议用三段式模板，配上 2-3 张数据截图作为附件。评审形式可以是 30 分钟的小范围对齐会，参与人包括业务负责人和技术负责人。

3. 100-1000 人：正式立项书 + 评审会，重点是约束层和反证层

这是最典型的场景，也是我在 PingCode 客户群体中见得最多的一档。这个规模的组织里，预算、安全、采购各有一票否决权，背景里必须主动写出约束条件与备选方案的排除理由。建议准备 10-15 页立项书，背景控制在 1-2 页，附件 6-10 页放数据与访谈记录。

评审前我通常建议做一次预演，把最可能被追问的 10 个问题写下来，逐个准备答案。这个动作看起来笨，但能把评审时长压缩一半以上。

4. 1000 人以上：立项 + 组合治理，重点是依赖关系

到这个规模，单个立项很少能独立成立，背景里必须写清楚本项目和已有项目、已有系统的依赖关系。比如”本项目依赖数据中台项目在 Q2 完成主数据治理，若该节点延后，本项目上线时间顺延”。这类表述会让评审觉得你在做组合管理，而不是在抢资源。

七、不同情况下的取舍

立项过程中真正难的从来不是”怎么写”，而是”在哪里停”。资源、时间、信息都不完整，你必须学会在几个相互冲突的目标之间做选择。下面四组取舍，是我在实际陪跑中给出建议最多的。

1. 速度与证据厚度的取舍

如果项目已经错过窗口，继续补材料只会让项目彻底失去意义。这种情况下我的建议是：保留战略层和窗口层的证据，把业务层和执行层的量化降到最低可信水平，同时在立项书里明确写出”本阶段采用抽样估算，详细基线将在立项后 2 周内补齐”。这种处理方式比硬凑数字更可信，也给评审留下了可控的后续动作。

2. 自建与采购的取舍

研发管理类项目自建的诱惑很大，因为团队觉得”我们自己也能写”。我的判断标准是三条：一是自建版本能否在窗口期内达到可审计水平；二是三年总拥有成本（含运维人力）是否低于采购；三是核心团队是否愿意在未来三年持续维护一个非主营业务系统。第三条否决的项目最多，也最容易被忽略。

3. 私有化与 SaaS 的取舍

这组取舍的关键变量不是价格，而是合规要求与运维能力。如果客户合同或行业规范明确要求数据驻留，那么私有化不是选项而是前提。反过来，如果组织没有运维储备，强行私有化会导致系统上线后长期处于”能跑但没人管”的状态。我的建议是在背景的约束层里把这两条都写清楚，让评审自己看到取舍的边界。

4. 一次性立项与分期立项的取舍

分期立项的好处是首期容易通过，坏处是后续期数容易被砍。我一般建议：如果项目的核心价值集中在第一期，就该一次性立项，避免二期被砍后系统变成半成品；如果项目价值分布均匀且预算压力大，可以分期，但必须在背景里写清楚分期划分逻辑和每期的独立价值。

八、7 天落地行动表：从零到能上会

如果你现在手上就有一个待立项的项目，下面这张 7 天行动表可以直接照做。它的目标是让你在第 7 天拥有一份可以上会的立项书，而不是完美无缺的立项书，后者通常永远上不了会。

1. Day 1-2：找证据，不写一个字

这两天只做一件事：把能查到的数据全部导出来。工单系统、缺陷库、交付周报、财务台账、客户合同附件、访谈记录。不要去写文档，也不要急着排版。我见过太多人第一天就开始调格式，结果第三天发现数据对不上，全部重来。

关键动作：至少找到 5 个可追溯数字，并且记录每个数字的导出时间、来源系统、统计口径。口径比数字本身更重要，因为评审一定会问。

2. Day 3-4：补代价和窗口

有了现状数据，接下来把它折算成代价，并找出时间窗口。代价折算优先用财务口径（人力成本、赔付金额、返工工时），窗口优先找外部触发的硬节点（审计日期、合约到期日、客户续约谈判日）。

这两天最容易卡住的是”找不到窗口”。我的经验是：如果真的找不到硬窗口，就把窗口往内部找，比如”Q2 预算冻结前”、”现有工具合约到期前”、”团队扩编前”。任何有具体日期的节点，都比没有节点强。

3. Day 5：写约束和反证

这一天专门用来写两件事：四条约束（预算、人力、时间、合规），以及至少两个备选方案的排除理由。排除理由必须是硬约束，不要写”方案 A 体验不好”这种主观判断。

写完这两块，背景的骨架就完整了。此时建议找一位同事做 15 分钟的对练，让他扮演评审问你三个问题：为什么是现在、不做会怎样、为什么不是别的方案。答不上来的地方，就是还需要补的地方。

4. Day 6-7：压缩成 1-2 页，准备预演问题清单

把前面所有内容压缩到 1-2 页。压缩的原则是：正文只留结论和关键数字，过程数据全部移到附件。同时准备一份 10 问清单，把最可能被追问的问题和答案写下来。

第 7 天下班前，你应该有一份 1-2 页的背景、一份 10 问清单、一份可追溯的数据附件。做到这三样，上会的成功率会明显提升。剩下的优化，留到实施阶段去做。

• Day 1-2：导出数据，找到 5 个可追溯数字并记录口径。
• Day 3-4：折算代价，找到至少一个带具体日期的硬窗口。
• Day 5：写四条约束，列出备选方案及硬性排除理由。
• Day 6：做 15 分钟对练，找出答不上来的问题。
• Day 7：压缩到 1-2 页，准备 10 问清单与数据附件。

九、常见问题

1. 项目背景要写多长才合适？

我的经验值是：20 人以下 3-5 句话，20-100 人 300-500 字，100-1000 人 600-1000 字，1000 人以上 1000-1500 字。超出这个范围通常意味着你把方案内容或行业科普混进来了。背景宜短不宜长，因为评审的注意力是稀缺资源，前面写太多，后面的目标与方案反而没人细看。

2. 找不到精确数据怎么办？

用抽样，但要写清抽样口径。”抽样 120 个工单，其中 43 个与变更无留痕相关，抽样区间为 2024 年 3-8 月”是可信的；”大约 35% 的工单存在此问题”是不可信的。关键差别在于前者可以被复核，后者不能。如果连抽样都做不到，就直接写”本项采用访谈估算，将在立项后 2 周内补齐基线”，坦白比虚构安全得多。

3. 立项被驳回后应该先改哪一部分？

先看驳回的理由落在五层证据的哪一层。如果是”为什么要做”，问题在战略层和业务层；如果是”为什么现在”，问题在窗口层；如果是”为什么这么做”，问题在约束层和反证层。改错了层级，改十遍也没用。我的建议是驳回后不要立刻动笔，先把评审的原话逐条抄下来，对照五层结构定位问题所在。

4. 项目背景和可行性分析有什么区别？

背景回答”为什么做”，可行性分析回答”能不能做成”。两者经常被合并，但顺序不能颠倒。如果必要性不成立，可行性再强也没有意义。我在实操中的做法是：背景里只保留必要性的论证和约束条件的声明，把技术可行性、资源可行性、风险应对放到独立的可行性章节。

5. 多人协作写背景时怎么避免拼盘感？

指派一个人做唯一执笔人，其他人只提供数据和事实，不写句子。这是我在多个项目里验证过最有效的做法。拼盘感的根源是叙事逻辑不统一，而逻辑统一的前提是只有一个大脑在做组织。数据提供者可以用表格提交，执笔人负责把它翻译成背景语言。

6. 背景里要不要写竞品或同行在做什么？

可以写，但只能作为参照基准，不能作为理由。”同行已上线类似系统”不构成立项依据，因为没有回答”我们不做会怎样”。如果一定要写，建议放在附件，并且给出具体对比维度，比如同类企业在需求变更率上的行业参考区间是多少、我们的位置在哪里。这样它就从”别人都做”变成了”我们偏离基准”。

十、写在最后

关于项目背景，我有一个和别人不太一样的观点：它不是立项书的开头，而是立项动作的结尾。你先去找证据、算代价、定边界、排方案，最后才动笔把结论写成 1 页纸。顺序反过来，写出来的东西一定是行业科普加愿望清单。

另一个值得记住的判断是：背景的质量不体现在文笔，而体现在”评审问不出来的问题”。一篇好的背景，会让评审从”要不要做”直接跳到”怎么做、什么时候上线、风险在哪”。当讨论焦点发生这种迁移时，你的立项其实已经通过了大部分。

最后给一个可执行的下一步：现在打开你正在准备的那个立项，把背景部分单独复制出来，用五层证据结构逐条对照。缺战略层的补窗口，缺业务层的补代价，缺执行层的补卡点耗时，缺约束层的补四条边界，缺反证层的补两个备选方案的排除理由。改完之后找一位不了解这个项目的同事读一遍，如果他能准确说出”为什么现在要做这件事”，那就说明你的背景写到位了。