第2章 · Solution Design 协同目标与角色职责

2.1 适用场景

Solution Design 协同发生在以下典型场景中，产品经理（PM）与解决方案架构师（SA）需同步对齐，避免需求理解偏差与设计断层：

• 跨系统/跨域功能定义 —— 功能边界涉及多个下游系统或外部平台，需 SA 评估集成可行性与数据流向。
• 高复杂度业务规则落地 —— 业务逻辑含多层判断、状态机或长周期编排，需 SA 提前识别技术约束。
• 非功能性需求决策 —— 性能、安全、可扩展性等非功能指标影响功能边界剪裁，需 SA 提供量化建议。
• 产品路线图与架构演进交汇 —— 功能上线节奏需匹配架构重构或技术债务清偿计划。
• 对外输出 Solution Design 文档 —— 研发团队启动开发前，PM 与 SA 必须完成协同评审并签署基线。

2.2 前置条件

2.3 操作步骤

PM 与 SA 的协作遵循 五步对齐模型，每一步均产出可追溯的决策记录：

1. Step 1 · 需求映射（PM 主导）
   将 PRD 中的用户故事逐一映射到系统上下文，标记“不确定”或“有冲突”的区域。
2. Step 2 · 技术预评估（SA 主导）
   对每个功能点给出技术可行性判断：可行 / 有条件可行 / 不可行，并注明约束原因。
3. Step 3 · 边界剪裁协商（PM + SA 共同）
   基于技术预评估结果，调整功能边界：拆分、降级、延期或替换方案。
4. Step 4 · Solution Design 骨架生成（SA 主导）
   输出包含核心模块、接口契约、数据流的 Solution Design 骨架（v0.8）。
5. Step 5 · 协同签署（PM + SA 共同）
   确认功能边界与设计骨架一致，在 RACI 矩阵上签字，进入研发排期。

2.4 协作模式框架图

下图展示 PM 与 SA 在 Solution Design 阶段的协作流程、角色边界及 RACI 映射关系：

2.5 输入输出物清单

2.6 责任边界与 RACI 矩阵模板

以下 RACI 矩阵明确 PM 与 SA 在每项活动中的角色：R（执行）、A（问责）、C（咨询）、I（知会）。

2.7 记录材料模板

每次协同会议必须记录 协同决策日志，格式如下：

【协同决策日志 · 第2章】
日期：YYYY-MM-DD
版本：v1.0
参与人：PM [姓名] / SA [姓名]

--- 议题清单 ---
1. [功能ID] 实时风控指标聚合边界
   - 分歧点：SA 提出单节点无法支持 1000 TPS
   - 决策：降级为近实时（批处理 5s 窗口），PM 确认业务可接受
   - 责任人：PM 更新 PRD，SA 更新设计骨架

2. [功能ID] 外部商户数据导入接口
   - 分歧点：数据格式标准未对齐
   - 决策：采用 CSV + JSON Schema 双格式，SA 提供 schema 定义
   - 责任人：SA 产出 schema，PM 同步给商户团队

--- 待办事项 ---
- PM 在 2 个工作日内更新 PRD 对应章节
- SA 在 3 个工作日内产出 SD 骨架 v0.9
- 下次复核会议：YYYY-MM-DD

2.8 异常处理

2.9 验收标准

第 2 章协同工作完成时，需满足以下验收条件：

• 标准 1 · 完整性 —— 所有前置条件物（PRD v0.5、语境图、NFR 检查表、约束矩阵）已归档至共享知识库。
• 标准 2 · 一致性 —— 五步对齐模型的每一步均有对应的输出物，且版本号连续可追溯。
• 标准 3 · 可读性 —— 协同决策日志包含至少 1 个分歧点及其决策理由，无空白待办项。
• 标准 4 · 签署完整性 —— RACI 矩阵中所有 A 角色均已签字确认，签署版 SD 骨架已上传至文档管理平台。
• 标准 5 · 异常清零 —— 2.8 节所列异常场景若发生，必须有关闭记录；未发生的异常需在日志中标注 “本次未触发”。