17 | 架构:需求分析 (上)
许式伟
该思维导图由 AI 生成,仅供参考
你好,我是七牛云许式伟。
前面我们多次提到过,架构的第一步是需求分析。那么,为什么要做需求分析?如何做好需求分析?
今天让我们一起聊一聊需求分析这个话题。
关于需求分析的那些事
为何要做需求分析?
首先,当然是因为我们做软件本身就是为了满足用户需求。那么,用户需求到底为何,我们需要清楚定义。
其次,需求边界定义的需要。用户需求理清楚了,不代表产品理清楚了。用户需求的满足一定会有行业分工,我们做什么,合作伙伴做什么,需要厘清大家的边界。
最后,架构设计的需要。架构需要切分子系统,需要我们梳理并对用户需求进行归纳与抽象。架构还需要防止过度设计,把简单的事情复杂化。
但什么是过度设计?不会发生的事情你考虑了并且为它做足了准备,就是过度设计。所以判断是不是过度设计是很困难的,需要对需求未来演化有很强的判断力。
从这几个维度来看,需求分析过程必然会涉及以下这些内容。
我们要面向的核心用户人群是谁?
用户原始需求是什么?最核心问题是哪几个?
已经有哪些玩家在里面?上下游有哪些类型的公司,在我们之前,用户是怎么解决他们的问题的?我们的替换方案又是怎样的?
进而,我们的产品创造的价值点是什么?用户最关注的核心指标是什么?
用户需求潜在的变化在哪些地方?区分出需求的变化点和稳定点。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文主要讨论了架构设计中的需求分析的重要性以及如何进行有效的需求分析。作者首先强调了需求分析在架构设计中的关键作用,指出需求分析是为了满足用户需求、定义产品边界和指导架构设计。然后,作者提出了如何进行需求分析,包括关注核心用户群体、理清用户原始需求、分析市场上的竞争对手、确定产品的价值点和关注用户需求的潜在变化等方面。此外,作者还强调了架构师在需求分析中的重要性,认为架构师需要深度参与产品设计,并指出准确的需求分析是做出良好架构设计的基础。最后,作者提出了在需求分析中需要注意的事项,包括心态第一、找到根源需求和对需求进行归纳整理。整体而言,本文突出了需求分析在架构设计中的关键作用,以及如何进行有效的需求分析,对于从事架构设计和产品开发的技术人员具有一定的指导意义。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《许式伟的架构课》,新⼈⾸单¥68
《许式伟的架构课》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(49)
- 最新
- 精选
- Geek_dxm架构的设计是宏观的,但是要落到实处是微观的,在考虑架构的时候,我觉得还要装着目前团队的资源、战略、技术结构等,要看是否需要变化,从宏观来设计,从微观来验证,反复循环,才能落到实处。我和同事经常说的一句话,没有落到实处的架构设计,就相当于没有设计。
作者回复: 👍
2019-06-1278 - Cordova产品的一体两面很赞同!另外我也觉得产品和架构方面负责人都有责任让自己的团队去知道产品当前的定位、上下游关系、产品边界、功能边界、帮助团队每一位成员理清楚稳定需求、扩展需求、和未来可扩展需求的方向,理清楚满足这些需求已使用技术方案、和可使用技术条件,这样,我们每个成员都能思考这个产品是什么,做什么,会成什么样,以及我该有怎样的技术储备,而不是上班简单完成任务,下班随意学习这样一个状态。谢谢许老师的分享!
作者回复: 👍
2019-06-1441 - 小风对这章内容深有同感,我们团队通过几年的实践和反复总结也逐渐认识到需求分析的重要性。对于常规的业务应用系统,需求/产品人员往往按照用户提出的需求做出原型,设计/开发人员基于界面原型完成接口设计和开发。实际上,需求人员并没有真正去分析用户需求背后隐含的根源需求,而设计人员也没有意识到他所谓的接口只是和界面耦合的实现,完全体现不出稳定通用的业务内核。导致的直接结果就是界面层次的频繁变动连带后台服务的不断修改。究其一点原因,现在很多开发人员入门的时候(很多需求人员也是从开发转过去的),面对的就是mvc,orm等各个层次成熟的框架和组件,设计开发系统就是熟练运用这些框架和组件实现功能,逐渐逐渐也就潜意识地认为设计就是组合使用这些框架和组件,去从框架的角度做需求和设计来迎合框架的使用,从而也就忽视了或没有意识到真正的需求分析和设计应该是什么。
作者回复: 👍
2019-09-28216 - 82老师好,以下是我的理解。 感觉需求分析的过程就是架构产品的过程。抽象最核心最根本想解决的问题点,围绕它构建产品模型。 技术设计感觉像是根据产品模型构建领域模型,将大的问题分解成小的领域模型处理的过程。 另外,以前在设计时总是脑补可能的未来场景,想着如何兼容拓展,进而带出一堆暂时用不上的设计。这种过度设计也许就是对产品需求理解的不深吧。 我想也许是宏观上的架构一定要考虑长远发展,相对具体的业务要结合具体需求设计,切记避免过度设计。
作者回复: 想着如何扩展肯定是好事,比想不到强太多,过度设计,这是架构师成长的必经之路。要想构建自己对需求发展的预判能力,就要分清楚需求的稳定点和变化点,这个是需要花时间在用户的需求理解上的,不可能一蹴而就。
2019-06-146 - 不温暖啊不纯良需求分析是架构设计的前置条件,所以作为一个开发人员,一定要想办法接触业务,进一步接触需求,更进一步接触用户。 就算是写代码,也是需要设计的,记得自己有一次在准备做一个新功能的时候,在没深入了解需求之间前,我的关注点在如何写代码上,后来又了解了一遍需求,回来之后就把自己写到一半的代码删了,因为我发现要满足这个新需求,根本不需要重新写一个新功能,只需要稍微改一下页面的交互方式就能够满足,在正确理解需求的前提下,就算你的效率低,你的进度也是一直往前的,最可怕的事情不是你做的慢,而是因为你干脆就做错事情了,在错误的方向上效率越高不就越糟糕嘛。 总结一下老师的分析需求的方法论。 第一,你要不断让自己更靠近需求的源头。 第二,在收到需求之后要分析这个需求是原汁原味的需求,还是已经被加工了的需求,如果是后者,那就要继续追问,寻求最根源上的需求。 第三,归纳整理收集到的需求,然后,选择你所要服务的人群,找到自己产品的核心。 第四,预测需求日后的变化,提前在这些地方做出可扩展性的设计。
作者回复: 👍
2021-04-035 - peter老许,我最近在写c,对.h文件中函数的申明,认为自己做的一直不满意。但又找不到好的需求分析模板或方法。您今天说的需求分析比较庞大,我的问题相对小一点。我的理解,编写.h头文件,本质是在将需求分析翻译成代码的过程。希望关于这个点,能听听您的建议。
作者回复: 没错,.h 写的是模块接口,要自然体现需求。觉得对 .h 的函数不满意,其实是对模块架构定义的接口不满意
2019-06-114 - 迷途书童许老师: 你把产品,需求,技术三者的关系 形容成 产品是一座桥连接了技术和需求,这个比喻不太好,会给人感觉产品就像一个媒婆, 连接了男方和女方。 实际上产品是最终的一个输出或者目标,技术是一个手段, 按照需求的定义 用来实现这个目标的。 桥这个这个比喻无法直观体现手段与目的这个关系
作者回复: 好吧😂
2019-06-1322 - panqing请问老师,"我们要避免把行业方案视作产品的一部分。"的意思是说 产品本身作为一层,然后再加上一层,这一层把产品整合到企业的行业方案,是这个意思吗?
作者回复: 是的
2019-09-301 - Geek_88604f注意的是,在讨论需求的变化点和稳定点的时候,我们需要有明确参考的坐标系。在不同视角下,稳定点和变化点的判断是完全不同的。老师能不能举个例子?
作者回复: 文章有例子
2019-06-131 - 在路上关于需求分析那些事儿中的[其次]部门 [用户需求的满足一定会有行业分工,我们做什么,合作伙伴做什么,需要厘清大家的边界。] 厘清应该为理清吧。
作者回复: 好像有厘清这个词
2019-06-111
收起评论