4. 需求拆解与功能粒度控制
4.1 业务问题：大需求带来的拆解困境
在B端产品迭代中，产品经理经常收到来自业务方的“大需求包”——一个需求描述涵盖多个业务环节、涉及多个角色、横跨多个模块。如果不进行系统化拆解，直接进入方案设计，会导致以下问题：
- 评估失真：需求过大，开发周期和资源难以准确估算；
- 风险集中：所有功能堆在一个迭代中，延迟和缺陷相互放大；
- 验收模糊：粒度太粗，验收标准难以定义，上线后效果无法衡量；
- 协作混乱：多模块依赖不清晰，团队之间频繁等待和返工。
核心认知：需求拆解不是简单的“把大需求切成小需求”，而是按照业务逻辑、技术依赖和用户价值，将需求组织成可独立交付、可独立验证的最小功能单元。
4.2 功能拆分四大原则
在多次B端PRD迭代实战中，我们总结出以下四条功能拆分原则，作为粒度控制的判断标准：
| 原则 | 说明 | 反面案例 |
|---|---|---|
| 单一职责 | 一个功能单元只解决一个业务问题，只改变一个业务对象 | “采购申请+审批+转订单”合为一个功能 |
| 高内聚低耦合 | 单元内部逻辑紧密关联，单元之间通过接口/事件解耦 | “订单管理”与“支付结算”代码混合 |
| 可独立验证 | 每个单元有明确输入/输出，可独立测试和验收 | “优化审批流程”没有具体输入输出 |
| 用户价值完整 | 单元交付后能独立完成一个业务闭环，用户可感知价值 | “创建采购申请单”不包含提交和保存 |
实战技巧：当你不确定一个功能是否拆分到位时，问三个问题——① 这个功能能独立测试吗？② 这个功能交付后用户能直接用吗？③ 这个功能如果延期，会影响其他功能上线吗？如果三个答案都是“是”，说明粒度合适。
4.3 最小可行单元（MVU）
最小可行单元（Minimum Viable Unit, MVU）是B端需求拆解的核心产出。每个MVU必须同时满足以下条件：
- 业务自闭环：单元内包含完整的业务操作流程（创建→提交→反馈）；
- 数据自包含：单元所需数据可在内部生成或通过已有接口获取，不依赖同一迭代中的其他MVU；
- 价值可感知：单元上线后，用户能直观感受到效率提升或问题解决；
- 验收可量化：单元有明确的验收指标（如操作时长、错误率、完成率）。
以下是一个典型的B端需求拆解案例，对比不同粒度的效果：
| 粒度类型 | 示例 | 交付周期 | 验收难度 | 风险等级 |
|---|---|---|---|---|
| 史诗需求 | “优化采购全流程” | 8周+ | 高 | 高 |
| 普通功能 | “采购申请单审批流” | 3~4周 | 中 | 中 |
| 最小可行单元 | “采购申请单创建与提交” | 1~2周 | 低 | 低 |
警惕粒度陷阱：不要为了追求“小”而把功能切碎到原子操作。如果一个MVU无法独立产生用户价值（例如只包含“保存草稿”而没有“提交”能力），说明粒度太细，反而增加了集成和验证成本。
4.4 模块边界划分
模块边界决定了功能单元的归属范围和交互方式。在B端产品中，我们推荐采用以下三种划分方式组合使用：
- 按业务域划分：将同一业务领域的功能归为一个模块（如采购、库存、财务），边界清晰，职责明确；
- 按用户角色划分：将同一角色使用的功能聚合为一个模块（如管理员后台、采购员工作台），提升使用效率；
- 按生命周期划分：将同一业务对象不同阶段的功能拆分（如订单创建、订单履约、订单结算），降低单模块复杂度。
模块边界一旦确定，就需要通过依赖关系图来显式管理跨模块的协作，避免循环依赖和隐形耦合。
4.5 功能模块依赖关系图
下图为某B端采购管理系统的功能模块依赖关系图，展示了不同MVU之间的分层与依赖关系：
图中箭头方向表示“依赖方向”：箭头从依赖方指向被依赖方。例如，“消息通知”依赖“支付结算”提供支付结果事件，因此箭头从消息通知指向支付结算。同层模块（如订单管理与库存管理）之间也存在协作关系，需要明确接口约定。
4.6 验收标准与交付物模板
每个MVU都需要配套明确的验收标准和交付物，才能保证拆解后的需求不遗漏、不偏差。以下为推荐的交付物模板结构：
MVU-ID：MVU-004
MVU名称：采购申请单创建与提交
所属模块：采购管理
依赖关系：依赖「用户权限管理」进行身份校验
用户场景：采购员在库存预警后创建采购申请单，填写物料信息并提交审批
验收标准（须全部通过）：
1. 采购员可填写物料编码、数量、期望到货日，系统自动校验物料编码有效性
2. 提交后生成唯一采购申请单号，状态为“待审批”
3. 提交成功后，系统向审批人发送待办通知
4. 整个操作流程不超过3分钟（基准值：当前线下流程平均8分钟）
交付物清单：
- 需求描述文档（含字段表、状态流转图）
- 界面原型（Figma / Axure）
- 验收测试用例（含正常流程 + 3条异常流程）
- 用户操作手册（图文版）
模板使用建议：每个MVU的验收标准中，至少包含1条可量化的性能指标（如操作时长、响应时间、成功率），用于上线后的效果验证。避免只用“功能正常”等模糊描述。
4.7 案例总结与自检清单
需求拆解与功能粒度控制是B端PRD质量的关键分水岭。在每次迭代中，建议使用以下自检清单进行复盘：
| 检查项 | 自检问题 | 通过标准 |
|---|---|---|
| 原则符合 | 每个MVU是否满足单一职责、高内聚低耦合、可独立验证、用户价值完整？ | 全部满足 |
| 依赖清晰 | MVU之间的依赖关系是否显式标注，且无循环依赖？ | 依赖关系图无闭环 |
| 边界明确 | 每个MVU的输入、输出、所属模块是否定义清楚？ | 模板中字段完整 |
| 验收可测 | 每个MVU的验收标准是否包含至少1条量化指标？ | 所有MVU均有量化标准 |
| 价值闭环 | 每个MVU上线后用户是否能独立完成一个业务操作？ | 用户可感知价值 |
迭代红线：任何两个MVU之间如果存在“你上线我才能上线”的强依赖，说明拆解不彻底，需要进一步调整模块边界或重新规划迭代顺序。依赖关系图是发现这类问题的核心工具，必须在PRD评审前完成绘制并团队对齐。
本章核心交付物：功能模块依赖关系图（SVG格式）+ MVU交付物模板（含验收标准）。这两个产物将直接进入PRD文档的需求规格章节，作为后续方案设计和开发评估的基准。