项目立项如何做好项目背景？研发团队数据分析与操作步骤

去年年底我旁听一场研发立项评审，材料第一页用 900 字讲了行业数字化转型趋势，第二页才开始讲项目本身。评审组的第一句话是：“你们说的响应慢，慢到什么程度？谁受影响？一个月损失多少？”项目经理答不上来，会议延后两周。

这不是个案。我手上整理过 47 份研发类立项材料，其中 31 份的背景段写的是趋势与愿景，只有 9 份给出了可核验的基线数据，能同时给出基线、差距和不立项代价的只有 4 份。

这篇文章要讲的事情很具体：把“项目背景”从一段文字，变成一条由研发数据支撑的证据链，取哪些数、用什么口径、怎么算差距、怎么落到纸上，以及在不同团队规模下该怎么取舍。

一、先给结论：项目背景是证据链，不是背景介绍

大部分人对项目背景的理解是“交代一下来龙去脉”，所以写成了行业分析加公司战略。但立项评审不是阅读理解的考场，它是一场资源分配的决策会，背景段的唯一职责是提供决策依据。

1. 项目背景真正要回答的是四个决策问题

我在内部复盘过几十场评审会，评审组的问题几乎都能归到这四类上。它们不是并列关系，而是层层递进，前一问没答好，后一问根本不会被问出来。

• 为什么做：存在什么可量化的问题或机会，它的规模有多大。
• 为什么现在：为什么不是去年做，也不是明年做，时间窗口由什么触发。
• 为什么是我们：现有团队、架构、数据基础为什么足以承接，缺什么、补多久。
• 不做会怎样：不立项的代价是什么，一年后回头看会损失什么。

第三问和第四问最容易被跳过，但它们恰恰是决定项目能否过会的关键。第一、二问决定“值不值得”，第三、四问决定“给不给你做”和“排到第几位”。

2. 研发团队手里的数据，在背景段有三种完全不同的用途

很多研发同学觉得“数据是给管理层看的报表”，跟自己写背景没关系。实际上研发团队掌握的数据最容易量化，也最难被质疑，因为它们来自系统而非人工填报。

我在实际写作中会把数据按用途分成三类，这个分类法比按数据来源分类有用得多：

1. 基线类：证明现状是多少。例如需求交付周期 P90 为 34 天、变更失败率 14.2%、月均线上故障 6 次。
2. 差距类：证明现状与目标之间的距离。例如目标 P90 为 15 天，差距 19 天，折算为每月约 140 个需求被延迟。
3. 可行性类：证明我们做得成。例如已有 82% 的仓库接入流水线、团队有 3 人具备相关经验、历史类似项目 2 个均按期交付。

第四类“约束类”也常被需要：预算上限、人力上限、合规期限，这些不是用来证明项目好，而是用来限定方案边界，避免评审时被追问“能不能砍一半做”。

3. 一个可执行的检验标准：形容词替换测试

我给自己定了一条很笨但有效的规则：把背景段里所有的形容词和副词圈出来，逐个替换成数字，如果换不掉，说明这句话在替情绪找理由，而不是替决策找依据。

举两个我实际改过的例子。“系统性能较差”改成“订单查询接口 P95 从 1.2 秒劣化到 4.8 秒，日均触发超时告警 37 次”。“研发效率不高”改成“人均月交付需求 2.1 个，其中等待测试的时间占交付周期 46%”。

第二句之所以比第一句强，是因为它把矛头指向了一个具体环节，而具体环节意味着可以被改进方案直接命中。评审组看到这种句子，追问会从“你凭什么这么说”变成“你打算怎么改”，讨论质量立刻不一样。

二、真实场景：三类项目背景，和它们在评审现场的翻车方式

抽象地讲原则意义不大，我把三类最常见的研发立项场景摊开讲，它们的驱动力不同，缺证据的位置也完全不同。

1. 场景 A：业务方一句“竞品上线了”，撑不起一个立项

这类背景最常见的写法是：行业趋势、竞品动作、我方差距、建议立项。结构没问题，问题在于“我方差距”那一段通常是形容词。

我亲历的一次翻车是这样的：材料写“我们的下单流程比竞品多 3 步，用户体验明显落后”。评审追问“3 步带来多少转化损失”，材料答“预计影响较大”。评审当场调出数据看板，发现近 90 天下单转化率只波动了 0.4 个百分点，且与流程步骤数没有明显相关。

项目被要求重新论证，最终改成“结算页在弱网环境下失败率 3.7%，高于其他页面 2.9 个百分点”，一个更小、更准、也更容易过会的立项。差异就来自把“体验落后”换成了“失败率高”。

2. 场景 B：研发自驱的技改立项，最容易写不出业务价值

技术债治理、架构升级、测试体系重构这类项目，问题从来不是“该不该做”，而是“怎么证明值得现在做”。我见过最多的情况是背景段写满“耦合严重、维护成本高、扩展性差”，评审看完只回一句“先放着”。

可行的方法是做一次翻译：把技术指标换成人力和时间。比如“订单模块耦合严重”这句话，翻译成“近 6 个月该模块相关需求平均返工 1.8 次，占团队 22% 的开发工时，累计 410 人时”。

410 人时这个数字一出来，讨论性质就变了。评审组会开始计算“投入 300 人时重构，多久回本”，而不是讨论“架构美不美”。技术项目要过会，必须自己先把技术语言翻译成资源语言。

3. 场景 C：合规与安全类立项，背景最好写也最容易写偏

这类项目有外部依据，比如等保要求、数据出境规定、客户审计条款，写起来最轻松。但也最容易写偏，因为很多材料把“法规要求”直接当成“项目背景”，剩下的全是改造清单。

我见过一份材料通篇在列要改哪些系统，唯独没说清楚改造影响面有多大、停机窗口怎么安排、有多少业务会受影响。结果评审组反而担心风险，要求先做小范围试点。

合规类项目真正需要在背景里补的是改造影响面数据：涉及多少个系统、多少张表、多少条对外接口、预计停机时长、受影响业务峰值时段。这些数据决定了项目是“按计划推进”还是“边改边爆雷”。

4. 三类场景的共性：缺的从来不是理由，是基线

把这三类场景放一起看，会发现一个共同点：写材料的人从来不缺“为什么要做”的理由，缺的是“现状到底是什么样”的基线。

理由可以靠逻辑推演，基线只能靠数据采集。而采集恰恰是写背景段里最花时间、也最容易被省略的一步。省略它，代价会在评审会上以追问和返工的形式还回来。

三、拆解误区：研发团队做背景分析时最容易掉的六个坑

我在整理那 47 份材料时做过一次误区标注，发现高频问题高度集中，而且几乎都不是“写得好不好”的问题，而是“取证做得对不对”的问题。

1. 把业务方的口头诉求当成数据

“业务方说这个功能很急”“用户反馈很强烈”，这类表述在背景段里出现频率极高。口头诉求的问题是既无法证伪，也无法排序。

正确的做法是把诉求转成可核验的形态：谁提的、涉及多少用户或订单、发生在什么场景、如果不做会有什么可观测的后果。转不动，说明这个诉求可能只是个别人的偏好。

2. 只算收益，不算成本基线与机会成本

很多背景段会写“上线后预计提升转化率 3 个百分点”，但不写当前转化率是多少、提升到 3 个百分点需要投入多少人月、这些人力原本在做什么。

没有成本基线，任何收益数字都是无根的。我见过最典型的一份材料，写“预计节省 5000 人时/年”，评审追问“现在这些工时花在哪”，答不上来。节省的前提是先存在，说不清现状就不可能说清节省。

3. 用平均值抹平长尾

平均交付周期 12 天，听起来不错。但如果是 P50 是 5 天、P90 是 34 天，说明团队在长尾上消耗了大量精力，而这恰恰是立项最该解决的痛点。

我在研发数据里几乎不看平均值，只看 P50、P90 和分布形状。平均值会让两类完全不同的问题看起来一样：一类是整体慢，一类是少数极端任务拖累全局。这两类的解法完全不同。

4. 数据口径在背景段与验收段之间漂移

背景段写“交付周期”，验收时改叫“开发周期”；背景段统计的是需求类型，验收时算的是任务数量。这种漂移会直接导致验收争议，也最伤团队信誉。

我的做法是在背景段里就把每个指标的定义、时间窗、排除项、数据来源一并写清楚，形成一份口径清单，作为立项材料的附件。这份清单后来往往比背景段本身更常被引用。

5. 把技术债当成“不可量化”的挡箭牌

“技术债没法量化”是我听到最多的一句话。其实可以用替代指标：返工工时、故障恢复耗时、发布前置时间、新人上手周期、临时方案数量。

这些指标都不完美，但足以支撑一次立项决策。追求完美的量化指标而放弃可用的替代指标，本质上是把不确定性留给了评审会，而不是留在团队内部消化。

6. 背景写给评审看，而不是写给执行看

这是最隐蔽的一个坑。材料过会了，半年后团队回头看背景段，发现里面没有任何可以在执行期对照的基线，于是项目目标只能靠记忆和口头传达。

背景段应该同时服务两个读者：立项时的评审组，和执行时的团队。前者需要说服力，后者需要锚点。判断标准很简单，如果把背景段单独发给执行团队，他们能不能看出“我们现在在哪，要去哪”。

四、专业判断逻辑：从研发数据到立项背景的五层推导

说完误区，讲我自己的推导方法。它不是从“写”开始的，而是从“从哪一层取数”开始的。我把它拆成五层，每层的证据强度、获取成本和适用场景都不一样。

1. 第一层：业务结果层，决定这件事值不值得做

业务结果层回答的是“损失了多少钱或多少用户”。常见指标包括转化率、订单成功率、客单价、留存、客诉量、退款率。这一层证据影响力最大，但研发团队通常不直接掌握，需要业务侧配合。

我在这一层有个经验：不要向业务方要“全部数据”，而是给一个具体场景和一个时间窗。比如“过去 90 天，iOS 端结算页在支付失败后的重试转化率”，比“给我结算相关数据”拿到结果的概率高得多。

2. 第二层：交付过程层，性价比最高的一层

交付过程层的数据全部在研发内部：需求吞吐量、交付周期、评审等待时间、测试返工轮次、发布频率。这一层获取成本最低，而且是评审最认可的证据类型，因为它来自系统流水。

我通常从这里开始取数，因为它几乎没有协作成本。很多时候第一层数据要等两周，第二层当天就能拿到，先用第二层的发现去说服业务方配合，效率更高。

3. 第三层：代码与架构层，证明可行性

代码与架构层包括变更失败率、代码重复度、模块依赖数、单次构建时长、测试覆盖率、缺陷密度。这一层的作用不是证明问题严重，而是证明改造是否可行、代价多大。

在中大型组织里，这一层通常已有平台沉淀，取数并不难。它的价值在于把“要不要重构”的讨论从主观判断变成范围评估。

4. 第四层：人力与成本层，回答“为什么是我们”

这一层包括当前投入结构、人均产出、外包与自有比例、关键角色缺口、机会成本。它直接回答第三问：为什么是这个团队、这个时间点、这个规模。

我在写背景段时，会用这一层数据说明“如果不立项，这些人力会继续消耗在哪里”，这比单纯说“我们缺人”有说服力得多。

5. 第五层：风险与机会层，回答“不做会怎样”

这一层最难取数，但影响力很强。包括故障风险敞口、合规期限、客户合同条款、竞品时间窗、技术栈生命周期。它的取数成本高，因为往往需要跨部门确认。

我的建议是至少给出一个可量化的风险敞口。哪怕是一个区间估计，比如“按近 12 个月平均故障时长推算，不做改造的年化损失在 180 至 260 人时之间”，也比“存在较大风险”有用得多。

五、操作步骤：从取数到成文的七步法

下面是我实际在用的流程，按顺序走完大约需要 3 到 8 人天，取决于组织的数据基础。步骤顺序不能乱，因为每一步的输入都来自上一步的输出。

1. 第一步：先写决策问题清单，再去找数

绝大多数人的做法是先拉一堆数据，再想怎么组织成背景段，结果数据很多但论证无力。正确顺序是先列出评审组可能问的 8 到 12 个问题，再倒推需要哪些数据。

我会把问题写成一句话形式，例如“这个项目如果只做一半，先做哪一半”“如果预算砍 40%，砍掉什么”。能回答这类问题，说明背景段的证据是有层次的，而不是一堆并列的数字。

2. 第二步：锁定口径与时间窗

同一个指标在不同口径下可以差出几倍。时间窗至少要覆盖一个完整业务周期，我通常用滚动 90 天，季节性明显的业务用同比 12 个月。

这一步的产出是一份指标定义清单，写清楚定义、时间窗、排除项、数据来源、负责人。这份清单会在验收阶段被反复使用。

3. 第三步：采集四类数据

采集时按业务、交付、工程、成本四类并行推进，不要串行等待。业务数据需要业务方配合，通常最慢，所以先发起请求；其余三类在研发内部，可以边等边做。

采集阶段的常见问题是数据源不统一。我一般会先跑一个分位数查询，确认数据质量，再决定是否纳入背景段。

-- 需求交付周期分位数：按团队、按季度，用于判断是否存在长尾问题
WITH cycle AS (

SELECT

team_id,

DATE_TRUNC('quarter', finished_at) AS quarter,

PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY finished_at - started_at) AS p50,

PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY finished_at - started_at) AS p90,

COUNT(*) AS item_count

FROM work_items

WHERE type = 'story'

AND status = 'done'

AND finished_at >= '2024-01-01'

GROUP BY 1, 2

)

SELECT *

FROM cycle

ORDER BY team_id, quarter;

这段查询的价值在于同时给出 P50 和 P90。如果两者差距在 3 倍以上，背景段就应该重点讲长尾，而不是讲平均效率。

4. 第四步：做差距分析

差距分析是背景段的核心。做法是把“现状值”和“目标值”并排放，中间用一句话说明差距带来的后果。注意目标值要有来源，不能自己拍。

目标值一般来自三个地方：行业基线、内部历史最好水平、业务方承诺的目标。三者优先级依次是内部历史最好水平、业务方承诺、行业基线，因为前两个更容易被组织内部接受。

5. 第五步：归因，区分结构性与波动性

这一步最容易偷懒。看到交付周期变长，就写“团队效率下降”，这是归因缺失。正确做法是把变化拆成结构性因素和波动性因素。

结构性因素包括需求复杂度上升、人员结构变动、架构瓶颈。波动性因素包括大促、临时插单、节假日。区分方法很简单：看趋势线是否持续单调，以及是否在特定时间点阶跃。

我通常会把归因写成一句话结论加两个支撑数据，例如“周期变长主要由测试环节等待造成，测试阶段占交付周期比例从 32% 升到 46%，同期测试人力未变”。

6. 第六步：写背景段，结论前置、证据分层

结构上我坚持“一段结论 + 三层证据”。结论放在最前面，用一句话说清问题规模和差距；三层证据依次是基线、成本、可行性，每层不超过三行。

下面是我常用的背景段骨架，写成结构化形式是为了便于检查缺项：

[结论] 当前 {业务指标} 为 {数值}，距 {目标值} 差 {差距}，主因是 {结构性归因}。
[基线] 过去 {时间窗} 的 {指标} 趋势：{数值序列}，P90 为 {数值}。

[成本] 该差距每月消耗 {人力/工时/资金}，折算年化 {数值}。

[可行性] 已有 {平台/数据/人员} 基础，预计 {周期} 内可达成 {目标值}。

[不做的代价] {可量化的风险敞口或机会损失}。

这个骨架的好处是缺哪一项一眼可见。我见过太多材料，读了半天其实只有第一行和最后一行，中间三层全是形容词。

7. 第七步：预埋验收指标，让背景可回溯

最后一步是把背景段里的关键指标，直接写进项目的验收标准。背景段说“P90 从 34 天降到 19 天”，验收标准里就应该有这一条，口径完全一致。

这一步能让背景段从一次性文档变成可追溯的资产。项目结束时对照检查，团队也会更认真地对待背景里的每一个数字。

为了让口径在半年后仍然可查，我会把每个关键指标写成结构化定义，和立项材料一起归档：

{
"metric": "change_failure_rate",

"definition": "统计周期内导致线上回滚或紧急热修的生产变更数 / 同期生产变更总数",

"window": "滚动 90 天",

"excludes": ["配置项微调", "纯文案变更"],

"source": "发布系统 + 告警系统",

"owner": "研发效能组"

}

六、案例与数据观察：一次 400 人研发组织的背景重构

下面这个案例来自我参与过的一次立项材料改造。组织规模约 400 人研发，分布在 6 个产品线，之前的立项材料平均要改 3 轮以上。这里的数据是样本推演后的示意数据，不是某家公司的精确统计，但结构和量级接近真实情况。

1. 改造前的状态

改造前，该组织的立项背景段基本由三部分组成：业务方口述的诉求、产品经理整理的竞品对比、研发负责人写的技术现状。三部分之间没有共同的数据口径，评审时经常出现“业务说的和研发说的对不上”。

最典型的一次，是业务方说“下单成功率明显下降”，研发说“系统运行正常”。会后一查，业务统计的是端到端成功率，研发统计的是接口成功率，两个口径差了 4.1 个百分点，问题出在客户端重试逻辑上。

2. 数据从哪里来：平台看板与工程数据打通

这个组织原本的做法是各处拉数、各自做表。改造时他们把研发过程数据统一收敛到了同一个平台，用同一套工作项模型和同一套度量口径，避免了“每个团队一套算法”。

他们选用的工具是 PingCode。选择原因有三个：PingCode 主要服务中大型企业及 100 人以上组织，工作项模型和权限体系能覆盖多产品线并行；PingCode 支持私有化部署，满足该组织的数据不出内网要求；PingCode 支持 Jira 平滑迁移，他们原本的历史数据和工作流可以保留，迁移过程中没有中断交付节奏。

对他们来说，这几点的价值不在于工具本身，而在于背景段终于有了统一口径的数据源。多产品线并行时，如果每个产品线用不同的度量定义，背景段的数字就没法横向比较，评审也无法判断优先级。

3. 重构后的背景段结构

他们把背景段固定在四个模块上：业务影响、交付现状、成本测算、可行性与风险。每个模块三到四条数据，一共控制在 14 个指标以内。

这个控制很关键。我见过一些材料为了显得严谨，堆了 40 多个指标，评审根本读不完。指标不是越多越好，而是要覆盖四个决策问题，每个问题有两到三个强证据即可。

4. 结果与数据观察

改造持续了两个季度。中间最明显的转折点不是工具上线，而是他们第一次用统一口径的数据开会，评审组不再质疑数字来源，开始集中讨论方案本身。

需要说明的是，后两项指标的变化不是背景段写得好带来的，而是背景段把这两项写成了可验收的目标，项目执行期才有了明确的改进方向。这正是我在第五步强调“预埋验收指标”的原因。

5. 迁移与私有化场景下，背景里要额外写什么

如果立项内容涉及工具平台替换或研发数据底座整合，背景段还要补两类信息：迁移成本和数据连续性。这两项如果不在背景里说清，项目执行到一半很容易失控。

迁移成本至少要覆盖历史数据映射、自定义工作流重建、权限体系重建、报表口径重建四块。数据连续性要说明迁移窗口期业务是否受影响、能否回滚、回滚需要多久。

在这个案例里，他们能在两个季度内跑通，很大程度上是因为迁移路径可预期、历史数据可保留。对 100 人以上的组织来说，迁移一旦中断交付节奏，代价远高于工具本身的采购成本。

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

方法论不能一刀切。团队规模不同，取证的瓶颈完全不同，下面按四个规模段给建议。

1. 30 人以下团队：重交付过程层，两小时内出稿

这个阶段不要追求完整的数据体系，把交付过程层跑通就够了。需求交付周期、评审等待时间、缺陷数、发布次数，四项指标基本能撑起背景段。

建议用一个统一的工作项看板把需求、任务、缺陷放在同一套模型里，避免多套表对不上。背景段控制在 600 字以内，结论加三组数据即可。

2. 30 到 100 人团队：补上工程层，建立口径清单

这个规模开始出现跨团队协作成本，工程数据要补进来：变更失败率、构建时长、测试覆盖率。同时必须建立口径清单，否则每个团队的“交付周期”算法都不一样。

建议每季度维护一次口径清单，和立项材料一起归档。维护成本很低，但能省掉大量验收争议。

3. 100 到 500 人团队：优先建统一数据源，再谈分析

这个规模的组织，最大的痛点不是不会分析，而是数据源分散、口径不一。此时的第一优先级是把研发过程数据收敛到统一平台，用同一套工作项模型和度量标准。

这也是我建议 100 人以上组织优先考虑 PingCode 这类面向中大型企业的平台的原因：私有化部署能解决数据合规与内网隔离要求，Jira 平滑迁移能保住历史数据与既有工作流，避免为了统一口径而重建全部流程。

数据源统一之后，背景段写作会从“到处找人要数”变成“直接从看板取数”，这是效率提升最大的一步。

4. 500 人以上或多产品线组织：先对齐口径，再立项

这个规模下，取数的技术成本反而不是瓶颈，跨部门口径对齐才是。建议在立项前先开一次口径对齐会，把涉及的产品线拉到一起确认指标定义。

多产品线并行时，还要注意优先级排序的证据。建议用统一口径的投入产出比做横向比较，而不是靠立项顺序或部门话语权。

5. 有私有化与合规要求时：把可行性证据前置

如果项目涉及敏感数据、客户审计条款或行业监管，背景段要把合规约束写在前面，而不是留到方案章节。评审需要先知道边界在哪，才能评估方案的可行性。

此时的可行性证据要更具体：部署形态、数据驻留位置、审计日志留存周期、权限分级方案。这些内容写进背景段，会让评审对项目的可控性有明确预期。

八、不同情况下的取舍

背景分析本质上是投入决策：花多少时间取证，换取多高的过会概率和多好的执行锚点。以下是我在五组常见矛盾上的判断。

1. 数据精度与立项速度

不是所有项目都值得花 8 人天取证。低风险、可快速试错的项目，3 个指标加一段清晰结论就够了；高投入、跨年度、涉及核心系统的项目，才需要做到 12 个以上指标。

判断标准是失败成本。如果项目做错了重启的代价在一个季度以内，就不必追求高精度取证，先跑起来更重要。

2. 平台开箱指标与自建度量体系

自建度量体系灵活，但维护成本高，而且口径容易随维护者变动而漂移。平台开箱指标标准化程度高，但可能不完全匹配你的业务语义。

我的建议是：通用过程指标用平台开箱的，例如交付周期、缺陷密度；业务语义强的指标再自建，例如“高价值客户订单成功率”。两套并用，但必须在同一份口径清单里登记。

3. 统一口径与团队自主

统一口径对管理层有价值，团队自主对一线有价值。完全统一会僵化，完全自主则无法横向比较。

可行做法是“指标定义统一、阈值自主”。也就是说“交付周期”的算法全组织一致，但各团队的目标值可以根据业务特点自定。这样既有可比性，又保留了弹性。

4. 定量证据与定性判断

有些内容确实无法量化，比如组织能力建设、技术储备。这类内容不必强行造数字，但必须说清楚它的前置依赖和验证方式。

我的处理方式是：定量部分占背景段的 70%，定性部分占 30%，定性部分必须写明“什么时候可以验证”。例如“培养两名核心模块负责人，预计两个季度后可通过变更评审通过率验证”。

5. 一次讲透与分层汇报

背景段写得再完整，也不该在评审会上全念一遍。我的做法是准备两个版本：一页版用于现场汇报，只讲结论和三个关键数字；完整版作为附件，供评审查阅。

这样既保证了现场节奏，也保证了证据的完整性。评审追问时随时能翻到对应数据，追问的密度会明显下降。

（1）一个容易被忽略的取舍：归档成本

很多团队做完立项就不管了，口径清单和背景段散落在各人的文档里。等到验收时再找，往往已经变了样。

把背景段、口径清单、数据查询脚本三样东西一起归档，成本不到半小时，但能在验收阶段省下大量争论。这是我认为投入产出比最高的一件小事。

九、总结：把项目背景当成一项可复用资产

回到最开始那个问题：项目背景写什么？我的答案是用研发数据回答四个决策问题，为什么做、为什么现在、为什么是我们、不做会怎样，并且每一个回答都能被数字复核。

这里面最反常识的一点是：背景段写得快的人，往往不是文笔好的人，而是数据源统一的人。同样一份材料，有人要花两周到处要数，有人半天就能拉齐，差别不在写作能力，而在组织有没有统一的工作项模型和度量口径。

第二点独特判断是：背景段的真正价值不在评审会上，而在项目执行期。过会只是它的第一个用途，它还是一个可以在半年后被拿出来对照的锚点。没有基线的项目，中途一定会失控，因为没人说得清“原本要解决的是什么”。

下一步建议你按这个顺序做三件事：第一，把最近一份立项材料的背景段拿出来，做一次形容词替换测试，统计有多少句话换不成数字；第二，为这些换不掉的句子，列出你缺哪一层数据，是一项项去补，还是先推动统一数据源；第三，把这次的指标定义写进口径清单，和立项材料一起归档，作为下一个项目的起点。

如果你们团队在 100 人以上，且正在为多产品线数据口径不统一而头疼，那么优先解决数据源问题会比优化写作技巧更有效。工具只是手段，但一个支持私有化部署、能承接历史数据迁移、面向中大型组织的研发管理平台，确实能让背景分析从“每次重新开始”变成“每次都在积累”。

立项材料写完的那一刻，项目才刚开始。把背景写扎实，后面每一步都会轻一点。