05 法则二：研发人员的人性需求是如何影响架构活动成败的？
你好，我是郭东白。上节课我们学习了马斯洛关于人性的理论，那么这节课我们就利用这个理论来看看我们在架构活动中应该注意些什么。
架构设计必须符合人性，而在架构活动中，与“人”相关的主要就是研发人员和目标用户。那么今天这节课我们就先从研发人员讲起。
想想看，如果架构设计忽略或剥夺了研发人员的人性，会怎样呢？再一个，如果架构活动中尊重和顺应了人性，那么又能给我们架构师一个怎样不同的解决问题的视野呢？这正是我们接下来要讨论的内容。
研发人员为什么需要安全感？
环顾四周，你会发现研发人员对安全感的需求很是强烈。内卷、35岁危机、996，各种流行关键词似乎都指向了安全感的缺失。为什么会这样呢？
我们刚刚学习的马斯洛理论这时候就可以回答了：因为我们都吃得太饱穿得太暖了！我们的生理需求得到了充分的满足！这么一来，心理安全感的需求就赤裸裸地暴露在那里，等待着被满足。
这个答案是半开玩笑的。不过一般情况下，大多数研发人员的生理需求的确不在架构师的考虑范围之内。顺便说一句，有极少数公司会利用人的生理需求来获益，比较阴暗。我唯一的建议就是，远离做这种尝试的公司，在这个时代你有更好的选择。
好了，言归正传。研发人员的生理需求是能够在软件架构考虑范围之外得到充分满足的，那么根据马斯洛的理论，如果一个研发团队，本来是具备心理安全感的，但是突然间却被剥夺了，这会导致什么问题呢？
没有人性的技术架构，就没有生存空间
接下来，我们就通过一个案例来演示一下，研发人员的心理安全感被破坏之后会造成什么损失。
案例背景
我曾受邀给一个在行业内处于垄断地位的大企业做架构规划的外部评审。这家企业的技术在自己所处领域内领先全球，加上资金雄厚，因而他们开始在海外做布局，投资了一家同领域的初创公司。
本来小公司有自己的研发人员，且初步建设了自己的技术体系，基本可以支持本国的业务。但在大企业看来，这家小公司的技术落后自己几年，而且研发人员的能力也有限。
在这个背景下，大企业的国际化团队提出了一个架构设计，如下图所示：
这张图略去了很多细节，不过完全保留了这个架构设计的本质。
投资前，小公司有自己的完整技术栈，如图中左边部分所示。但投资之后，大企业期望小公司能把他们的技术迁移到一个由自己开发的技术平台上去，这样大企业的部分技术就可以通过平台输出给这家小公司了。
这个技术平台主要包含两部分：
- 一部分是全球业务网络和支持这个业务网络运作的全球技术平台，也就是图中的最底层部分。
- 另一部分是一个通用的本地技术平台，由大企业开发，全球通用。这是图中右侧位于全球网络上面的部分。
如果将小公司的技术迁移到本地技术平台之后，他们的研发团队就可以集中关注怎么在本地技术平台上开发自己国家的解决方案。这样一来，之前做本地平台功能的研发人员可以减少很多。而且由于对本地解决方案开发者的技能要求相对更低，这样的研发人员很容易找到，那么用人成本也低。
此外，这样做还有几个附加的好处。首先，大企业开发的本地技术平台基于全球最先进、业务体量最大的中国市场的技术建设，所以不但技术先进，而且附带了很多海外同行们还没有开发出来的业务能力。
其次，本地技术平台和大企业的全球业务网络是打通的，所以小公司一旦接入本地技术平台，那跟它就和全球业务网络一下子就完全打通了。额外的生意滚滚而来，成本又少了很多，何乐而不为呢？
但结果呢？
一年后，大企业投入几千人终于建成了这个庞大的系统，也大幅扩招了在海外的投资版图，但能接受这个方案的小公司却寥寥无几。第二年， 大企业又做了一次全面的技术升级，放宽合作条件，增加对部分小公司的投资占比，但技术方案的推进和被投资业务的增长都不尽如人意。又过了一年，这个方案最终被取消了。
四年后，行业蓬勃发展，但大企业投资的小公司完全没有像期望的那样复制了大企业在国内的成功。不算小公司侧的研发损失，仅大企业损失的研发资源就达到了1.5万到2万人年，再加上直接投资，损失高达几十亿美金。这还不算浪费掉的机会成本。
忽略研发人性的架构设计，会怎样呢？
为什么会造成如此惨重的结果呢？
因为这个架构设计完全忽略了人性。具体来说，就是这个架构方案完全忽视了小公司里研发团队的心理安全感需求。
想想看，如果你在小公司任职，你研发了第一代技术，让公司被一个资金雄厚的国际化大企业看中。但随之而来的就是把你辛苦开发的代码全部下线。紧接着，你的日常工作就变成了跟第三方供应商做系统对接，与核心技术失去了接触。这个方案一旦采用， 那么一夜之间，从CTO到一线研发，每个技术人的安全感都被一扫而光。这个时候你还会安心地留在公司吗？
或许你会说，如果小公司被大企业收购，肯定会签约保留老员工，用股权机制拴住他们。这样一来，他们肯定可以完成技术迁移，不是吗？
正如我们在上节课所讲的，依照马斯洛模型，心理安全感是一个人的内在需求，只有这个内在的需求被完全满足了，它所诱发的动机才会消失，否则这种动机将持续被诱发。所以, 虽然外部激励的确会诱导员工的行为，但却不能从本质上满足已经被剥夺的心理安全感。在这个软件开发人员相对能够保障衣食无忧的年代，没有比获取心理安全感更高的动机了。
让我们再来回忆一下上节课讲的马斯洛的动机跃迁模型：
一个动机一旦进入了主导状态，那么这个动机就会召唤一个人的全部能力去满足这个动机。在这种情形之下，你整个人，包括你的视觉、听觉、嗅觉，你的思考、记忆、行为等等，都只有一个目的，那就是满足这个动机。
现在你应该知道了，获取心理安全感必然会成为小公司研发人员的主导动机。假设你在小公司工作，在拿到技术方案后，你的第一优先级会是去完成技术迁移吗？哪怕有股权和激励诱导你这么做，你会全身心地投入其中，保障迁移迅速完成吗？ 至少马斯洛不这么认为。
如果把这些被投资的海外小公司的研发团队比作一个人的话，那么我们在“案例背景”部分看到的那张架构设计图，无疑是断了他的生路。在这种新架构之下，研发团队根本没法创造出任何可以让自己长期被企业依赖，也就是保障自己生存的长期价值。我们甚至可以继续推演一下，当一个小公司的非研发人员发现自己公司被收购之后，所有的核心研发人员都开始陆续离职，那么他们自己的心理安全感还是硬杠杠的吗？
虽然从技术角度来看，这是个非常有价值的架构方案，但这却是一个完全没有人性的架构。一个完全忽略了研发视角的设计，不但没有从共情出发，甚至是践踏了人性。那么这个架构在海外屡战屡败的事实也就不证自明了。
因而这个例子告诉我们，你作为一个架构师，设计的方案必须要尊重研发同学的人性，一个完全忽略人性的架构是没有生存空间的。
再回到这家国内的垄断大企业，你可能会好奇了，为什么这种没有人性架构竟然能够横空出世？为什么这种方案在屡战屡败的情况下竟然还被整整实施了两年多呢？
为什么会有人设计没有人性的架构？
在邀请我去做架构评审的时候，这家大企业的研发已经有五千多人了。而拿到那次架构评审会议上的项目，也就不到十个。那么每个项目动辄就是数百甚至上千人参与。
这个国际化技术平台的项目，也有好几百人研发人员的参与。虽然是项目评审，但是拿到会上的时候，项目已经启动了。不只是架构师，各方参与人员早已排列整齐，甚至部分研发工作已经启动了。
在架构评审会上，我曾经极力劝阻这个项目的架构师和相关的研发主管，期望他们能放弃这个设计。但最终没能说服他们。
为什么要劝他们放弃呢？因为马斯洛的理论也在这个时候起作用了！
所有已经在这个项目里的人，他们的升职、团队招聘、晋升、年终奖、股票都已经和这个项目牢牢绑定。对于他们而言，任何动摇这个项目稳定性或者是削弱这个项目价值的言论，必然会伤害到他们的自身利益和心理安全感。
同样，在这个时候，他们获取心理安全感的动机也会主导他们所有的感官、意识和行为。所以项目里的人会拼命维护他们的立场，就像小公司里的研发人员一样，他们都在为获取自己的心理安全感投入全身心的努力！
结果就是项目评审会并没有对项目的状态产生什么本质影响。项目启动之后，在国外的接连挫败也没能让参与者们从根本上改变这个架构，因为他们就是这个国际技术平台下的一个衍生物种，让他们去破坏自己赖以生存的空间，完全不可能。更现实的是，越到项目后期，大家的利益和平台绑定得就越深，越是难以阻止。
也就是说，在那次评审会上，这个项目因为前期投入太大，参与的人太多，项目已经不是箭在弦上、不得不发的状态，而是离弦之箭，驷马难追。单靠一个项目评审会，很难把这个项目拉回来。
你看看，马斯洛的理论是多么美妙，又是多么对称的一个理论啊！这个理论不但解释了受迫害一方的行为，而且也完美解释了施虐方的行为。这是个多么讽刺的场景啊！
现在让我们再次强调一下今天讲的生存法则：架构活动需要尊重和顺应人性。架构师必须洞察研发人员的人性，在方案设计和架构活动组织中充分考虑研发的人性，才能保障方案的正确性，以及方案的高效实施。
如果说我们还能从这个案例中能得到什么额外认知的话，那就是：越是大型的架构方案，就越要在早期去讨论它的方案可行性，而且要尽量试图要从批判和否定的眼光去看待它。这种讨论越早越好，涉及的利益方也越少越好，而不是放在详细规划已经完成之后，甚至是项目已经了启动一小半了才做评审。
那么你可能会问我，但是为啥要这么长的时间大家才意识到这个方案是不可行的呢？难道不能上线半年内就终止，减少损失吗？
从某种层面上讲，当一个架构方案有数千人参与，那么这个方案随着时间已经逐渐演变成了一个运动。一个运动，由这个运动自身而产生的惯性，已经不受一两个决策者控制，大量的参与者已经为这个运动注入了持续的生命力。
这个惯性是非常令人恐惧的。而惯性的根源就在于马斯洛的人性理论中的生理需求和心理安全感，这是一种参与者哪怕有认知都很难抗拒的心理。在参与者人数足够大的时候，这种内在的驱动里就很难从外部被影响。这也是为什么我认为人类历史上有一个又一个从悲惨的开局一直持续演到悲惨的结尾的长剧。
当然，马斯洛理论的应用还不止这些。如果架构活动尊重和顺应了人性，那么又能给我们架构师一个怎样不同的解决问题的视野呢？
如何设计微服务的粒度？
微服务有个永恒的话题，就是微服务的粒度到底该怎么定。一个人应该分到几个微服务，还是几个人一起维护一个微服务呢？
对于这个问题，我想你肯定听到过各式各样的答案。有讲3个人维护一个的，也有说应该两个人维护一个的，还有说一个人维护一个的。那么现在让我们来假设一下，如果是马斯洛马老师，他会怎么设计微服务的粒度呢？
“根据您的理论，同时考虑到现实情况，微服务应该不能只满足研发人员的生理需求，对吧？” 我断言道。
“是的，所以安全感对一个研发人员就很重要了。那么我们应该怎么划分微服务，才能让每个研发拥有最大的安全感呢？”马老师问我。
我想了想，回答道：“每人至少一个，而且还得是核心服务”。
“为什么呢？”马老师继续问。
“这样每个研发都不用担心他的工作安全，因为没有人能够轻易取代他。”我老实回答。
“还不止这些好处。如果这么划分，也会给予每个研发以自尊，因为他们对自己的微服务拥有完全决策的自由，这相当于给了他们自信和勇气。此外，他们能从服务他人的过程中感觉到自己是被需要的，这就又给了他们成就感。自尊和成就感，这两者都是有底气的自尊的源泉。更进一步讲，如果说他们的微服务能帮助一家公司更好地服务社会，那么他们甚至能在自己的微服务中找到自我实现的价值！”
“想不到马老师对微服务这么有研究啊！” 我的敬仰如滔滔江水。
“哪里哪里，我只是看透人性罢了。”马老师谦虚地回答我。
当然，划分微服务的粒度不仅需要考虑研发的人性，还要考虑服务本身的原子性、团队大小、团队人员的稳定性、服务的高可靠性要求等等。不过单从人性角度思考，如果你独立负责一个核心微服务的话，那么你的安全感和自尊都是最大化的。
举个现实中的案例，我们来验证一下。在阿里时，我们部门的人均服务数是1.5个左右，而淘宝是不到0.3个。我们团队的人均代码产出是淘宝同学的三倍，代码质量指标千行代码的缺陷率是淘宝的一半，人均日发布次数是淘宝的7倍多，发布成功率和淘宝持平。
当然，两个业务的体量和复杂度完全不能相提并论，而且稳定性要求也不一样。所以直接推导出人均服务数越多越好的结论也不合理。
这是从研发ROI的角度来思考微服务粒度的问题，我们还可以从微服务本身的设计出发来思考。微服务的核心价值在于以下几点：
- 粒度小，单个服务可以紧贴业务快速迭代；
- 去中心化组织和部署结构，减少不必要的协同；
- 数据和商业逻辑受同一个服务控制，从而在商业逻辑快速变更的同时，保障数据模型的一致性；
- 数据和状态独立封装，保障一个业务快速演变的同时，还不污染其他业务；
- 服务本身的独立部署能力使得容错和容量弹性最大化；
- 细粒度服务发布回滚和故障响应能够有效隔离，出了问题可以迅速降级或回滚。
其中第1、2、3项是人越少越高效的，最高效的状态就是一个人。想想看，你自己对业务有深度理解，能够和业务同频率迭代。你什么时候想改代码就改代码，不需要协同，改好了就上线。你自己一个人改自己的商业逻辑和数据模型，根本不需要担心其他人祸害。
在这种状态下，你的速度绝对是最快的。而且就你个人的能力为极限，也是协同越少，你能产出代码的质量越高。所以从这个角度来说，让多名研发维护一个微服务的配置是不合理的。
唯一能够支持多名研发维护同一个服务的理由，就是服务本身对公司的价值太大，它上面承载的业务量，对稳定性的要求，对服务连续性的要求，大到可以忽略研发资源的成本的时候；或者是从性能角度来看，服务无法拆分，它得复杂度大到可以支持多个研发维护的时候。在这种情况下，多个研发维护同一个服务的布局才是合理的。
这种布局在年交易额超过万亿美金的淘宝平台，其实是说得过去的，尤其在中国这种互联网研发人员供给相对充沛的环境之下。
但是，我们大多数人所在的公司并不是像阿里腾讯这样处于垄断地位的互联网公司，甚至哪怕你在阿里和腾讯，你也很可能不在公司最主流的现金流业务中，那么多个人维护一个服务的配置，我认为就不合理。
当然，有些人认为一个服务上只有一名研发会有稳定性风险，我觉得这个理由不成立。微服务的隔离性和有分布式架构带来的稳定性，是能抗住个别同学离职的压力的。而且服务粒度越小，这种承受能力越大。
我曾经经历过一家公司一个月内有15%的研发人员离职的情况，而且这家公司的服务数和研发人员数之比远大于一。但即使是在这种情况下，最终也没有发生稳定性大崩盘的情况。所以以稳定性为由来扩充研发人员，我不认为这是一种好的策略。事实上，比这好的提升稳定性的办法有的是。
其实我一直认为做微服务就像农民耕耘自己的土地一样。无论是古罗马，还是中国封建社会的历朝历代，再或是美国，开国之初都有过开荒屯田的政策，每个农民都可以分到一块属于自己的土地，国家也因此得到了飞速的发展。
对于我们今天这些进城的互联网民工来说，微服务就是咱们的土地。有了自己的地，我们肯定会拼命劳作，想办法从土地里找到致富的希望，不是吗？ 但是如果大家都在一个大锅盛饭吃，而且总是僧多粥少，曾经挨过饿的互联网民工们能不担心吗？
小结
通过今天讲的这两个案例，我想你不仅知道该如何理解马斯洛的人性理论，而且还知道该如何应用了。正如我反复强调的那样，或许你学完这些法则会觉得内容太过简单，但就是这些最基本的原理，其实对结果的影响和对效率的撬动才越大。你用对了这样基本的理论，就可以带来成倍效果提升；而用错了，或者忽略了，则会带来灾难性的损失。
所以越是一个看似简单的道理，其实越需要你运用这个道理去深度思考自己身边发生的事情，从而看清事物的本质。听说过原理不等于懂，懂得原理而不会用，就等于入宝山而空手归。而原理用得多了，事情的本质也会看得更清楚。
那么下节课，我们将从用户的角度来继续探讨人性。
思考题
三个作业，任选一道：
- 在第一个案例中，我还听到过这样一种说法：大企业的CEO肯定会支持这个项目，那么我们派进去的人进场完成迁移就好了。真的可以这样吗？你能否从CEO的视角来看，这种说法违反了马斯洛理论的什么动机和需求层次？如果你是CEO，你会从内心里接受这个架构方案吗？为什么？
- 从安全感的角度来看，许多企业经常把“拥抱变化”的价值观挂在口上，但这其实是反人性的。拥抱变化，也就是在变相要求员工去接受一个他们不连续的、不安全的、不一致的，甚至有可能是不公平的处境。你是怎么看待这个问题的呢？这个观点正确的部分在哪里？错误的地方又在哪里呢？在什么情况下，拥抱变化是能够成为员工发自内心所认同的价值观呢？
- 影响微服务粒度的决策还有不少其他因素，你如果有其他的理由或者完全不同的角度来得出你的结论，也欢迎你把你的想法分享给大家。
欢迎把你的想法和思考分享在留言区，和我一起交流。相信经过你的深度思考，知识会掌握得更牢固。
- Right 👍（55） 💬（1）
回答第二题：「拥抱变化」是否反人性，在于变化的内容是什么。许多公司「稳定守旧」反而让人更没有安全感，比如抱着多年前的老技术不放，项目中使用的技术和目前世面上流行的技术严重脱轨，研发人员在这种项目下除了稳定熟悉之外，更多的是惶恐不安。如果公司乐于拥抱前沿的技术，研发人员反而会安全感十足，因为他知道自己在增值。所以「拥抱变化反人性」这一点，正确性是对于目前所处的环境中我是安稳的（熟悉项目、没有挑战没有失败、没有压力），而错误性在于对于整个大的市场来说我是在减值的（技术落后、没有挑战也没有成就）。 当然，不是说拥抱新技术就一定是好的，还得有一个度，如果一有什么新鲜玩意就无脑上，那也会让研发人员缺乏安全感。 上面说的只是现在技术的角度，如果变化的内容是业务方向、战略意图等，这种我觉得就不算是「拥抱变化」，而是像前几课说的「没有确定架构目标」，这种情况毫无疑问会让研发人员没有安全感。 说到这里，其实可以发现老师讲的几条架构守则都互有关联、一脉相承，前几课讲的确定架构目标带来的好处，用这节课的内容也能很好地阐述：有了明确的架构目标，才能顺应人性，研发人员才会有的放矢，从而增强内心的安全感。
2021-12-19 - qinsi 👍（27） 💬（5）
文中提到，开发微服务好比新时代的农民工种地，并列举了古罗马和中国等的例子作对比，让我想到了另一个古希腊的例子。据传古希腊有支精锐部队叫底比斯圣队(Sacred Band of Thebes)，战斗力极强，甚至击败了不可一世的斯巴达军队。其特点就是两人一组的作战单位，彼此相互掩护，为对方提供安全感。那么开发单个微服务是否也可以两人一组，顺便还能够延续结对编程的优良传统？
2021-12-14 - neohope 👍（20） 💬（2）
拥抱变化的七个层次： 1、极少数个人来自于某种信仰 2、少数个人来自对自己能力的信任 3、部分人来自对组织或环境的信任 4、多数人是被逼无奈，被动接受 5、某些人只想别人拥抱变化，自己才能维持不变 6、很多时候是组织对无法维持稳定环境的一种掩饰 7、更多时候就是一个口号，自嗨而已，不敢付出行动
2021-12-30 - jiankang 👍（19） 💬（2）
学到现在，忽然感觉老师讲的内容暗含了自我实现。 良知是自尊的前提，决策的正确性是增强自我的一种方式，思考力是决策质量的保证。
2021-12-15 - shawn 👍（17） 💬（1）
我觉得一个微服务可以让2个人负责，高级工程师和初级工程师，高级工程师的安全感体现在主导该服务，初级工程师的安全感在工作中得到高级工程师的指点，觉得自己在成长。
2021-12-14 - lujg 👍（14） 💬（4）
有一个疑惑，希望老师回答。微服务架构中一个人负责一个以上核心服务。那么对于pull merge的review过程应该怎么实施？
2021-12-17 - 罗均 👍（14） 💬（2）
再次感恩东白老师精彩的课程，和精辟的解说🌹🌹🌹 关于第三个问题，学生是一名一直在汽车行业的车厂老兵，这个领域连SOA都是奢求，更不用说微服务了。 然而老师以微服务作为土地来作比喻，的确是非常独到且精确的理解。再结合老师以类似SRP(Single Responsibility Principles)的原则来分配微服务工作的例子，对于微服务粒度的分解，学生有以下肤浅的想法。 服务分核心业务和非核心业务，核心业务相当于东南沿海发达地区的土地，粒度可以尽可能细到一人一服务，这些土地都是“寸土寸金”的。而非核心业务或相当于西北气候恶劣和土地贫瘠的地区，几乎没人肯去，这需要有魄力有能力，更需要有恒心的精英去开垦，才能将“黄沙变金沙”。从90年代朱总理发起的“西部大开发”战略以来，福建省帮扶宁夏省致富的事迹最为amazing。对于非核心业务也是如此，在明确的战略意图指导下，粒度可以大很多个数量级，例如90年代有位福建老板，一口气包下10万亩戈壁滩，经过20多年的开垦经营，硬生生将那块寸草不生的戈壁滩变成绿油油的创收百亿的红酒基地。一些非核心业务，最直接的就是运维，美国那边就有很多优秀团队就硬生生“开垦”出极其优秀的服务，例如目前一大堆神奇的DevOps工具链。 在非核心业务上开创绿洲，或比在核心业务上锦上添花，更有意思。 谢谢老师😊
2021-12-16 - 与非 👍（10） 💬（2）
中台战略是不是也让开发人员没有安全感？
2021-12-14 - JianXu 👍（8） 💬（6）
郭老师，关于第一个CEO 从心里是否认同的问题，我也有一个问题： 从这篇文章的阐述来看，得出CEO 从内心并不认同似乎是很直接的结论。但是我宁愿把人高看一眼，一家这么大的公司的CEO 能力应该是强的，认知应该是高的，所以我宁愿相信该公司的CEO 甚至整个项目里也不乏能看到您文章中指出问题的人的，那为什么仍然没有撤回这个项目呢？利益绑定问题下面的人不能破那上面的人呢？最终上面的人还是要对业务结果负责人的啊…… 关于派人去直接做迁移，我不知道这个项目的目的是什么？是完成迁移还是去赋能小公司的开发人员？如果只是迁移我认为可行，如果是赋能那就背道而驰了。而当问到赋能这个问题的时候，我的心是为这些小公司的员工好；当问到迁移从而不需要这么多并且可以降低员工要求的时候，发起这个动作的高管对待这些人的心是如何的呢？资源吗？
2021-12-18 - 欧阳绍聪 👍（8） 💬（1）
带领团队通过技术优化，进行架构演进，为业务带来外部变化适应性，这是我理解的拥抱变化。而不是要求研发团队，不断修改业务方向，通过广泛探索，“瞎猫逮到死耗子”的方式，找到变化突破口。
2021-12-16 - 李二木 👍（7） 💬（3）
想到一个题外话，马斯洛的需求理论是可整伪的吗？就像弗洛伊德精神分析法很流行。但是很多人认为弗洛伊德精神分析学说不可证伪。如果基础原理有错，推导出的结论也就有偏差。
2021-12-20 - 术子米德 👍（6） 💬（1）
🤔☕️🤔☕️🤔 * CEO支持的项目，由外派进场来搞定，事情当然能做下去，可是其中的阻力，无时无刻都在摩擦放电直至冒烟。 * 最好的下场，事情做完CEO走了，最坏的下场，事情做完就CEO还在。 * 项目中干活的人，完全处于被动状态，随时被调遣，没有任何安全感，更没有任何信任感，就像行尸走肉一般，喊我干啥就干啥，干好了不是我的好，干炸了肯定是我的锅。
2021-12-16 - CheungQ 👍（6） 💬（2）
之前在其他地方看到的，学习金字塔模型，光听光看知识吸收率不足20%，讨论演练能达到50%、70%，如果能把你学到的讲出来教会别人，或者立刻应用到实践当中能达到90%的吸收率，所以其实很多学习教授相关的都会强调自己动手做一做，给别人讲一讲，大家互相交流探讨下这些学习之后的动作的重要性 学了 ≠ 会了
2021-12-14 - 天下为公 👍（5） 💬（2）
拥抱变化就是拥抱transformation，这是企业在科技日新月异的时代想要跟上时代必由之路，过多考虑一般员工的安全感需求可能重蹈诺基亚手机的覆辙，而丢掉包袱的IBM就是这一拥抱必要重要的明证。拥抱新技术新架构新商业模式的风险和不变就会有焦虑感比起来，架构师更需要安抚高层的焦虑感。
2021-12-20 - 术子米德 👍（5） 💬（2）
🤔☕️🤔☕️🤔 * 📖：研发人员的人性需求，与架构成败之间，有成败关系。架构设计必须符合人性。 * 🤔：看到这句话，忽然冒出来，我作为研发人员，原来也没少干过拆架构台的活。如今我也算个架构师，虽然只是入门级的那类，想必也有拆架构台的活在发生。这是人性。这样的人性，难道就不能修饰一下嘛。不，是这样的架构，难道不得整改一下嘛。到底哪方能够扭赢对方。在机会面前，人性扭赢架构，否则就是失职，就是在挥霍机会。在形势面前，架构扭赢人性，看清就另找出路，别处寻觅机会。 * 📖：研发人员对安全感的需求很是强烈 * 🤔：安全感的侧面站着紧迫感。当我可以连续几个月吃泡面，还很开心调试着代码，虽然项目很紧迫，但是我并没有紧迫感，即使我随时会被赶走，但是安全感一丁点儿都没有被诱发出来。可是，当我知道下个月房贷等着还清，女儿眼看长大没有独立房间，每天睁开眼都不敢看天花板，洗脸刷牙都不肯照镜子，我知道天花板上和镜子里的脸上都写满了紧迫感。芝麻一丁点儿的事情，都能挑动到我紧张的心理，寻求工作安全感的需求，从未如此迫切。只是没有看到课程里这句话的之前，自己没有把这样的状态理解为对安全感的需求而已，现在真相大白。实际上就是缺乏安全感，才会整天盯着课程学，名其曰终身学习，实际就是求安全的焦虑诱发的学习动机。果真如此这般这般如此嘛。 * 📖：没有人性的技术架构，就没有生存空间，尤其忽略研发团队心理安全感需求时，纯粹就是自寻短见的技术架构 * 🤔：技术架构的价值，可以仅从架构本身来评估价值，也更要从架构放到整体中去评估价值，尤其关注其对人对价值。说起来很轻松，听起来很有道理。可要是知道，对人价值的关注不难，对人价值的度量就极难。难在度量发生在机会层面，难在人是能够对任何刺激都做出反应的活系统，难在人的反应又会再次反馈进来被迭代度量。 * 📖：让我独立负责一个核心微服务，那么我的安全感和自尊都是最大化 * 🤔：原来可以如此嘛，不管信不信，我要试试看。
2021-12-16