需求的本质

软件开发不是写代码，是解决业务问题。

但太多时候，我们在做”功能搬运工”：产品经理说做什么，我们就做什么。

好的需求管理，是建立业务价值和实现方案之间的桥梁。

用户故事：从功能到价值

为什么要用户故事

传统的需求文档：

系统应该提供导出Excel功能，
支持选择导出字段，
支持自定义文件名。

用户故事：

作为销售经理，
我需要导出客户数据到Excel，
以便在离线状态下分析客户分布。

区别：

  • 明确用户角色
  • 说明业务价值
  • 留下实现空间

用户故事模板

标准格式：

作为 [角色]
我需要 [功能]
以便 [价值]

验收标准（AC）：

  • 具体、可测试
  • 覆盖正常和异常情况

示例：

AC1: 导出文件格式为 .xlsx
AC2: 最多支持导出10000条记录
AC3: 导出时显示进度条
AC4: 导出失败时显示错误信息

用户故事的大小

INVEST 原则：

  • Independent（独立）：减少依赖，便于优先级调整
  • Negotiable（可协商）：不是合同，可以讨论实现方案
  • Valuable（有价值）：对用户有意义
  • Estimable（可估算）：团队能估算工作量
  • Small（小）：一个迭代内完成
  • Testable（可测试）：有明确验收标准

优先级排序

1. MoSCoW 方法

  • Must have：没有它系统不能用（核心功能）
  • Should have：重要但不紧急（体验优化）
  • Could have：有更好，没有也行（锦上添花）
  • Won’t have：明确不做（控制范围）

2. 价值 vs 成本矩阵

高价值+低成本 → 立即做
高价值+高成本 → 规划做
低价值+低成本 → 抽时间做
低价值+高成本 → 不做

3. Kano 模型

  • 基本型：必须有，有了不加分，没有会抱怨
  • 期望型：做得越好，满意度越高
  • 兴奋型：超出预期，惊喜功能

实际应用：

  • 先做基本型，确保可用
  • 重点做期望型，提升满意度
  • 穿插兴奋型，制造惊喜

需求拆分

为什么要拆分

大象需求： “做一个电商系统”

团队面面相觑，无法估算，风险极高。

纵向拆分 vs 横向拆分

横向拆分（不推荐）：

  • 第1周：完成所有数据库设计
  • 第2周：完成所有 API 开发
  • 第3周：完成所有前端页面

问题：3周内看不到可用功能，风险累积。

纵向拆分（推荐）：

  • 第1周：商品浏览功能（数据库+API+前端）
  • 第2周：购物车功能
  • 第3周：下单支付功能

每周末都有可用的功能，风险分散。

拆分技巧

按工作流拆分：

  • 用户注册 → 登录 → 找回密码

按业务规则拆分：

  • 普通用户下单
  • VIP 用户下单（有折扣规则）

按数据类型拆分：

  • 导入 Excel 数据
  • 导入 CSV 数据

变更管理

变更不可避免

计划赶不上变化，尤其是在敏捷环境中。

变更处理流程

1. 记录变更请求 不在走廊里随口答应，必须记录到 backlog。

2. 评估影响

  • 对当前 sprint 的影响
  • 对发布计划的影响
  • 技术债务风险

3. 决策

  • 立即做（替换当前 sprint 低优先级任务）
  • 下个 sprint 做
  • 加入 backlog 排队
  • 拒绝（解释原因）

控制变更的节奏

Sprint 中的变更： 原则上不接受，除非是生产环境紧急 bug。

Sprint 之间的变更： 重新排序 backlog，下一个 sprint 实现。

需求评审会议

会议结构

1. 产品负责人讲解（15分钟）

  • 业务背景
  • 用户故事
  • 验收标准

2. 团队提问澄清（20分钟）

  • 边界情况
  • 依赖关系
  • 技术约束

3. 方案讨论（20分钟）

  • 实现思路
  • 技术选型
  • 风险识别

4. 任务拆分和估算（25分钟）

  • 拆分成具体任务
  • 每个任务估算

会议原则

  • PO 回答”做什么”和”为什么”
  • 团队决定”怎么做”
  • 会议时间控制在1-1.5小时
  • 复杂需求会前预研

工具推荐

需求管理：

  • Jira：功能全面，适合大型团队
  • Linear：简洁现代，适合小团队
  • Notion：灵活，适合文档型需求

协作沟通：

  • Figma：原型评审
  • Miro：用户故事地图
  • Loom：异步视频讲解

常见陷阱

1. 需求镀金 PO 不断加需求，超出 MVP 范围。

2. 完美主义 等需求”完全明确”才开始开发，永远不开始。

3. 忽视技术约束 不考虑实现难度，导致估算严重偏差。

4. 变更不透明 私下承诺变更，破坏计划性。

总结

好的需求管理：

  • 聚焦价值，而非功能
  • 保持灵活，但有纪律
  • 团队共创，而非单向传递
  • 持续交付，快速验证

需求管理的艺术在于平衡：足够清晰但不僵化，足够灵活但不失控。