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

Jun 11, 2019

17 | 架构：需求分析 (上)-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

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

2019-06-11 许式伟来自北京

《许式伟的架构课》

课程介绍



讲述：丁伟

时长14:30大小13.34M



你好，我是七牛云许式伟。
前面我们多次提到过，架构的第一步是需求分析。那么，为什么要做需求分析？如何做好需求分析？
今天让我们一起聊一聊需求分析这个话题。
关于需求分析的那些事为何要做需求分析？
首先，当然是因为我们做软件本身就是为了满足用户需求。那么，用户需求到底为何，我们需要清楚定义。
其次，需求边界定义的需要。用户需求理清楚了，不代表产品理清楚了。用户需求的满足一定会有行业分工，我们做什么，合作伙伴做什么，需要厘清大家的边界。
最后，架构设计的需要。架构需要切分子系统，需要我们梳理并对用户需求进行归纳与抽象。架构还需要防止过度设计，把简单的事情复杂化。
但什么是过度设计？不会发生的事情你考虑了并且为它做足了准备，就是过度设计。所以判断是不是过度设计是很困难的，需要对需求未来演化有很强的判断力。
从这几个维度来看，需求分析过程必然会涉及以下这些内容。
我们要面向的核心用户人群是谁？
用户原始需求是什么？最核心问题是哪几个？
已经有哪些玩家在里面？上下游有哪些类型的公司，在我们之前，用户是怎么解决他们的问题的？我们的替换方案又是怎样的？
进而，我们的产品创造的价值点是什么？用户最关注的核心指标是什么？
用户需求潜在的变化在哪些地方？区分出需求的变化点和稳定点。
当然，我并不是说，我们应该在需求分析的文档中完整地回答这些问题。需求分析文档目的并不是回答这些问题。但是在我们梳理需求的过程中，我们无法回避对这些问题的思考。
可能有人会认为，这些问题是 CEO 或产品经理这样的角色需要回答的，而不是架构师需要回答的。
某种意义上来说这句话没错。回答这些问题的首要责任方是 CEO 或产品经理。他们有责任让团队中的每一个人理解我们的产品逻辑。
但是，如果架构师只是被动地接受产品需求，以按图索骥的方式来做架构设计，是不足以成为顶级架构师的。原因在于两点。
一方面，用户需求的深层理解是很难传递的。你看到的产品文档，是产品经理和用户沟通交流后的二次理解，是需求的提炼和二次加工，很难原汁原味地传递用户的述求。
所以架构师自己亲身近距离地接触用户，和用户沟通，去体会用户的述求是非常有必要的。
况且，大部分人并不会那么仔仔细细地阅读别人写的文档。当然这不完全是看文档的人单方面的原因，如果团队文档平均质量不高的话，也会影响到阅读者的心态。
另一方面，产品设计过程需要架构师的深度参与，而不是单向的信息传递。产品经理非常需要来自架构师的建设性意见。
为什么我会有这样的看法呢？这涉及我对产品的理解。产品本身是运用先进的技术来满足用户需求过程的产物。
用户需求的变化是缓慢的，真正改变的是需求的满足方式。而需求满足方式的变化，深层次来说，其背后往往由技术迭代所驱动。
从这个角度来说，产品是桥，它一端连接了用户需求，一端连接了先进的技术。产品经理是需要有技术高度的，他不一定要深刻了解技术的原理，但是一定要深刻理解新技术的边界。
某项技术能够做什么，不能做到什么，顶级产品经理甚至比实现这项技术的开发人员还要清楚。
认为产品经理不需要理解技术，这可能是我们普遍存在的社会现象，但很可能并不符合这个岗位的内在诉求。
回到架构师这个角色。
我经常说一个观点，产品经理和架构师其实是一体两面。两者都需要关心用户需求与产品定义。
只不过产品经理更多从用户需求出发，而架构师更多从技术实现出发，两者是在产品这座桥的两端相向而行，最终必然殊途同归。
这也是我为什么说架构师需要深度参与产品设计的原因。产品经理很可能会缺乏他应该有的技术广度，这就需要架构师去补位。产品定义过程需要反复推敲琢磨，并最终成型。
需求分析并不是纯技术的东西，和编程这件事情无关。它关乎的是用户需求的梳理、产品的清晰定义、可能的演变方向。
需求分析的重要性怎么形容都不过分。准确的需求分析是做出良好架构设计的基础。
前面我也说过，我个人认为架构师在整个架构设计的过程中，至少应该花费三分之一的精力在需求分析上。
这也是为什么很多非常优秀的架构师换到一个新领域后，一上来并不能保证一定能够设计出良好的架构，而是往往需要经过几次迭代才趋于稳定。
原因就在于：领域的需求理解是需要一个过程的，对客户需求的理解不可能一蹴而就。
怎么做需求分析那么怎么才能做好需求分析？
首先，心态第一，心里得装着用户。除了需要 “在心里对需求反复推敲” 的严谨态度外，对用户反馈的尊重之心也至关重要。
其次，对问题刨根究底，找到根源需求。有很多用户反馈需求的时候，往往已经带着他自己给出的解决方案。
这种需求反馈已经属于二次加工的需求，而非原始需求。这个时候我们要多问多推敲，把它还原到不带任何技术实现假设的根源需求。
如上图所示，根源需求可能会有非常非常多的技术方案可以满足它。我们上面示意图中的小圆点是一个个用户反馈的需求。在用户提这些需求的时候，往往可能会带着他熟悉的技术方案的烙印。
对于那些我们明显不关心的需求，如上图的小红点，相对容易排除在外。毕竟产品的边界意识大家还是会有的，产品不可能无限制膨胀下去。
但是对于上面的小绿点，决策上就比较难了。不做？可能会丢了这个客户。做？如果我们手放宽一点，最后产品需求就会被放大（如上图中蓝色的圆圈），做出一个四不像的产品。
最后，在理清楚需求后，要对需求进行归纳整理。一方面，将需求分别归类到不同的子类别中。另一方面，形成需求的变化点和稳定点的基本判断。
前面我们也强调过：在需求分析时，要区分需求的变化点和稳定点。稳定点往往是系统的核心能力，而变化点则需要对应地去考虑扩展性上的设计。
要注意的是，在讨论需求的变化点和稳定点的时候，我们需要有明确参考的坐标系。在不同视角下，稳定点和变化点的判断是完全不同的。
所以需要明确的一点是，当我们说需求的变化点和稳定点时，这是站在我们要设计的产品角度来说的。
比如我们要设计一台计算机，那么多样化的外部设备是一个变化点。但是如果我们今天是在设计一台显示器，问题域就完全变了，需求的变化点和稳定点也就完全发生了变化。
本质上来说，对变化点的梳理，是一次产品边界的确立过程。所谓的开放性设计，就是说我把这个功能交给了合作伙伴，但是我得考虑怎么和合作伙伴配合的问题。
开放性设计并不是一个纯粹的用户需求问题，它通常涉及技术方案的探讨。因此，产品边界的确立不是一个纯需求，也不是一个纯技术，而是两者合而为一的过程。
对变化点的梳理至关重要。产品功能必须是收敛的，必须是可完成的。
如果某个子类别的需求呈现出发散而无法收敛的趋势，这个事情，团队一定要坐下来一起去反复推敲。不断拷问，不断明确响应需求的正确姿势到底为何。
产品定义需求分析的目标和最终结果，都是要最终形成清晰的产品定义。产品定义并不是简单的产品需求的归类。
上面我也说过，产品是桥，它一端连接了用户需求，一端连接了先进的技术。所以产品定义不可能做到和技术方案完全没关系。
首先，需要明确产品中有哪些元素，或者叫资源，以及这些资源的各类操作方式。如果我们从技术的视角来理解，这就是定义对象和方法。当然这仅仅是这么理解，实际上一个我们技术上的对象方法，从产品需求角度会有多条路径的操作方式来达到相同的目的。
其次，需要对产品如何满足用户需求进行确认。用户的使用场景未必全部是我们的产品所能直接满足的，面向特定的行业，有可能需要相应的行业解决方案，把我们的产品整合进去。
我们要避免把行业方案视作产品的一部分。更多的情况下，需要我们更加开放的心态来看待这件事情，优先寻找合作伙伴来一起完成这类行业的需求覆盖。
最后，产品定义还需要考虑市场策略，我们的产品如何进入市场，和既有市场格局中的其他主流解决方案的关系是什么样的。
我们希望获取的用户，可能大部分都已经有一个既有的产品和技术方案，在满足他的需求。在考虑如何让客户从既有方案迁移到我们的产品后，我们确定产品的边界时又会复杂很多。
在一些极其关键的市场，我们有可能会把迁移需求视作产品需求的一部分。但更多的情况下，我们产品上只为这些市场上的主流方案提供迁移路径，而不是完整的迁移方案。
为何架构课从基础平台开始？很抱歉我说得很抽象，但是总结需求分析的方法论的确是一件很难的事情。
为什么我们谈架构会从 “基础平台” 讲起？为什么从硬件架构，到编程语言，再到操作系统，我们似乎绕了一大圈，还没有谈到架构？
有两个原因。
最直接的原因是 “基础平台” 是我们所依赖的环境，是我们应用的业务架构的一部分。越了解我们所处的环境，我们就越能够运用自如。
但还有一个重要的原因是架构的探讨容易过度抽象。所以我并没有先长篇大论谈架构方法论，谈需求应该怎么怎么去分析，而是围绕着基础平台的演进过程来谈需求分析。
信息世界的构建过程，本身就是一个最宏大的架构实践。我们通过对信息世界的骨架构成的参悟，自然能够感悟到架构思维的要点。
学内功需要悟心，学架构也需要悟心。怎么准确研判需求，对需求演进进行预测，这并不是靠技术技能，而是靠谦和求取的心态。
所以我们第一章 “基础平台”  篇整体来说，内容介绍以产品的需求分析为主、核心技术原理为辅。我们尝试把整个基础平台融为一个整体，宏观上不留任何疑惑。
实际上这一章的内容很难做到只看一遍就可以，可能要时时看，反复看。还需要查阅一些资料，也可以与人一起探讨。当然，我们也欢迎留言一起交流。
这一章我们介绍的内容，大部分内容都有一些对应的经典书籍，在后面 “基础平台篇: 回顾与总结” 一讲中，我也会给大家推荐一些经典的图书。
但我们并不是要重复这些书籍中的内容。我们的关注点在于：一是构建信息世界的宏观骨架，二是需求演进。
经典书籍虽然好，但是它们写作时候的历史背景和今天有很大不同。从架构视角来说，结合我们今天的现实情况来看，一方面我们可以总结今天区别于当初的所有变化，另一方面主动去思考为什么发生了这样的变化。以这样的视角去读经典书籍，会别有一番滋味。
结语在我们介绍完第一章 “基础平台” 篇的所有内容后，今天我们终于正式开始谈架构思维。我们探讨的是架构的第一步：需求分析。
需求分析并不是纯技术的东西，和编程这件事情无关。它关乎的是用户需求的梳理、产品的清晰定义、可能的演变方向。
怎么提升需求分析能力，尤其是预判能力？
首先，心态第一，心里得装着用户。除了需要 “在心里对需求反复推敲” 的严谨态度外，对用户反馈的尊重之心也至关重要。
其次，对问题刨根究底，找到根源需求。
最后，对需求进行归纳整理。一方面，将需求分别归类到不同的子类别中。另一方面，形成需求的变化点和稳定点的基本判断。
需求分析的目标和最终结果，都是要最终形成清晰的产品定义。产品定义将明确产品的元素，明确产品的边界，与产业上下游、合作伙伴的分工。
为什么我们的架构课从日常最平常之处，我们日日接触的基础平台讲起？
你真了解它们吗？你真感悟到它们的不凡之处了吗？
学习架构，关键在于匠心与悟心。
用思考的方式去记忆，而不是用记忆的方式去思考。
如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲将是 “架构: 需求分析（下）· 实战案例”。
如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 32

提建议

16 | 安全管理：数字世界的守护

18 | 架构：需求分析 (下) · 实战案例

 写留言

精选留言(47)

Geek_dxm
2019-06-12
架构的设计是宏观的，但是要落到实处是微观的，在考虑架构的时候，我觉得还要装着目前团队的资源、战略、技术结构等，要看是否需要变化，从宏观来设计，从微观来验证，反复循环，才能落到实处。我和同事经常说的一句话，没有落到实处的架构设计，就相当于没有设计。
作者回复: 👍
75
Cordova
2019-06-14
产品的一体两面很赞同！另外我也觉得产品和架构方面负责人都有责任让自己的团队去知道产品当前的定位、上下游关系、产品边界、功能边界、帮助团队每一位成员理清楚稳定需求、扩展需求、和未来可扩展需求的方向，理清楚满足这些需求已使用技术方案、和可使用技术条件，这样，我们每个成员都能思考这个产品是什么，做什么，会成什么样，以及我该有怎样的技术储备，而不是上班简单完成任务，下班随意学习这样一个状态。谢谢许老师的分享！
展开
作者回复: 👍
39
苟范儿
2019-06-12
”产品是桥，它一端连接了用户需求，一端连接了先进的技术“，老师这句话对技术、产品、需求关系的描述太精辟了～
21
ljf10000
2019-06-11
产品经理和架构师是一体两面，这句总结得牛
共 1 条评论
16
小风
2019-09-28
对这章内容深有同感，我们团队通过几年的实践和反复总结也逐渐认识到需求分析的重要性。对于常规的业务应用系统，需求/产品人员往往按照用户提出的需求做出原型，设计/开发人员基于界面原型完成接口设计和开发。实际上，需求人员并没有真正去分析用户需求背后隐含的根源需求，而设计人员也没有意识到他所谓的接口只是和界面耦合的实现，完全体现不出稳定通用的业务内核。导致的直接结果就是界面层次的频繁变动连带后台服务的不断修改。究其一点原因，现在很多开发人员入门的时候(很多需求人员也是从开发转过去的)，面对的就是mvc,orm等各个层次成熟的框架和组件，设计开发系统就是熟练运用这些框架和组件实现功能，逐渐逐渐也就潜意识地认为设计就是组合使用这些框架和组件，去从框架的角度做需求和设计来迎合框架的使用，从而也就忽视了或没有意识到真正的需求分析和设计应该是什么。
展开
作者回复: 👍
共 2 条评论
16
潘华引Simon Pan
2019-06-12
用思考的方式去记忆
11
我在你的视线里
2019-06-11
架构更多的是宏观的东西。看未来远不如看过去清楚。心里装着用户。最好的架构应该是符合人的本能。
11
82
2019-06-14
老师好，以下是我的理解。感觉需求分析的过程就是架构产品的过程。抽象最核心最根本想解决的问题点，围绕它构建产品模型。技术设计感觉像是根据产品模型构建领域模型，将大的问题分解成小的领域模型处理的过程。另外，以前在设计时总是脑补可能的未来场景，想着如何兼容拓展，进而带出一堆暂时用不上的设计。这种过度设计也许就是对产品需求理解的不深吧。我想也许是宏观上的架构一定要考虑长远发展，相对具体的业务要结合具体需求设计，切记避免过度设计。
展开
作者回复: 想着如何扩展肯定是好事，比想不到强太多，过度设计，这是架构师成长的必经之路。要想构建自己对需求发展的预判能力，就要分清楚需求的稳定点和变化点，这个是需要花时间在用户的需求理解上的，不可能一蹴而就。
5
lckfa李钊
2019-06-12
看了两遍,不得不感慨需求分析确实是一件很难的事情,在实际开发中有一个问题就是,有时我们根本不知道现有的技术栈能不能实现某个需求,调研是必不可少的,也可能做着做着,就不得不砍需求了;需求的临时变更是让人无语,架构的设计也可能因为某些个需求的加入或者删除而不得不变化.怎么把变化也考虑到架构中是一个很困难的事情,也可能有公司制度的问题,具体问题当然是要具体分析的,多思考总结,架构师都是野生的,需野蛮生长啊.
4
peter
2019-06-11
老许，我最近在写c，对.h文件中函数的申明，认为自己做的一直不满意。但又找不到好的需求分析模板或方法。您今天说的需求分析比较庞大，我的问题相对小一点。我的理解，编写.h头文件，本质是在将需求分析翻译成代码的过程。希望关于这个点，能听听您的建议。
作者回复: 没错，.h 写的是模块接口，要自然体现需求。觉得对 .h 的函数不满意，其实是对模块架构定义的接口不满意
4
不温暖啊不纯良
2021-04-03
需求分析是架构设计的前置条件，所以作为一个开发人员，一定要想办法接触业务，进一步接触需求，更进一步接触用户。就算是写代码，也是需要设计的，记得自己有一次在准备做一个新功能的时候，在没深入了解需求之间前，我的关注点在如何写代码上，后来又了解了一遍需求，回来之后就把自己写到一半的代码删了，因为我发现要满足这个新需求，根本不需要重新写一个新功能，只需要稍微改一下页面的交互方式就能够满足，在正确理解需求的前提下，就算你的效率低，你的进度也是一直往前的，最可怕的事情不是你做的慢，而是因为你干脆就做错事情了，在错误的方向上效率越高不就越糟糕嘛。总结一下老师的分析需求的方法论。第一，你要不断让自己更靠近需求的源头。第二，在收到需求之后要分析这个需求是原汁原味的需求，还是已经被加工了的需求，如果是后者，那就要继续追问，寻求最根源上的需求。第三，归纳整理收集到的需求，然后，选择你所要服务的人群，找到自己产品的核心。第四，预测需求日后的变化，提前在这些地方做出可扩展性的设计。
展开
作者回复: 👍
4
Aaron Cheung
2019-06-12
打卡17 目前感觉需求分析可能占六七成
3
李二木
2021-02-02
为何要做需求分析 1) 因为我们做软件本身就是为了满足用户需求。用户需求到底为何，我们需要清楚定义。 2) 需求边界定义的需要。用户需求理清楚了，不代表产品理清楚了。用户需求的满足一定会有行业分工，我们做什么，合作伙伴做什么，需要厘清大家的边界。 3) 架构设计的需要。架构需要切分子系统，需要我们梳理并对用户需求进行归纳与抽象。架构还需要防止过度设计，把简单的事情复杂化。需求分析过程必然会涉及以下这些内容 1) 我们要面向的核心用户人群是谁？ 2) 用户原始需求是什么？最核心问题是哪几个？ 3) 已经有哪些玩家在里面？上下游有哪些类型的公司，在我们之前，用户是怎么解决他们的问题的？我们的替换方案又是怎样的？ 4) 进而，我们的产品创造的价值点是什么？用户最关注的核心指标是什么？ 5) 用户需求潜在的变化在哪些地方？区分出需求的变化点和稳定点。如果架构师只是被动地接受产品需求不利原因在于两点 1) 用户需求的深层理解是很难传递的 2) 产品设计过程需要架构师的深度参与，而不是单向的信息传递。产品经理非常需要来自架构师的建设性意见怎么做需求分析 1) 心态第一，心里得装着用户 2) 对问题刨根究底，找到根源需求 3) 在理清楚需求后，要对需求进行归纳整理需要明确的一点是，当我们说需求的变化点和稳定点时，这是站在我们要设计的产品角度来说的。产品定义 1) 需要明确产品中有哪些元素，或者叫资源，以及这些资源的各类操作方式 2) 需要对产品如何满足用户需求进行确认 3) 产品定义还需要考虑市场策略，我们的产品如何进入市场，和既有市场格局中的其他主流解决方案的关系是什么样的。为何架构课从基础平台开始 1） “基础平台” 是我们所依赖的环境，是我们应用的业务架构的一部分。越了解我们所处的环境，我们就越能够运用自如。 2）架构的探讨容易过度抽象
展开
2
悠游
2020-06-04
梁宁老师的产品思维课值得好好读一读
2
阿卡牛
2019-07-08
红绿色盲看到的都是绿点~~
2
晓凉
2019-06-15
需求分析确实太难了，平时说需求分析大多是分析客户需求，但要做出好产品，不只要分析客户的需求。产品的研发和运营的过程中，有大量的利益相关者，它们的需求可能都需要分析。还有大量技术或非技术的制约条件，不是一般人容易看清楚的。能在行业或社会尺度上搞清楚需求的，都已经成为大佬，或将会成为大佬。
2
迷途书童
2019-06-13
许老师：你把产品，需求，技术三者的关系形容成产品是一座桥连接了技术和需求，这个比喻不太好，会给人感觉产品就像一个媒婆，连接了男方和女方。实际上产品是最终的一个输出或者目标，技术是一个手段，按照需求的定义用来实现这个目标的。桥这个这个比喻无法直观体现手段与目的这个关系
作者回复: 好吧😂
共 2 条评论
2
忠厚
2022-03-24
"用户需求的变化是缓慢的，真正改变的是需求的满足方式. " 这段让我受益匪浅，一下子好像串通了好多事！
2
Geek007
2019-12-31
“产品是桥，它一端连接了用户需求，一端连接了先进的技术”，切中要害
1
头发茂密
2019-12-24
金句：用思考的方式去记忆，而不是用记忆的方式去思考
1

