4. 需求获取方法：访谈法、问卷调查法、文档分析法、原型法、观察法
做楼宇自控系统，最怕什么？
怕需求没搞清楚就开工。我见过太多项目，图纸画得漂漂亮亮，设备装得整整齐齐，结果一调试，业主说「这不是我要的」。嗯，那场面，真叫一个尴尬。
所以，需求获取是地基。地基不稳，楼盖得再高也得塌。今天我就把这五种最常用的方法掰开揉碎了讲给你听。
4.1 访谈法：最直接，也最容易被带偏
访谈法说白了就是「找人聊天」。但这不是随便聊，你得有目的、有结构。
我的经验：访谈对象要分层。别只盯着领导问，操作工、维修工、甚至保洁阿姨，他们的视角完全不同。
访谈分三种：
- 结构化访谈：问题提前写好，像考试一样。适合收集标准化信息，比如「空调开启时间」「温度设定范围」。
- 半结构化访谈：有个大纲，但允许自由发挥。我比较喜欢这种方式，因为经常能挖出意想不到的需求。
- 非结构化访谈：完全开放式聊天。适合前期探索，但后期效率低。
避坑指南：我曾经访谈一个物业经理，他信誓旦旦说「我们只需要控制照明」。结果后来发现，他们真正痛点是空调能耗太高，只是他不懂怎么表达。所以，别只听表面话，要追问「为什么」。
4.2 问卷调查法：量大，但别指望深度
问卷适合大规模收集数据。比如你要了解整栋楼1000个用户的舒适度感受，一个个访谈不现实，问卷就派上用场了。
设计问卷要注意：
- 问题要具体，别问「你对环境满意吗？」这种废话。要问「您希望办公室温度在多少度？」
- 选项要互斥，别让人纠结。
- 留一个开放题，但别指望太多人填。
注意：问卷回收率通常不高。我做过一次，发了200份，只收回来47份。所以，别把宝全押在问卷上。
4.3 文档分析法：最省力，但信息可能过时
文档分析就是翻图纸、看招标文件、读运维记录。这活儿看起来枯燥，但信息量巨大。
重点看什么？
- 设计图纸：了解系统架构、设备选型。
- 运维日志：看看哪些设备经常坏，哪些报警频繁出现。
- 合同文件：搞清楚甲方的真实预算和期望。
我的习惯：拿到图纸先看变更记录。变更越多的地方，问题越多。你想想看，如果一张图纸改了七八版，说明当初就没想清楚。
4.4 原型法：让用户「看见」需求
很多用户说不清楚自己要什么，但你做个界面给他看，他马上就能说「这里不对」「那里要改」。原型法就是干这个的。
在楼宇自控里，原型可以是：
- 一个简单的HMI界面草图
- 一个模拟的监控大屏
- 甚至是一段动画演示
避坑指南：我曾经用Axure做了个很精美的原型，结果用户以为系统已经做好了，天天催我上线。所以，一定要说清楚「这只是个模型，不是真系统」。
4.5 观察法：最真实，但也最耗时
观察法就是去现场看。看操作工怎么用系统，看设备实际怎么运行。
为什么要观察？因为人说的和做的往往不一样。比如，操作工嘴上说「我每天都会检查报警记录」，实际上可能一周才看一次。
观察法分两种：
- 参与式观察：你跟着操作工一起干活。能获得第一手体验，但可能影响对方正常工作。
- 非参与式观察：你躲在旁边看。更客观，但有些细节可能看不到。
我的经验：观察法最适合发现「隐性需求」。比如，我发现某个机房的空调总是半夜自动关闭，查了半天才发现是保安巡逻时误触了开关。这种问题，访谈和问卷根本问不出来。
4.6 五种方法怎么选？
别纠结哪个最好。实际项目中，我通常是组合使用：
| 阶段 | 推荐方法 | 原因 |
|---|---|---|
| 前期探索 | 访谈法 + 文档分析法 | 快速了解背景和痛点 |
| 中期细化 | 问卷调查法 + 观察法 | 收集量化数据，验证假设 |
| 后期确认 | 原型法 | 让用户确认需求是否准确 |
最后提醒一句：方法只是工具，别为了用方法而用方法。我见过有人拿着问卷到处发，结果问题设计得一塌糊涂，回收的数据根本没法用。嗯，那还不如直接去现场转一圈。
好了，这五种方法就讲到这里。下一章我们聊聊怎么把收集到的需求整理成文档。到时候我会分享一个我踩过的坑——需求文档写得太详细，结果没人看。你猜怎么着？