3、需求获取方法：用户访谈、现场调研、文档审查、原型法

说到需求获取，很多刚入行的朋友觉得就是「拿着本子去问用户想要什么」。嗯，我当年也这么想。直到有一次，我花了整整两周访谈了十几位司机和调度员，回来整理时发现——大家说的根本对不上。有人要「自动对标」，有人要「人工干预优先」，还有人觉得「ATO 能跑就行，别整太复杂」。

所以，需求获取不是简单的「我问你答」。它是一门手艺。今天我就把这四种最常用的方法掰开揉碎了讲给你听。

3.1 用户访谈：别只听，要会问

用户访谈是最直接的方法。但这里有个坑——用户说的，不一定是真实需求。

举个例子。我在做某条线路的 ATO 系统时，司机反复强调「我要一个紧急制动按钮，位置要顺手」。我们照做了。结果试运行时，司机一次都没用过。后来聊天才知道，他真正想要的是「在紧急情况下能快速切断牵引力」，而不是那个按钮本身。

访谈技巧：

• 开放式问题为主：别问「你要不要这个功能」，要问「你平时遇到这种情况怎么处理」
• 追问细节：用户说「停车不准」，你要追问「偏差多少？什么场景下发生的？」
• 区分「痛点」和「痒点」：痛点是非解决不可的，痒点是「有更好，没有也行」
• 记录原话：我习惯用录音笔（征得同意后），回去再整理。光靠脑子记，容易漏掉关键信息

3.2 现场调研：纸上得来终觉浅

用户访谈是「听他们说」，现场调研是「自己去看」。这两者差别很大。

我记得有一次，用户说「我们的站台屏蔽门和 ATO 联动没问题」。结果我去现场一看，屏蔽门的关门时间比 ATO 预期的晚了 0.8 秒。这 0.8 秒在单站运行看不出问题，但在高峰期的折返站，就会导致列车晚点。

现场调研要关注什么？

• 实际环境：信号机位置、轨道状态、站台长度、屏蔽门类型
• 操作流程：司机怎么操作？调度员怎么监控？有没有「潜规则」？
• 异常情况：设备故障时，人工怎么介入？有没有备用方案？
• 数据记录：我建议带个相机（注意保密要求），拍下关键设备、操作面板、告警信息

3.3 文档审查：别忽视「历史」

文档审查听起来枯燥，但它是需求获取的「地基」。为什么？因为很多需求不是凭空产生的，而是从历史文档中「长」出来的。

我一般会审查以下几类文档：

• 系统规格书：上一版系统的功能定义、性能指标
• 变更记录：哪些需求被改过？为什么改？
• 故障报告：历史故障中暴露出的需求缺陷
• 运营日志：日常运营中遇到的问题、临时措施
• 标准规范：行业标准、企业标准、安全规范

举个例子。我在审查某条线路的文档时，发现一份三年前的故障报告：ATO 在雨雪天气下频繁触发紧急制动。原因是对轨面湿滑的粘着系数估计不足。这个信息直接影响了我们新系统的牵引控制算法需求。

3.4 原型法：让需求「看得见」

原型法是我个人最喜欢的方法。为什么？因为很多用户说不清楚自己要什么，但当你把原型摆在他面前，他立刻就能说「不对，这里应该是这样」。

原型法在 ATO 系统中的应用：

• 界面原型：HMI（人机界面）的布局、颜色、字体、告警方式
• 交互原型：按钮点击后的响应、菜单层级、操作流程
• 逻辑原型：用简单的模拟程序演示 ATO 的决策逻辑（比如对标停车、速度调整）
• 数据原型：展示 ATO 系统需要采集和输出的数据格式

我曾经用 Axure 做了一个 ATO 的 HMI 原型，拿给司机看。司机说：「这个速度表盘太小了，我开车时余光扫不到。」就这一句话，我们改了三次设计。如果等到开发完再改，成本至少翻十倍。

3.5 四种方法的组合策略

说了这么多，你可能会问：「那我到底该用哪种？」

我的经验是：别只用一种，也别全用。要根据项目阶段和资源来组合。

说白了，这四种方法就像工具箱里的四把扳手。没有哪把是万能的，但组合起来，基本能搞定 90% 的需求获取场景。

好了，关于需求获取方法，我就讲这么多。下一章我们聊聊需求分析与建模——那才是真正考验功力的地方。