常见问题

先看你要解决的是哪一类问题：是范围界定不清、执行环节缺人、还是已有产出需要按标准核对。每组服务的适用对象在 服务矩阵 里都写明了典型需求，对照着看通常能定位到最接近的一组。如果同时落在两组之间，不必急着二选一，说明清楚两边的诉求，由双方一起判断主次。

可以。需求确认阶段本来就是用来把模糊想法收敛成明确范围的，不需要等全部想清楚再开口。带上你已经确定的部分——比如要覆盖的环节、大致时间预期、内部必须参与的岗位——剩下的部分在沟通中逐步补齐。反过来，如果连要解决的问题都还没定，建议先内部讨论一轮再来。

基础的是三类：一是你现在的做法和遇到的问题，二是期望达成的结果，三是内部能投入的配合资源。如果涉及已有的文档、数据或历史记录，先整理成可查阅的形式即可，不必提前加工。启动前需要确认的事项在合作流程页的启动前准备清单里有逐条列出，可以对照检查。

不会在未确认的情况下扩大。范围以双方确认的需求说明为准，沟通中如果发现原定范围之外还有必要补充的内容，会先说明影响再决定是否纳入，而不是直接加进执行。这一点在 服务边界说明 里也有对应表述。

建议先内部对一遍，把重叠的部分合并、冲突的部分标出来。带着一份统一的诉求来沟通，比各部门分别提一轮效率高得多，也能避免执行阶段反复调整方向。如果内部确实难以统一，把分歧点明确列出来，也是有效的信息。

按阶段划分：需求确认和方案对齐阶段以你方提供信息、我方整理成文为主；执行交付阶段以我方推进为主，但需要你方在约定的节点上确认；验收复盘阶段双方共同核对。每个阶段的具体分工在合作流程页有对应说明，不需要在执行中临时商定。

越早提出越好。在方案对齐阶段调整，成本最低；进入执行后再调整，需要重新评估对已产出内容的影响。提出时建议说明调整的原因和期望结果，而不是只描述现象，这样能更快判断是否需要重新走一遍对齐。

在方案对齐阶段确定，通常按阶段产出节点安排同步，而不是固定每天或每周。节点同步的好处是每次都有明确要确认的内容，避免为沟通而沟通。如果执行中遇到需要即时判断的问题，按双方约定的方式直接提出即可。

会影响，所以建议在方案对齐时就把内部审批环节的时间预留出来，写进整体节奏里。如果审批流程较长，可以提前说明，把需要审批的内容集中处理，减少零散等待。提前告知比中途发现延误更容易安排。

先判断是否属于原定范围。属于范围内的，按原计划推进；超出范围的，先说明对进度和产出的影响，双方确认后再决定是否纳入本轮还是留到下一轮。不确认就动手，容易在验收时产生口径分歧。

按双方在方案对齐阶段确认的交付内容清单和质量核对要点逐条比对。标准是事先写明的条目，不是验收当天临时商定的印象。如果某一条在确认时没有写清楚，验收时就以该条的实际约定内容为准，必要时补充确认。

先对照清单确认是遗漏、偏差还是理解差异。遗漏和偏差按偏差处理流程走，理解差异则回到确认过的需求说明核对。把具体条目和实际产出一起列出来，比笼统说不符合预期更容易定位问题。

可以提出，但需要区分是修正偏差还是新增需求。属于修正偏差的，按原定标准处理；属于新增的，作为新一轮需求重新确认范围。验收不是终点，而是把当前这一轮的口径固定下来。

按交付物类别区分形式，文档类以可查阅的文件提交，清单类以条目化形式提交，说明类以书面说明提交。具体形式在交付标准页的交付物形式说明里有对应描述，验收前可以先对照确认接收方式。