第2章：需求重用的价值
为什么需要需求重用
说实话，我刚开始做产品线的时候，对需求重用这事也不太感冒。那时候觉得，每个项目都是全新的，需求当然要重新写。直到有一次，我接手了一个手机操作系统的定制项目——客户要求跟上一代产品几乎一模一样，就改了几个UI细节。
我当时傻乎乎地从头写了一遍需求文档。结果呢？花了三周时间，写出来的东西跟上一版有80%雷同。更惨的是，还漏掉了几个关键的非功能性需求，导致后期返工。
这件事让我彻底明白了：需求重用不是偷懒，是专业。
你想想看，一个典型的手机产品线，从旗舰机到千元机，底层需求其实高度相似：
- 通信模块：4G/5G、WiFi、蓝牙——这些需求几乎不变
- 操作系统：Android底层、驱动适配——核心需求稳定
- 安全机制：指纹、面部识别、支付安全——架构级需求可复用
- 用户体验：流畅度、续航、散热——这些指标每个项目都要定义
如果每个项目都从零开始，你就是在重复造轮子。而且，造出来的轮子还不一定比上次好。
核心观点：需求重用的本质，是把组织级的经验资产化。不是简单的复制粘贴，而是把已验证的、高质量的需求，变成可配置的资产。
重用带来的ROI分析
ROI这东西，光说理论没意思。我直接给你算笔账。
假设你们公司一年做10个手机项目。每个项目的需求阶段平均耗时：
| 阶段 | 不重用（人天） | 重用（人天） | 节省 |
|---|---|---|---|
| 需求调研 | 15 | 5 | 10 |
| 需求分析 | 20 | 8 | 12 |
| 需求规格编写 | 25 | 10 | 15 |
| 需求评审 | 10 | 5 | 5 |
| 需求变更管理 | 8 | 3 | 5 |
| 合计 | 78 | 31 | 47 |
看到了吗？每个项目能省47人天。10个项目就是470人天。按一个工程师日均成本2000元算，一年省下94万。
但这只是直接成本。我再说几个隐性收益：
- 质量提升：重用的需求都是经过验证的，bug率能降低40%-60%
- 交付加速：需求阶段缩短，整个项目周期能压缩15%-20%
- 沟通成本降低：团队对复用需求的理解一致，减少扯皮
- 知识沉淀：老员工的经验不会流失，新员工上手更快
我的经验：我在一个手机产品线项目中，把核心的100多条需求做成了复用库。结果第二年，新来的产品经理只用了一周就完成了需求规格，而以前至少要三周。这就是复用的力量。
当然，建立复用库本身需要投入。我估算过，初期投入大约需要60-80人天。但第一年就能回本，后面全是净赚。
行业案例：手机产品线
手机行业是需求重用的典型场景。我参与过几个手机OS的项目，说说我的观察。
先看华为的EMUI（现在叫HarmonyOS）。他们的需求管理做得相当成熟。从P系列到Mate系列，再到荣耀系列，核心需求复用率能达到70%以上。怎么做到的？
- 分层管理：把需求分为平台层、产品线层、项目层。平台层需求全复用，产品线层按系列复用，项目层才是个性化需求。
- 变点管理：每个需求都标注了可变点。比如「屏幕分辨率」这个需求，旗舰机是2K，中端机是1080P，但需求的模板是一样的，只是参数不同。
- 版本追溯：每个复用的需求都能追溯到原始版本。改了什么、为什么改，一目了然。
再说说小米。MIUI的需求复用做得更接地气。他们有个「需求超市」的概念——把常用的需求做成标准化组件。比如：
- 通知栏样式：有3种模板可选
- 手势操作：有5种方案
- 主题引擎：统一接口，各机型适配
新项目启动时，产品经理直接去「超市」里挑。挑完了再配几个差异化需求，完事。
避坑指南：我曾经见过一个团队，为了追求复用率，把需求写得特别抽象。结果呢？每个项目都要花大量时间做二次解释。复用率是上去了，效率反而下降了。记住：复用不是目的，效率才是。
最后说说OPPO。他们的ColorOS有个做法我很欣赏——需求血缘分析。每个新需求都会标记「继承自哪个旧需求」。这样做的价值在于：
- 如果旧需求有bug，所有继承它的新需求都能自动预警
- 如果旧需求被废弃，能快速评估影响范围
- 新需求的质量，直接跟旧需求的缺陷率挂钩
说白了，需求重用不是简单的复制粘贴。它是一个系统工程，需要组织、流程、工具三管齐下。
我个人习惯，在启动任何产品线项目之前，先花一周时间做需求复用评估。看看哪些需求可以直接拿过来用，哪些需要调整，哪些必须新建。这一步做好了，后面至少省30%的功夫。
嗯，这就是需求重用的价值。不是理论，是实打实的效率和质量。