需求收集与用户调研：利益相关者分析、用户故事编写、需求访谈技巧

说实话，很多做计算机视觉的团队，项目做砸了不是因为技术不行。

而是从一开始就没搞清楚：到底要给谁做？做什么？

我见过太多团队，上来就调模型、跑数据集，结果交付的时候客户说“这不是我要的”。嗯，那场面，真的很尴尬。

这一章，我们就聊聊需求收集这件事。别觉得它“不技术”，它恰恰是决定你项目生死的第一步。

一、利益相关者分析：先搞清楚“谁说了算”

一个计算机视觉项目，通常不止一个人说了算。

我参与过一个智慧零售项目，甲方派了三个部门对接：业务部要“识别准确率高”，IT部要“接口响应快”，财务部要“预算不能超”。

你看，这三个人对同一个项目的诉求完全不同。

利益相关者分析，就是把这些人都找出来，然后分类管理。

我个人习惯用这个四象限法：

权力/影响力	高利益	低利益
高权力	重点管理（如：项目出资方、CEO）	保持满意（如：合规部门）
低权力	保持知情（如：一线操作员）	最小关注（如：外部顾问）

二、用户故事编写：把“我要”变成“我能”

用户故事是敏捷开发里的经典工具。说白了，就是用一句话讲清楚：谁、要什么、为什么。

标准格式是：

作为 <角色>，我想要 <功能>，以便 <价值>

举个例子，一个安防项目：

• 错误写法：“系统需要检测异常行为” —— 太模糊，没法验收。
• 正确写法：“作为安保人员，我想要系统在检测到人员倒地时自动报警，以便我能及时处理突发事件。”

你看，后者明确了角色、触发条件、期望结果。

写用户故事时，我建议遵循 INVEST 原则：

• Independent（独立的）
• Negotiable（可协商的）
• Valuable（有价值的）
• Estimable（可估算的）
• Small（小规模的）
• Testable（可测试的）

你想想看，如果一条用户故事没法测试，那你怎么验收？

三、需求访谈技巧：问对问题，比答案更重要

需求访谈，不是聊天。它是有目的的挖掘。

我刚开始做项目时，访谈就是“您需要什么功能？”结果对方说“我要一个能识别人的系统”。好，回去做吧，做完发现人家要的是“能识别戴口罩的人”。

为什么会这样？因为用户自己也不清楚技术边界。

我的访谈三板斧：

1. 开放式问题开场：“您目前处理这个任务，最大的痛点是什么？”
2. 场景化追问：“如果系统识别错了，您希望它怎么做？是忽略还是二次确认？”
3. 反向验证：“我理解一下，您是说在光照不足的仓库里，需要识别货架上的商品，对吗？”

另外，访谈后一定要做一件事：整理成文档，发给用户确认。

这一步能避免80%的后期扯皮。

四、从需求到方案：一个真实案例

我参与过一个工厂质检项目。一开始，甲方说“我们要检测产品表面缺陷”。

通过利益相关者分析，我们发现：

• 生产经理要“减少漏检率”
• 质检员要“操作简单，别增加工作量”
• IT主管要“能对接现有MES系统”

通过用户故事，我们写出了：

作为质检员，我想要系统在传送带上自动标记缺陷位置，
以便我不用逐帧查看视频。

通过访谈，我们了解到：现场光照不稳定，产品种类有20多种，缺陷类型有划痕、凹陷、色差等。

最终，我们的方案不是“做一个通用缺陷检测模型”，而是：

• 先做光照补偿预处理
• 按产品类别训练多个轻量模型
• 输出结果直接叠加到MES看板上

你看，需求收集做扎实了，技术方案自然就清晰了。

嗯，这一章就到这里。下一章我们聊聊如何把需求转化成技术方案，包括架构选型和数据策略。