笔记 · 17 | 架构：需求分析 (上)

本篇要回答的问题：架构第一步——为什么要做需求分析？怎么才能做好？ 它和"产品定义"是什么关系？为什么这门架构课偏偏从基础平台讲起？

第一章"基础平台篇"讲完了硬件、编程语言、操作系统的全部内容，本讲正式进入架构思维，谈架构的第一步：需求分析。它不是纯技术活，而关乎用户需求的梳理、产品的清晰定义、可能的演变方向。

关于需求分析的那些事

为何要做需求分析？三个层次：

关键判断：什么是过度设计？"不会发生的事情你考虑了并为它做足准备"就是过度设计。判断难就难在它需要对需求未来演化有很强的预判力。

需求分析过程必然涉及的思考（不必都写进文档，但无法回避）：核心用户人群是谁、原始需求是什么、已有哪些玩家、产品价值点与核心指标、需求的变化点与稳定点。

核心观点：架构师不能只被动接受产品需求、按图索骥。原因有二：① 用户需求的深层理解很难传递（产品文档是二次加工）；② 产品设计需要架构师深度参与，而非单向信息传递。

关键洞见：产品经理与架构师是一体两面——都关心用户需求与产品定义，只是产品经理从用户需求出发、架构师从技术实现出发，在"产品"这座桥的两端相向而行，殊途同归。“产品是桥，一端连用户需求，一端连先进技术。”

重要判断：用户需求的变化是缓慢的，真正改变的是需求的满足方式，而满足方式的变化背后由技术迭代驱动。所以顶级产品经理甚至比开发更清楚某项技术的边界。

需求分析重要到什么程度？架构师至少应花三分之一精力在需求分析上。这也解释了为何优秀架构师换新领域往往要几次迭代才趋稳——领域需求理解需要一个过程。

步骤	要点
① 心态第一	心里装着用户：既要"反复推敲"的严谨，也要对用户反馈的尊重之心
② 刨根究底	找到根源需求——用户反馈常已带着自己的解决方案（二次加工需求），要还原到不带技术假设的原始需求
③ 归纳整理	一是归类到不同子类别；二是形成变化点与稳定点的基本判断

从一个个用户反馈还原到根源需求

关键洞见：图中小红点（明显不关心）易排除，但小绿点最难决策——不做可能丢客户，手放宽了产品需求就被放大成"四不像"。

关于变化点/稳定点的两个要点：

要点	说明
稳定点 = 系统核心能力；变化点 = 需做扩展性设计	——
必须有明确参考坐标系	站在"要设计的产品"角度——设计计算机时外设是变化点，但设计显示器时问题域完全变了

关键判断：对变化点的梳理，本质是一次产品边界的确立过程。开放性设计不是纯需求也不是纯技术，而是两者合而为一。产品功能必须收敛、必须可完成；若某子类需求发散无法收敛，团队必须坐下来反复推敲。

需求分析的最终结果是形成清晰的产品定义——它不是产品需求的简单归类，因为"产品是桥"，必然与技术方案有关。产品定义要明确三件事：

维度	内容	图示
元素/资源与操作	技术视角即"定义对象和方法"
如何满足需求	面向特定行业可能需行业解决方案，应优先找合作伙伴，避免把行业方案当产品一部分
市场策略	与既有主流方案的关系；多数只提供迁移路径而非完整迁移方案

原因	说明
基础平台是我们依赖的环境	它是业务架构的一部分，越了解越能运用自如
架构探讨容易过度抽象	围绕基础平台的演进过程谈需求分析，比空谈方法论更有抓手

关键洞见：信息世界的构建过程本身就是最宏大的架构实践。“学架构需要悟心——用思考的方式去记忆，而不是用记忆的方式去思考。”

需求分析是架构第一步、占架构师三分之一精力，关乎需求梳理、产品定义与演变预判。做法是三步法：心态第一、刨根究底找根源需求、归纳整理出变化点/稳定点。最终落到清晰的产品定义——明确元素与操作、满足方式、市场策略与产业分工。

需求分析三步走——心里装用户、刨到根源需求、归纳出变化点/稳定点；最终把模糊诉求收敛成可完成的清晰产品定义。

怎么提升需求分析能力，尤其是预判能力？回到你自己的项目：你最近一次接到的需求，有没有还原到"不带任何技术实现假设的根源需求"？如果没有，你很可能正在为用户自带的某个解决方案做设计，而不是为他真正的问题做设计。