2、需求分析阶段：如何平衡硬件性能与软件功能的需求优先级

需求分析阶段，说白了就是「吵架阶段」。

硬件团队说：「这个性能指标必须达标，否则没法用。」

软件团队说：「这个功能用户一定要有，否则卖不出去。」

产品经理夹在中间，左右为难。我见过太多项目，因为需求优先级没理清，最后硬件改版三次，软件重写两遍，项目延期半年。

为什么会这样？因为大家没搞清楚一个核心问题：硬件是骨架，软件是血肉。骨架歪了，血肉再丰满也没用。

2.1 先搞清楚：哪些需求是「硬约束」

我个人习惯，拿到需求清单后，第一件事不是排序，而是分类。

我把需求分成三类：

• 硬约束：必须由硬件决定的，软件改不了。比如传感器采样率、无线通信频段、电池容量。
• 软约束：硬件能支持，但软件可以优化或妥协。比如UI动画流畅度、数据上报频率。
• 伪需求：听起来很美好，但实际用户根本用不到。比如「支持所有蓝牙协议版本」。

举个例子。我在做一款智能门锁时，销售提了个需求：「指纹识别速度要小于0.3秒。」

硬件团队评估后说：「可以做到，但需要换一颗更贵的指纹模组，成本增加30%。」

软件团队说：「我们可以在算法上优化，把识别速度压到0.4秒，用户基本感觉不到差异。」

你看，这就是典型的软硬博弈。最后我们怎么做的？

2.2 优先级矩阵：一个实用的工具

我整理了一个优先级矩阵，每次做需求分析时都会拿出来用。你想想看，这个矩阵其实很简单：

需求类型	硬件影响	软件影响	优先级
核心功能	高	高	P0（必须做）
体验优化	低	高	P1（软件先做）
差异化卖点	高	低	P2（评估硬件成本）
锦上添花	低	低	P3（砍掉或延期）

嗯，这里要注意：P0的需求，硬件和软件必须同时支持，缺一不可。P1的需求，尽量用软件解决，别轻易动硬件。P2的需求，要算一笔账——这个卖点能带来多少销量？硬件成本增加多少？

我曾经遇到一个案例。某款智能手表，产品经理坚持要加「血氧监测」功能。硬件团队说：「需要加一颗血氧传感器，BOM成本增加8块钱。」软件团队说：「算法我们可以写，但准确率只有80%。」

最后我们做了用户调研，发现目标用户中只有15%的人在意血氧功能。算下来，为了这15%的用户，所有用户都要多付8块钱成本。这个决策就很简单了——砍掉，放到下一代产品。

2.3 避坑指南：硬件性能的「过度设计」

我曾经犯过一个错误。做一款智能音箱时，我坚持要用一颗高性能的DSP芯片，想着「性能冗余总比不够好」。结果呢？

• 硬件成本高了20%
• 功耗大了，散热问题突出
• 软件团队抱怨：「这颗芯片的SDK太难用，开发周期要延长一个月」

后来复盘才发现，用户实际用到的功能，那颗低一档的芯片完全能胜任。我花了冤枉钱，还拖慢了项目进度。

那怎么判断「够用」？我的方法是：

1. 列出所有软件功能对硬件资源的需求（CPU、内存、存储、功耗）
2. 找出最吃资源的那几个功能
3. 用这些功能跑一个「极限场景」测试
4. 如果测试通过，就选这颗芯片；如果勉强通过，就加一档

2.4 软件功能的「硬件依赖」分析

很多软件功能，看起来是软件的事，其实背后都有硬件依赖。我习惯在需求分析阶段，就让软件团队把每个功能拆开来看：

• 计算密集型：比如图像识别、语音处理。依赖CPU/GPU/NPU的性能。
• I/O密集型：比如数据上传、日志记录。依赖存储读写速度和网络带宽。
• 实时性要求高：比如电机控制、传感器数据采集。依赖中断响应时间和总线延迟。

举个例子。某款扫地机器人，软件团队想加一个「实时视频通话」功能。听起来很酷，对吧？但一分析硬件依赖：

• 需要一颗摄像头（硬件成本+15元）
• 需要Wi-Fi模块持续传输视频流（功耗增加30%）
• 需要主芯片有视频编码能力（芯片选型受限）

最后我们算了一笔账：这个功能的使用场景极少（谁会在扫地时跟机器人视频通话？），但硬件成本增加不少。果断砍掉。

2.5 决策流程：三步走

说了这么多，最后总结一下我的决策流程。其实就三步：

1. 分类：把需求分成硬约束、软约束、伪需求
2. 评估：用优先级矩阵打分，算清楚硬件成本和软件工作量
3. 决策：能软件解决的，不动硬件；必须动硬件的，算ROI

你想想看，这个流程是不是很简单？但很多团队就是做不到。为什么？因为大家太着急了，需求一来就急着开工，没花时间想清楚。

我个人习惯，需求分析阶段至少留出两周时间。第一周用来吵架、讨论、评估。第二周用来写文档、定方案。这两周花得值，后面能省两个月。

最后说一句：硬件产品经理的核心能力，不是懂硬件，也不是懂软件，而是懂得在两者之间做取舍。这个能力，没有捷径，只能靠一个个项目积累。但有了这套方法和工具，至少能让你少走一些弯路。