2. 业务需求分析：需求收集方法论、需求优先级排序、技术可行性评估
说实话，很多架构师一上来就画架构图，这是大忌。
我见过太多项目，技术方案做得漂漂亮亮，结果业务方根本不买账。为什么？因为需求没搞清楚。你想想看，连要解决什么问题都没弄明白，就开始选型、画图，这不是本末倒置吗？
这一章，我就跟你聊聊业务需求分析这件事。说白了，就是搞清楚三件事：用户到底要什么、哪些先做、技术上能不能做。
2.1 需求收集方法论
需求收集，不是拿着本子去问“你有什么需求”。那样问出来的，基本都是伪需求。
我个人习惯用“5W1H + 场景化”的方法。什么意思？就是每个需求都要回答六个问题：
- Who — 谁在用？用户角色是什么？
- What — 要做什么？核心功能是什么？
- Where — 在什么环境下用？PC端？移动端？
- When — 什么时候用？实时还是离线？
- Why — 为什么要做？解决了什么痛点？
- How — 怎么用？操作流程是怎样的？
举个例子。业务方说：“我们需要一个报表系统。” 你如果直接答应，后面就等着被坑吧。
我会追问：“谁看报表？老板看还是运营看？每天什么时候看？数据要实时还是T+1？为什么要看这个报表？是想监控异常还是做决策分析？”
核心原则：需求必须绑定具体场景。没有场景的需求，都是耍流氓。
我在项目中遇到过最典型的一个案例：业务方说要“实时数据大屏”。我们花了三周搭了一套，结果上线后发现，老板每天就看一眼，根本不需要实时。其实一个定时刷新的页面就够了。嗯，这就是典型的伪需求。
2.2 需求优先级排序
需求收集完了，你会发现一个问题：什么都想做，但资源永远不够。
这时候就需要排序。我常用的方法是“价值-成本四象限”，也叫 Eisenhower 矩阵的变体：
| 象限 | 业务价值 | 技术成本 | 处理策略 |
|---|---|---|---|
| 第一象限 | 高 | 低 | 优先做（Quick Win） |
| 第二象限 | 高 | 高 | 规划做（战略投入） |
| 第三象限 | 低 | 低 | 顺手做（锦上添花） |
| 第四象限 | 低 | 高 | 砍掉（坚决不做） |
你可能会问：“这个价值怎么量化？” 我一般用“用户量 × 使用频率 × 业务影响”来估算。比如一个功能影响100万用户，每天用10次，那价值就是1000万级。另一个功能只影响100个内部员工，每周用一次，那价值就低得多。
我的习惯：每次排完优先级，我都会跟业务方过一遍。让他们自己选：是保A功能还是保B功能？把选择题抛回去，别自己扛。
我曾经犯过一个错：把所有高价值需求都排进了第一期。结果开发周期拉长到半年，上线时市场已经变了。后来我学乖了，第一期只做核心闭环，能跑通就行，剩下的迭代加。
2.3 技术可行性评估
需求排好序了，下一步就是：技术上能不能做？
这一步很多人容易走极端。要么什么都敢答应，结果做不出来；要么什么都说不行的，被业务方骂“技术保守”。
我一般从三个维度评估：
- 技术成熟度 — 这个技术我们团队用过吗？社区有没有成熟方案？
- 资源匹配度 — 现有团队能不能搞定？需要招人吗？
- 风险可控度 — 最坏情况是什么？有没有Plan B？
举个例子。业务方说：“我们要做实时推荐系统。” 技术可行性评估怎么做？
- 技术成熟度：实时推荐有成熟的 Flink + Redis 方案，没问题。
- 资源匹配度：团队没人搞过 Flink，需要学习成本。嗯，这里要注意。
- 风险可控度：如果实时搞不定，能不能先用离线推荐顶着？可以。
最后我给的建议是：可以做，但第一期先做离线推荐，实时推荐放到第二期。这样既满足了业务，又给了团队学习时间。
避坑指南：我曾经答应过一个“实时数据同步”的需求，没仔细评估源系统的压力。结果上线后，把业务数据库拖垮了。从那以后，我每次做技术评估，都会加上一句：“源系统扛得住吗？”
2.4 知识体系总览
说了这么多，我画了一张图帮你理清思路。这张图展示了业务需求分析的核心流程：从需求收集，到优先级排序，再到技术评估，环环相扣。
这张图你看懂了吗？从左到右，是一个完整的决策链条。每个环节都不能跳过。我见过太多人，需求没搞清楚就跳到技术选型，结果翻车了。
好了，这一章就聊到这里。记住一句话：需求分析做得好，后面少踩一半坑。