4. 功能边界识别步骤（第1步
4.1 适用场景
- 新产品立项阶段，需要明确数据产品要解决的业务问题域。
- 现有数据产品需要重构或合并，避免功能重复或缺失。
- 跨部门协作时，统一对业务目标的认知，减少后续需求变更风险。
- 从零开始设计数据产品Solution Design前，必须完成的目标映射。
4.2 前置条件
| 条件 | 说明 |
|---|---|
| 业务愿景文档 | 已获得高层或业务方明确的数据驱动目标描述。 |
| 干系人清单 | 包含业务Owner、产品经理、技术负责人、数据工程师。 |
| 现有系统梳理 | 了解已有数据采集、存储、分析工具的边界。 |
| 组织可用资源 | 确认参与解构工作坊的人员时间与协作工具。 |
4.3 操作步骤
- Step 1: 业务核心陈述
与业务方共同用一句话描述“希望通过数据产品实现什么”。例如：“提升用户留存率5个百分点”。 - Step 2: 用户故事映射 (User Story Mapping)
将核心陈述分解为不同用户角色的活动，按时间顺序排列用户故事卡片。 - Step 3: 目标拆解树 (Goal Decomposition Tree)
从顶级业务目标向下逐层拆解为可量化的子目标、指标、数据需求。 - Step 4: 产出交付物
输出《业务目标解构画布》与《目标拆解树》，并标注每个叶子节点的输入物来源。
技巧：用户故事映射中的“故事”不要超过15个，否则后续功能边界会过度碎片化。优先选取最高频、最核心的用户旅程。
4.4 输入输出物
| 类型 | 名称 | 格式/载体 |
|---|---|---|
| 输入 | 业务愿景文档 | PDF 或 关键纪要 |
| 输入 | 干系人访谈记录 | 结构化笔记 |
| 输出 | 用户故事映射板 (USM) | 在线白板截图或 Excel |
| 输出 | 目标拆解树 (GDT) | 思维导图 或 SVG |
| 输出 | 数据需求清单 | 表格 (字段、来源、频率) |
4.5 责任边界
- 产品经理 (PO)：主导用户故事映射，保证故事覆盖核心业务活动。
- 数据架构师：负责目标拆解树中“数据可行性”校验，指出无法量化的节点。
- 业务Owner：提供业务目标陈述并确认拆解结果的正确性。
- 开发代表：记录每个叶子节点的技术约束（如数据延迟、接口限制）。
4.6 记录材料
- 《用户故事映射卡片》：包含故事ID、用户角色、活动描述、优先级。
- 《目标拆解树附件》：每个节点对应的业务术语解释，避免后续歧义。
- 《解构工作坊纪要》：记录关键讨论、争议点与最终共识。
模板参考：目标拆解树每个节点建议记录
节点ID / 目标名称 / 量化指标 / 数据源 / 验收标准。
4.7 异常处理
| 异常场景 | 处理方式 |
|---|---|
| 业务目标模糊，无法一句话概括 | 采用“5W1H”追问法重新定义，直到产出可衡量的陈述。 |
| 用户故事与目标拆解树出现矛盾 | 停止拆解，返回 Step 2 修正故事映射，确保上下一致。 |
| 缺乏数据源支撑的子目标 | 标记为“待探索”，不纳入当前功能边界，需进入技术预研。 |
| 干系人意见分裂 | 设置决策截止时间，由业务Owner 做最终裁决，并记录在《解构工作坊纪要》中。 |
4.8 验收标准
- 目标拆解树已包含至少3层节点，且每层都有明确量化指标。
- 用户故事映射覆盖了至少80%的核心用户活动。
- 所有叶子节点都关联了已存在的或可采购的数据源。
- 输出物通过干系人评审，没有未关闭的异议。
常见误区：将“业务目标解构”做成纯需求收集，而不是功能边界界定的起点。解构阶段要敢于删除“想要但不必需”的故事节点，否则后续Solution Design会超载。