为什么有些项目永远“马上就做完”？警惕最后 10% 变成资源黑洞

项目经理说：“差不多了，再两天。”两天以后，群里又来了消息：“主要功能已经好了，再把几个问题处理一下。”

下周，客户提了几处修改，开发再支持一下。再下一周，项目已经上线，测试和实施还要跟几天。每次理由都说得通，每次看起来也没有严重到需要重新立项。

这是一个假设的项目场景。一个月、两个月过去，开发、测试、项目经理和实施人员仍然隔三差五被拉回来。排期上他们早已转去别的项目，实际工作却始终没有完全离开这个项目。

此时值得追问的不是下一次承诺有多可信，而是：这个项目到底从哪一天开始“快做完”的？从那一天到今天，又额外投入了多少资源？

项目未必突然失控。更隐蔽的情况是，每一次都只差一点，每一次追加都不多，每一次延期都有合理理由。两天、三天、半周、一个测试轮次、一次客户修改，不断累积，等到回头看时，已经形成了另一段不小的项目投入。

为什么“马上做完”会持续很久？

项目进入尾声，剩余工作往往从几块明确的功能，变成很多零碎事项：Bug、边界情况、客户反馈、数据处理、环境差异、上线问题、临时修改、交付材料和验收确认。单看任何一项，可能都不像一项大工程。

负责开发的人说代码改好了，测试的人还要验证；测试通过，客户还要确认；客户确认，实施还要迁移数据；上线以后，又暴露出只在真实环境出现的问题。一个角色完成自己的环节，不能直接代表整个交付链已经结束。

组织很容易形成这样的判断：大头都做完了，再投入一点就能结束。这个判断有时确实成立，问题在于它可能连续出现很多次。每次只解决眼前的障碍，却没有把后续依赖和验证工作一起算进去。

所谓“最后 10%”在这里是对收尾阶段的形象表达，并不是测量出来的固定比例。功能清单完成得很多，也不意味着测试、交付和验收只剩同样比例的投入。用一个笼统的百分比代替剩余工作清单，很容易让完成时间看起来比实际更近。

最容易被忽略的，是一次次“小额追加”

如果项目突然要求增加三个人做一个月，管理层通常会追问：增加的范围是什么？为什么原计划不够？哪些其他项目要让路？

换成“开发再帮两天”“测试再跟三天”“项目经理再协调半周”，大家就容易接受。请求很小，解释也具体，单次审批的心理成本很低。为了两天工作重新讨论预算和优先级，似乎还不如先把问题处理掉。

但项目成本是累计值。上一次的两天不会因为下一次又只要两天而消失。开发的投入之外，还有复测、沟通、部署、交接和验收人员的时间。只盯着申请里最显眼的那个人，账面上就会持续低估项目仍占用的资源。

还有一类影响不会直接出现在追加申请里：关键人员被旧项目临时叫回，新项目的评审、测试或交付就要重新协调。不能凭感觉把这种影响折算成精确损失，但必须让相关项目负责人知道，原先承诺的人员安排已经发生变化。

为什么大家一直觉得，这次真的快结束了？

剩余范围在变，名字却一直叫“收尾”

一开始的收尾是修复已知问题，后来变成客户调整，再后来包含一项原本没承诺的报表。每次新增的事项都小，于是继续挂在“最后几个问题”下面。剩余范围已经改变，项目状态和管理判断却没有同步改变。

不能把所有新问题都当成新增需求。原范围内的缺陷、必要的交付工作、合同约定的支持，与新增功能，应当分别核对。关键是说清它属于哪一种、由谁确认、是否改变完成边界，而不是用“收尾”这个词把差异盖过去。

估算的是当前问题，没有重估整个剩余工作

“这个 Bug 两天能改完”回答的是修复时间，不一定包括回归测试、发布窗口、客户验证和交付材料。当前问题解决后，下一环节才暴露出另一个问题，于是又给出新的两天。

如果每次只看最新一张问题单，负责人可能每次都认真估算，却仍然连续低估整体。此时需要把已知工作、依赖事项和仍未验证的风险放在一起，重新看完整的剩余路径。

已经投入很多，更难接受重新决策

“前面都做了这么多，再给一点时间就能交付。”这种想法很容易理解，也可能包含沉没成本倾向：为了不让过去的投入看起来白费，继续接受新的追加。但过去投入很多，并不能单独证明下一次投入值得。

这也不能解释所有问题。验收口径不清、外部依赖未就绪、负责人没有决定范围的权限，都可能让项目持续拖尾。应当核对具体障碍，而不是把责任简单归到团队“不愿放弃”。

更根本的问题是缺少退出条件。如果没有说明什么状态算完成、哪些事项可以转入后续支持、超出什么边界需要重新决策，那么新的工作总能找到留在原项目里的理由。

一个“最后 10%”，可能怎样累计出另一段投入

以下为示意案例，不对应真实客户。假设一个项目第一次宣布“再处理几个问题就结束”后，陆续发生了五次追加。表中的人天是各角色实际投入的合计，不是日历上过去了几天。

2 + 3 + 4 + 5 + 4，累计是 18 人天。没有哪一次看起来特别严重，但它已经不能只用“再帮两天”来解释。这里没有推算工资、利润或精确财务损失，只展示小额投入如何累积。

人天也不等于延期天数。两名成员同一天各投入一个完整工作日，合计是两个人天；有人每天只支持一小段时间，也可能跨几周累计。汇总时应使用团队一致的换算口径，同一笔时间不能同时算进开发和上线支持两处。

如果这 18 人天换来了清晰的验收结果，它可能是有必要的追加。如果完成边界仍在后移，下一轮又只剩“几个问题”，就需要重新判断。数字提醒管理者回看，不会自动替管理者作出停止决定。

哪些信号说明，项目正在持续吞噬资源？

本文用“项目黑洞”形容一种管理现象：项目持续吸收时间、人力和预算，完成边界不断后移，新增投入与可见成果越来越难建立清晰关系。它不是正式项目管理标准中的严格专业术语，也不是对所有延期项目的判定。

• 预计完成时间连续多次只往后推一点，汇报里反复出现“再两天”“最后一轮”“再一周”。
• 同一批关键人员不断被临时拉回，原定释放时间已经失去安排工作的意义。
• 新增功能或客户调整仍被叫作“收尾”，没有单独确认范围和接受条件。
• 项目很少重新评估全部剩余工作，只为新出现的问题分别估算。
• 没人能说清从第一次宣布“快结束”以后，又投入了多少人天。
• 新增投入对应的交付物、关闭的问题或验收结果越来越难说明。
• 项目没有明确的继续、缩范围、暂停或结束决策节点。

一个信号不一定意味着项目已经失控。必要的上线保障可能持续一段时间，外部验收也可能等待。区别在于：工作范围是否清楚、投入是否可回看、责任是否有人承担、下一次决定何时发生。只要这些仍然明确，尾声较长也可以管理；反过来，“已上线”也不能自动证明资源已经释放。

管理者要问的，不只是“还差几天”

一次收尾评审可以很短，但应当把几个问题问具体：还剩哪些工作，每项由谁负责，完成证据是什么？如果不追加资源，会影响哪项交付承诺，是否有替代处理？这次继续投入，是为了验收、降低上线风险，还是满足新提出的范围？

接着确认：这一次追加以后，什么条件算完成？如果再次没有完成，下一步由谁决定继续、缩范围、延期、暂停或结束？如果这些答案仍然是“先试试看”，追加申请就还没有形成可检查的计划。

讨论时也要区分已知工作与不确定事项。例如，数据核对尚未完成，就不能把它写成“没有问题”；客户还未确认口径，就应保留这项依赖，并写明确认人和时间。承认不确定性，比再次给一个没有依据的两天更有助于安排资源。

怎样让最后一段工作有明确边界

把必须完成、可以延期、可以取消拆开

重新列出剩余范围，把影响既定验收或必要风险控制的事项，与可放入后续版本的改进分开。哪些可以延期、取消或单独立项，要由有权限的负责人和相关方确认，不能由开发人员为了按时结项自行删掉交付承诺。

对客户新提出的调整，说明它与原范围的关系、需要的投入及对完成时间的影响。小需求也可以被接受，但接受以后应留下新的范围约定，避免下一轮仍按旧承诺判断。

重新估算完整的剩余路径

不只估当前 Bug，还要覆盖修复、复测、数据处理、部署、客户确认和交付材料。对外部依赖和未验证事项单独说明，给出估算依据与需要核对的条件，不把所有未知都藏进一个“预计两天”。

负责人需要组织相关角色共同确认，而不是把各自口头给出的天数简单相加。部分工作可以并行，部分必须等待，人员投入和日历工期应分别说明。

让每次追加同时带着累计数

追加申请不必变成复杂表单，可以同时写清本次目的、预期投入、收尾起点后的累计投入、目标成果和回看日期。这样批准的是有边界的下一段工作，也能看见这段工作处在怎样的累计消耗之中。

若历史记录不完整，应说明已确认投入覆盖哪些人员和期间，缺失部分由谁补充。不要为了凑出漂亮的总数而凭记忆编造精确人天。

把完成条件和后续支持分开

“功能基本好了”过于模糊。可按实际约定说明：必要问题已处理并验证，数据已核对，交付材料已确认，验收责任人已接受，剩余事项已有去向。这是完成条件的示例，具体要求应以项目范围和承诺为准。

结项后的支持若仍有必要，应明确支持内容、期间、负责人及资源安排。不能靠把状态改成“完成”就让投入消失，也不能把后续所有需求无限留在旧项目里。

触及约定边界，就重新决策

团队可以事先约定：累计追加达到什么程度、完成日期连续变更到什么情况，或关键验收条件发生什么变化，就必须重新评审。阈值应结合项目规模、风险和承诺设定，不存在适合所有项目的统一次数或人天上限。

到达节点后，比较继续投入、缩小范围、调整日期、暂停和结束的影响。暂停或结束也要处理交接、合同义务和必要支持。重新决策的价值是让选择有依据、有责任人，而不是让团队遇到难题就停止。

工时数据在这里，应该回答什么问题？

当管理者开始回看累计追加，稳定的工时记录才有明确用途：这个项目实际持续占用了哪些人？每个阶段增加了多少投入？从第一次说“快结束”以后，累计又消耗了多少人天？同一批人员原定参与的其他项目，是否因此需要调整安排？

记录可以围绕项目、人员、日期、实际时长和必要的工作说明展开。收尾起点要保留依据，例如一次阶段评审的记录；后续范围变更和验收结果也要能对上。这样汇总出的投入，才有机会解释为什么增加、增加之后解决了什么。

工时在这里记录的不是“谁干得快”，而是“这个项目到底还在持续吞掉多少资源”。不能把投入多直接解释成效率低，也不能把投入少解释成工作不认真。工作难度、质量、协作和外部依赖，都需要另外核对。

工时只能说明已发生的时间投入，不能单独证明项目完成度、未来还需多少天或下一次追加是否值得。要判断其他项目受到什么影响，还需要排期、任务状态和相关负责人的确认。数字与项目事实一起使用，才能支持资源判断。

面对下一次“再支持两天”，管理者可以要求负责人拿出剩余清单、累计投入和本轮完成条件。继续投入有清晰目标，就按新的边界执行；完成边界仍说不清，就先把范围和决策责任谈清楚。项目能否结束，不能始终只靠下一次口头承诺。