01
初步沟通
本站动作
- 听清需求背景、使用场景与期望结果，先判断需求落在哪个 服务方向 。
- 说明该方向大致的工作内容，以及本站不承接的事项，避免方向错配。
- 给出需要补充的信息清单，方便访客在下一次沟通前准备好。
访客动作
- 用一段话说清自己遇到的情况，不必先想好术语。
- 说明期望的推进节奏，以及内部有谁需要参与确认。
- 如已有资料、样例或过往记录，一并提供，能减少来回确认。
确认节点： 双方对需求方向达成一致，并明确下一步要补充哪些信息。若需求不在服务范围内，此阶段直接说明并给出替代建议。
合作流程：从初步沟通到交付确认的推进步骤
这一页把合作拆成四个阶段，写清每个阶段本站做什么、访客需要配合什么、在哪个节点需要确认。看完之后，你可以对照自己的情况，先把该准备的资料理一遍。
合作流程阶段总览
四个阶段按顺序推进，前一个阶段的确认结果决定后一个阶段怎么展开。阶段名称在全站保持一致，服务方向与交付标准页也沿用这套划分。
-
01
初步沟通
说明需求背景与大致期望，判断是否属于本站服务方向。
-
02
需求确认
把模糊描述整理成可核对的需求条目，明确范围与边界。
-
03
方案与排期
按确认后的需求确定工作内容、推进顺序与核对方式。
-
04
执行与交付
按方案推进工作，完成后按交付标准逐项核对并反馈。
各阶段双方动作与确认节点
每个阶段都分成两栏：本站负责推进的动作，以及需要访客配合的动作。阶段结束前会有一个确认节点，确认通过再进入下一阶段。
02
需求确认
本站动作
- 把口头描述整理成条目化的需求清单，逐条写明要做什么。
- 标注哪些属于服务范围内、哪些需要访客自行处理，边界写在同一份清单里。
- 对表述含糊的条目提出具体问题，直到可以判断完成与否。
访客动作
- 逐条核对需求清单，确认理解没有偏差。
- 指出清单里遗漏或多余的条目，越早提出改动成本越低。
- 确认最终由谁拍板，避免多人意见在后期反复。
确认节点： 需求清单定稿。此后的范围调整按新增需求处理，重新走一次确认。
03
方案与排期
本站动作
- 按需求清单拆分工作内容，标明先后顺序与相互依赖的部分。
- 说明每个环节结束后按什么标准核对，与 交付标准 保持一致。
- 列出需要访客在特定时点提供的资料，避免中途等待。
访客动作
- 确认工作内容与自身预期一致，特别是容易忽略的边界部分。
- 核对需要自己提供资料的时间点，提前安排内部配合。
- 对排期顺序提出意见，例如某些部分需要优先推进。
确认节点： 工作内容、推进顺序与核对方式三方确认，进入执行阶段后按此推进。
04
执行与交付
本站动作
- 按确认后的顺序推进工作，中途遇到与需求清单不符的情况先说明再处理。
- 交付前按标准逐项自查，把核对结果一并说明。
- 对反馈的问题给出处理方式，属于范围内的直接修正。
访客动作
- 按约定时点提供资料，或提前说明延迟情况。
- 收到交付内容后逐项核对，把问题集中在一次反馈里。
- 确认验收结果，明确哪些已完成、哪些需要继续处理。
确认节点： 验收确认。核对通过即视为本阶段完成；需要返工的部分按 返工情形说明 处理。
合作前需要准备的信息清单
这三组信息准备得越完整，需求确认阶段来回沟通的次数越少。没有现成文档也没关系，按组整理成几条要点即可。
需求信息
- 当前遇到的具体情况，以及希望改善到什么程度
- 需求涉及的业务范围，是一件事还是一整条流程
- 已经尝试过的做法和效果，避免重复走同一条路
- 希望优先解决的部分，便于安排推进顺序
资料信息
- 与需求相关的现有文档、记录或样例
- 内部已有的规范、格式要求或既有标准
- 需要保持一致的历史内容，避免前后冲突
- 资料可提供的范围，以及不能外传的部分
时间信息
- 希望什么时候开始推进，以及是否有硬性时点
- 内部审阅和确认大概需要多久
- 关键参与人何时方便参与沟通
- 是否存在需要避开的时间段
阶段推进中的常见卡点与处理方式
下面几种情况在推进中出现得比较频繁，提前知道处理方式，遇到时不必反复讨论。
-
需求描述停留在感受层面
“不太满意”“感觉不对”这类描述无法直接核对。处理方式是把它转成具体问题：哪个部分不符合预期、换成什么样才算合适、有没有可参照的例子。转成条目后再进入需求确认。
-
参与人意见不一致
多方意见在需求确认阶段就应摆到同一份清单上。处理方式是先明确最终确认人，其余意见作为参考记录，避免在执行阶段出现两套标准同时生效。
-
资料迟迟无法提供
缺少关键资料会打断推进节奏。处理方式是把可以先行开展的部分先做，需要资料的部分挂起并标明依赖项，资料到位后按原顺序接上。
-
中途新增需求
新增内容不直接插入正在推进的部分。处理方式是记录为独立条目，评估是否影响已确认内容，再决定是并入当前阶段还是单独安排。