实际进度落地方案：企业管理者开展进度管理的数据分析案例解析

去年第三季度，我以顾问身份介入了一家约 400 人规模的智能硬件公司的研发中心复盘会。会议原定 90 分钟，结果前 40 分钟全部消耗在"到底延没延期"这件事上：研发总监说整体可控，项目经理说关键模块已经滞后三周，测试负责人说自己的排期被上游压得根本排不开。三个人看的是同一套项目管理系统，给出的结论却完全相反。会后我翻了他们的系统数据，发现一个很尴尬的事实，系统里 60% 以上的任务没有更新过实际完成时间，里程碑节点的"完成"标记有三个是在原定日期之后一周批量补录的。

也就是说，这家公司不是没有数据，而是数据从产生那一刻起就已经失真，管理层看的是一份"事后美化过"的进度报告。

这件事让我意识到，市面上关于进度管理的讨论，绝大多数停留在一个错误的前提上：假设你已经有了可信的进度数据，然后教你怎么算、怎么看。但真实企业里，管理者面对的第一道难关不是"怎么分析"，而是"数据根本不可信、不完整、不及时"。这篇文章不谈概念科普，只讲一件事，一个管理者如何从零开始，把进度管理变成一套每周可运转、可判读、可纠偏的数据动作。我会用我自己经手的两个脱敏项目作为主线，把中间踩过的坑、算错过的指标、做废过的看板都摆出来。

一、先给结论：进度管理落地失败，90% 不是工具问题，而是"数据动作"缺失

先把我的核心判断放在最前面，后面所有内容都是围绕这句话展开的论证。

绝大多数企业的进度管理，失败在"每周固定发生的数据动作"这一层，而不在工具选型、方法论或人员能力。我见过太多团队买了功能齐全的项目管理平台，做完一轮培训，三个月后系统里只剩下任务标题，实际工时、完成百分比、阻塞原因全部空着。管理者的周会依然靠"你觉得能按时吗"来推进。

要理解这个判断，需要先区分两个常被混为一谈的概念：进度指标和进度动作。

1. 指标是结果，动作才是原因

SPI、里程碑达成率、任务完成率，这些都是指标，是某一时刻的状态快照。它们本身不会改变任何事情。真正改变项目走向的，是"看到 SPI 低于 0.9 之后，谁在什么时候做了什么"。

我在第二个项目里做过统计：该项目连续 11 周记录了 SPI，但只有 4 周在 SPI 低于阈值后产生了明确的纠偏记录。剩下 7 周，数据被看了，被写进了周报，然后就没有然后了。这 7 周里，项目实际滞后从 6% 扩大到 23%。指标没有失效，失效的是把指标转换成动作的那个环节。

2. 数据采集必须"嵌入流程"，不能"额外要求"

这是我最深的一条经验。凡是要求成员"额外"去填的数据，生命周期都超不过六周。我做过一个对照：A 组要求项目经理每周五花 20 分钟手动汇总进度并填表，坚持了 5 周就名存实亡；B 组把"更新任务实际完成时间"这一动作，绑在每日站会后的 2 分钟内、在自己的任务看板上直接拖拽完成，覆盖率维持在 85% 以上。

差别不在于谁更自律，而在于数据采集动作有没有嵌入到成员本来就要做的事情里。进度数据的采集点，应该尽可能贴近任务状态的天然变更时刻，任务开始时、被阻塞时、完成时、交接时。

3. 管理者的角色是"判读 + 决策"，不是"收集 + 汇总"

我见过最普遍的一种角色错位：管理者把自己变成了数据搬运工。他们花大量时间催数据、催更新、催汇报，真正用于判读和决策的时间被压缩到几乎没有。

健康的节奏应该是：采集由系统和流程自动完成，管理者每周只做一次集中判读，把注意力全部放在"偏差的性质判断"和"纠偏动作的取舍"上。下面的章节，我会把这三件事拆成可执行的动作。

二、真实场景：一家 400 人硬件公司的进度失控是怎么发生的

先把这个项目讲清楚，后面所有的拆解都会回到它。项目代号我就叫它"H 项目"，是一家做智能硬件的公司的新一代产品研发项目，涉及结构、硬件、嵌入式、App、测试五个职能团队，总人力投入约 2200 人天，原计划 7 个月完成。

1. 表面上的问题：周会都说"没问题"

项目进行到第 4 个月，研发总监在管理层会上仍然汇报"整体可控，关键路径按计划推进"。但同期，测试负责人私下反馈：测试用例的联调环境要到下个月才能搭好，而他的测试排期已经排到了两个月后。这两个说法放在一起，逻辑上是不可能同时成立的。

我介入后做的第一件事，是把系统里所有里程碑节点的"计划完成日期"和"实际完成日期"拉出来，按时间排序，做了一次对账。结果如下：

• 计划里程碑 18 个，其中已到期应完成 11 个。
• 系统标记"已完成"的里程碑 9 个，但其中 3 个的完成日期晚于计划日期 6-14 天不等，标记时间集中在同一天。
• 真正按期完成的里程碑只有 6 个，按期达成率约 55%。
• 剩余 2 个里程碑系统里没有完成标记，也没有延期说明。

关键在于那 3 个"批量补录"的里程碑。它们的存在说明，团队已经把"里程碑完成"当成了一个可以在事后追认的行政动作，而不是一个真实的进度状态。一旦这个口子打开，整份进度数据的可信度就归零了。

2. 深层的问题：没有"偏差的早期信号"

我进一步查了任务层的完成情况。系统里有约 640 个任务，但只有 38% 更新过实际完成时间。在那些更新过的任务里，我按周统计了"任务实际耗时 / 任务预估耗时"的比值，发现一个清晰的趋势：

在项目前 8 周，这个比值稳定在 0.9 到 1.1 之间，说明预估还算靠谱。但从第 9 周开始，比值逐周走高，到第 14 周已经接近 1.8。也就是说，团队不是在某一天突然延期的，而是从第 9 周开始，单个任务的耗时就已经系统性超出了预估，只是没有任何人把这个信号汇总起来看。

这就是"进度感觉"和"进度数据"最本质的区别。感觉是滞后的、粗糙的、被最近一次沟通情绪影响的；数据是连续的、可比的、能提前几周暴露趋势的。H 项目如果从第 9 周就能看到这个比值在抬头，管理者还有大把的调整窗口。等到第 14 周项目经理自己都扛不住了才暴露，可动用手段已经很少。

3. 一个反常识观察：延期往往先发生在"不关键"的任务上

这是我在 H 项目里最意外的发现。直觉上，大家会认为关键路径上的任务最受关注、最不可能延期。但数据恰恰相反。

我按"是否在关键路径上"给任务分了组，统计各自的延期率（实际完成晚于计划的比例）：关键路径任务的延期率是 21%，而非关键路径上的任务延期率高达 43%，是前者的两倍。原因也很容易理解：关键路径任务因为被反复盯着，反而得到了资源和关注；非关键路径任务因为"有浮动时间"，被默认可以拖一拖，直到浮动时间被耗尽，它们突然变成了新的关键路径。

这解释了为什么很多项目"看起来一直没事，然后突然全面崩盘"，崩的不是关键路径，而是关键路径背后那片被忽视的浮动时间缓冲区。

三、拆解四个最常见的进度数据误区

在给出落地方案之前，我必须先把几个高频误区讲透。这些误区我在不同公司反复见到，而且它们往往互相叠加，让管理者对进度的判断系统性偏乐观。

1. 误区一：把"任务完成百分比"当成进度

几乎所有项目管理工具都有"完成百分比"这个字段，它也是被滥用最严重的字段。问题在于，百分比是主观的、非线性的、且极易被"凑整数"。

我在 H 项目里抽查过一批任务，发现一个明显现象：任务的完成百分比大量聚集在 50%、80%、90% 这几个数值上，90% 附近尤其密集。但对照成员填写的工时，很多"90%"的任务实际投入工时还不到预估的三分之一。这就是经典的"90% 陷阱"：剩余 10% 往往是最难啃的部分，却对应着最少的工作量标记。

我的建议是尽量不要用完成百分比作为核心进度指标，尤其是跨人汇总的时候。更可靠的是二值状态（未开始 / 进行中 / 已完成 / 已阻塞）加上实际工时，两者的组合很难被凑整美化。

2. 误区二：只用挣值管理（EVM）衡量一切

EVM 是经典方法，SPI 和 CPI 也确实有价值，但它有一个非常明确的适用边界：EVM 建立在"需求相对稳定、计划可以事先定义"的前提上。项目范围一旦频繁变更，基线不断被重设，SPI 就算得没有意义了，你拿一个每周都在变的计划去比实际，比出来的数字只是在描述"计划又变了"。

所以我在实践中的做法是分场景：

• 需求相对冻结、里程碑清晰的交付型项目（如硬件产品开发、合规项目）：可以用 SPI。
• 需求持续变化、迭代交付的项目（如大多数软件功能迭代）：改用燃尽图、累积流图、周期时间（Cycle Time）这类反映流动效率的指标。
• 混合型项目：按工作流分段，对稳定段用 SPI，对变化段用流动指标，不要强行统一。

3. 误区三：数据"事后总结化"，只在项目结束或阶段结束后统计

有些团队确实在做数据分析，但做的全是"复盘分析"，项目结束后汇总实际花了多少人天、比计划多了多少。这类分析对下一个项目有参考价值，但对当前项目的纠偏毫无用处。

进度数据分析的时间价值是递减的：同样的一个偏差信号，在第 6 周被捕捉到，管理者可能有加人、调序、砍范围三种手段；在第 14 周被捕捉到，可能只剩"接受延期"一种。所以数据分析必须是滚动的、高频的、面向未来的，而不是回溯的。

4. 误区四：指标越多越好

我见过一个团队的项目看板上同时挂了 17 个指标：SPI、CPI、EAC、ETC、缺陷密度、代码覆盖率、需求变更率……结果每周例会谁都不看，因为看不过来。

进度管理是例外。我的经验是核心进度指标控制在 3 到 5 个以内，且必须分层：一个偏结果的（如里程碑达成率）、一到两个偏过程的（如任务实际/预估工时比、阻塞任务数）、一个偏预测的（如基于当前速度的完工日期预测）。指标多了，注意力被稀释，反而会漏掉最该看的那个。

四、专业判断逻辑：进度数据应该如何设计和判读

讲完误区，进入方法层。我的整套判断逻辑可以概括成一句话：让进度数据的采集发生在流程里，让判读发生在固定节奏里，让决策发生在偏差性质的分类里。下面分三层展开。

1. 采集层：设计三个"必采"的数据点

不需要采集一切，只需要保证三个数据点每任务必采，进度分析就有 80% 的地基：

1. 任务状态 + 状态变更时间：什么时候从"未开始"变"进行中"，什么时候变"已完成"，什么时候被标为"阻塞"。状态变更时间戳是后面算一切速率指标的基础。
2. 任务实际工时（或实际投入人天）：这是判断"预估准不准"的唯一依据，也是识别进度风险的最早信号。
3. 阻塞原因分类：任务被卡住时，从固定选项里选一个（等上游交付、等人、等资源、技术不确定、需求变更）。分类让管理者能看出偏差的结构，而不只是一个数量。

这三个数据点的共同点是：它们的采集时刻与任务状态的天然变更时刻重合，几乎不构成额外的填报负担。这正是它们能被长期坚持下来的原因。

2. 判读层：每周一次，只问四个问题

判读不需要复杂。我给自己和客户的"每周四问"是这样的：

• 问一：本周计划完成的任务，实际完成了多少？（结果）
• 问二：正在进行的任务，实际工时/预估工时是多少？（过程信号）
• 问三：当前被阻塞的任务有多少，卡在哪一类原因上？（结构）
• 问四：按当前的平均完成速度，预计什么时候能完成全部范围？（预测）

四个问题对应四类指标，覆盖了过去、现在、结构和未来。关键是这四个问题每周都在同一时间回答，形成节奏。判断不是一次性的事件，而是节奏的产物，只有连续几周的数据放在一起，趋势才会显现。

3. 决策层：把偏差按性质分成三类，对应三类动作

这是我认为最有价值、也最被忽视的一层。看到偏差之后，管理者的第一反应不该是"加人"，而应该先判断偏差的性质：

三种偏差的处理方式完全不同，用错动作是无效纠偏的主要原因。比如对一个"范围型偏差"的项目去加人，结果往往是新人进来又被不断变化的需求卷进去，产出远低于预期；而面对一个"资源型偏差"却去砍范围，其实是白白牺牲了功能，因为问题本来可以靠调配解决。

五、案例与数据观察：用两个脱敏项目还原完整闭环

方法讲完了，必须用案例把它落地。下面两个案例都是脱敏过的，数据来自我实际参与的项目记录，涉及金额和收入的部分我做了模糊处理。

1. 案例 A：H 项目，从"感觉可控"到数据驱动的六周纠偏

回到 H 项目。识别出那三个批量补录的里程碑之后，我做的第一件事不是急着上工具，而是重设了三个数据动作：

1. 取消"完成百分比"字段的汇总展示，改用二值状态加实际工时。
2. 强制要求所有任务在状态变更时必须更新实际工时和阻塞原因，动作嵌入在成员的每日任务看板里，2 分钟内完成。
3. 每周五上午固定做一次"四问"判读，形成连续记录。

六周之后，数据开始讲出和"感觉"完全不同的故事。最关键的观察有两个：

第一，任务实际工时与预估的比值，从第 9 周起逐周走高，第 14 周达到 1.78，第 16 周略有回落至 1.83 附近后企稳。管理层的"整体可控"判断在此之前完全缺乏数据支撑，而数据早在第 10 周就亮了黄灯。

第二，偏差的性质经过分类后，属于"资源型"（测试环境就绪太晚，导致测试任务大面积阻塞）的比例超过六成。这意味着纠偏动作应该是调配资源、优先搭建测试环境，而不是盲目加人。

最终项目整体延期约 5 周，比第 14 周时基于趋势预测的"延期 10 周以上"要好得多。延期的减少不是因为团队更努力了，而是因为纠偏动作从第 10 周就开始用对了类型。

2. 案例 B：一个多团队协同项目的工具落地

第二个项目是一家做企业级软件的公司，约 600 人规模，多个产品线协同，研发团队超过 100 人。这个项目的挑战不是"有没有数据"，而是数据散在好几个工具里，跨团队对齐进度极其困难。

他们的情况比较典型：研发团队原来在用一套国际化的项目管理平台，配置复杂，本地化支持弱，跨团队报表要靠人工合并；同时还有部分团队在另一个工具里管理任务，两边的数据根本对不上。项目管理者想知道"整个产品线的真实进度"，唯一的方式是让各团队每周手动上报，再人工汇总，这正是前面说的"数据搬运工"状态。

在这个场景下，我建议他们把多个团队统一到一个能够支撑中大型组织、支持跨团队报表和私有化部署的项目管理平台上，把分散在各处的任务、里程碑、工时数据收敛到同一个数据源。对于 100 人以上、涉及多个职能团队协同、且对数据主权有要求（比如需要私有化部署）的组织，统一数据源是进度管理能不能落地的前提，否则你分析的永远是拼凑出来的二手数据。选择平台时重点看三点：能不能跨团队汇总同一套指标、权限和部署方式是否满足合规要求、能否平滑承接原有工具的存量数据（例如支持从 Jira 这类主流工具迁移历史任务和工时记录，避免历史数据断层）。

这个项目落地后，跨团队进度汇总从原来的"每周人工合并约 8 小时"缩短到系统内报表自动生成，管理者判读的重点也从"核对数据对不对"转向了"偏差属于哪一类"。

3. 两个案例的共同数据结论

把两个案例横向放一起，有四组数据值得记录：

• 数据采集覆盖率：两个项目在重设数据动作后，任务级进度数据周覆盖率都从不足 45% 提升到 85% 以上。
• 偏差识别提前量：相比原来依赖周会口头汇报，数据化后偏差被识别的时间平均提前了约 5 周。
• 里程碑按期达成率：H 项目从约 55% 回升到 79%（含调整后的新基线）。
• 管理者判读效率：每周用于进度判读的时间从 6 小时以上压缩到约 1.5 到 2 小时，且判读质量提升（因为看的是趋势而非快照）。

六、不同情况下的行动建议：按团队成熟度分三档

没有一种方案适合所有团队。我按"数据化成熟度"把团队分成三档，每档给出不同的起步动作。关键是先站到自己那一档，别一步跨太大。

1. 起步档：还没有任何稳定的进度数据采集

典型特征：进度判断全靠周会口头汇报，系统里任务更新率低，没有固定的进度指标。

这一档的团队不要一上来就搭大看板、不要上复杂指标。我的建议是先做三件极小的事：

1. 只选定一个指标：里程碑达成率。把每个里程碑的计划日期和实际日期记录下来。
2. 只在一个团队试点，把"任务状态变更时更新实际工时"这一个动作嵌入流程。
3. 只坚持一个节奏：每周固定一小时做一次简单判读。

坚持一个季度。这一档的目标不是分析多深，而是建立"数据动作会每周发生"这个习惯本身。习惯比方法重要得多。

2. 进阶档：有采集，但判读和纠偏弱

典型特征：系统里有数据，但管理者看完就把周报发出去，偏差出现后反应慢、动作乱。

这一档的关键是补上"判读层"和"决策层"。具体动作：

• 建立"每周四问"的固定判读节奏，形成连续记录。
• 给偏差做分类（能力型 / 资源型 / 范围型），并为每一类预设对应的纠偏动作。
• 把核心指标压缩到 3 到 5 个，分结果、过程、预测三层。

这一档最常见的失败是"只判读不决策"。前面提到过，H 项目有 7 周是"看了数据但没动作"，这一档的团队要特别警惕，判读之后必须明确"谁在什么时间做什么"。

3. 成熟档：单团队数据成熟，但跨团队协同困难

典型特征：单个团队内部进度管理得不错，但多个团队、多个产品线之间数据对不上，管理者想看全局进度只能靠人工合并。

这一档的瓶颈在工具架构和数据源分散。具体动作：

1. 评估是否有必要统一数据源，如果跨团队汇总耗时每周超过 4 小时，答案通常是有必要。
2. 选型时重点看跨团队报表能力、部署方式（是否支持私有化部署）、以及历史数据的迁移承接能力。
3. 统一后，把管理者的重点从"核对数据"转移到"判读偏差结构"。

对中大型组织（如 100 人以上、有多个职能团队协同、且有合规或数据主权要求）来说，支持私有化部署、并能从主流项目管理工具平滑迁移历史数据的平台，往往是让全局进度管理真正可落地的基础设施。选型时要确认它能承接原有的任务、工时、里程碑记录，避免出现历史数据断层，一旦历史数据接不上，趋势分析会直接从零开始。

七、不同情况下的取舍：哪些能做，哪些必须放弃

进度管理落地本质上是一系列取舍。资源、时间、范围三者不可兼得，而数据动作本身也占资源。下面是我总结的几组最常见的取舍。

1. 数据的"精细度"与"采集成本"：宁粗勿假

你当然可以要求成员记录每个子任务的开始结束时间、每个中断的原因、每段工作对应的需求编号。但采集成本会飙升，而成员会开始"为了填而填"，数据质量反而下降。

我的取舍原则是：宁要粗糙但真实的数据，不要精细但造假的记录。任务级的状态和工时已经够用，子任务级的秒表式记录，除非有特殊合规要求，不值得。

2. 指标的"全面性"与"可读性"：宁少勿滥

把所有能想到的指标都挂上看板，看似全面，实则没人看。取舍的方向是砍指标，保留 3 到 5 个最核心的，其余作为"需要时下钻查看"的存在。

判断标准很简单：这个指标每周会改变某个人做的某个决定吗？如果连续几周都不会，它就该从主看板上撤下来。

3. 工具统一与团队自主：先统一数据，再谈自主

有些组织内部各团队习惯用不同工具，强行统一会引发抵触。我的判断是分两个层次：数据模型必须统一，工具形态可以适度灵活。

也就是说，不管团队用什么方式记录，任务的"状态、工时、阻塞原因"这三个数据点的口径必须一致，才能汇总；至于具体在哪个界面录入，可以给团队一定选择空间。但如果团队间数据口径长期无法统一、汇总成本居高不下，那就得果断收敛到统一平台，这时的取舍是牺牲一部分团队习惯，换取全局可视。

4. 加人与调序：永远先考虑调序

面对偏差，管理者的直觉动作往往是加人。但软件和硬件项目中，加人的收益有很长的滞后，尤其是新人融入期，短期内甚至可能因为沟通成本上升而拖慢进度。

更常被忽视、但往往更有效的动作是"调序"，调整任务的先后顺序，把不依赖阻塞项的、能出成果的任务提前做，先把价值交付出去，让阻塞项有时间解套。调序的代价远低于加人，且见效快。只有当偏差被判定为能力型、且调序无法解决时，加人才是选项。

八、常见问题

1. 小团队（20 人以下）需要做这么细的进度数据采集吗？

不需要全套。20 人以下的团队，沟通成本低，很多信息本来就能通过面对面同步。这一档只需要抓一个数据点：里程碑达成率，以及一个过程信号：任务实际工时是否明显超预估。其余可以靠沟通补充。等团队规模上来、跨职能协同变多，再逐步补齐。

2. 用完成百分比真的不行吗？

不是绝对不行，而是不要用它做跨人汇总。在个人自己的任务层面，估算一个粗略的百分比没问题。但一旦把多个人的百分比加总成一个项目进度，误差会被放大，而且容易被凑整美化。跨人汇总请用二值状态加实际工时。

3. SPI 到底什么时候能用，什么时候不能用？

记住一个判断标准：如果项目的计划基线在过去两个月里被重设过两次以上，SPI 就不该作为主要指标。需求频繁变更的项目请改用燃尽图、累积流图等反映流动效率的指标。需求相对冻结的交付型项目才适合 SPI。

4. 数据采集会不会让团队觉得被监控，产生抵触？

这是很现实的顾虑。我的经验是三点：一是采集动作必须嵌入流程、不额外增加负担；二是采集的数据要"用起来"，让团队看到自己的输入确实改变了决策，而不是填完就沉底；三是不要用进度数据直接做个人考核，一旦考核化，数据必然造假。这三个条件缺一个，抵触就会出现。

5. 跨团队数据统一，是不是一定要换工具？

不一定，要看现有工具能否承载跨团队报表。如果现有工具本身支持多团队、多项目的统一汇总，只是没配置好，那先配置好即可。如果现有工具的数据模型就是按团队隔离、跨团队报表要人工合并，且组织规模在 100 人以上、有私有化部署等要求，那么统一到能支持这些能力的平台会更划算，同时要确认能从原有工具（如主流国际化项目管理平台）平滑迁移历史数据。

6. 判读之后没动作，问题出在哪？

通常出在三个地方：一是没预设好"偏差到什么程度、由谁做什么"的规则，导致看到偏差后没人认领；二是动作代价太高，没人愿意拍板；三是指标和动作之间没有绑定关系。解决办法是提前为每一类偏差预设好动作清单和决策人，把决策前置到"规则"层面，而不是每次临时商量。

九、总结：进度管理的关键，是让数据动作每周真实发生

写到这里，我想把整篇文章的独特观点再收一遍。市面上关于进度管理的讨论，绝大多数停在"介绍指标、讲解方法"这一层，隐含假设是数据已经可信。但真实企业里，管理者的第一难题从来不是"怎么算"，而是"怎么让每周发生的数据动作持续产生可信数据，并把偏差转换成正确类型的动作"。

我在两个脱敏项目里最大的收获是：进度失控几乎从来不是某一天突然发生的，而是在任务层积累了 5 到 6 周的趋势信号后、才在里程碑层爆发。这些信号之所以长期被忽视，是因为它们既没有被采集，也没有被放进一个每周固定发生的判读节奏里。把这两件事补上，进度管理的效果会比换任何工具、上任何方法都明显。

如果你读到这里想做点什么，我的建议是按下面的顺序走，不要跳步：

1. 先花一小时，把你当前项目里所有里程碑的计划日期和实际日期列出来，算一次按期达成率。这一步会立刻告诉你数据的可信度。
2. 再查一次任务的实际工时更新率。低于 60%，说明采集动作还没嵌入流程，优先级最高的是修这个，不是搭看板。
3. 从下周开始，固定每周一小时做"每周四问"。连续做满 6 周，再回头判断趋势。
4. 当偏差出现时，先判断它属于能力型、资源型还是范围型，再对照动作清单选择动作。优先考虑调序，其次调配资源，最后才考虑加人。
5. 如果你的组织超过 100 人、跨多个职能团队协同、且跨团队进度汇总靠人工合并超过每周 4 小时，那么认真评估一次"是否需要一个能支撑跨团队统一数据源、支持私有化部署、并能从原有工具平滑迁移历史数据的项目管理平台"。这一步是基础设施，越早做，后面所有数据动作的成本越低。

进度管理没有一劳永逸的银弹，但有一套可以让每周都发生、并且确实能改变结果的数据动作。先把动作跑起来，数据会自己告诉你哪里出了问题。