第1章：需求树的价值与使用场景
用户场景：为什么需要需求树？
产品经理小张刚接手一个中台项目，需求文档堆了30页，用户故事散落在多份表格里。每次评审会，开发问“这个功能到底对应哪个业务目标？”，测试问“验收标准写在哪？”，设计问“这是第几个版本的范围？”——小张发现自己连需求之间的层级关系都说不清。
类似场景在互联网公司、硬件产品团队、SaaS企业中都反复出现：需求信息碎片化、层级混乱、责任边界模糊，导致返工、延期和团队冲突。
关键洞见： 需求管理的核心矛盾不是“没写需求”，而是“需求之间没有结构化的连接”。需求树正是为解决这一矛盾而生的可视化工具。
业务问题：传统需求文档的四大短板
| 问题维度 | 传统做法 | 业务影响 |
|---|---|---|
| 需求可视化 | 纯文本列表 / Word / Excel | 无法一眼看清全貌，遗漏依赖关系 |
| 层级分解 | 长篇段落罗列，无父子结构 | 开发切割任务时找不到根因 |
| 团队对齐 | 邮件 + 会议反复澄清 | 沟通成本高，信息衰减严重 |
| 项目落地闭环 | 需求文档 – 开发 – 测试 – 验收脱节 | 交付物与原始需求偏移30%以上 |
用户访谈：一线团队的典型反馈
- 产品总监王姐：“每次复盘都发现，上线的功能有一半不是最初想要的，因为需求拆解到开发层面时就变形了。”
- 前端工程师阿杰：“后端接口改了，但没人通知我，因为需求条目之间没有关联标记。”
- 测试主管老刘：“验收标准写得像散文，我们只能靠猜。要是有一条树状链路，从业务目标 → 功能点 → 用例，我就知道测到什么程度算达标。”
需求拆解：用层级树替代平面列表
需求树的核心拆解逻辑是“逐层精化”：
- 战略层（为什么做）：业务目标、北极星指标
- 能力层（做什么）：用户故事、Epic
- 功能层（怎么做）：Feature、User Story
- 任务层（谁来做）：Task、Acceptance Criteria
- 验证层（如何检查）：测试用例、验收标准
可视化表达原则：每个节点必须包含唯一编码、标题、负责人、优先级、状态。不必在一开始就填满所有字段，但结构骨架必须清晰。
方案表达：Figma需求树绘制流程
在Figma中绘制需求树的核心步骤：
- 创建父节点：使用矩形+文字，代表业务目标（例如“提升用户留存”）。
- 向下分支连线：用自动布局或插件（如 FigJam）生成连接线，保持同层对齐。
- 用颜色区分层级：例如深蓝代表战略层，绿色代表功能层，橙色代表任务层（配色参考SVG色板）。
- 添加标签元数据：在节点右下角用小字号显示优先级 P1/P2、负责人简称。
指标验证：如何衡量需求树是否有效？
在引入需求树后，建议跟踪以下关键指标（基线 vs 目标）：
- 需求澄清时间：从第一次评审到全员理解的平均会议时长（目标缩短40%）
- 需求遗漏率：上线后发现未被实现的需求数（目标降至<5%）
- 团队认知偏差：同步测试：让开发与产品分别画需求树，重合度（目标>85%）
- 验收通过率：一次性通过测试的需求比例（目标>70%）
常见陷阱：不要试图在第一版就把所有Field填满。需求树是“生长出来的”，先搭骨架，再逐步填充细节。如果一开始就追求完美，团队容易陷入细节争论，反而失去可视化优势。
验收标准：第1章学习成果检查清单
| 验收项 | 合格标准 |
|---|---|
| 能说出需求树解决的4个业务问题 | 口头或书面列举，不少于3个即可 |
| 能画出需求树的5层拆解结构 | 在纸上或Figma中完成分层草图 |
| 能解释每个颜色层级的含义 | 对应色板中的蓝、绿、橙、紫、红 |
| 能列举3个使用场景并说出区别 | 评审、拆解、对齐、验证中任选3个 |
交付物模板：第1章输出要求
完成本章后，需产出以下交付物（可在Figma文件或白板中创建）：
- 需求树价值四象限图：类似本章SVG，但必须包含你所在业务线的真实场景替换文字。
- 一份会议记录：记录与团队（至少2人）讨论“当前需求管理痛点”的要点，并标注哪些痛点可以被需求树解决。