name: 价值链映射 description: 从用户需求到底层组件映射价值链 allowed-tools: Read, Glob, Grep, Write, Edit

价值链映射技能

从用户需求到底层组件映射价值链，作为Wardley Maps的基础。

何时使用此技能

使用此技能当：

价值链映射任务 - 处理从用户需求到底层组件的映射任务
规划或设计 - 需要价值链映射方法的指导
最佳实践 - 希望遵循既定模式和标准

强制：文档优先方法

在映射价值链之前：

调用docs-management技能获取价值链模式
通过MCP服务器验证映射方法（如perplexity）
基于Wardley的价值链分解作为指导

价值链基础

价值链 = 通过依赖连接的组件

用户需求
    │
    ▼
┌─────────────────┐
│ 组件A           │ ◄── 对用户可见
└────────┬────────┘
         │ 依赖于
         ▼
┌─────────────────┐
│ 组件B           │ ◄── 较少可见
└────────┬────────┘
         │ 依赖于
         ▼
┌─────────────────┐
│ 组件C           │ ◄── 对用户不可见
└─────────────────┘

关键原则：
- 从用户需求开始（锚点）
- 向后工作到依赖
- 更高 = 对用户更可见
- 更低 = 更不可见（基础设施）

步骤1：识别锚点（用户需求）

好与坏的锚点

好锚点（需求）：
✓ "我需要与团队沟通"
✓ "我需要处理客户付款"
✓ "我需要可靠地部署软件"
✓ "我需要了解客户行为"
✓ "我需要管理我的财务"

坏锚点（解决方案）：
✗ "我需要Slack"
✗ "我需要Stripe"
✗ "我需要Kubernetes"
✗ "我需要Google Analytics"
✗ "我需要QuickBooks"

测试：需求是否可以通过多种方式满足？
如果绑定到特定解决方案，你有一个解决方案，而不是需求。

锚点识别问题

寻找用户需求：

WHO问题：
- 用户是谁？
- 谁从中受益？
- 我们在为谁服务？

WHAT问题：
- 他们想要什么结果？
- 他们在解决什么问题？
- 他们获得什么价值？

WHY问题：
- 他们为什么需要这个？
- 这对他们为什么重要？
- 他们为什么会为此付费？

测试问题：
- 这是一个能力还是解决方案？
- 这个能否以不同方式满足？
- 底层的工作待完成是什么？

步骤2：分解为组件

分解方法

分解过程：

开始：用户需求
问："满足这个需求需要什么？"
答：组件列表（第一层）

对每个组件：
问："这个依赖什么？"
答：子组件列表（下一层）

重复直到达到：
- 商品（电力、带宽）
- 标准服务（云计算）
- 众所周知的基础设施

停止当：
- 组件是真正的商品
- 进一步分解没有战略价值
- 已达到常见行业基础设施

组件识别清单

对每个潜在组件：

□ 它是一个能力（不仅仅是活动）吗？
□ 它是否对上面的东西提供价值？
□ 它可以独立演化吗？
□ 它是否有可识别的演化阶段？
□ 你能指出谁/什么提供它吗？

组件边界：
- 应该是内聚的（单一职责）
- 应该有清晰的接口
- 应该是可管理单元
- 应该与兄弟组件有意义地不同

步骤3：建立依赖

依赖类型

依赖关系：

需要（硬依赖）
组件A ───► 组件B
"A没有B无法运作"

示例：API服务 ───► 数据库

使用（软依赖）
组件A - - ► 组件B
"A使用B但可以使用替代品"

示例：应用 - - ► 日志服务

启用（反向依赖）
组件A ◄─── 组件B
"B启用/增强A"

示例：分析 ◄─── 用户界面

依赖规则

依赖原则：

1. 方向
   - 依赖沿价值链向下流动
   - 更高组件依赖更低组件
   - 用户在顶部，基础设施在底部

2. 可见性相关性
   - 更接近用户需求的组件 = 更可见
   - 更远离用户的组件 = 更不可见
   - 依赖深度 ≈ 不可见性

3. 多重依赖
   - 组件可以依赖多个其他组件
   - 创建链中的复杂性
   - 注意关键路径依赖

4. 循环依赖
   - 应该很少/避免
   - 可能表示分解不佳
   - 可能导致分析瘫痪

步骤4：验证价值链

验证清单

价值链验证：

完整性
□ 链是否从用户需求开始？
□ 是否捕获所有关键依赖？
□ 链是否达到商品级别？
□ 没有孤立组件（断开连接）？

准确性
□ 依赖是否反映现实？
□ 可见性排序是否正确？
□ 组件边界是否适当？
□ 是否匹配实际工作流程？

有用性
□ 粒度是否适合目的？
□ 能否将组件定位在演化轴上？
□ 是否揭示战略洞见？
□ 能否从此链做出决策？

常见验证问题

需要注意的问题：

太浅
症状：少层级，大组件
修复：多问"这个依赖什么？"几次

太深
症状：多层级，琐碎组件
修复：合并组件，专注于战略项目

缺失组件
症状：依赖中有缺口，魔法跳跃
修复：追踪实际工作/数据流

解决方案偏见
症状：组件是产品，不是能力
修复：重构为"这个提供什么能力？"

活动混淆
症状：组件是动词，不是名词
修复：活动不是组件；能力是

价值链模式

常见模式

标准价值链形状：

线性链
用户需求
    │
    ▼
[A] → [B] → [C] → [D]
简单，顺序依赖

分支链
用户需求
    │
    ├──► [A] → [C]
    │          ↓
    └──► [B] → [D] → [E]
满足需求的多个路径

汇聚链
用户需求
    │
[A]─┴─[B]
    │
    ▼
   [C]
    │
   [D]
多个组件汇入一个

平台链
用户需求
    │
    ▼
   [A]
    │
┌───┼───┐
▼   ▼   ▼
[B][C][D]
    │
    ▼
  [平台]
共同平台在下方

领域特定示例

电子商务价值链：

用户需求："在线购买产品"
    │
    ├── 产品发现
    │       ├── 搜索
    │       ├── 目录
    │       └── 推荐
    │
    ├── 购物体验
    │       ├── 购物车
    │       ├── 愿望清单
    │       └── 定价
    │
    ├── 结账
    │       ├── 支付处理
    │       ├── 税费计算
    │       └── 地址验证
    │
    └── 履约
            ├── 库存
            ├── 运输
            └── 通知
                    │
                    ▼
            [云基础设施]

SaaS应用价值链：

用户需求："协作管理项目"
    │
    ├── 用户管理
    │       ├── 认证
    │       ├── 授权
    │       └── 身份提供商
    │
    ├── 项目管理
    │       ├── 任务跟踪
    │       ├── 时间线/甘特图
    │       └── 资源分配
    │
    ├── 协作
    │       ├── 实时同步
    │       ├── 通知
    │       └── 评论/聊天
    │
    └── 报告
            ├── 分析
            ├── 仪表板
            └── 导出
                    │
                    ▼
            [数据库] [计算] [存储]

价值链文档模板

# 价值链：[领域/上下文]

## 用户需求
[锚点 - 用户实际需要的]

## 用户
- [主要用户角色]
- [次要用户角色]

## 价值链图

```text
[价值链ASCII图]
```

## 组件清单

| ID | 组件 | 描述 | 依赖于 | 可见性 |
|----|-----------|-------------|------------|------------|
| 1 | [名称] | [做什么] | - | 高 |
| 2 | [名称] | [做什么] | 1 | 中 |
| 3 | [名称] | [做什么] | 2 | 低 |

## 依赖矩阵

|   | C1 | C2 | C3 | C4 |
|---|----|----|----|----|
| C1 | - | | | |
| C2 | X | - | | |
| C3 | | X | - | |
| C4 | | X | X | - |

## 关键路径

[哪些依赖最关键]

## 假设

- [关于用户需求的假设]
- [关于组件的假设]

## 开放问题

- [需要进一步调查什么]

## 下一步

- [ ] 与用户验证
- [ ] 在演化轴上定位
- [ ] 识别战略机会

可见性评估

Y轴定位指南

可见性级别	特征	示例
0.90-1.00	直接用户交互	UI, 客户门户
0.75-0.89	用户知晓功能	通知, 搜索
0.50-0.74	应用服务	业务逻辑, API
0.25-0.49	平台服务	认证, 消息, 缓存
0.10-0.24	基础设施	数据库, 计算, 存储
0.00-0.09	公用事业	电力, 网络, 物理

可见性问题

评估可见性：

高可见性（近用户）：
- 用户是否直接与此交互？
- 用户是否知道此存在？
- 这是否是向用户的卖点？

中可见性：
- 这是否直接影响用户体验？
- 用户是否会注意到它失败？
- 这是否在用户文档中提及？

低可见性：
- 这纯粹是技术基础设施吗？
- 能否替换此而用户不知？
- 这是否是行业标准管道？

工作流

当映射价值链时：

定义范围：我们在映射什么？为了什么目的？
识别锚点：用户需求是什么？
列出第一层组件：什么直接满足需求？
递归分解：每个组件依赖什么？
绘制依赖：用依赖箭头连接组件
验证链：检查完整性、准确性、有用性
评估可见性：在Y轴上定位组件
文档化：捕获组件、依赖、假设
准备演化：准备添加X轴定位

参考

详细指导：

最后更新： 2025-12-26