2019-12-31感觉这样的架构师不仅让产品经理失业了，还让项目经理失业了😄作者回复: 产品经理关注的维度不太一样，关键词是：用户需求、技术赋能、商业成功。而架构师的关键词是：用户需求、技术实现、业务迭代。产品经理与架构师是一体两面，对人的能力要求的确会比较像，但是分工不同。项目经理在很多公司并不存在，它是交付类工作比较多的情况下的产物。
1 8
2019-12-27项目管理有去评判一个项目成不成功狭义来讲是项目有没有在限定的时间、资源把项目成功交付， 广义的来讲是项目客户满不满意、项目的成果有没有被应用并产生预期效果。 视角不一样 境界完全不一样，架构师也一样作者回复: 👍
1 2
2019-12-31许老师，有些产品就是要解决某个领域的特定问题的，像CRM这样的产品。像好用和易用大部分是由于产品设计决定的，如果一个产品设计的不好，比如用户使用的场景化考虑的不够，交互设计不够，这种情况下，架构师有什么好的办法吗可以让开发出来的产品好用呢，谢谢啦。易用性指标上，架构师可以做什么贡献呢？作者回复: 易用性需要打磨，没有捷径。所有角色都可以对产品提出见解，最终形成多个不同的方案来对比。
1 1
2019-12-27期待软件工程的未来 在老师说的很多基础服务固化之后 后端工程师还能在何处进行发展 1
2019-12-27非常期待后面的课程，特别是如何阅读别人的代码 1
2020-01-04关于软件工程的论述让人大开眼界，特别是关于软件工程本质的归纳高度很不一般。结合老师关于软件工程的宏观论述和当下的现状有一些疑问：
（1）微服务对软件工程管理带来了很大的冲击。微服务强调小而自治，快速开发，快速发布，快速试错。微服务的研发团队通常也很小，10个以下，3～5也很常见，用户的需求怎么做几个人碰个头就开搞了，没有架构师参与，质量保证工工作也不多。这样做也不是没有道理，因为有些需求最终有多少用户使用可能是个未知数，投入的资源很可能带不来价值。这种情况下软件工程应该怎做。
（2）软件工程和微服务治理之间有没有什关联？传统的软件工程是服务上线前的治理，服务治理是服务上线后的软件工程。随着服务治理技术的发展，高可用用、高性能等质量属性通过服务治理就能搞定，会不会逐步降低线下质量保证工工作的重要性？展开作者回复: 1、微服务会让团队对架构能力产生更大的依赖。架构把控力不强的团队，大半会被微服务带进坑里。我们评价一个团队的架构能力好坏，看的关键是是否能够“坚持最小化的核心系统不变”，如果增加一个微服务团队不需要改变核心系统，那只能说你们的架构太牛了。
2、服务治理解决的是无缺陷系统的稳定运行，并不能解决非可用性相关的问题。
2020-01-01要将所做的项目或者产品当成一个有生命体的，有生命力的事物来看待，从生到死，负责到底，，，这是最基本的职业素养和道德😎
2019-12-27许老师，如你所说产品设计阶段架构师参与其中，虽然有比较明确的职责，产品负责需求边界、架构负责技术方案，决策的时候有冲突了，这个时候依靠什么去决策？七牛一般怎么做？盼复，谢谢作者回复: 还是产品经理决策。如果还有疑义，可以找双方共同的上级。
2019-12-27许老师后续是否可以讲一下ai的浪潮下对做工程的同学以及架构师们带来的改变有哪些作者回复: ai 背后更大的浪潮，是马云说的 DT（数据科技）
2019-12-27借用一个老师之前课程中的比喻“架构与建筑”：一路学习、一路强化、一路领悟，软件工程与建筑工程的特性不知不觉中发现确实可以相互解释。前几天一群人聊天问架构是干什么的有些事情为何那么做，边上一个资深架构师解释了一堆没解释清楚，我直接用建筑去解释，然后对方立刻明白了。
一个很生活化的例子和解释反而让我去明白老师开课时所说的“架构与建筑”：当我们用很复杂很专业的东西去理解时有时反而深陷其中不能自清，跳出框框去思考去讲解的过程反而让我们对此的更简单明了的理解。
谢谢老师今天的分享：期待后续的课程。
2019-12-27其二，快速变化。建筑工程在完工以后就结束了，基本上很少会进行变更。但在软件工程里，软件生产出来只是开始。只要软件还在服务客户中，程序员们的创造过程就不会停止，软件系统仍然持续迭代更新，以便形成更好的市场竞争力。
这一段语音读错了，修改一下。作者回复: 收到