郭东白的架构课_06_05法则二研发人员的人性需求是如何影响架构活动成败的
你好，我是郭东白，上节课，我们学习了马斯洛关于人性的理论。
那么这节课我们就利用这个理论来看看我们架构活动中应该注意些什么，架构设计必须符合人性。
而在架构活动中，跟人相关的主要就是研发人员和目标用户。
那么今天这节课我们先从研发人员讲起，想想看，如果架构设计忽略，甚至剥夺了研发人员的人性会怎么样呢？再一个，如果在架构活动中尊重和顺应的人性，那么又能给我们架构师一个怎样不同解决问题的视角呢？这正是我们接下来要讨论的内容。
我们先谈谈研发人员为什么需要安全感。
在现在这个时代，我们会发现研发人员对安全感的需求非常强烈。
内卷三十五岁危机九九六心种流行的关键词，好像都指向了安全感的缺失。
为什么这样呢？我们上节课学习的马斯洛理论，这时候就可以回答你了，因为我们都吃的太饱，穿的太暖了，我们的生理需求得到了充分的满足。
这样一来，心理安全感的需求就赤裸裸的暴露在那里，等待着被满足。
其实这个答案呢是半开玩笑的。
不过一般情况下，大多数研发人员的生理需求的确不在架构师的考虑范围内。
顺便说一句，有极少数的公司会利用人的生理需求来获取利益，比较阴暗。
我唯一的建议就是远离做这种尝试的公司，在这个时代你有更好的选择。
好了，言归正传，研发人员的生理需求呢是能够在软件架构的考虑范围之外得到充分满足的。
那么根据马斯洛的理论，如果一个研发团队本来是具备心理安全感的，但是突然间被剥夺了，会导致什么问题呢？答案是，没有人性的技术架构，就没有生存的空间。
接下来我就通过一个案例给你演示一下，看看研发人员的心理安全感被破坏之后，到底会造成什么损失？我先描述一下案例的背景。
我曾经被邀请去给一个大企业做架构规划的评审。
这家企业的技术在自己所处的领域内可以说领先全球，再加上资金雄厚，所以他们开始在海外做布局，投资了一家同领域的初创公司。
本来这家小公司有自己的研发人员，而且初步设计的自己的技术体系基本可以支持自己国家的业务。
但是在大企业来看，这家小公司的技术落后自己几年，而且研发人员的能力也有限。
在这个背景下，大企业的国际化团队提出了一个架构设计，我把这张架构图放在了文稿里。
你可以在文稿里查看，我来解释一下这张图的核心内容。
这张图省略了很多细节，不过完全保留了这个架构设计的本质。
在投资之前，小公司有自己的完整技术站。
但是投资之后，大企业希望小公司把他们的技术迁移到由自己开发的一个技术平台上去。
这样的话大企业的部分技术就可以通过平台输出给这家小公司了。
这个技术平台呢包含两部分，一部分是全球业务网络和支持这个业务网络运作的全球技术平台。
另一部分呢通过本地技术平台，由大企业开发全球通用。
如果把小企业的技术迁移到本地技术平台之后，他们的研发团队就可以集中关注怎么在本地技术平台上开发自己的国家解决方案。
这样一来，之前做本地平台功能的研发人员就可以减少很多，而且由于对本地解决方案，开发者的技能要求相对来说更低一些。
那么这样的研发人员就很容易找到，用人成本也更低。
另外这样做还有几个附加的好处。
首先，大企业开发的本地技术平台是基于全球最先进的、业务体量最大的中国市场技术而建设的。
所以不但技术先进，而且附带了很多海外同行们还没开发出来的技术能力。
其次，本地技术平台和大企业的全球业务网络是一体的。
所以小公司一旦接入本地技术平台，那么它就和全球业务网络一下子完全打通了。
那么它本意集中关注成本又少了很多，何乐而不为呢？但结果呢？一年后，大企业投入了几千人，终于建成了，这个庞大的系统也大幅扩招了。
在海外的投资版图，但是能够接受这个方案的小公司呢却寥寥无几。
第二年，大企业又做了一次全面的技术升级，放宽了合作条件，增加了对部分小公司的投资占比。
但技术方案的推进以及被投资业务的增长都不尽如人意。
又过了一年，这个方案最终被取消了。
四年后，行业蓬勃发展，但大企业投资过的小公司呢，完全没有像七万个那样可以复制。
大企业在国内的成功不算小。
公司册的研发损失，光是大企业损失的研发资源就达到了一点五到两万人年，再加上投资损失更高达几十亿美金，这还不算浪费掉的机会成本。
为什么会造成如此惨重的结果呢？因为这个架构完全忽略了人性。
具体来说就是这个下构方案完全忽视了小公司里面研发团队的心理安全感需求。
想想看，如果你在小公司任职研发了第一代技术，让公司被一个资金雄厚的国际化大企业看中。
但随之而来的就是把你辛苦开发的代码全部下线。
紧接着你的日常工作就变成了跟第三方供应商做系统对接，跟核心技术完全失去了接触。
这个方案一旦采用，那么一夜之间从CTO到一线研发，每个技术人的安全感都被一扫而光。
这个时候你还会安心的留在公司吗？或许你会说，小公司被大企业收购，肯定会签约，保留老员工，用股权机制拴住他们。
这样一来，他们肯定会完成技术迁移，不是吗？就像我在上节课里所说的，按照马斯洛的模型、心理安全感系一个人的内在需求，这有这个内在需求被完全满足了，他所诱发的动机才会消失，否则这种动机就会持续被诱发。
所以说，虽然外部激励的确会诱导员工的行为，但是却不能本质上满足他们已经被剥夺的心理安全感。
在这个研发人员相对能够保障衣食无忧的年代，没有比获取心理安全感更高的动机了让我们再回忆一下，上节课里讲到的马斯洛的动机变迁模型，一旦动机进入了主导状态，那么这个动机就会召唤一个人的全部能力去满足这个动机。
在这种情况下，你整个人包括你的视觉、听觉、嗅觉、你的思考、记忆行为等等，都只有一个目的，那就是满足这个动机。
现在你应该知道了，获取心理安全感必然会成为小公司研发人员的主导动机。
假设你在小公司工作，拿到技术方案后，你的第一优先级会是完成技术迁移吗？哪怕有股权和激励，诱导你这么做。
你会全身性投入其中，保障完成技速完成吗？至少马斯洛，我这么认为，如果把那些被投资海外的小公司的研发团队比作一个人的话，那么我们在案例背景部分看到那一个架构设计图肯定是断了他们的生路。
在这种新架构下，研发团队根本没法造出任何可以让自己长期被企业依赖，也就是保障自己生存的长期价值。
我们甚至可以推演一下，当一个小公司的非研发人员发现自己公司被收购后，所有的核心研发人员都开始陆续离职。
那么他们自己的心理安全感还是杠杠的嘛。
虽然从技术角度来看，这是一个非常有价值的架构方案，但这是完全没有人性的架构。
一个完全忽略了研发人员安全感的设计，不但没有从共情出发，甚至是践踏了人性。
那么这个架构在海外屡战屡败的事实也就不证自明了。
这个例子告诉我们，你作为一个架构师设计的方案，必须尊重研发人员的人性，一个完全忽略了人性的架构是没有生存空间的。
再回到这家垄断大企业，你可能好奇了算什么？这种没人性的架构竟然能够横空出世呢？为什么这个方案在屡战屡败的情况下，竟然整整被实施了两年多呢？接下来我们就讨论一下这个问题，看看为什么会有人设计和实施。
没有人性的架构。
在邀请我去做架构评审的时候，这家大企业的研发已经有五千多人了。
但是拿到那次架构评审，会议上的项目也就是不到十来个为下来，每个项目就有几百人，甚至上千人的参与。
这个国际化技术平台的项目也有好几百研发参与。
虽然是项目评审，但是拿到会上的时候，项目已经启动了不，只是架构师各方参与人员已经排列整齐，甚至部分研发工作已经启动了。
在架构评审会上，我极力劝阻这个项目的架构师和相关的研发主管，希望他们能够放弃这个事情。
但是我最终没有能说服他们，为什么他们不愿意放弃呢？因为马斯洛的理论在这个时候又起作用了。
所有已经在这个项目里的人，他们的升职团队招聘、晋升、年终奖、股票都已经和这个项目牢牢绑定。
对他们来说，任何动摇这个项目稳定性或者是削弱这个项目价值和行为，肯定会伤害到他们的自身利益。
还有他们自己的心理安全感。
同样在这个时候，他们获得心理安全感的动机，也会主导他们所有的感官意识和行为。
所以在项目里的人肯定会拼命维护他的立场，就像小公司的研发人员一样，他们其实也在为获取自己的心理安全感投入全身心的努力。
结果就是项目评审会并没有对项目安全感产生什么本质的。
你想项目启动后，在国外的连连挫败，也没能让参与者们从根本上改变这个架构。
因为他们就是这个国际技术平台下的一个衍生物种，让他们去破坏自己赖以生存的空间，完全不可能。
更现实的是，越到项目后期，大家的利益和平台绑定的就越深，越是难以阻止。
也就是说，在那次评审会上，这个项目因为前期投入太大，参与的人太多，项目已经不是箭在弦上不得不发的状态，而是离弦之箭驷马难追。
单靠一个项目评审会，很难把这个项目拉回来。
你看看马斯洛的理论是多么美妙，又是多么对称的一个理论啊。
这个理论不但解释了受迫害一方的行为，而且也完美解释了施虐方的行为，这是一个多么讽刺的场景啊。
现在我们再强调一下，今天讲的生存法则，那就是架构活动需要尊重和顺应人性。
架构师必须洞察研发人员的人性，在方案设计和架构活动组织中充分考虑研发人员的人性，这样才能保障方案的正确性以及方案的高效实施。
如果说我们还能从这个案例中得到什么额外认知的话，那就是越是大型的架构方案，就越要早期去讨论它的方案可行性。
而且要尽量从批判和否定的角度去看待他，最终讨论越早越好，设计的利益方也是越少越好，而不是放在架构规划已经完成之后，甚至是项目已经启动了一小半了才做评审。
那么你可能问我，为啥要这么长的时间，大家才意识到这个方案是不可行的呢？难道不能上线半年就终止减少损失吗？从某个层面上来讲，当一个架构方案有几千人参与。
那么这个方案随着时间已经逐渐演变成了一个运动，已经不再受一个运动。
有这个自身产生的惯性，已经不受一两个决策者的控制了。
大量的参与者已经为这个运动注入了持续的生命力，这种惯性是非常令人恐惧的，而惯性的根源在于马斯洛的人性理论中的生理需求和心理安全感。
这是一种参与者，哪怕有认知都很难抗拒的心理。
在参与者人数足够多的时候，这种内在的驱动力就很难从外部被影响。
当然马斯洛的理论还不止这些，如果架构活动尊重和顺应了人性，那么又能给我们架构师一个怎么样的不同的解决问题的视角呢？我们就拿微服务的力度呢，举个例子，微服务呢有个永恒的话题，就是微服务的力度到底该怎么地？一个人到底应分到几个微服务，还是几个人一起维护一个微服务呢？对于这个问题，我想你肯定听到过各种各样的答案。
有人讲三个人维护一个的，也有说应该两个人维护一个的，还有说一个人维护一个呢。
让我们来假设一下，如果是马斯洛马老师，他会怎么样设计微服务的力度呢？我们用一个简单的对话来想象一下，我问马老师，根据您的理论，同时考虑到现实情况，微服务应该无法满足研发人员的生理需求，对吧？马老师哦，是的，所以安全感对一个研发人员就很重要了。
那么我们应该怎么划分微服务才能让每个研发拥有最大的安全感呢？我想了想，每个人至少一个，而且还得是核心服务，为什么呢？马老师继续问我，这样的话，每个研发都不用担心他的工作安全了。
因为没有人能轻易取代他，我老实回答还不止。
这些好处，如果这么划分，也会让每个研发拥有自尊。
因为他们对自己微服务拥有自我实策的自由，这相当于给了他们自信和勇气。
另外，他们能从服务他人的过程中，感觉到自己是被需要的这就给了他们成就感、自尊和成就感，这两者都是有底气的自尊的源泉。
再进一步讲，如果他们的微服务能够帮助一家公司更好的服务社会，那么他们甚至在自己的微服务中拥有自我实现的价值。
听完了马老师的回答我的敬仰如滔滔江水，就说想不到马老师对微服务这么有研究啊，那里他们甚至是砍滔人性，拔了马老师谦虚的回答我好了，这就是我和马老师的完整对话。
你可能会说，划分微服务的力度，不仅仅要考虑研发的人性，还要考虑服务本身的原则性、团队大小，团队人员的稳定性，服务的高可靠性要求等等。
不过单单从人性角度考虑，如果你独立负责一个核心微服务的话，那么你的安全感和自尊都是最大化的。
举个现实中的案例，我们来验证一下。
之前我在一家大企业里的时候，我们的小部门人均服务数是一点五个左右。
而另外一个大部门的人均服务数不到零点三个，但我们团队的人均代码产出是这个大部门的三倍代码质量指标，也就是千行代码缺陷率是大部门的一半日，人均的发布次数呢是大部门的七倍友，而发布成功率持平。
当然，两个业务的体量和复杂度完全不能相提并论，而且各自对稳定性的要求也不一样。
所以直接推导出人均服务数越多越好的结论也不合理。
即使从研发OI的角度来思考微服务力度的问题，那么我们还可以从微服务本身的设计出发来思考。
我们都知道，微服务的核心价值有这么六点，第一，力度小，单个服务可以紧贴业务快速迭代。
第以去中心化的组织和部署结构减少了不必要的协同。
第三，数据和商业逻辑受同一个服务控制，从而在商业逻辑的快速变更的同时，保障数据模型的一致性。
第么数据和状态独立分装可以保障一个业务在快速演变的同时，还不污染其他业务。
第五，服务本身独立部署能力可以让容错和容量弹性最大化。
第六，细粒度的服务发布、回滚和故障响应能够有效隔离，出了问题之后呢就可以迅速降级或回滚。
其中第三项是人越少越高效的，最高效的状态就是一个人。
你想想看，你自己对业务有深度理解，能够跟业务同频迭代。
你什么时候想改代码就改代码，不需要协同，改好了就上线。
你自己改自己的商业逻辑和数据模型，根本不需要担心其他人祸害这种状态下，你的速度绝对是最快的。
而且就你个人的能力为极限，能够有效隔离，你能产出的代码质量越高。
所以从这个角度来讲，让多个研发维护一个微服务的配置就是不合理。
我认为唯一能够支持多个研发，维护同一个微服的理由就是服务本身对公司的价值太大，它上面承载的业务量，对稳定性的要求，对服务连续性的要求，大到可以忽略研发资源的成本，或者从性能角度来说，服务没办法拆分，它的复杂度大到可以支持多个研发，同时维护。
在这种情况下，多个研发维护同一个服务的布局才是合理的。
这种布局在年交易额在万亿美金量级的大平台其实是说得过去的。
尤其是在中国这种互联网研发人员供给相对充沛的环境下。
但是我们大多数人所在的公司并不像阿里、腾讯这样处于垄断地位的互联网公司。
但怕你在阿里和腾讯，你也可能不在公司最主流的现金流业务中，那么多个人维护一个微服务的配置，我认为就不合理。
当然也有人认为一个微服务上只有一名研发，就会有稳定性风险。
我觉得这个理由不成立。
微服务的隔离性，还有分布式架构带来的稳定性是能扛住个别同学离职的压力的，而且服务力度越小。
这种承受能力越大我曾经经历过这样一种情况。
一家公司里一个月有百分之十五的研发人员离职，而且这家公司的服务数和研发人员人数之比接近于此。
但即使在这种极端的情况下，最终也没发生稳定性大翻盘的情况。
所以说把稳定性当借口来扩充研发人员，我不认为这是一种好的策略，事实上比这更好的提升稳定性的方法。
有的是，其实我一直认为做微服务就像农民耕耘自己的土地一样。
无论是从古罗马还是中国封建社会的历朝历代，再或是美国开国之初都有过开荒屯田的政策，每个农民都可以分到一块属于自己的土地。
国家呢也因此得到了自足的发展。
对于我们这些进城务工的互联网农民工来说，微服务就是咱们的土地。
有了自己的地，我们肯定会拼命劳作，想办法从土地里找到致富的希望，难道不是吗？但是呢如果我们大家都在一个大锅里盛饭吃，而且总是僧多粥少，曾经挨过饿的互联网农民工们能不担心吗？好了，今天的内容就是这些。
我最后来总结一下，通过今天讲的这两个案例，我们不仅知道了该怎么理解马斯洛的人性理论，而且才知道怎么应用了。
就像我反复强调的那样，或许你学完这些法则，也觉得内容太简单了。
但是就是这些最基本的原理，其实对结构的影响以及对效率的撬动才最大。
你用对了基本的理论就可以带来成倍的效果提升，而用错了或者是忽略了，就可能会带来灾难性的损失。
所以说，越是一个看似简单的道理，其实越需要你运用这个道理，去深度思考自己身边发生的事情，从而看清事物的本质。
听说过原理不等于懂，懂了，原理也不等于会用。
如果是这样，就等于入宝山，而空手归原理用的多了，事情的本质就会看得更清楚。
那么下节课我们就从用户的角度来继续探讨人性。
最后呢是思考题环节，一共三道题，你可以任选一道作答。
第一题，在第一个案例中，我还听说过这么一种说法，大企业的CEO肯定会支持这个项目，我们派进去的人进场完成迁移就好了。
真的是这样吗？你能不能从CEO的视角来思考一下这种说法，违反了马斯洛理论的什么动机和需求层次。
如果你是CEO,你会从内心里接受这个方案吗？为什么？第二题，从安全感的角度来说，许多企业经常把拥抱变化的价值观挂在嘴上，但这其实是反人性的拥抱变化。
其实在变相要求员工去接受一个有可能是不公平的处境。
你是怎么看待这个问题呢？这个观点的正确部分在哪里？错误的地方又在哪里？什么情况下拥抱变化是能够成为员工发自内心所认同的价值观呢？第三题，影响微服务力度的决策呢，还有其他不少因素。
如果你有其他理由或者完全不同的角度，也欢迎你把你的想法分享给大家。
那我们下节课再见。
最后呢我还想跟大家说个事儿，这周呢我把我的推荐奖励体现了很多钱啊，有一千多啊。
我感谢购买了我的课程的朋友们，也欢迎你们呢用我们的即课时间的分享，推荐的功能分享，来拿到你的属于你的那一份的推荐奖。
好，再见。