从需求确认到交付验收的推进节点

• 需求描述停留在目标，没有说明现状

  只说想要什么结果，容易让范围不断膨胀。处理方式是先补充现状说明：现在是怎么做的、卡在哪一步、哪些做法已经试过。现状写清楚，范围自然收窄。

• 对接人变动导致信息断层

  中途更换对接人时，之前的确认结论容易被重新讨论。处理方式是把每个阶段的输出保留成可查阅的记录，新对接人先读记录再提意见，避免重复确认。

• 中间成果反馈积压到最后

  所有意见都留到验收时集中提出，修改成本会明显上升。处理方式是在执行推进阶段就按节点反馈，每个中间成果给出通过或修改的明确结论，不把问题攒到最后。

• 把不包含项当成遗漏项

  不包含项是提前写明的边界，不是执行中的疏漏。处理方式是在范围对齐阶段逐条确认不包含项，如果确实需要，作为新的范围单独讨论，不影响当前阶段的推进。

如果卡点与自身业务场景的判断有关，可以先看 行业场景索引 ；如果属于合作前的疑问， 常见问题 里按类别给出了回答。