2、需求分析与规划：业务需求调研、技术选型原则、系统边界定义、项目里程碑规划

说实话，很多风电平台项目一开始就栽了跟头。为什么？因为大家急着写代码，急着搭架构，却忘了最根本的事——搞清楚你到底要建什么。

我见过太多团队，上来就讨论用 Kafka 还是 RabbitMQ，争论微服务还是单体架构。结果呢？三个月后才发现，客户真正需要的只是一个能稳定采集振动数据的网关。嗯，这就是典型的「需求没对齐」。

这一章，我就带你走一遍我自己的「需求分析与规划」四步法。每一步都是我在真实项目中踩过坑、填过土之后沉淀下来的。

2.1 业务需求调研：别让客户说「你看着办」

调研不是拿着问卷去问问题。我个人习惯是：先看现场，再聊痛点，最后才看数据。

第一步：现场走一圈

你想想看，一个风电场的运维人员，每天面对的是什么？是几十台风机、几百个传感器、上千条报警。他们最怕的不是数据多，而是数据来了不知道看哪里。

我在江苏某风电场调研时，运维班长跟我说了一句话，我到现在都记得：「你们搞的系统，别让我点超过三次鼠标。」

第二步：梳理核心角色

一个风电平台，至少涉及这几类人：

• 运维人员：关注实时告警、设备状态、工单处理
• 设备工程师：关注振动趋势、温度曲线、故障诊断
• 管理层：关注发电量、可利用率、运维成本
• 数据分析师：关注历史数据、模型训练、预测结果

第三步：输出需求清单

调研结束后，我会输出一份《业务需求调研报告》。里面必须包含：

• 核心业务场景（至少5个）
• 用户痛点清单（按优先级排序）
• 数据流简图（谁产生数据、谁消费数据）
• 非功能性需求（响应时间、并发量、数据保留周期）

2.2 技术选型原则：别追新，要追稳

技术选型这件事，我吃过不少亏。曾经有个项目，我选了当时最火的流处理框架，结果社区版本迭代太快，半年后接口全变了，我们被迫重构。从那以后，我给自己定了三条铁律：

1. 成熟度优先：选社区活跃、版本稳定、文档齐全的技术栈
2. 团队熟悉度：再好的技术，团队没人会用，就是灾难
3. 生态兼容性：选的技术要能跟上下游系统无缝对接

具体到风电平台，我一般这样选：

2.3 系统边界定义：画好你的「势力范围」

系统边界，说白了就是「哪些事归我管，哪些事不归我管」。很多项目后期扯皮，就是因为边界没划清楚。

我习惯用一张图来定义系统边界。下面是我为风电平台画的边界图：

从这张图你能看到：

• 数据采集层：只负责收数据，不负责分析
• 数据处理层：只负责计算和存储，不负责展示
• 应用服务层：只负责业务逻辑，不负责数据采集
• 展示层：只负责呈现，不负责业务逻辑

边界外的东西，比如硬件固件升级、财务结算、人员排班，这些要么由其他系统负责，要么我们明确告诉客户「这个我们不做」。划清楚，后面少吵架。

2.4 项目里程碑规划：把大象装进冰箱分几步

项目规划这件事，我个人的经验是：宁可多分阶段，不要一口吃成胖子。风电平台这种项目，涉及硬件对接、数据采集、实时计算、可视化展示，任何一个环节出问题，整个项目都可能延期。

我一般把项目分成四个里程碑：

最后说一句：规划阶段多花一周，执行阶段少花一个月。这个道理，我是用几个通宵换来的。

公众号:蓝海资料掘金营，微信deep3321