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

架构的设计是宏观的，但是要落到实处是微观的，在考虑架构的时候，我觉得还要装着目前团队的资源、战略、技术结构等，要看是否需要变化，从宏观来设计，从微观来验证，反复循环，才能落到实处。我和同事经常说的一句话，没有落到实处的架构设计，就相当于没有设计。

产品的一体两面很赞同！另外我也觉得产品和架构方面负责人都有责任让自己的团队去知道产品当前的定位、上下游关系、产品边界、功能边界、帮助团队每一位成员理清楚稳定需求、扩展需求、和未来可扩展需求的方向，理清楚满足这些需求已使用技术方案、和可使用技术条件，这样，我们每个成员都能思考这个产品是什么，做什么，会成什么样，以及我该有怎样的技术储备，而不是上班简单完成任务，下班随意学习这样一个状态。谢谢许老师的分享！

对这章内容深有同感，我们团队通过几年的实践和反复总结也逐渐认识到需求分析的重要性。对于常规的业务应用系统，需求/产品人员往往按照用户提出的需求做出原型，设计/开发人员基于界面原型完成接口设计和开发。实际上，需求人员并没有真正去分析用户需求背后隐含的根源需求，而设计人员也没有意识到他所谓的接口只是和界面耦合的实现，完全体现不出稳定通用的业务内核。导致的直接结果就是界面层次的频繁变动连带后台服务的不断修改。究其一点原因，现在很多开发人员入门的时候(很多需求人员也是从开发转过去的)，面对的就是mvc,orm等各个层次成熟的框架和组件，设计开发系统就是熟练运用这些框架和组件实现功能，逐渐逐渐也就潜意识地认为设计就是组合使用这些框架和组件，去从框架的角度做需求和设计来迎合框架的使用，从而也就忽视了或没有意识到真正的需求分析和设计应该是什么。

老师好，以下是我的理解。 感觉需求分析的过程就是架构产品的过程。抽象最核心最根本想解决的问题点，围绕它构建产品模型。 技术设计感觉像是根据产品模型构建领域模型，将大的问题分解成小的领域模型处理的过程。 另外，以前在设计时总是脑补可能的未来场景，想着如何兼容拓展，进而带出一堆暂时用不上的设计。这种过度设计也许就是对产品需求理解的不深吧。 我想也许是宏观上的架构一定要考虑长远发展，相对具体的业务要结合具体需求设计，切记避免过度设计。

需求分析是架构设计的前置条件，所以作为一个开发人员，一定要想办法接触业务，进一步接触需求，更进一步接触用户。 就算是写代码，也是需要设计的，记得自己有一次在准备做一个新功能的时候，在没深入了解需求之间前，我的关注点在如何写代码上，后来又了解了一遍需求，回来之后就把自己写到一半的代码删了，因为我发现要满足这个新需求，根本不需要重新写一个新功能，只需要稍微改一下页面的交互方式就能够满足，在正确理解需求的前提下，就算你的效率低，你的进度也是一直往前的，最可怕的事情不是你做的慢，而是因为你干脆就做错事情了，在错误的方向上效率越高不就越糟糕嘛。 总结一下老师的分析需求的方法论。 第一，你要不断让自己更靠近需求的源头。 第二，在收到需求之后要分析这个需求是原汁原味的需求，还是已经被加工了的需求，如果是后者，那就要继续追问，寻求最根源上的需求。 第三，归纳整理收集到的需求，然后，选择你所要服务的人群，找到自己产品的核心。 第四，预测需求日后的变化，提前在这些地方做出可扩展性的设计。

老许，我最近在写c，对.h文件中函数的申明，认为自己做的一直不满意。但又找不到好的需求分析模板或方法。您今天说的需求分析比较庞大，我的问题相对小一点。我的理解，编写.h头文件，本质是在将需求分析翻译成代码的过程。希望关于这个点，能听听您的建议。

许老师： 你把产品，需求，技术三者的关系 形容成 产品是一座桥连接了技术和需求，这个比喻不太好，会给人感觉产品就像一个媒婆， 连接了男方和女方。 实际上产品是最终的一个输出或者目标，技术是一个手段， 按照需求的定义 用来实现这个目标的。 桥这个这个比喻无法直观体现手段与目的这个关系

请问老师，"我们要避免把行业方案视作产品的一部分。"的意思是说 产品本身作为一层，然后再加上一层，这一层把产品整合到企业的行业方案，是这个意思吗？

注意的是，在讨论需求的变化点和稳定点的时候，我们需要有明确参考的坐标系。在不同视角下，稳定点和变化点的判断是完全不同的。老师能不能举个例子？

关于需求分析那些事儿中的[其次]部门 [用户需求的满足一定会有行业分工，我们做什么，合作伙伴做什么，需要厘清大家的边界。] 厘清应该为理清吧。