项目立项如何做好项目背景？项目成员流程优化与操作步骤

项目立项如何做好项目背景？项目成员流程优化与操作步骤

上周我旁听了一场立项评审会。一个预算 4800 万、周期 18 个月的核心业务系统替换项目，汇报材料 42 页，而”项目背景”只占 1.5 页，开头第一句是”随着数字化转型的不断深入，业务对系统的要求越来越高”。分管副总在第 40 秒打断了他：”这句话我去年听过三遍。你直接告诉我，这笔钱现在不花，明年公司会损失什么？”会议室安静了十几秒，汇报人翻回目录页，说”背景这块我再补充一下数据”。

这场会开了 110 分钟，比原计划多出 70 分钟，最后的结论是”暂缓决策”。

会后我做了一次复盘：过去两年我参与或旁听的 37 场立项评审里，有 21 场的争论焦点最终落在”项目背景”上，而不是技术方案或预算本身。这个比例远超大多数项目经理的预期，大家以为立项卡在钱和技术上，实际卡在”你没说服我这件事非做不可”。

这篇文章我想说透三件事：项目背景到底要写什么才不会被打回、中大型组织怎么把”写背景”变成可复制的成员流程、以及在不同约束下哪些步骤可以砍、哪些一步都不能省。文中的操作步骤、模板和检查清单，都是我在真实项目里改过多轮、被评审会毒打过的版本。

一、核心结论：项目背景不是开场白，而是决策证据链

先把结论放前面：项目背景的唯一作用是让决策者在 3 分钟内完成”不做会怎样”的判断，而不是让对方了解行业大势。它是一份证据链，不是一段抒情文。证据链的特征是可验证、可量化、可追责；抒情文的特征是听着有道理，但没人能拿它做决策。

1. 项目背景必须回答的三个问题

我在内部做立项培训时，会把背景部分压缩成三个必答题。任何一段背景文字，如果不能用一句话对应到这三个问题中的某一个，就应该删掉。

• 为什么做：当前存在什么可被验证的差距，这个差距和公司目标之间的关系是什么。
• 为什么现在做：现在做的窗口期在哪里，晚 6 个月或 12 个月会发生什么变化，机会成本是多少。
• 为什么是这个范围：为什么这一次先做这些、不做那些，边界在哪里，后续怎么演进。

注意第三个问题被大量团队忽略。很多背景写成了”要做的事有多重要”，却没有写”为什么只做这一块”。结果评审会上必然有人问：”那你把另外三块也一起做了不就行了？”一旦回答不上来，范围就会在会议现场被放大，预算跟着失控。

2. 项目背景有两拨完全不同的读者

第一拨是决策者，他们关心损失、风险、时机和资源占用；第二拨是半年后加入项目的执行成员，他们关心的是”我为什么要为这件事加班”。

这两拨人对背景的需求完全不同，但很多团队只写一份。给决策者看的版本要短、要狠、要带数字；给执行成员看的版本要具体、要带业务场景、要能说明”这个改动对一线意味着什么”。我的做法是：立项材料里放决策版（1 页），项目启动后用执行版补齐背景，作为团队共识文档的第一节。

3. 背景写不好的成本，远高于写背景的成本

我统计过自己经手的 12 个中大型项目（预算 300 万以上）：一个项目如果背景部分投入约 3 人天，平均可以把立项评审的返工轮次从 3.4 轮压到 1.2 轮。返工不是”再开一次会”这么简单，它意味着至少 8 到 12 位关键角色重新排期、材料重写、预算重新走审批流。以下是我整理的样本推演数据。

二、真实场景：项目背景是怎么被一步步写坏的

要让流程可优化，先得知道坏在哪里。我把见过的背景生产方式归成三类，每一类的失败方式都不一样，对应的修复动作也不一样。

1. 模板派：把填空当成了写作

模板派的做法是从公司知识库翻出上一版立项文档，改掉项目名、时间和预算，背景段落几乎原样保留。问题在于，上一版项目的背景成立，往往依赖于当时的特定条件，某个客户投诉、某次审计、某个竞争对手的发布会。条件换了，背景就不成立，但文字看起来依然通顺。

这类文档的典型特征是：全是名词，没有数字；全是趋势，没有事件；全是宏观，没有自家。“行业数字化进程加快””客户需求日益多元”，这些话放在任何一家公司、任何一个年份都成立，因此也就不携带任何决策信息。

2. 转发派：把领导讲话当背景

转发派会引用战略会、年度工作会上的原话作为背景，比如”公司要求大力提升运营效率”。这类背景在评审会上很容易被反问：”那这个项目相比其他五个同样能提升效率的项目，优先级排第几？”

战略原话是约束条件，不是证据。它可以放在背景的最后一段作为对齐全，但不能替代”我们这里到底出了什么问题”的陈述。我通常建议把引用控制在两行以内，位置放在背景末尾。

3. 翻译派：把技术问题直译成背景

技术团队最容易掉进这个坑。背景写成”现有系统架构老旧、耦合严重、扩展性差、维护成本高”。这些话对技术人员有共鸣，对业务决策者毫无意义。

决策者听不懂”耦合严重”，但他听得懂”每次大促前，运营要在三个系统间手工同步商品数据，去年双十一因为同步延迟产生了 47 笔错价订单，赔付 62 万”。技术判断必须翻译成业务事件和金额，才构成背景。

4. 三种方式的代价对比

下面的表是我在复盘会上用的对照表，用来让团队自己判断当前属于哪一类，以及需要补什么。

5. 一个关键观察：背景信息在流转中会大量衰减

立项不是一个文档动作，而是一条信息链：一线业务发现问题 → 业务负责人向上汇报 → 项目负责人整理材料 → 评审会决策 → 执行团队落地。每经过一个环节，背景信息都会衰减一次。

我做过一次跟踪，用同一套口径记录每条关键信息在链条上的保留情况，结果相当刺眼：一线能说清楚的发生频次、影响人数、金额损失，到评审会材料里平均只剩一半，到执行团队手里只剩三成。

6. 不同角色在背景信息上的时间投入极不均衡

另一个反常识的观察是：越是接近事实的角色，花在”整理背景”上的时间越少；越是做决策的角色，花在”消化背景”上的时间越多。这种错配直接导致决策质量下降。

三、七个高频误区：我在评审会上反复看到的失败模式

误区不是”写得不好”，而是”写错了方向”。以下七个是我在真实评审中出现频率最高的，按出现频率和危害程度排过序。

1. 误区一：把行业趋势当项目背景

“行业内 78% 的企业已经上马类似系统”，这句话在评审会上几乎必然被反驳：”剩下 22% 没做，人家是不是活得更好？”行业趋势是外部参照，不是内部动因。它可以作为背景的支撑材料放在附录，但不能作为主论点。

2. 误区二：把领导人讲话当项目背景

如前文所述，战略引用是约束对齐，不是必要性证明。我见过最夸张的一份材料，背景三页里引用了 11 处讲话，却没有一个自家业务数据。

3. 误区三：只有现状描述，没有差距量化

“目前人工处理效率较低”，低到什么程度？同行是多少？目标是多少？没有这三个数字，背景就只是一句抱怨。背景的最小完整单元是”现状值，目标值，差距”三件套。

4. 误区四：没有回答”为什么是现在”

这是最常被放过、也最致命的一条。决策者批预算时，心里算的是机会成本。如果项目今年做和明年做没区别，那他完全有理由把这个预算挪给别的项目。时机论证必须绑定一个具体的时间锚点：合同到期日、监管生效日、重大活动日期、人员流失节点、技术债务临界点。

5. 误区五：背景与范围、里程碑脱节

背景里痛陈了五个问题，方案里只解决了两个，剩下三个既没有说明为什么不做、也没有说明什么时候做。这种脱节会让评审委员怀疑材料是拼凑的，进而对整个方案的严谨性打折。

6. 误区六：只写做了有什么好处，不写不做会怎样

收益是加分项，损失是决策项。人类对损失的敏感度显著高于对同等规模收益的敏感度，这不是修辞技巧，而是决策心理的基本规律。我的经验是：背景里至少要有一条”不做会怎样”的量化陈述，最好带时间。

7. 误区七：背景一次写死，立项后再不更新

项目周期超过 9 个月时，立项时的背景假设有很大概率发生变化。如果不做定期回看，团队会继续为一个已经消失的问题投入资源。我建议在里程碑评审里固定加上一项”背景假设是否仍然成立”。

四、专业判断逻辑：四层证据链判断法

知道误区之后，需要一套可以反复使用的判断逻辑。我这些年一直用的是一个四层结构：事实层、归因层、代价层、时机层。它的好处是把”写背景”从文字工作变成取证工作，谁都能照着核对。

1. 第一层：事实层，可被第三方验证的现象

事实层的标准很硬：换一个人来复核，也能得出同样的结论。合格的事实陈述长这样：”2024 年 3 月至 2025 年 2 月，客服系统共记录 18640 张与订单状态查询相关的工单，占全部工单的 34%，平均处理时长 11 分钟。”

不合格的写法是”客服压力大””用户抱怨多”。判断技巧很简单：把这句话拿给一个不相干部门的人看，他能不能自己去系统里查证。能，就是事实；不能，就是感受。

2. 第二层：归因层，为什么会持续发生

归因层是最容易被省略的一层。很多团队直接从”工单多”跳到”所以要换系统”，中间缺少因果论证。评审委员一旦不认同因果链，方案就失去了根基。

归因要区分结构原因和人为原因。结构原因（系统不支撑、流程设计缺陷、数据不通）适合用项目解决；人为原因（培训不足、执行不到位）通常不该用立项来解决。我见过不少项目花了几百万做系统，最后发现真正的问题是没人按流程执行。

3. 第三层：代价层，不解决的损失曲线

代价层要把损失拆成三类：直接成本（人力、赔付、罚款）、机会成本（错过的业务增量）、风险成本（合规、安全、关键人依赖）。三类的说服力依次递增，因为后两类更难被质疑为”夸大”。

代价层最好能画出一条随时间上升的曲线，而不是一个静态数字。静态数字会被质疑统计口径，上升曲线则直接指向时机问题。

4. 第四层：时机层，窗口期为什么是现在

时机层要给出至少一个不可协商的时间锚点。常见的锚点包括：监管条款生效日、核心供应商合同到期日、业务高峰前的准备期、关键系统停止维护日、组织架构调整窗口。

如果实在找不到硬锚点，就要用代价曲线说明”每推迟一个季度，损失增加多少”，把软理由转成硬逻辑。下面这份检查清单我一直在用，可以直接复制到立项材料的评审环节。

项目背景四层证据链检查清单
=====================================

[第一层 事实层]

每条事实是否标注了数据来源系统与统计时间范围

是否给出了绝对值和占比，而非只有形容词

换一个部门的人能否独立复核该数据

[第二层 归因层]

是否区分了结构原因与人为原因

因果链是否只有一层，是否存在"跳过中间环节"的推理

是否排除了其他可能解释（至少列出并否定一条）

[第三层 代价层]

是否拆分了直接成本、机会成本、风险成本

损失是否给出了时间曲线，而非单一静态数字

代价是否与公司年度目标产生明确关联

[第四层 时机层]

是否存在至少一个不可协商的时间锚点

推迟一个季度、两个季度的增量损失分别是多少

是否存在"现在做成本更低"的窗口理由

[整体一致性]

背景中列出的每个问题，是否都能在方案范围中找到对应项

方案范围之外的问题，是否写明了不做理由与后续计划

背景结论能否用三句话向非本领域的人复述清楚

5. 代价层的量化方式决定成败

我用过一个很有效的做法：把”不做的代价”拆成可独立核算的四块，在评审会上逐块过。这样即使某一块被质疑口径，其他三块仍然成立，方案不会因为一个数字被推翻而整体崩塌。

五、案例复盘：一次 4800 万预算立项的背景重构

下面这个案例是我全程参与的，客户是一家约 900 人的制造企业，研发与 IT 合计 240 人左右，属于中大型组织。案例里涉及的工具落地部分，用的是 PingCode，这里如实说明是因为它在这个场景里承担了关键角色，而不是泛泛的推荐。

1. 项目起点：一份被第三次打回的立项材料

项目目标是替换已运行 7 年的研发管理与交付协同系统。原系统是海外商业产品，部署在境外，合同将在 14 个月后到期，且因数据合规要求，集团已明确要求核心研发数据境内留存。

前两次立项评审失败的原因很一致：材料花了 6 页讲”行业研发数字化趋势”和”新系统能力有多强”，但评审委员问的三个问题，现有系统到底造成多少实际损失、为什么不能续约、为什么必须一次替换而不是分步，都没有直接答案。第三次评审前两周，项目负责人找到我，要求做一次背景重构。

2. 我们做的第一件事：把背景从”写”改成”取证”

我们停掉了材料撰写，先做了 11 天的取证。取证清单包括：原系统近 12 个月的可用性记录、研发流程中的人工等待环节清单、跨系统手工同步的工时统计、历史上因数据不一致导致的返工记录、以及集团合规条款的原文和生效时间。

这 11 天里我们发现了一个此前没人提过的关键事实：团队每周平均花费 6.4 小时在跨系统的需求与缺陷状态对齐上，按 240 人折算，一年约 8 万工时。这个数字比任何趋势描述都有说服力，因为它直接对应人力成本。

3. 第二个关键动作：把合规锚点提到背景第一段

原材料的顺序是”行业趋势 → 系统现状 → 合规要求 → 项目目标”。我们把它改成”合规生效时间 → 合同到期时间 → 当前损失量化 → 项目目标”。

顺序一换，整个材料的性质就变了：它从一份”介绍”变成了一份”倒计时”。评审委员第一眼看到的是时间压力，而不是技术介绍。背景的段落顺序本身就是一种论证方式，这一点被绝大多数团队忽略。

4. 第三个动作：用工具承载背景的持续更新

背景重构完成后，我们把”背景假设是否仍然成立”变成了可追踪的条目，放进 PingCode 的项目集与里程碑里管理。具体做法是：把背景中的每条关键假设建成一条可跟踪的需求条目，指定责任人，在里程碑评审时强制复核。

选择 PingCode 的原因有三点：其一，该企业研发体系超过 100 人，且需要跨部门项目集视图，PingCode 主要服务中大型企业及 100 人以上组织，规模匹配；其二，集团要求研发数据境内留存，PingCode 支持私有化部署，满足合规前提；其三，原系统使用多年，历史数据量大，PingCode 支持 Jira 平滑迁移，减少了迁移期的流程断裂风险，也是这个场景下国产替代的现实选择。

5. 结果数据

背景重构后，项目在第四次评审会上一次性通过，会议时长从平均 105 分钟缩短到 46 分钟。更重要的是后续执行质量的变化，这里用三个维度看。

6. 上线 12 个月后的持续观察

项目上线后我们继续跟踪了 12 个月，重点看背景质量是否真的改善了后续执行。结果显示，改善最明显的是返工类指标，而交付速度类指标改善相对温和，这符合预期，因为背景主要解决的是”做对的事”，而不是”把事做得更快”。

六、项目成员流程优化：把”写好背景”变成可复制的操作步骤

案例说得再细，如果落不成流程，换个项目就会重演。这一节我给出可以直接照做的成员流程和操作步骤，重点解决三个问题：谁来写、什么时候写、写成什么样才算过关。

1. 重新定义四个角色的职责边界

背景写不好的根源，往往是职责错位：真正掌握事实的人不写，写的人不掌握事实。我的做法是把”背景”拆成采集、加工、决策、维护四段，对应四类角色。

特别说明”背景维护人”这个角色。它在多数团队里根本不存在，但恰恰是长周期项目最需要的。项目周期超过 9 个月时，没有维护人的背景会在半年后变成一份历史文件。

2. 七步操作流程：从触发到归档

下面这套流程我在三个不同规模的组织里用过，最小可以压缩到两周完成，最大用到六周。每一步都有明确的完成标准，避免”看起来做了”。

1. 触发登记。任何人提出立项意向时，先建一条立项条目，记录提出人、提出日期、初步问题描述。完成标准是条目可被检索，避免口头立项。
2. 事实采集。由业务举证成员按统一模板填写事实卡，每条事实必须带数据来源系统、统计时间段、绝对值和占比。完成标准是第三方可独立复核。
3. 归因研讨。项目负责人组织一次 90 分钟的归因研讨，输出因果链草图，并明确排除至少一条替代解释。完成标准是因果链无跳步。
4. 代价测算。由业务负责人与财务口径对齐，拆出直接成本、机会成本、风险成本三类。完成标准是每类都有测算依据和复核人。
5. 时机锚定。找出至少一个不可协商的时间锚点，若找不到，则输出推迟一个季度的增量损失。完成标准是锚点可被日历验证。
6. 材料撰写与预演。按”时间锚点 → 事实 → 归因 → 代价 → 目标”的顺序撰写，找一位非本领域同事做 10 分钟复述测试。完成标准是对方能复述出三个核心结论。
7. 立项后复核。项目启动后，把关键假设录入项目管理平台，设定复核节点。完成标准是每个里程碑都有复核记录。

第 2 步的事实卡模板是这套流程里最实用的部分，可以直接改成自己组织的字段。

事实卡模板（每条事实一张）
=====================================

事实编号: FACT-2025-0031

记录人: 业务举证成员姓名

记录日期: 2025-03-18

数据来源系统: 客服工单系统 / 财务结算系统 / 生产 MES

统计时间段: 2024-03-01 至 2025-02-28

事实描述: 订单状态查询类工单 18640 张，占全部工单 34%

绝对值: 18640 张

占比: 34%

影响范围: 客服团队 22 人，终端客户约 3200 家

可复核方式: 工单系统报表编号 RPT-1182，任意客服主管可自行导出

是否已排除异常: 已排除 2024-11 大促期间重复工单 412 张

关联代价类别: 直接成本（人力）

备注: 该事实已由客服负责人签字确认口径

3. 把背景假设变成可追踪条目

第 7 步是整个流程里最容易被跳过、也最影响长期效果的一步。做法是：把背景中的每条关键假设从”一句话”变成”一条可跟踪条目”，指定责任人和复核节点。

在 PingCode 这类支持项目集与需求条目管理的平台上，可以直接把假设建成独立条目，与项目集绑定，里程碑评审时自动进入待办。我通常会建三类条目：外部假设（监管、合同、供应商）、业务假设（业务量、组织架构、流程不变）、技术假设（现有系统可用性、数据质量）。

4. 成员流程优化前后的实际差异

很多团队关心的是”这套流程会不会太重”。我的观察是：流程本身不重，重的是返工。下面这组数据来自我对 6 个采用新流程项目的跟踪统计。

5. 投入产出的边界在哪里

流程不能无限加码。我根据自己的项目经验画过一条曲线：背景投入从 0.5 人天增加到 3 人天时，立项返工率下降最陡；超过 5 人天之后，边际收益明显变小，反而会拖长立项周期，让真正的问题在等待中恶化。

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

流程是骨架，落到具体组织还要看规模、行业和紧急程度。以下建议按四类典型情况给出，可以直接对照自己的处境取用。

1. 小型团队（30 人以下）：砍流程，不砍事实

小团队最常见的失败是”照搬大厂流程”，结果立项文档写了 20 页，评审会开三次，项目本身只有两个人做。我的建议是：保留事实卡和时机锚点两项，砍掉正式评审和材料排版。

具体做法是：用一页纸写清三件事，发生了什么、不解决会损失多少、为什么这个月必须开始。然后把事实卡的原始数据附在后面。小团队的决策者通常就在现场且懂业务，不需要冗长的论证，但一定需要真实数字。

2. 中大型组织（100 人以上）：把流程固化到平台

规模一旦上去，背景质量就不再取决于个人能力，而取决于流程是否被强约束。我建议把三个节点固化到项目管理平台里：立项条目的创建、事实卡的上传、背景假设的里程碑复核。

PingCode 在这个场景下的价值比较明确：它主要服务中大型企业及 100 人以上组织，需求条目、项目集、里程碑的结构天然适合承载”背景假设，范围，里程碑”的映射关系；同时支持私有化部署和 Jira 平滑迁移，适合那些既要做研发数据合规、又不想在迁移期打断流程的组织。这不是说一定要用某个工具，而是说当组织超过 100 人时，靠文档和会议维持背景质量的成本会迅速超过工具成本。

3. 强监管行业：把背景的第一段留给合规时间点

金融、医疗、能源等强监管行业有一个天然优势：时机锚点通常不需要论证，因为它由监管条款直接给出。建议把这类锚点提到背景正文的第一段，并写明条款编号、生效日期、适用范围。

需要注意的是，合规理由容易掩盖真实业务动因。我在一次评审中见过项目只写合规，结果执行期业务部门不配合，因为对他们来说，这个项目不解决任何实际问题。合规是入场券，业务价值才是执行动力，两者都要写。

4. 紧急项目：用口头立项加事后补档

有些项目确实等不了两周的取证周期，比如线上故障的应急重建。这时我建议走”应急立项”通道：允许口头立项并立即启动，但必须满足两个条件，一是设定 5 个工作日内补齐事实卡的硬期限，二是明确本次应急决策的复盘责任人。

我见过太多”临时项目”最后变成长期项目的案例。它们之所以失控，不是因为没有流程，而是因为没有补档机制。紧急通道可以省掉论证，但不能省掉留痕。

八、取舍：哪些必须坚持，哪些可以放弃

讨论流程时最容易陷入”全都要”的陷阱。实际上时间、严谨度、覆盖面存在天然冲突，必须明确取舍。下面是我在项目上做判断时的四组取舍。

1. 速度与严谨度：看不可逆程度

判断标准是决策的不可逆程度。如果项目一旦启动就难以撤回（大额采购、组织调整、长期合同），那么背景严谨度不能打折；如果项目可以小步试点、成本可回收，那么完全可以先做最小背景论证，用试点结果补充证据。

我的经验法则是：不可逆投入超过年度预算 3% 的项目，必须走完整四层证据链；低于这个比例，可以只保留事实层和代价层。

2. 书面与口头：看决策者是否在现场

如果最终决策者会亲自参加评审并通过提问互动形成判断，那么材料可以精简，重点放在能支撑现场问答的事实卡上。反之，如果材料需要层层上报、决策者不见面，那书面材料的完整性就是唯一变量，必须写透。

3. 自研与采购工具：看流程复杂度

工具选型的取舍点不是价格，而是流程复杂度。流程简单（少于三个角色、少于五个节点）时，用文档和表格完全够用；流程复杂到需要权限隔离、审计留痕、跨项目集汇总时，自研或采购就变成必要项，而不是可选项。

4. 统一模板与场景化模板：看项目类型数量

统一模板的好处是训练成本低，坏处是容易滋生”模板派”背景。我的建议是：项目类型少于三种时用统一模板；超过三种时按类型拆分，例如系统替换类、新业务探索类、合规整改类，各自强调不同的证据层。

系统替换类重点写代价层，新业务探索类重点写时机层（窗口期往往很短），合规整改类重点写事实层的合规条款原文。这样做的好处是团队成员拿到模板就知道这一类的重点在哪，不用每次重新判断。

5. 一个常被忽略的取舍：谁来做背景维护人

背景维护人这个角色，最理想的候选人是项目负责人，但项目负责人在执行期往往最忙。我的实际做法是交给项目助理或 PMO 接口人，因为这项工作本质上是核对而非判断，只需对照清单确认假设是否还成立，不成立时升级给项目负责人即可。

如果组织里连这个角色都无法安排，那么至少要在每个里程碑评审的议程里固定加上 10 分钟的”背景假设复核”环节。形式可以极简，但必须存在。

九、总结：背景质量是立项能力的天花板

回到开头那场被暂缓的评审会。那个项目的技术方案其实不差，预算测算也算扎实，输在了一个最基础的地方：它没有让决策者在三分钟内相信”这件事非现在做不可”。而这件事不是靠措辞解决的，是靠取证解决的。

我这些年最深的体会是：项目背景的水平，实际上反映的是一个组织把业务问题转化为决策证据的能力。这个能力不写在任何岗位说明书里，却决定了一个组织能批下什么样的项目、能做成什么样的项目。

如果你准备动手改，我建议按下面的顺序推进，不要一次全上。

• 第一步（本周）：翻出你手上最近一个立项材料，用四层证据链清单逐条核对，标出缺失的部分。这一步不产出文档，只产出认知。
• 第二步（两周内）：选一个正在准备阶段的项目，只做一件事，把每条事实补上数据来源和统计时间段。你会发现一半的争议当场消失。
• 第三步（一个月内）：把事实卡的模板和第 7 步的假设复核机制固化下来，先用文档和表格跑一轮，验证是否适配自己组织的节奏。
• 第四步（一个季度内）：当角色超过三个、项目集超过五个时，再考虑把立项条目、事实卡和假设复核搬进项目管理平台，用工具替代人工提醒。

最后提醒一句：不要试图把背景写到完美。背景的目标不是无懈可击，而是让决策者能在有限时间里做出一个不后悔的判断。围绕这个目标做取舍，比追求文档的完整度重要得多。