01
场景确认
参与方
- 提出需求的一方，负责说明现状与目标
- 了解服务方向的对接人，负责判断落在哪一类方向
- 实际使用或受影响的角色，负责补充真实场景细节
产出物
- 一份场景描述，写清问题、涉及角色与期望状态
- 对应的服务方向归类，明确后续看哪一类说明
- 需要进一步确认的问题清单
合作流程
合作流程说明：从场景确认到交付验收的四个阶段
一次合作推进被拆成四个阶段，每个阶段都有明确的参与方、产出物和判断是否继续的条件。先看自己现在处在哪一段，再决定这一步该准备什么、该确认什么，比笼统地问“能不能做”更省时间。
四阶段流程展开
场景确认、方案对齐、执行推进、交付验收依次推进。阶段之间不是走过场，每一步都留下可核对的产出物，后一阶段的起点就是前一阶段确认过的结论。
-
阶段 01
场景确认
先把要解决的问题说清楚：现在卡在哪一步、涉及哪些人、期望达到什么状态。这个阶段不急着谈方案，重点是把模糊的需求还原成具体场景，判断它落在哪一类服务方向上。
-
阶段 02
方案对齐
根据确认的场景，把可做的范围、推进节奏和分工讲明白。哪些现在能做、哪些要分步做、哪些不在范围内，都在这一步说清楚，避免执行到一半才发现理解不一致。
-
阶段 03
执行推进
按对齐后的节奏推进具体工作，过程中保持信息同步。遇到与原计划不一致的情况及时调整，而不是攒到最后一起暴露，让问题在还能改的时候被处理掉。
-
阶段 04
交付验收
对照事先约定的验收标准逐项核对交付内容，确认无误后完成收尾。验收依据在方案对齐阶段就已明确，不临时加码，也不含糊带过。
每阶段的参与方与产出物
每个阶段谁参与、最后留下什么，提前写清楚，协作时就不容易互相等。产出物是阶段结束的标志，也是下一阶段的输入。
02
方案对齐
参与方
- 方案拟定方，负责给出可执行的范围与节奏
- 需求决策方，负责确认范围与优先级
- 执行协作方，负责确认分工与时间安排
产出物
- 一份对齐后的范围说明，含做与不做的边界
- 推进节奏与各阶段时间点
- 验收标准的初步约定
03
执行推进
参与方
- 执行方，负责按节奏推进具体工作
- 需求方对接人，负责同步信息与反馈
- 相关协作角色，负责在需要时提供支持
产出物
- 阶段性进展记录，说明已完成与待处理
- 过程中调整项的说明与原因
- 接近交付前的自检结果
04
交付验收
参与方
- 交付方，负责说明交付内容与依据
- 验收方，负责逐项核对是否达标
- 使用方，负责确认实际可用性
产出物
- 交付条目核对结果
- 验收标准对照结论
- 遗留问题与后续处理说明
阶段常见障碍与支持方式
卡住的地方往往不在技术，而在信息没说全或预期没对齐。下面几条是推进过程中反复出现的障碍，以及对应的处理方式。
-
需求描述太笼统
只说“想优化一下”，很难判断从哪下手。支持方式是先用几个具体问题把场景问细，落到谁在用、卡在哪、希望变成什么样。
-
参与角色缺位
决策的人和执行的人不在同一场沟通里，结论容易反复。支持方式是提前列出每阶段需要的角色，缺谁就补谁。
-
范围理解不一致
一方以为包含某项工作，另一方以为不包含。支持方式是在方案对齐阶段把做与不做的边界写进范围说明，逐条确认。
-
进度反馈滞后
问题攒到最后才暴露，改动成本高。支持方式是执行阶段保持固定节奏的信息同步，出现偏差及时说明。
-
验收标准模糊
交付时才发现双方对“完成”的理解不同。支持方式是把验收依据提前写清，交付前先自检一遍。
-
范围外需求临时插入
推进中冒出新需求，打乱原有节奏。支持方式是先记录再评估，确认是否纳入本轮，还是放到后续单独处理。
进入下一阶段前的核对清单
每个阶段收尾时对照这几条过一遍，能减少返工。清单不复杂，关键是逐条确认而不是凭印象跳过。
