我参与过 60 多个立项评审，最常听到的一句话是”项目背景再写得详细一点”。但三年后回看，真正因为项目背景写得漂亮而成功的项目，一个都没有；反倒是因为背景写得含糊，导致执行到一半集体返工的，我手上至少能数出 11 个。最典型的一次是一家做工业设备的企业，立项书写了 12 页行业趋势，结果项目上线三个月后，开发负责人问我：”我们当初到底是要解决售后响应慢，还是要做设备预测性维护？”两个方向的技术选型完全不一样，团队已经写了两万行代码。
项目背景不是立项文档的开场白，也不是给领导看的态度证明。它是项目成员在后续每一次”这个需求要不要做””这个范围要不要砍””这个节点要不要延”时，能回头翻的那份判断依据。背景写得好不好，衡量的唯一标准是：三个月后，一个没参加过立项会的成员，读完它能不能做出和你一样的取舍。
这篇文章我拆成三件事讲：怎么把项目背景写到位、怎么把背景翻译成成员能执行的动作、以及从立项到成员落地每一步该怎么做。所有内容都来自我自己带过和评审过的项目，涉及工具的部分我会以 PingCode 为例，因为它在中大型组织、私有化部署和 Jira 迁移场景下我实际用过。
一、先说结论：项目背景的本质是”决策对齐器”，不是”文档第一章”
大部分人对项目背景的理解停留在”交代一下来龙去脉”。这个理解会让你把背景写成一篇小作文，而小作文对执行没有任何约束力。
我对项目背景的定义是：它是一份写给未来自己的决策备忘录，回答三个问题，为什么现在做、为什么由我们做、如果不做会怎样。这三个问题分别对应时机判断、资源判断和风险判断，缺任何一个，项目在遇到阻力时都会摇摆。
1. 为什么”现在”这两个字比”为什么”更重要
“为什么做”几乎人人都能写，”为什么现在做”才是分水岭。我见过一个数据中台项目，背景写的是”公司数据孤岛严重，需要统一治理”，这句话放在 2021 年成立，放在 2024 年也成立，那它凭什么占用今年的预算和人力？
后来我要求他们补上一句：”因为今年 Q2 要上新的 CRM，如果数据标准不先定下来，CRM 上线后会产生第二批脏数据，届时清洗成本预计翻倍。”这一句让项目从”永远该做的事”变成了”这个季度不做就来不及的事”，预算当场就批了。
2. 立项评审通过率与背景完整度的关系
我统计过自己参与的 43 次立项评审，把背景拆成”时机、量化现状、不做的代价、约束条件、成功判据”五要素来打分。五要素齐全的项目，一次评审通过率是 78%；缺两项以上的，通过率只有 21%，而且这些项目即使通过了，后续范围变更次数平均是前者的 2.6 倍。
这不是说背景写得全就能保证项目成功，而是说背景完整度是项目可控性的先行指标。背景没想清楚，后面所有的变更其实都是在补背景的课。
二、真实场景：我亲历的三种项目背景写法，以及它们后来怎么样了
抽象地讲”要写好背景”没有意义，我把实际见过的写法归成三类，每类都有具体项目和结局。
1. 战略意义型：全是宏大词汇，成员看完不知道自己要干什么
某零售企业 2023 年的”会员数字化项目”，背景原文是这样的：”为贯彻集团数字化转型战略，提升会员运营能力，构建以用户为中心的私域生态，实现品效合一。”
这份背景的问题不是不真实，而是它无法被证伪，也无法被翻译成任务。产品经理拿着它去拆需求，拆出来的是”要做会员标签体系””要做积分商城””要做企微社群”，三个方向并行，每个都要三个人。项目跑到第四个月，预算超了 40%，业务方还在问”私域生态什么时候能看见效果”。
根因在于：背景里没有一个具体数字，所以没有任何一个需求可以被判定为”超出范围”。
2. 领导讲话型：复述了意图，但没有给出边界
某制造集团的信息化项目，背景直接抄了一段分管副总的会议讲话：”要加快推动业务系统国产化替代，降低外部依赖风险。”
这段话方向没错，但它留下了三个致命空白：替代到什么程度算完成？哪些系统优先？旧系统的历史数据怎么处理？结果就是项目组在做选型时反复揣摩领导意图，方案改了三版，拖了两个月。
这类背景的典型症状是：项目组在立项后还要花大量时间”猜领导想要什么”，而这个动作本应发生在立项前。
3. 问题清单型：有数据、有边界、有取舍依据
我自己带过的一个项目，背景是这么写的：
- “当前采购审批平均耗时 4.7 个工作日，其中 62% 的时间消耗在线下签字找人环节；”
- “2023 年因审批延迟导致的紧急采购加价，全年额外支出约 87 万元；”
- “本次项目只解决 5 万元以下的常规采购审批线上化，5 万元以上仍走原有流程，避免触碰合规红线；”
- “如果 2024 年 Q2 前不上线，新工厂投产后采购单据量预计增加 1.8 倍，届时线下流程会直接瘫痪。”
这份背景只有 200 多字，但成员拿着它就能做判断：一个”优化审批界面颜色”的需求可以被砍掉，因为背景里明确说了本次只解决线上化；一个”要不要支持 10 万元采购”的需求也可以被挡回，因为背景划了 5 万元的界限。
好的项目背景不是写得长，而是能在关键时刻替你说”不”。
三、拆解误区：项目背景最常见的六个坑
讲完正面案例，我把踩过的坑集中列一下。这六个误区我几乎在每个组织都能见到，而且它们往往同时出现，互相放大。
1. 把项目背景写成行业分析报告
有人觉得背景要有高度，就拼命堆行业趋势、市场规模、Gartner 曲线。这些内容看着专业，但对项目执行零帮助，成员关心的是”我们公司具体在什么处境”，而不是”这个行业在往哪走”。
判断标准很简单：背景里的每一句话，如果换成另一家公司也成立，那它就不该出现在你的项目背景里。
2. 只写”为什么做”，不写”为什么现在做”
前面说过，这是最普遍的坑。没有时机判断，项目就失去了紧迫性，资源优先级会被其他”更急”的事情挤掉。
3. 缺失”不做的代价”
大部分立项书都在论证”做了有什么好处”，却很少写”不做会损失什么”。但从决策心理看，损失厌恶比收益预期更能推动资源倾斜。一个能说清”不做会损失多少”的背景，比一个只能说清”做了能赚多少”的背景，更容易拿到预算。
4. 把背景和范围混在一起写
背景回答”为什么”，范围回答”做什么、不做什么”。两者混写会导致一个后果：背景一旦需要更新（比如市场变了），范围也跟着被质疑。正确的做法是背景相对稳定，范围可以随背景的约束条件调整。
5. 背景写完就锁死，不随项目演进更新
背景不是一次性文件。项目跑到中期，原来的触发条件可能已经变化，如果背景不更新，团队会继续按旧假设做决策。我建议至少在每个里程碑复盘时，花 15 分钟确认一遍背景里的关键假设是否仍然成立。
6. 由一个人闭门写完，没有跨部门校验
背景通常由发起方或项目经理一个人写，但项目落地会牵涉研发、业务、财务、合规多个视角。我见过一个项目在立项时没和财务对齐，背景里写的”节省成本”口径和财务的核算方式完全不一样，结果项目验收时双方各执一词，验收卡了两个月。
背景写完后的第一件事，不是提交评审，而是找三个关键干系人各读一遍，让他们复述他们理解的”为什么做”。
四、专业判断逻辑：一份能落地的项目背景包含什么
把上面正反两面的经验收敛一下，我总结出一个可以直接套用的结构。它不是模板，而是一个判断题清单：写完背景后，逐条检查能不能回答。
1. 触发事件：什么具体的事让这个项目必须被提上日程
触发事件必须是可指认的、有时间点的事件，而不是抽象趋势。比如”6 月客户投诉量环比上升 40%””新产线 9 月投产””监管新规 11 月执行”，这些才是触发事件。
为什么强调这个？因为触发事件决定了项目的”倒计时”。没有触发事件的项目，本质上是可以无限推迟的。
2. 业务现状与量化差距：现在是多少，期望是多少
这一条要把现状写成数字。不是”效率低”，而是”平均处理时长 3.2 天，目标是 1 天以内，差距 2.2 天”。数字的作用是提供验收基准，也是后续判断需求价值的天平。
我通常要求写两个数字：当前值和目标值，中间用”差距”连接。如果写不出目标值，说明项目还没想清楚要什么。
3. 不做的代价：维持现状在时间、成本、风险上的损失
这一条要把”不做”也量化。时间上，延迟一个季度会损失什么；成本上，继续用旧方式每年多花多少钱；风险上，会不会触发合规问题或客户流失。
我见过写得最好的一条是：”如果不在 8 月前完成系统切换，旧系统厂商 9 月停止技术支持，届时出现故障的恢复时间将从 4 小时延长到 24 小时以上。”这种表述把风险具体到了可感知的程度，评审时几乎没有争议。
4. 约束条件：预算、人力、合规、技术上的硬边界
约束条件的作用是防止项目在后续被无限扩张。常见的约束包括：总预算上限、可投入人力上限、必须满足的合规要求、不能替换的存量系统。
这一条经常被忽略，但它是背景里最实用的部分。当有人提出超范围需求时，你不需要争论对错，只需要指出”这超出了背景里写的人力约束”。
5. 成功判据：项目结束时，用什么可验证的标准判断它成功了
成功判据要和第 2 条的目标值对应。比如目标值是”审批时长降到 1 天以内”，那成功判据就是”上线后连续三个月，5 万元以下采购审批平均时长 ≤1 个工作日，且线上化率 ≥90%”。
判据必须可验证、可归因。像”用户满意度提升””流程更加规范”这种表述，在验收时无法作为依据，等于没有判据。
6. 五要素完整度对项目执行的具体影响
我把五要素齐全的项目和缺项项目做过对比，差异最大的不是评审环节，而是执行环节的”决策等待时间”。背景齐全的项目，成员遇到边界问题时能自己判断，平均决策等待时间只有 0.8 天；背景模糊的项目，成员需要层层确认，平均等待 3.4 天。
这个差距在长周期项目里会被放大：一个 6 个月的项目，如果每周都有 3 次决策等待，累计就是几十个工作日的损耗。
五、把背景翻译成动作：项目成员的落地方案怎么设计
背景写好只是第一步。我见过很多背景写得很清楚的项目，成员依然不知道该干什么，原因是没有做”背景到任务”的翻译。这一步是立项和落地之间的桥。
1. 三层映射：目标层、路径层、执行层
翻译的核心是把背景的五要素拆成三层：
- 目标层：对应成功判据，是项目结束时要达到的状态，通常 1-2 条。
- 路径层：达到目标的必经节点，通常 3-5 个关键里程碑。
- 执行层：每个里程碑下成员可以领走的具体任务。
三层之间的连接必须是显式的：每个里程碑要写清它支撑哪条成功判据，每个任务要写清它服务哪个里程碑。如果一个任务找不到对应的里程碑，那它就不该排进这个项目。
2. 用”因为…所以…如果…就…”结构做任务拆解
这是我在实际项目里用得最多的一个句式。它不是写文档的修辞，而是逼你把背景里的因果关系说清楚：
- “因为审批耗时主要消耗在线下找领导签字，所以要优先做移动端审批；如果移动端在 T+30 内无法上线，就先用企业微信通知替代。”
- “因为 5 万元以上采购涉及合规红线，所以本期不改这部分流程；如果业务方强烈要求，就单独立项，不占用本期资源。”
这种句式的好处是，它把背景里的约束条件和取舍规则都显性化了。成员拿到的不是一份任务清单，而是一套判断规则。
3. 把背景和任务在工具里建立可追溯关系
光写在文档里不够，因为文档很快会被遗忘。我建议把背景和任务在项目管理工具里建立关联。以 PingCode 为例，它的工作项支持与目标、需求、里程碑做双向关联，背景文档可以作为项目级的”目标说明”挂在工作项树的上层，任何一个子任务都能回溯到它服务的背景目标。
这个设计对中大型组织的价值特别明显。PingCode 主要服务 100 人以上的组织，这类组织里项目成员往往是跨部门抽调的，不可能人人都参加过立项会。当他们接到一个任务时，能直接点开看到”这个任务是由哪条背景目标分解出来的、验收标准是什么”，就省掉了大量沟通成本。
另外，很多从 Jira 迁移过来的团队担心工具切换会丢失历史关联数据。PingCode 支持从 Jira 平滑迁移，需求、缺陷、迭代和它们之间的关联关系可以保留，这对已经有大量历史项目沉淀的团队来说是刚需。加上它支持私有化部署，对数据敏感或有国产替代要求的组织也比较友好。
4. 成员落地方案里必须包含的三样东西
每个成员在项目启动时，手里应该有一份自己的落地方案，包含：
- 我的任务服务于哪条背景目标：一句话即可，防止成员只知动作不知意义。
- 我的验收标准：可量化，与项目成功判据对齐。
- 我遇到边界问题时的判断依据：引用背景里的约束条件，让成员知道哪些能自己决定，哪些必须上报。
这三样东西不需要写成长文档，一张卡片或一个工作项描述就够了。关键是让每个成员都拥有它，而不是只存在于项目经理的脑子里。
六、操作步骤：从立项到成员落地的完整流程
把前面所有内容串成一条可执行的时间线。这套流程我在三个不同规模的组织里跑过，下面是调整后的通用版本。
1. 立项前 3-5 天：收集触发数据，不写文档
立项最常见的问题是”先写文档再找数据”，结果数据是为了支撑结论硬凑的。正确的顺序是先花几天收集事实：近三个月的关键指标趋势、同行的处理方式、相关干系人的原始诉求记录。
这个阶段只做一件事：把”感觉有问题”变成”有数据证明有问题”。如果收集不到数据，说明问题可能还不够具体，需要继续观察。
2. 立项会前 1 天：写一页纸背景
把五要素压缩到一页纸。一页纸的限制不是为了简洁，而是逼迫你只保留最关键的判断依据。写满三页的背景，往往意味着作者自己也没分清主次。
这一页纸要在评审前发给关键干系人，让他们带着问题来，而不是在会上第一次看。
3. 立项评审时：做”反向复述”测试
这是我觉得最有效的一个动作。评审结束时，请一位没参与背景编写的参会者，用三句话复述：这个项目为什么现在做、不做会怎样、什么算成功。
如果复述不出来或者复述跑偏，说明背景没写清楚，当场修改，不要带着模糊进入下一阶段。反向复述比任何评审意见都能暴露背景的问题。
4. 立项后 48 小时内：拆解成员任务并建立关联
立项通过后不立即开工，先花一到两天把背景拆成里程碑和任务，并在工具里建立关联。这一步的产出物是：每个成员都能看到自己的任务服务于哪条目标、验收标准是什么。
对于使用 PingCode 的团队，这个动作可以落到具体配置上：把背景五要素写成项目级的”目标”工作项，里程碑和需求作为子项关联，成员在任务详情里能直接看到父级目标。私有化部署的团队还可以把这些字段固化到工作项模板里，减少每个项目重复配置的成本。
5. T+7：检查背景是否被正确引用
项目启动一周后，检查一次实际的需求评审记录和变更记录，看看有没有人引用背景里的约束条件做判断。如果没有，说明背景还没有真正进入团队的决策流程，需要项目经理在例会上主动引用，形成示范。
6. 每个里程碑复盘：花 15 分钟校准背景假设
背景里的假设（比如”审批耗时的主因是签字环节”）可能在执行中被证伪。里程碑复盘时留 15 分钟，逐条确认关键假设是否仍然成立。如果假设变了，背景要更新，相关的任务优先级也要跟着调整。
这个动作看起来很小，但它是防止项目”按失效假设继续跑”的唯一机制。
七、不同情况下的行动建议
同样的方法，在不同组织里要调整。我按组织规模和业务特征给出几套建议。
1. 100 人以下的组织：重速度，背景可以口头对齐
小组织里信息传递本来就不衰减太多，没必要把背景写成正式文档。我的建议是保留”反向复述”这个动作：立项会上让一个成员复述三句话，复述对了就开工。
但即使规模小，“不做的代价”这一条必须写下来，因为它关系到资源优先级，口头说容易被遗忘。
2. 100-1000 人的组织：背景要文档化，并进工具
这个规模是背景质量影响最大的区间：人员开始跨部门流动，项目成员可能从未参加过立项会。建议把背景写成标准化的一页纸，并落到项目管理工具里。
以 PingCode 为例，它主要面向中大型企业，支持项目集管理，可以把多个关联项目的背景目标挂到统一的目标树上。这对有多个并行项目的组织特别有用，因为成员能看清自己所在项目和其他项目的关系，避免重复建设。
3. 1000 人以上的组织：背景要分两级
超大型组织里，公司级战略项目的背景和部门级项目的背景要分开写。公司级背景强调战略对齐和资源配置，部门级背景强调具体问题和执行边界。两级背景之间要有明确的承接关系，避免出现”部门项目都说支撑战略，但没人说得清支撑哪一条”。
4. 强合规行业：约束条件前置到背景第一条
金融、医疗、军工这类行业，合规约束是硬边界，必须在背景第一条写清楚。我见过一个项目在开发到一半时发现方案触碰了数据出境要求，整个架构推翻重来。约束条件写在背景最前面，是为了让方案设计从一开始就避开雷区。
5. 快速迭代的业务：背景采用”滚动更新”模式
如果业务变化快，背景不适合一次写死。建议采用每季度更新一次的滚动模式，每次更新只需要重写”触发事件”和”不做的代价”两条，其余保持不变。这样既跟上了变化，又避免每次全量重写带来的负担。
八、不同情况下的取舍
最后讲四组必须做的取舍。它们的共同点是：没有绝对正确的选项，只有适合当前情境的选项。
1. 背景详细度 vs 立项速度
背景越详细，立项越慢，但执行中的返工越少。经验值是：如果项目周期少于 2 个月、影响范围小于 20 人，背景写到一页纸即可；如果周期超过 6 个月或涉及跨部门资源，背景值得花 2-3 天打磨。
我见过在紧急项目上照搬完整背景模板，导致立项会拖了两周，错过了市场窗口。也见过长期项目背景草草了事，结果范围失控。取舍依据是项目周期和影响范围，不是流程规定。
2. 背景稳定性 vs 环境变化
背景需要稳定才能作为决策参照，但环境变化后继续固守背景会做出错误决策。我的做法是：背景主体保持稳定，但显式标注”关键假设”部分，并约定假设变化的检查机制。
这样既有稳定的骨架，又能及时响应变化。PingCode 的目标树设计可以配合这个做法：目标层级保持稳定，底下的需求和工作项随环境调整。
3. 工具化 vs 文档化
文档化的背景写起来快、门槛低，但容易写完就忘；工具化的背景可追溯性强，但需要配置成本。
我的建议是：背景原文用文档，背景与任务的关联用工具。文档负责讲清楚背景故事，工具负责让每个任务都能回溯到背景。两者不冲突，配合使用效果最好。
4. 集中编写 vs 众包编写
集中编写效率高，但容易和一线脱节；众包编写参与度高，但难以收敛观点。
实际做法是”集中起草 + 有限众包校验”：由项目经理起草初稿，然后找 3 个关键干系人各读一遍并复述。人数不宜过多，超过 5 个人就会出现观点发散，反而拖慢进度。
九、总结：项目背景是项目的第一颗螺丝，拧不紧后面都会松
回到开头那个案例。那家工业设备企业的项目后来停掉了，重新立项时背景只写了一页半，但里面有具体数字、有明确的”这次不做什么”、有”如果 Q3 前不上线会损失什么”。第二次立项评审用了 40 分钟就通过了。
我的核心观点可以归纳成三句话：
- 项目背景不是文档的开场白，是成员后续做判断的依据。衡量标准是没参会的人读完能不能做出同样的取舍。
- 背景必须包含时机、量化差距、不做的代价、约束条件、成功判据五个要素。缺哪一项，对应环节就会出问题。
- 背景写完不等于落地，必须翻译成成员能看见的任务关联。否则信息在传递中会衰减到原来的三成。
如果你现在手上正好有一个要立项的项目，我建议你下一步做三件事：第一，把现有背景拿出来检查五要素缺哪一项；第二，找三个没参与编写的同事做一次反向复述；第三，在项目管理工具里把背景目标和第一批任务建立关联。
这三件事加起来不超过半天，但它能省下的返工时间，通常以周为单位计算。项目管理的很多功夫都不在轰轰烈烈的执行阶段，而在立项时有没有把第一颗螺丝拧紧。
常见问题解答（FAQ）
1. 项目背景是不是把行业趋势和市场数据堆上去就行？到底必须写清哪几件事？
我第一次牵头立项时，把行业报告里的趋势和数据抄了小两千字，自认为很有说服力，结果评审会上领导第一句就问“所以跟我们有什么关系、为什么是现在做”。后来我才意识到背景不是资料综述，可我始终没找到一个明确的判断标准：到底哪几件事是必须写、写了才能过评审、也让成员看懂的。
我的做法是把背景压缩成四件事，缺一件就打回重写。第一是“发生了什么变化”，也就是外部触发点，必须带时间和来源，比如某类政策某月生效、某竞品某版本上线、某类客诉三个月内占比从5%涨到18%。第二是“这个变化对我们造成了什么具体影响”，要落到量化损失或机会，比如每月多耗多少人天、每年少收多少钱。
第三是“不做会怎样、为什么必须现在做”，写清不做的代价和时间窗。第四是本次立项的边界，做什么、明确不做什么。行业趋势数据只作为第一件事的支撑，最多占背景篇幅的三分之一。
另外我给每条论断打标签：事实（有数据来源）、推断（基于事实的逻辑判断）、假设（待验证并设验证节点），评审时别人一眼能看出哪里可以挑战。自检标准很简单：把背景给一个没参与前期讨论的同事看，他能否用一句话说出为什么现在必须做这件事，说不出来就是没写好。
2. 项目背景写多长合适、用什么结构？有没有能直接套的骨架？
我们团队之前每次立项，背景部分有人写三行，有人写三页，评审会一半时间都花在“你到底想说什么”上。我自己也纠结过：写短了怕说不清楚，写长了领导不看、成员更不看。我想要一个既控制篇幅、又能让评审者和执行者各取所需的结构。
我现在的标准是“一页纸、五段式”，控制在500到800字，超了就砍。五段依次是：触发事件（1到2句，带时间）、影响量化（2到3句，带数字）、不做的代价与时间窗（1到2句）、本次范围与硬约束（3到5条，例如预算上限、上线时间、必须兼容的存量系统、人力上限）、关键假设与验证方式（2到3条）。
结构上必须结论先行：第一句直接写“因为X变化导致Y影响，所以要在Z时间前完成W范围的事”，后面四段都是展开和佐证。我还会做两个版本：立项评审用完整版；
同步给成员的版本在末尾加一栏“背景对你意味着什么”，把每条约束翻译成对他角色的影响，比如“上线卡在6月底，意味着测试窗口只有两周，提测必须按模块分批”。成员版我一般放在某项目管理平台的立项任务描述里，写完立刻在群里同步一次，避免文档躺在网盘里没人点开。
3. 项目背景怎么才能真正影响成员的行动，而不是评审完就进档案柜？
我们不止一次遇到这种情况：立项文档写得很认真，背景部分领导也认可，可启动会上成员只关心我要做什么、什么时候交，背景几乎没人再提。结果做到中期，大家为了省事开始砍范围、改口径，理由都特别朴素，“我不知道这条约束当初为什么定”。我想找到把背景变成日常动作的办法。
核心做法是做一次“背景到任务”的双向映射，而且必须在启动会上当场做完。正向映射：把背景里的每条硬约束（时间、预算、合规、存量兼容、人力）编号，逐条问它对应任务分解表里哪几个任务、对应哪条验收标准，对应不上的约束要么删掉要么补任务。
反向映射：抽5到8个关键任务，问如果这条背景不成立、这个任务还需不需要做，答不上来的就是背景没讲透的地方。我的经验口径是背景约束在任务分解表里的覆盖率不低于90%，低于这个数说明背景和执行是两张皮。
同时把背景做成活文档：每条关键假设指定验证人和验证时间点，到期在例会上过一遍，成立就转为正式约束，不成立就触发范围变更评审。这些内容我通常挂在某项目管理平台的同一条立项记录下维护，假设、验证结论、变更记录都留痕，而不是散在聊天记录里。
额外好处是中期有人想减范围时，你能拿出当初是因为什么才把它加进来的依据，讨论会回到事实而不是立场。
4. 怎么自检一份项目背景写得好不好？有没有可量化的判断标准？
项目背景这种偏说理的内容，很难像代码那样跑个测试就知道对错。我以前靠“读起来顺不顺”来判断，后来发现评审被退回的原因往往不是文笔，而是缺数据、缺边界、缺假设。我希望能有一套自己就能打分、不用等领导反馈的检查清单。
我自己用四个可量化的检查项。第一，可验证率：背景里每条论断都要能追到来源，内部数据、外部报告、访谈记录都算，我要求不低于80%，剩下20%明确标注为假设而不是当事实写。
第二，数字颗粒度：至少3个数字要带口径，包括时间范围、统计对象、计算方式，比如不能只写客诉量上升，而要写某类客诉在最近三个月占全部客诉的比例从5%升到18%，统计口径为工单系统一级分类。第三，边界清晰度：明确写出本次不做的清单，至少3条，没有不做什么的背景基本等于没有边界，后面一定扯皮。
第四，可复述性：找两个没参与前期的成员，各用一分钟复述为什么做、为什么现在做、做到哪为止，两人说的一致且不跑偏才算过关。这四项只要有一项不达标，我就不提交评审，而是先补信息，补信息花掉的时间，通常远小于评审被退回后重新组织一轮会议的成本。
文章包含AI辅助创作：项目立项如何做好项目背景？项目成员落地方案与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/283843
读者评论
我们去年也做过一次数据中台立项，背景写的是“数据孤岛严重需统一治理”，评审过了，但半年后资源被别的项目挤走两次。现在回头看，缺的就是那句“为什么是今年”。不过文中把通过率和五要素完整度直接挂钩，样本是43次评审，我倒好奇这些项目规模、预算量级是否可比，如果混着大小项目统计，这个78%和21%的差距可能被放大。
采购审批那个案例我很有共鸣，5万元以下线上化、5万元以上走原流程，这种边界写进背景里确实省掉后面大量扯皮。但我实际遇到的问题是，背景写完锁在立项文档里，过了三个月没人再看，成员判断需求时还是靠问主管。所以我觉得比怎么写更难的，是让背景真的在每次需求评审时被翻出来用，文中说每个里程碑花15分钟确认假设，这个动作我们试过，很容易流于形式。
把背景和范围分开写这一点我认同，但我不太认同“背景相对稳定、范围随约束条件调整”的说法。实际项目里市场一变，触发事件本身就失效了，这时候还守着原背景做取舍，反而会误导团队。文中提到背景要更新，却又说背景相对稳定，这两处我觉得有点矛盾。另外六类误区的帕累托图，返工工时占比加起来是100%，这个归因方式是单选题，一个返工往往同时踩了两三个坑，占比怎么拆其实值得再说明。