2. 项目需求调研方法论：需求调研的5W1H法、干系人识别与访谈技巧、需求文档的撰写规范
2.1 为什么需求调研是储能项目的“生死线”
说实话，我见过太多储能项目翻车了。翻车的原因五花八门，但根子往往只有一个——需求没搞清楚。
你想想看，一个储能系统少则几十万，多则上亿。设备进场了，才发现客户要的是削峰填谷，你给设计成了后备电源。这能不出问题吗？
我个人习惯，在项目启动前，至少花20%的时间在需求调研上。别觉得这是浪费时间。磨刀不误砍柴工，这个道理在储能行业尤其适用。
核心观点：需求调研不是“问问题”，而是“挖真相”。客户说的不一定是他真正要的，你得学会听“弦外之音”。
2.2 5W1H法：把需求问透
5W1H不是什么新鲜东西，但真正用好的人不多。我把它改造成适合储能项目的版本，你直接拿去用。
| 维度 | 储能场景下的具体问题 | 常见踩坑点 |
|---|---|---|
| Why（为什么做） | 客户的核心诉求是什么？省钱？合规？还是品牌形象？ | 客户说“要节能”，实际是“要补贴” |
| What（做什么） | 系统容量多大？充放电策略？并网还是离网？ | 只问容量，不问负载特性 |
| Where（在哪做） | 场地条件如何？有没有遮阳？通风好不好？ | 忽略现场勘测，图纸和实际差很多 |
| When（何时做） | 投运时间？峰谷时段？季节性负载变化？ | 只问现在，不问未来3-5年规划 |
| Who（谁来做/谁受益） | 运维团队水平如何？决策链有多长？ | 只对接技术，忽略财务和法务 |
| How（怎么做） | 预算多少？验收标准？运维模式？ | 默认客户懂技术，沟通用太多术语 |
我在项目中遇到过一件事：客户说“我们要做光储充一体化”。我按5W1H一问，发现他们真正要的是“用光伏发电给充电桩供电，储能只是备选方案”。你看，一字之差，系统架构完全不同。
小技巧：每次访谈前，把5W1H列成清单。问完一个划掉一个。别怕问题多，怕的是漏掉关键点。
2.3 干系人识别：谁说了算？谁会用？谁买单？
储能项目的干系人，远比你想的复杂。我一般把他们分成三类：
- 决策者：通常是老板或项目总监。他们关心投资回报率、政策合规性。
- 使用者：运维团队、现场工程师。他们关心好不好用、好不好修。
- 影响者：财务、法务、政府监管部门。他们关心预算、合同、安全标准。
嗯，这里要注意。很多人只盯着决策者，忽略了使用者和影响者。结果呢？系统上线了，运维说“这界面太难用了”，财务说“超预算了”，法务说“合同条款有问题”。
我曾经在一个工业园区项目上，就因为没提前和消防部门沟通，导致验收时被卡了两个月。从那以后，我每次做干系人分析，都会画一张干系人影响力-兴趣矩阵图。
2.4 访谈技巧：别把天聊死
访谈不是审问。我见过太多人拿着问题清单，一条一条念，客户回答“是”或“不是”，然后就没有然后了。
我的做法是：
- 先聊家常，再聊正事。 “最近天气热，你们厂区用电压力大吧？”——这种开场白比“请问你们的需求是什么”好十倍。
- 多问开放式问题。 别问“你们需要储能吗？”，要问“你们目前用电最大的痛点是什么？”
- 学会追问。 客户说“我们想省钱”，你就要追问“省多少？从哪省？省下来的钱打算怎么用？”
- 记录，但别只顾着记录。 眼睛要看对方，点头、微笑、给反馈。别全程低头写字。
避坑指南：我曾经在访谈时太着急，客户说“我们想要一套智能管理系统”，我立刻开始讲EMS架构。结果客户其实只是想要一个能远程看电量的APP。所以，先听完，再判断，别急着给方案。
2.5 需求文档的撰写规范：把“人话”翻译成“技术话”
需求文档是干什么用的？说白了，就是让所有人对“我们要做什么”达成共识。
我见过最烂的需求文档，通篇都是“系统应具备良好的性能”、“界面应友好易用”。这种话写了等于没写。什么叫“良好”？什么叫“友好”？每个人理解都不一样。
好的需求文档，应该满足三个标准：
- 可量化： 不说“响应快”，说“页面加载时间不超过2秒”。
- 可验证： 不说“系统稳定”，说“连续运行30天无故障”。
- 无歧义： 不说“支持多种模式”，说“支持削峰填谷、需量管理、后备电源三种模式，且可一键切换”。
我个人习惯用这样的模板：
# 需求编号：REQ-2024-001
# 需求名称：储能系统充放电策略
# 需求来源：客户技术负责人（张工）
# 优先级：P1（必须实现）
# 详细描述：
# 系统应支持基于分时电价的自动充放电策略。
# 具体参数：
# - 充电时段：00:00-08:00（谷时电价）
# - 放电时段：18:00-22:00（峰时电价）
# - SOC保护范围：10%-90%
# - 策略可远程修改，修改后5分钟内生效
# 验收标准：
# 1. 系统按策略自动执行充放电，连续运行7天无异常
# 2. 远程修改策略后，系统在5分钟内切换为新策略
# 3. 当SOC低于10%时，自动停止放电并报警小技巧：写完需求文档后，找一个人“读一遍”。如果他能不看任何解释就理解你的意思，那这份文档就合格了。
2.6 知识体系框架图
下面这张图，是我自己总结的需求调研方法论框架。你可以把它当作一个检查清单，每次做调研前看一眼。
2.7 写在最后
需求调研这件事，说难不难，说简单也不简单。它考验的不是你的技术能力，而是你的沟通能力和逻辑思维。
记住一句话：需求调研的终点，不是写出一份文档，而是让所有干系人都在同一页上。
好了，这一章就到这里。下一章我们聊聊如何把需求转化成系统架构设计——那才是真正考验功力的时候。