第三章 芯片产品需求收集：客户拜访与需求访谈技巧、需求优先级排序（MoSCoW/Kano模型）、内部研发需求收集
3.1 客户拜访：别急着推销，先学会听
做芯片产品经理，最怕什么？
怕你拿着PPT冲进客户办公室，一顿猛吹自家芯片多牛。结果客户问一句“你们支不支持MIPI C-PHY v2.0？”你当场卡壳。
我刚开始带产品线时，就犯过这毛病。拜访一家做安防摄像头的客户，我滔滔不绝讲了半小时功耗优势。对方技术总监终于忍不住打断我：“功耗是挺好，但我们最痛的是sensor接口带宽不够，你们能解决吗？”
嗯，那次拜访基本白费了。
核心原则：客户拜访不是推销会，是需求挖掘会。
我个人习惯把拜访分成三个阶段：
- 破冰期（前10分钟）：聊行业趋势、客户业务痛点。别一上来就谈芯片参数。
- 深挖期（中间30分钟）：用开放式问题引导。比如“你们下一代产品在接口上有什么规划？”
- 确认期（最后10分钟）：复述客户需求，确保理解一致。“我确认一下，您刚才说需要支持4路4K@60fps同时编码，对吗？”
这里有个小技巧：多问“为什么”。客户说“我要低功耗”，你得追问“为什么？是散热受限，还是电池续航要求？”
我遇到过客户说“要支持PCIe Gen4”，结果一问才知道，他们只是觉得“Gen4听起来先进”。实际上Gen3 x4带宽已经够用。你看，不问清楚就立项，成本全白花了。
3.2 需求访谈：结构化提问与陷阱规避
需求访谈不是聊天，得有结构。我常用的框架叫“STAR+3W”：
| 维度 | 问题示例 |
|---|---|
| Situation（场景） | 你们在什么场景下用这颗芯片？ |
| Task（任务） | 芯片需要完成什么核心功能？ |
| Action（行动） | 目前怎么解决的？有什么痛点？ |
| Result（结果） | 理想状态下，你希望达到什么效果？ |
| Why（为什么） | 为什么这个参数必须达到？ |
| When（时间） | 什么时候需要量产？ |
| Who（决策者） | 最终谁拍板用哪家芯片？ |
避坑指南：我曾经访谈一位客户，对方说“功耗越低越好”。我追问“具体多少？”他说“1W以内吧”。结果回去一算，他们系统散热能力只能支持0.5W。如果我不追问具体数值，后面研发就白干了。
还有一点：别只问技术负责人。采购、项目经理、甚至产线工人，他们的视角完全不同。采购关心价格和交期，项目经理关心开发难度，产线工人关心封装和测试便利性。
3.3 需求优先级排序：MoSCoW模型实战
需求收集了一大堆，怎么排优先级？
我推荐MoSCoW模型。说白了就是把需求分成四类：
- Must have（必须有）：没有这个功能，芯片没法用。比如MCU必须有GPIO。
- Should have（应该有）：很重要，但可以暂时没有。比如支持USB 3.0，但第一版可以先做USB 2.0。
- Could have（可以有）：锦上添花。比如支持RGB灯效控制。
- Won't have（这次不做）：明确放弃。比如支持Wi-Fi 7，但市场还没起来。
我习惯用一张表来管理：
| 需求描述 | 客户A | 客户B | 内部研发 | 最终优先级 |
|---|---|---|---|---|
| 支持4K@60fps编码 | Must | Must | Should | Must |
| 支持HDR10+ | Should | Could | Could | Should |
| 支持eDP输出 | Won't | Must | Should | Should |
你想想看，如果两个客户都说是Must，那基本就是Must。如果只有一个客户说Must，你得评估这个客户的市场份额和战略价值。
个人经验：MoSCoW模型最怕“全是Must”。我遇到过客户把20个需求全标成Must。这时候你得帮他做减法：“如果只能选3个，你选哪3个？”
3.4 Kano模型：区分“惊喜”与“基本”
MoSCoW解决的是“要不要做”，Kano模型解决的是“做了客户会不会满意”。
Kano模型把需求分成五类：
- 基本型需求：做了客户没感觉，不做客户暴怒。比如芯片必须能正常启动。
- 期望型需求：做了客户满意，不做客户不满意。比如功耗比竞品低10%。
- 兴奋型需求：做了客户惊喜，不做客户无所谓。比如内置AI加速器，客户没想到但用了觉得真香。
- 无差异需求：做不做客户都没感觉。比如芯片颜色是黑色还是绿色。
- 反向需求：做了客户反而反感。比如增加不必要的功能导致成本上升。
我举个例子。做一款蓝牙音频芯片：
- 基本型：蓝牙连接稳定、音质不破音。这是底线。
- 期望型：支持LDAC高清编码、续航10小时以上。
- 兴奋型：支持主动降噪+空间音频，同价位竞品都没有。
怎么判断需求属于哪一类？做问卷。问客户两个问题：
- 如果芯片有这个功能，你感觉如何？（满意/理所当然/无所谓/勉强接受/不满意）
- 如果芯片没有这个功能，你感觉如何？
然后对照Kano评估表，就能分类了。
核心观点：基本型需求必须做，期望型需求尽量做，兴奋型需求选择性做。别把资源浪费在无差异需求上。
3.5 内部研发需求收集：别忽视自家人的声音
很多产品经理只盯着外部客户，忘了内部研发团队也是“客户”。
研发团队的需求通常包括：
- 可测试性需求：比如增加DFT（可测试性设计）接口，方便量产测试。
- 可复用性需求：比如IP模块化设计，方便后续项目复用。
- 开发效率需求：比如提供完善的SDK和参考设计，减少开发周期。
我建议每两周和研发团队开一次“需求吐槽会”。不聊进度，只聊痛点。
有一次，研发负责人跟我说：“你们产品经理天天加新功能，但测试用例都没时间写。流片回来发现bug，全怪我们。” 嗯，这话说得我哑口无言。
从那以后，我定了个规矩：每个新需求必须附带测试方案。没有测试方案的需求，优先级自动降一级。
避坑指南：我曾经忽略了一个研发需求——芯片封装尺寸。研发说“能不能用BGA封装？PCB好走线。”我觉得客户没要求，就用了QFN。结果客户打样时发现PCB布线困难，硬生生多花了两周改板。你看，内部需求不重视，最后坑的还是自己。
3.6 需求优先级排序的最终决策
需求收集完了，MoSCoW和Kano也用了，怎么拍板？
我个人习惯用“价值-成本-风险”三维矩阵：
| 需求 | 客户价值 | 研发成本 | 技术风险 | 决策 |
|---|---|---|---|---|
| 支持4K@60fps | 高 | 中 | 低 | 做 |
| 支持Wi-Fi 7 | 中 | 高 | 高 | 暂缓 |
| 增加GPIO数量 | 低 | 低 | 低 | 做 |
说白了，就是用有限的资源，做最有价值的事。
你想想看，芯片流片一次几百万，改版一次又是几百万。需求没排好，浪费的不只是钱，还有团队半年的时间。
最后分享一个习惯：每次需求评审会，我都会问三个问题：
- 这个需求不做，客户会流失吗？
- 这个需求做了，能帮我们多拿几个客户？
- 这个需求现在不做，三个月后做来得及吗？
三个问题问完，优先级基本就清楚了。
嗯，需求收集和排序，说到底就是平衡的艺术。平衡客户期望、研发能力和商业目标。没有完美的需求清单，只有最合适的取舍。