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

”产品是桥，它一端连接了用户需求，一端连接了先进的技术“，老师这句话对技术、产品、需求关系的描述太精辟了～

产品经理和架构师是一体两面，这句总结得牛

架构更多的是宏观的东西。看未来远不如看过去清楚。心里装着用户。最好的架构应该是符合人的本能。

用思考的方式去记忆

看了两遍,不得不感慨需求分析确实是一件很难的事情,在实际开发中有一个问题就是,有时我们根本不知道现有的技术栈能不能实现某个需求,调研是必不可少的,也可能做着做着,就不得不砍需求了;需求的临时变更是让人无语,架构的设计也可能因为某些个需求的加入或者删除而不得不变化.怎么把变化也考虑到架构中是一个很困难的事情,也可能有公司制度的问题,具体问题当然是要具体分析的,多思考总结,架构师都是野生的,需野蛮生长啊.

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

打卡17 目前感觉需求分析可能占六七成

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

终于进入正题了，豁然开朗，只有趟过坑才知道，这里面说的多务实

红绿色盲看到的都是绿点~~

需求分析，在大公司工作的时候，这是第一步，而且是需要严格执行的，所以看到这部分特别有感触。好的需求分析，能带来一个产品往好的方向上走，如果来一个需求就做，那这个产品是做不好的

需求分析确实太难了，平时说需求分析大多是分析客户需求，但要做出好产品，不只要分析客户的需求。产品的研发和运营的过程中，有大量的利益相关者，它们的需求可能都需要分析。还有大量技术或非技术的制约条件，不是一般人容易看清楚的。能在行业或社会尺度上搞清楚需求的，都已经成为大佬，或将会成为大佬。

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

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

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

一门深入 长时薰修

本篇在整个架构课框架中承上启下，需要反复读，精读。再次感谢许老师。