3. 利益相关者分析：识别利益相关者、利益相关者分类、利益相关者需求收集方法

好，咱们进入第三题。前面我们讲了怎么把模糊的“想法”变成清晰的“问题”，但问题是为谁解决的？谁说了算？谁掏钱？谁用？——这就是利益相关者分析要干的事。

说白了，AI产品不是技术自嗨。我见过太多项目，算法团队闷头搞了三个月，模型精度刷到98%，结果业务方说“这玩意儿跟我流程对不上，没法用”。为什么？因为一开始就没把利益相关者拉进来。所以，这一步做不好，后面全是白费。

第一步，先把“人”找全。别只盯着老板和用户。我习惯用一张表，把可能相关的人都列出来，哪怕你觉得“这人可能不重要”，先写上再说。

我的经验是：做一个人脸识别门禁的AI产品，你以为利益相关者只有行政部和员工？错了。保安大叔才是关键——他每天要处理误识别、放行访客，如果系统不给他一个手动覆盖的按钮，他分分钟把电源拔了。所以，识别阶段宁可多，不可漏。

常用的识别维度有：

你可以画一个利益相关者地图，把名字写在便签上，贴在白板周围。别偷懒，这一步花30分钟，能省后面30天返工。

人找全了，接下来要分类。不是所有人都有同等话语权。我常用一个经典模型：权力-利益矩阵（Power-Interest Grid）。

权力（高）	权力（低）
高利益：关键人物必须重点管理，频繁沟通。例：业务负责人、出资方。	高利益：保持知情定期同步进展，别让他们意外。例：一线用户代表。
低利益：保持满意不需要频繁打扰，但别惹毛。例：合规部门（平时不管，出事就炸）。	低利益：最小关注简单通知即可。例：隔壁部门同事。

举个例子。我之前做银行智能风控产品，业务总监（权力高、利益高）每周要过进度，我专门给他准备一页纸的摘要。而一线信贷员（权力低、利益高），我每两周去他们工位坐半小时，听他们吐槽系统哪里反人类。至于IT运维（权力低、利益低），发个邮件告知上线时间就行。

这里有个坑：别把“权力低”的人不当回事。他们往往是实际使用者，如果系统难用，他们会用脚投票——消极使用、绕开系统、甚至故意输入错误数据。我吃过这个亏，后来学乖了。

分类完了，怎么把他们的需求挖出来？注意，是“挖”，不是“问”。因为很多人说不清自己要什么。你问业务方“你想要什么功能？”，他大概率说“我要一个智能的、自动化的、能提升效率的系统”——全是废话。

我常用的方法有四种，按场景选：

一对一访谈：适合关键人物。提前准备半结构化提纲，先聊痛点，再聊期望。别一上来就问AI，先问“你现在每天最烦什么？”
工作坊/焦点小组：适合有冲突的群体。比如销售和运营对AI分配线索有分歧，把他们拉到一个房间，用白板画流程，当场对齐。
跟岗观察：适合一线使用者。我做过一个仓储AI项目，跟了拣货员一整天，发现他们为了省两步路，宁愿手动记货架号也不用PDA扫描。这个需求，访谈是问不出来的。
原型验证：适合验证假设。拿一个低保真原型（甚至纸面草图）给用户点一点，看他们会不会点错。我常说：用户说的，和他做的，往往是两回事。

收集时，记得记录原始需求，别急着翻译成技术语言。比如用户说“我希望AI能自动识别异常”，你记下来，后面再分析。我习惯用一张需求卡片，格式很简单：

【需求编号】REQ-003
【来源】客服主管 张姐
【原始描述】“每天要手动查几百条聊天记录找投诉，眼睛都快瞎了”
【场景】每天下班前，需要汇总当日投诉
【期望】系统能自动标记疑似投诉的对话
【优先级】高（影响工作效率）

最后，提醒一句：利益相关者的需求会变。尤其是AI产品，用户看到原型后，往往会冒出新的想法。所以，别指望一次收集完。我一般会在项目启动、原型评审、UAT三个节点，各做一轮需求确认。

好，这一节就到这里。记住：找对人、分好类、挖对需求，你的AI产品就成功了一半。下一节我们讲怎么把这些零散的需求，变成结构化的需求文档。

权力（高）	权力（低）
高利益：关键人物必须重点管理，频繁沟通。例：业务负责人、出资方。	高利益：保持知情定期同步进展，别让他们意外。例：一线用户代表。
低利益：保持满意不需要频繁打扰，但别惹毛。例：合规部门（平时不管，出事就炸）。	低利益：最小关注简单通知即可。例：隔壁部门同事。