mod

极客时间专栏/后端技术面试 38 讲/技术人的思维修炼/34 | 技术修炼之道：同样工作十几年，为什么有的人成为大厂架构师，有的人失业？.md

@@ -0,0 +1,81 @@
+<audio id="audio" title="34 | 技术修炼之道：同样工作十几年，为什么有的人成为大厂架构师，有的人失业？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ce/e5/cead9660a6f1c9467704fbdda6e71ce5.mp3"></audio>
+
+在软件开发招聘中，“有多少年工作经验”是一个重要的招聘指标。但实际上，技术能力和工作年限并不是正相关的，特别是工作三五年以后，很多人的技术能力进步就几乎停滞了。但是招聘面试的时候，面试官是期待他有着和工作年限相匹配的技术能力的。
+
+如果一个人空有十几年工作经验，却没有相应的技术能力，那么这十几年的工作经验甚至可能会成为他的劣势，至少反映了他已经没有成长空间了。反而是工作年限不如他，但是技术能力和他相当的其他候选人更有优势，因为这个人可能还有进步的空间。
+
+事实上，就我这些年的面试经验而言，空有十几年工作经验而没有相应技术能力的人大有人在。其实从简历上就能看的出来：最近几年的时间他承担的工作职责几乎没有变化，使用的技术、开发的项目几乎和头几年一样，那么很难相信这些年他的技术会有什么进步。
+
+那么如何保持技术能力持续进步，使工作年限成为自己的优势而不是缺点呢？
+
+## 德雷福斯模型
+
+我们先看一个德雷福斯模型。德雷福斯是一个专业人员能力成长模型，这个模型认为所有专业人员都需要经历5个成长阶段，不管是医生还是律师，或者是软件开发，任何专业技能的从业者都需要经历新手、高级新手、胜任者、精通者、专家5个阶段。
+
+<img src="https://static001.geekbang.org/resource/image/75/57/751f36321ade6b0e9a6214b6494f6857.png" alt="">
+
+通常一个人进入专业的技能领域，即使在学校已经系统学习过这个专业的相关知识，但依然无法独立完成工作，必须在有经验的同事指导下，学习相关的技能。这里主要学习的是有关工作的规则和套路。比如用什么工具、什么框架，如何开发程序，如何开会、写周报，如何和同事合作，业务领域的名词术语是什么意思等等这些各种各样和工作有关的大小事情。这个阶段叫做**新手**阶段。
+
+通常说来，一个人大约工作两三年后，就差不多掌握了工作的各种套路，可以摆脱新手阶段，独立完成一些基本的工作了。通过新手阶段的人，少部分会直接进入胜任者阶段，而大多数则进入**高级新手**阶段。
+
+高级新手其实是新手的自然延续，他不需要别人指导工作，也不需要学习工作的规则和套路，因为高级新手已经在新手阶段掌握了这些套路，他可以熟练应用这些规则套路完成他的工作。但是高级新手的能力也仅限于此，他不明白这些规则是如何制定出来的，为什么使用这个框架开发而不是另一个框架，也不明白这个框架是如何开发出来的。
+
+因此，一旦需要解决的问题和过往的问题有很大不同，以前的规则套路无法解决这些新问题的时候，高级新手就抓瞎了，不知道该怎么办。
+
+一个悲观的事实是，新手会自然进入高级新手阶段，而高级新手却无法自然进入其后的其他等级阶段。实际上，**在各个专业领域中，超过半数的人终其一生都停留在高级新手阶段**，也就是说，大多数人一生的工作就是基于其专业领域的规则在进行重复性的劳动。他们不了解这些规则背后的原理，也无法在面对新的问题时，开创出新的方法和规则。那些简历上十多年如一日使用相同的技术方案、开发类似软件项目的资深工程师大部分都是高级新手。
+
+导致一个人终身停留在高级新手阶段的原因有很多，其中一个重要的原因是：**高级新手不知道自己是高级新手**。高级新手觉得自己在这个专业领域混得很不错，做事熟练，经验丰富。
+
+事实上，这种熟练只是对既有规则的熟练，如果岁月静好，一切都循规蹈矩，也没什么问题。而一旦行业出现技术变革或者工作出现新情况，高级新手就会遇到巨大的工作困难。事实上，各行各业都存在大量的高级新手，只是软件开发领域的技术变革更加频繁，问题变化也更加快速，使高级新手问题更加突出。
+
+少部分新手和高级新手会在工作中学习、领悟规则背后的原理，当需要解决的问题变化，或者行业出现技术革新时，能够尝试学习新技术，解决新问题，这样的人就进入**胜任者**阶段。胜任者工作的一个显著特点是，**做事具有主动性**。他们在遇到新问题时，会积极寻求新的解决方案去解决问题，而不是像高级新手那样，要么束手无策，要么还是用老办法解决新问题，使问题更加恶化。
+
+胜任者能够解决新问题，但他们通常只会见招拆招，局限于解决问题本身，而缺乏反思精神以及全局思维：为什么会出现这样的问题？如何避免类似问题再发生？这个问题在更宏大的背景下处于什么位置？还有哪些类似的问题？
+
+而拥有反思精神和全局思维，即使没有新问题也能够进行自我突破、寻求新的出路的人，就进入了**精通者**阶段。**精通者需要通过主动学习进行提升，主动进行大量的阅读和培训**，而不是仅仅依靠工作中的经验和实践。他们在完成一个工作后会反思：哪些地方可以改进，下次怎么做会更好？
+
+精通者**拥有了自我改进的能力**。
+
+高级新手会把规则当做普适性的真理而使用，甚至引以为豪；而精通者则会明白所有的规则都只在特定的场景中才会有效，**工作中最重要的不是规则，而是对场景的理解**。
+
+而最终，各行各业大约只有1%的人会进入**专家**阶段，专家把过往的经验都融汇贯通，然后形成一种直觉，他们直觉地知道事情应该怎么做，然后**用最直接、最简单的方法把问题解决**。专家通常也是他所在领域的权威，精通者和胜任者会学习、研究专家是如何解决问题的，然后把这种解决方案形成套路，成为行业做事的规则。
+
+## 如何在工作中成长
+
+德雷福斯模型告诉我们，人的专业能力不会随着工作年限的增加而自然增长，多数人会终身停留在高级新手阶段。那么如何在工作不断成长，提升自我，最终成为专家呢？以下三个建议供你参考。
+
+**1.勇于承担责任**
+
+好的技术都是经过现实锤炼的，能够真正解决现实问题的，得到大多数人拥护的。所以自己去学习各种各样的新技术固然重要，但是更重要的是要将这些技术应用到实践中，去领悟技术背后的原理和思想。
+
+而所有真正的领悟都是痛的领悟，只有你对自己工作的结果承担责任和后果，在出现问题或者可能出现问题的时候，倒逼自己思考技术的关键点，技术的缺陷与优势，才能真正地理解这项技术。
+
+如果你只是去遵循别人的指令，按别人的规则去做事情，你永远不会知道事物的真相是什么。只有你对结果负责的时候，在压力之下，你才会看透事物的本质，才会抓住技术的核心和关键，才能够让你去学好技术，用好技术，在团队中承担核心的技术职责和产生自己的技术影响，并巩固自己的技术地位。
+
+**2.在实践中保持技能**
+
+有个说法叫做**1万小时定律**，是说要想成为某个领域的专家，必须经过1万小时高强度的训练才可以，对软件开发这样更强调技术的领域来说，这一点尤其明显。我们必须要经过长时间的编程实践，从持续的编程实践中提升技术认知，才能够理解技术的精髓，感悟到技术的真谛。
+
+但是1万小时的编程时间并不是说你重复的编程1万小时就能够自动提升成为专家的。真正对你有帮助的是不断超越自我，挑战自我的工作。也就是说，每一次在完成一个工作以后，下一次的工作都要比上一次的工作难度再增加一点点，不断地让自己去挑战更高难度的工作，从而拥有更高的技术能力和技术认知。
+
+通俗说来，就是要摘那些跳起来才能够得着的苹果，不要摘那些伸手就能够得着的苹果。但是如果难度太高，注定要失败的任务，其实对技术提升也没有什么帮助。所以最好是选择那些跳起来能够摘得到的苹果，你要努力再进步一点点，才能够完成。通过这样持续的工作训练和挑战，在实践中持续地获得进步，你就可以不断从新手向专家这个方向前进。
+
+**3.关注问题场景**
+
+现实中，很多人觉得，学好某一个技术就大功告成了。但事实上是，即使你熟练掌握了强大的技术，但如果对问题不了解，对上下文缺乏感知，也不会真正地用好技术，也就无法去解决真正的问题。试图用自己擅长的技术去解决所有问题，就好像是拿着锤子去找钉子，敲敲打打大半天，才发现打的根本就不是一个钉子。
+
+所谓的专家其实是善于根据问题场景发现解决方法的那个人，如果你关注场景，根据场景去寻找解决办法，也许你会发现解决问题的办法可能会非常简单，也许并不需要多么高深的工具和方法就能够解决，这时候你才能成为真正的专家。也就是在这个时候你会意识到方法、技术、工具这些都不是最复杂的，而真正复杂的是问题的场景，是如何真正地理解问题。
+
+这个世界没有万能的方法，没有一劳永逸的银弹。每一种方法都有适用的场景，每一种技术都有优点和缺点，你必须要理解问题的关键细节、上下文场景，才能够选择出最合适的技术方案，真正地解决问题。
+
+## 小结
+
+如果你是一个新手，刚刚工作不久，那么不要被所谓的工作经验和所谓的资深工程师的说教局限住，你要去思考规则背后的原理，主动发现新问题然后去解决问题，越过高级新手阶段，直接向着胜任者、精通者和专家前进吧。
+
+如果你是一个有多年经验的资深工程师，那么忘了你的工作年限吧，去问自己，我拥有和工作年限相匹配的工作技能吗？我在德雷福斯模型的哪个阶段？我该如何超越当前阶段，成为一个专家？
+
+## 思考题
+
+在成为专家的道路上，关于提升自我、突破自我，你有哪些经验方法和心得体会？
+
+欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/后端技术面试 38 讲/技术人的思维修炼/35 | 技术进阶之道：你和这个星球最顶级的程序员差几个等级？.md

@@ -0,0 +1,80 @@
+<audio id="audio" title="35 | 技术进阶之道：你和这个星球最顶级的程序员差几个等级？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c6/a6/c6565d4f447cdf65a9429044ca76aca6.mp3"></audio>
+
+这些年，我跟一些年轻的软件工程师朋友们交流，关于未来的职业发展，大家普遍都有憧憬和规划，要做架构师，要做技术总监，要做CTO。对于如何实现自己的职业规划，也都信心满满：努力工作，好好学习，不断提升自己。但现实总是复杂的，日复一日的工作生活总能让人一次又一次地陷入迷茫。其原因之一就是对职业发展轨迹和自我能力进步的一般规律缺乏认识，导致做事找不到方向或是操之过急。
+
+## 软件技术的生态江湖与等级体系
+
+软件编程这个领域看似平等、开放、自由，但这并不代表混乱、无序。这个领域并没有什么成文的行为准则，却自有一套运作体系，依靠这套体系，软件开发的技术和知识以极快的速度在全世界范围内传播、推广。如果你致力于成为软件架构师，那么你必须了解一下软件技术的生态江湖与等级体系，因为你的技术处境和你的技术发展之路就在其中。
+
+全世界从事软件开发的技术人员大约有几千万，有序稳定的组织方式总是金字塔结构，在软件开发这个领域也不例外，我们按照每个人的影响力和技能水平，使用二八定律进行划分，得到一个如下的金字塔结构。
+
+<img src="https://static001.geekbang.org/resource/image/18/ab/188e67e7c63176fc979f4565aa4ad0ab.jpg" alt="">
+
+80%的工程师处在这个金字塔最底层，全世界绝大多数的代码出自这一层的工程师之手，但是他们却没有任何技术决策能力和技术影响力。用什么编程语言，用什么数据库，用什么编程框架，日志规范与代码规范如何制定，统统不由他们决定。大多数情况下，一个10人团队，有8个是这样的人，他们在金字塔的第零层，在这个体系中，他们没有自己的称呼。
+
+这一层之上，剩下的20%技术人员中的80%，也就是总数为16%的工程师，他们被称为**团队影响者**。他们是项目架构师、技术经理、技术骨干，他们撑起了项目的技术核心，在项目范围内决定着各种技术方向，核心的代码由他们开发，出了重要的问题也要找他们去解决。这样的人，在一个10人团队中，大约有一两人。
+
+团队影响者之上，是**公司影响者**，大约占总数的3.2%，他们决定整个公司的技术方向，用Java还是用PHP？用MySQL还是SQLServer？微服务用Dubbo还是Spring Cloud？在一个有300名技术人员的公司，这样的人大约有10个。他们通常是公司的技术元老，在公司的技术团队中拥有较大知名度的技术牛人。
+
+团队影响者和公司影响者又如何做出技术判断和决策呢？他们的技术从何而来？通常他们会关注国内最新的技术风向，参加各种技术峰会，阅读各种技术图书，通过这些信息获取知识并做出自己的技术判断和决策。而向他们传播这些最新技术动向的人，是**全国影响者**。这些人通常来自知名的IT互联网公司，当他们说，我们在淘宝、腾讯如何做开发的时候，全中国的开发者都静心倾听。
+
+而这些全国影响者通常是通过关注国外的技术动向来获取信息，主要是一些美国的公司，比如Google、Facebook、微软这些公司的工程师。当他们讲，我们在Google是如何做开发的时候，全世界的开发者静心倾听，想要了解下一次的技术潮流在哪里。他们是**全球影响者**。
+
+在这个技术影响力体系里面，越往高，背景越重要。你是谁不重要，你代表谁更重要，人们关注的不是你叫什么名字，而是你来自哪个公司，这也是很多人想要加入Google，阿里巴巴的原因。有趣的是，来自知名大厂的一些工程师常常忘记了这一点，觉得自己得到关注和掌声是来自自己的成就和能力，结果导致对自己的职业发展产生重大误判。
+
+技术等级体系直到这里，关注的都是技术影响力，通过影响力决定使用何种技术进行软件开发。那我们常用的这些软件技术又从何而来？事实上，正是这些知名软件的开发者，推动了一次又一次软件编程的革命，领导了一次又一次技术进步，带领软件技术行业不断前进。
+
+他们有的开发了一些关键性的技术产品，比如一些广为使用的JSON解析器、单元测试框架、分布式缓存系统，他们是一些**关键开创者**。
+
+还有一些则开创了一个领域，比如Spring，构建了一个完整的Java web开发技术栈，这些软件的核心开发者是**领域创建者**。
+
+而在这个金字塔的最顶层，则是那些开创了一个行业的**行业开创者**，Hadoop成就了大数据行业，Linux引领了操作系统行业，Linus、Doug Cutting这些人就是软件技术领域的王者。
+
+基本上，你能超越你当前所在层次的80%的人，你就可以进入更上一个层级。
+
+## 技术进阶之捷径
+
+那么如何完成技术层级的跃迁，成为更高一级的技术高手呢？你当然可以一级一级地从金字塔的最底层努力做起，在每一层都超越80%的人进入更上一层的技术等级。
+
+那么，有没有捷径呢？
+
+其实还真有，而且被许多人尝试过了。那就是直接去做一个全国影响者，在工作之外，通过持续地维护一个技术博客，或者技术公众号，不断地发表一些高质量的原创技术文章，在某个技术领域打造自己的技术影响力。并通过在一些有影响力的技术峰会上做主题演讲，以及出版一些高质量并畅销的技术图书，持续扩大自己的影响力。
+
+应该说，每一次大的技术浪潮，都会使一批默默无闻的技术人员快速获得全国性的技术影响力，在分布式技术、移动互联网、大数据、AI、区块链等领域，莫不如此。
+
+因此，通过这种方式获得全国性的技术影响力，一方面要持续努力，不断学习、实践，持续获得知识，并把这些知识有效地传播出去。另一方面，还要有眼光，你在一个已经非常成熟的技术上耕耘，再努力也很难获得足够的关注；而在那些尚不成熟的技术上努力，你又如何知道将来这个技术会成功？这就需要有足够的技术敏感性，进行足够多的技术尝试，做出有战略眼光的技术决策。
+
+所以，所谓的捷径只是路径上的捷径，要想在这条捷径上获得成功，需要付出更多的努力和聪明才智。
+
+事实上，如果你足够努力并有足够的天分，你甚至可以超越影响者阶层，直接进入开创者阶层，比捷径更加捷径。
+
+在计算机软件开发领域，美国是全球的领导者，软件领域的新技术基本都是美国人引领的，我们日常使用的各种软件基本上都是在美国开发的。大到各种编程语言，小到各种编程框架和工具，几乎都是在美国开发出来的。
+
+如果说，最近几年这个现象有什么细微的变化，那就是中国开发者的身影越来越多，中国本土开发的软件，也越来越多被全球开发者接受，特别是在开源软件以及最新的技术领域上，中国人越来越多。
+
+这主要得益于最近十几年中国开发者人数的急剧增加，以及中国开发者技术水平的快速提高。在上个世纪，中国人开发一款技术产品，被全球软件开发者使用，似乎是天方夜谭，而到了今天，这完全不是什么不可能的事情。
+
+所以，如果你能直接开发一款在全球范围内被软件开发人员广泛接受的技术产品，并能吸引全球的开发者参与到你的产品开发中，那么你就成为某方面的开创者了。事实上，因为中国开发者人数的庞大，即使你只要在中国范围内获得广泛的接受，其实离距离全球范围内流行也已经不远了。
+
+比捷径更捷径的路不是没有，只是更加艰难，不只需要你个人的努力，还要看历史的进程。
+
+## 小结
+
+所以，从根本上说，技术进阶根本没有捷径，所谓的捷径，其实是你经历了各种努力和挫折后，最后化蛹成蝶的惊鸿一瞥。
+
+为了最后众人瞩目的成功，你依然需要经历金字塔每一层的考验。
+
+在工作中，技术实力固然重要，但是技术实力要转化成公司需要的成果和价值，技术影响力非常重要，通过技术影响力引导团队、部门、公司按照你的技术价值观去构建产品架构和技术发展路径，凝聚公司的技术力量，让你自己和公司向着更高的技术等级前进。
+
+关于如何构建自己的技术影响力，有两点建议：
+
+1. 承担责任：重大的技术决策可能会带来重大的技术风险，要有勇气承担风险，并因此赢得他人的尊重。
+1. 帮助他人：团队成员遇到技术问题的时候，即使不是自己的工作范围，也可以帮助他们去解决问题，一方面建立自己的技术影响力，另一方面，通过解决问题获得更快的技术成长和领悟。
+
+当然，技术影响力的前提是真正的技术实力，没有实力的影响力就是空中楼阁，不堪一击。
+
+## 思考题
+
+最后，你不妨想一想，如何构建自己的技术影响力呢？你有什么想法或者心得吗？
+
+欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/后端技术面试 38 讲/技术人的思维修炼/36丨技术落地之道：你真的知道自己要解决的问题是什么吗？.md

@@ -0,0 +1,71 @@
+<audio id="audio" title="36丨技术落地之道：你真的知道自己要解决的问题是什么吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/28/85/28014d1a0ee909629af6ae63e3f35585.mp3"></audio>
+
+做软件开发，其实就是用软件的手段完成业务需求，而业务需求一定是用来解决某些问题的，用户的问题、老板的问题、运营的问题等等。软件工程师常常疲于奔命，开发各种需求，但是这些需求到底想要解决什么问题，开发完成以后是否真的解决了问题，实现了功能的自身价值。对于这些问题，很多开发者常常既不了解，也不关心。
+
+我们讲一个小故事吧。北欧有一个度假胜地，是欧洲人民夏天避暑度假的好去处，去度假胜地需要经过一个长长的隧道，隧道的工程师为了保证隧道的安全使用，在隧道入口处立了一块牌子，写着：请打开车灯。
+
+游客们开着汽车，打开车灯，穿过隧道，到达度假胜地，愉快地去玩耍了。而等他们要回去的时候，有些人却发现车子无法启动——他们忘记关闭车灯，汽车电池耗尽了。小镇的警察们只好开着自己的警车四处为游客们充电，疲惫不堪。而沮丧的游客们则在回去以后四处抱怨，分享他们糟糕的旅游经验，导致小镇旅游业大受影响，镇长压力山大。
+
+于是人们找到隧道的工程师，要求他在隧道的尽头再立一块牌子，写上：请关闭车灯。工程师照做了以后，却发现麻烦来了：夜晚穿过隧道的游客看到牌子，虽然非常疑惑，但还是按照指示关闭了车灯，结果却发生了车祸，麻烦更大了。于是工程师不得不写上：如果是白天，请关闭车灯。结果有的游客没看到隧道入口的牌子，却看到了隧道出口的牌子，同样疑惑。为了解决新问题，工程师不得不在牌子上继续写下去⋯⋯
+
+这个场景和软件工程师们日常的工作场景是不是很相似？总有客户、老板、产品经理过来跟你说，这里需要这样一个按钮，那里需要这样一个功能。你照做了以后，发现带来了更多的麻烦，为此，你不得不在代码里不断地写if/else。你不是在解决问题，而是在制造问题。
+
+回到这个故事，我们重新思考一下：这是谁的问题？谁能够解决这个问题？如果这是镇长的问题，那么能不能让镇长在停车场修建充电桩让游客们充电？如果这是警察的问题，那么能不能多招一个警察，专门帮游客充电。如果这是游客的问题，能不能在隧道出口立一块牌子，写上：你的灯亮着吗？提醒他们问题的存在，让他们自己去解决问题。
+
+所以，你在每次解决问题的时候，是否想清楚了问题的本质究竟是什么？这是谁的问题？谁能解决这个问题？你在为谁解决问题？这些问题决定了你是否能真正解决问题，为公司创造价值，也决定了你是否能选择最合适的技术去解决问题，进而提升自己的技术能力以及自己的技术影响力。
+
+作为一个软件工程师，如果只是听从别人的指令开发代码，却不了解这些代码究竟想要解决什么问题，那么很多时候你是在制造问题，而不是解决问题，你加班加点辛苦工作只是在为公司制造麻烦。而对于你自己而言，日复一日重复执行解决方案，距离你成为一个技术专家也越来越远。
+
+关于如何发现真正的问题，这里有几个小的建议，供你参考。
+
+## 不要把解决方案当作问题的定义，而忽略了真正要解决的问题是什么
+
+我工作这么多年来，经历过很多公司，参加过很多次技术会议，就我所见，几乎所有的技术会议都没有有意识地讨论过一个主题：这个会要解决的问题是什么？
+
+很多时候，会议一开始就讨论解决方案。有的会议上，产品经理上来就说我们需要一个什么样的功能，请技术部门给一个技术方案和工作量评估，至于这个功能用来解决什么问题，给用户或者公司带来什么价值，几乎很少说明。有的会议上，架构师上来就说我们打算推广一个什么样的技术，请相关技术团队配合，至于这个技术用来解决什么问题，给用户或者公司带来什么价值，也几乎很少说明。
+
+所以，这样的会议，讨论的重点就是解决方案本身：这个功能怎么做，这个技术怎么应用落地。而不是讨论真正的问题是什么：为了解决真正的问题，这个功能是不是必须要做，有没有更好的解决办法；这个技术是不是必须要上，能不能带来足够的价值。
+
+这样的会议，即使有争论，争论的也是解决方案本身，而不是问题。关于解决方案的争论又往往陷入各种细节之中，经过一番讨论，更加不知道要解决的问题是什么了。
+
+所以，以后参加技术会议的时候，也许不需要急于参与到讨论之中，而是要多思考：这次会议把要解决的问题说清楚了吗？需求背后真正要解决的问题是什么？当前讨论的内容真的能解决问题吗？
+
+想清楚了这些，你会对当前的局面有更加清晰的认识，你会发现其他与会者的激烈争论，都是在盲人摸象，自说自话，彼此的关注点根本不在同一个问题上。
+
+这个时候，你出手把大家拉回到问题本身，主导会议的讨论方向，你就会成为最有技术影响力的那个人。
+
+## 你不需要去解决别人的问题，你只需要提醒他问题的存在
+
+在有关育儿教育的经典书籍中，对于如何面对婴幼儿的哭闹，比如小孩子摔倒了，开始哭闹的时候，给出的解决方案是，不要立即鼓励小孩子，要让他们勇敢一点，自己爬起来。更不要斥责他没出息，走路不小心什么的，而是把他抱在怀里，轻轻在他耳边说，（爸爸）妈妈知道你摔疼了。重复这句话，直到小孩子不哭了，然后再跟他说，你是个勇敢的孩子，你可以自己面对的，下次你可以自己爬起来。
+
+在这个例子中，小孩子摔倒了哭，是谁的问题？当然是小孩子自己的问题，但是他太小，又处在巨大的挫折之中，无法独自解决问题。所以，父母这时候要做的是，安抚好孩子的情绪，告诉孩子，爸爸妈妈和你在一起，理解你的痛苦。等他从挫折中恢复过来，不哭了，然后鼓励他，让他自己解决问题。
+
+我们开篇那个隧道车灯的故事也是如此，忘了关闭车灯导致汽车无法启动是谁的问题？是游客自己的问题。谁最适合解决问题？是游客自己，他只需要关闭车灯就可以了。所以镇长设立充电桩，多招一个警察帮游客充电，都使问题更加复杂。但是游客又没有意识到问题的存在，所以不去解决问题。那么要做的事情就不是去帮游客解决问题，而是提醒他问题的存在：**你的灯亮着吗？**游客意识到问题的存在，他就会自己解决问题。
+
+软件需求开发中，也有很多帮用户解决问题的场景。日常开发中，产品、运营、开发、测试、运维，也有很多交互合作，需要互相帮助；哪些问题对方可以轻易解决，哪些问题应该通过修改软件功能来解决，应该思考清楚。
+
+## 鱼是最后一个看到水的，身处问题之中的人往往并不觉得有问题
+
+身处问题之中的人常常并不能感知到问题的存在，正如身在水中的鱼儿看不到水一样。**太多的问题被人们的适应能力忽略掉了，直到有人解决了这些问题**，身处其中的人才恍然，原来过去的方式都是有问题的。
+
+所以，如果你到一个新环境中，发现存在着一些问题，而身处其中的人却熟视无睹，往往不是他们有问题，也不是你有问题，可能只是他们已经适应了问题的存在，而你还没有适应。
+
+关于问题的定义有个公式：**问题 = 期望-体验**。
+
+到一个新环境中，大家体验差不多，但是你的期望和其他人不同，你就会感受到问题。而这种感受则可能是你出人头地的机会：如果你解决了这些问题，其他人也会明白过去的方式是有问题的，而你就是那个解决问题的人。
+
+## 小结
+
+一个技术，是不是真的能解决问题，是衡量一个技术是否有效的主要标准。而业务究竟遇到了什么问题，用什么样的技术才能真正有效地解决问题，是工程师在进行技术落地之前必须要考虑清楚的事情。
+
+不去思考，真正地面对问题，总是试图用自己擅长的技术，或者业界热门的技术解决工作中看似一样，其实大不相同的业务问题，既不能够真正解决问题，为公司创造价值，也不能够提升自己的技术水平，获得真正的进步。
+
+如果自己用技术总是能有效解决问题，在这个过程中，也会不断增强自己的技术自信，知道自己用技术可以创造真正的价值，自己可通过技术参与到改造世界的过程中，也会树立起技术的信仰。不会总是犹豫，自己是不是要转管理，是不是要转行。
+
+## 思考题
+
+隧道车灯的小故事对你有什么启发？
+
+如果你是一个管理者，你团队某个员工工作不认真，工作效率低，是谁的问题？是公司的问题吗？是你的问题吗？是员工自己的问题吗？如果是员工自己的问题，你该如何提醒他问题的存在，并进而帮助他提高工作效率？
+
+欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/后端技术面试 38 讲/技术人的思维修炼/37丨技术沟通之道：如何解决问题？.md

@@ -0,0 +1,73 @@
+<audio id="audio" title="37丨技术沟通之道：如何解决问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a9/62/a9648808b900237c71fb1c4a990a7062.mp3"></audio>
+
+我们在日常工作中，总要和很多人合作。有时候，我们需要依赖别人的工作结果，以作为我们工作的输入；有时候，我们的工作产出需要交付给别人，才能产生最终的价值。在这些合作过程中，可能会遇到各种问题。
+
+如何通过有效的沟通解决各种问题，这里我给出一些建议，供你参考。
+
+## 如果某人能够解决问题，而他自己却感受不到问题，那么就让他感受一下
+
+在工作合作的过程中，有的时候，对于对方来说，明明是举手之劳的事情，但他偏偏在拖延，你去催促也没什么效果。这时候，我们很容易将问题归结为对方的工作态度有问题，事实上，很多时候，其实是对方没有理解你的问题，他觉得你在没事找事，你才是工作态度有问题的人。
+
+将问题归结为人的态度问题，大多数情况下，是无法解决问题的，况且，很多时候确实不是态度问题，而是不同的人做事能力、理解能力、立场和看待事物的角度不同而已。所以，如果只是立场和角度的问题，那么就可以将对方拉到同一个立场来解决问题，如果对方没有感受到问题，那么想办法让对方感受一下问题。
+
+通常说来，上司的能力要比你的能力强，调动的资源也比你多，有些事情对你而言可能非常困难，但是你上司也许一句话就可以搞定，这个时候，你可以考虑利用你的上司去解决问题。如果他没有感觉到问题，那么想办法让他感觉到问题。
+
+所以有句话叫做：**用人的最高境界是用上司**。
+
+有的时候，对于一件有风险的工作，如果你自己做决策，那么当事情不顺利的时候，你可能无法承担风险，那么你就应该将你的上司拉进来。你可以直接问他：有这样一个方案和计划，你觉得合适吗？但是这种提问方式，可能会导致你的方案被上司否定。更好的提问方式是：这里有A、B两个方案，你觉得哪个方案更合适？从而将上司的回答引导到你期望的方案上面去。
+
+而上司一旦回答了你的问题，就等于参与到你工作中去了，当事情出现风险的时候，你再去找他寻求支持的时候，因为是他曾经做出的决策，那么他更容易跟你站在一起，帮你解决问题。
+
+这里要注意的是，当你寻求上司支持的时候，不要问上司怎么办，不要给上司提开放式的问题。一则上司可能不理解你的问题上下文，无法给出合适的建议，从而使上司和你都难堪。再则上司如果给出的方案是你难以执行的，你是在给自己挖坑往里跳。
+
+而封闭式的问题，只需要回答好不好就可以，比如选择A方案还是B方案，就不会有上面的问题。
+
+相反，如果你给下属提问，就不要提封闭式的问题，你问下属这个方案好不好，可能会导致他质疑你的能力，同时也限制了他的能动性，使他无法思考和调查更多的解决方案。
+
+## 直言有讳
+
+在合作的过程中，合作的小伙伴可能犯一些错误，如果这个错误影响了你，你应该指出来，而不是为了和谐假装视而不见，任由事情向失败的方向滑落。但是，这里要注意的是，你指出错误是为了改正错误，达成目标，而不是为了责备、打压对方，也就是所谓的：**要批评而不要责难，要对事而不要对人**。
+
+如果你针对人，那么对方就一定和你处在对立的一面，你们就是在进行人际斗争，而不是在解决问题。**直言有讳**就是说，指出负面情况的时候，要直接，不要兜圈子、说含糊话，否则你的语言就没有力量，无法解决问题，但是也不要想说什么就说什么，要有所避讳，主要就是不要把问题指向人。可以说这件事情这样做是不对的，但是不要说你这个人是有问题的。
+
+即使直言有讳，但是有的时候还是会引起人与人之间的对立，特别是在你反对对方的某个方案的时候，对方很容易就认为你是在反对他，进而排斥你的建议。这方面，我在阿里巴巴的时候，跟我当时的上司，学到一个非常好的技巧。
+
+他当时是阿里巴巴的首席架构师，要经常参与各种技术方案的评审会，也要否定掉很多的技术方案，但是他几乎没有和任何他要反对的技术方案的提出者发生过争执或者冲突，固然，他有很大的技术影响力和技术权威，但另一方面，他也有很好的反对技巧。
+
+后来，我总结了一下，就是**以赞成的方式表示反对**。当他要反对一个技术方案的时候，他先是表示赞成，他会说，这个方案很好，然后从设计、价值几个方面快速说几个比较好的点，这个时候，方案的设计者就和他站在同一个立场上了，将他接纳为自己人。接着，他就会将话题转换，他会说：“但是，我还有几个小小的疑问和建议。”然后，他会说出他反对的观点，而设计方案的提出者因为已经从内心接纳了他，所以能够认真倾听他的疑问和建议，重新思考自己的方案。
+
+还有一种情况，就是有些新来的同事，会针对公司现状提出各种建议和方案，这些方案和建议有的并不靠谱，但是，如果你直接指出其中的不靠谱之处，可能会非常打击新同事的积极性，他们甚至会怀疑公司的合作氛围。
+
+这种情况下，**适当的逃避问题**，反而是一种解决问题的正确方法。可以跟新同事说：我今天比较忙，改天我们组织个会议详细聊。将讨论的时间推后，将讨论的门槛提高（组织会议），新同事将有时间更严肃地思考他的方案，他会自己发现方案的问题，自己放弃这个方案。这样的结果，对新同事，对同事之间的关系，对公司都有好处。
+
+## 如果你想解决一个大家都不关注的问题，那么试试让问题变得更糟
+
+有的时候，系统架构已经欠了太多技术债，摇摇欲坠，你想要做一次重构，但是团队上下都以事情太多、忙不过来为由不支持；还有的时候，你想要对系统加一个应用防火墙，以保护系统安全，但是大家都觉得你没事找事，瞎折腾。
+
+这种情况下，你怎么办？在你力所能及的范围内做一些修修补补，避免问题的发生？其实，这样做，只会让问题看起来确实不那么严重，并不需要着急去解决，距离完全解决问题反而是拖延了。事实上，很多问题，拖得越久，越难解决。
+
+所以，如果你觉得这里真的有问题，需要尽快解决，那么就不要试图对问题进行修修补补，使问题被拖得越来越久。也许你放任问题发生，尽快暴露出问题，反而却使大家对问题的严重性达成一致意见，完全支持你去解决问题。
+
+大家都听说过“亡羊补牢”这个成语，以前我一直觉得这是一个贬义词：一个人直到丢了羊才去修补他的羊圈。现在，我渐渐觉得，这也许才是做事的正确方式，工作、生活中每天有太多的事情需要去做，你怎么知道哪些事情是重要的？如果是在一个团队中，你怎么让大家相信，你应该做的事情是重要的？也许“丢几只羊”才能让自己、让大家真正意识到问题的严重性，也许这是我们真正解决问题必须要付的代价。
+
+## 如果你不填老师想要的答案，你就是个傻瓜
+
+我们每天在解决各种问题，帮产品经理解决问题，帮用户解决问题，其实我们最终都是在帮自己的上司解决问题，你如果不解决这些问题，你的上司可能就会遇到问题。
+
+因此，如果你觉得一个问题很重要，而你的上司却不觉得，那么你辛苦去解决这个问题可能就是在白费功夫。你无法在一个管理体系中获得认可，你的工作无法获得正反馈，你的努力是无法持续的。
+
+所以，如果这个问题真的很重要，而你无法让你的上司认可其重要性，那么对于你而言，真正严重的问题不是问题本身，而是你的上司本身。
+
+既然员工是以上司的意志作为自己工作的依据，那么就可以得出一个推论：管理者对待问题的视角和态度，决定了下属会成为什么样的人。管理者的眼光和判断会决定团队做事的风格和方向，也决定了什么样的人会加入团队，什么样的人会选择离开。最终这个团队的人都会变成某种类型的人，虽然这可能完全不是管理者期望的，但结果却往往如此。
+
+## 小结
+
+这两篇专栏文章都是关于问题的。我们的工作、生活都是由一个个问题组成的。但是发现问题，解决问题其实并不能让我们超越现状，获得更多的自由和成就。太沉迷于解决问题，会使我们的视野和努力专注于过去，而不是放眼于未来。
+
+事实上，真正的成就与超越来自于对未来的探索和追求，而不是对当下问题的分析和处理。
+
+## 思考题
+
+如果未来更值得我们去思考，那么这里有一个真正的问题：假如今天晚上所有困扰你的问题都消失了，明天你想做什么？如果你的回答是睡觉、旅游，甚至是学习，那么请再想一想，睡觉、旅游、学习之后呢？你的人生真正想要的是什么？
+
+欢迎你在评论区与我分享你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/后端技术面试 38 讲/技术人的思维修炼/38丨技术管理之道：你真的要转管理吗？.md

@@ -0,0 +1,69 @@
+<audio id="audio" title="38丨技术管理之道：你真的要转管理吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/13/75/13355f4e28eb85c3c10d050d3a9c5675.mp3"></audio>
+
+做技术开发同学的职业规划通常有两个方向：一个是持续做技术，成为技术专家、架构师；一个是转管理，带领技术团队做开发。开发团队需要管理者，那么开发出身的工程师做管理者也是顺理成章的事。过去十几年，很多优秀的工程师成功转为技术管理人员，成功的比例似乎比成长为技术专家的比例还要高一些。这也给了更多工程师转管理的信心，似乎技术转管理是一件相对比较容易的事。
+
+事实上，过去十几年技术人员之所以能够更容易转为管理人员，根本原因在于开发行业的快速扩张，过去十几年，随着互联网的快速发展，从事软件开发的从业人员数量大概增长了几十倍，开发团队规模迅速扩张。必须要有技术人员成为管理者，以管理越来越庞大的技术团队。
+
+如果一个人在技术部门只有十来个人的时候加入公司，经过几年发展，公司现在技术部门有100多人，组织上差不多需要划分为十多个开发小组，每个小组需要一个技术主管，那么就需要10多个技术管理者，所以在公司早期加入的这个开发人员，如果能够胜任工作，跟着公司一起成长，那么大概率地会被任命为技术主管。
+
+如果公司继续发展，技术部门达到1000多人，那么100多人的时候加入公司的技术人员也有很大概率会被任命为技术主管，如果这个人在管理方面表现得足够好，那么他可能会被继续提拔，成为经理、总监、CTO，在管理的道路上越来越成功。
+
+看起来，技术转管理这条路似乎很光明，是软件技术人员一条不错的职业发展之路。
+
+但是，这条光明的道路其实隐藏了一个非常重要的前提，那就是技术团队规模必须指数级增长，才能不断产生足够数量的管理岗位空缺，才会让后来的人跟前面加入公司的人一样有机会成功转型管理。
+
+事实上，过去十几年中，整个行业的软件开发从业人员确实是指数级增长的，但是最近几年，这个增长势头已经明显变慢，未来会怎么样，相信不用我说，你也能做出判断。
+
+如果整个行业的软件开发人员数量从现在开始不再增加，那么现在的工程师转管理的难度将比自己的前辈难一个数量级。所以，如果你觉得你的主管、经理的管理水平不过如此，你做管理不比他们做的差，这是远远不够的，这并不能够支持你成功转型管理。这是因为他们转管理的时候，难度要远低于你现在转管理的难度，如果你的规划是将来几年转管理，那么局面会更加悲观。
+
+但是，我并不是在这里给你打退堂鼓，劝你放弃转管理。我们的国家现在正在进行产业升级，各行各业都需要在科技水平和管理水平上进行升级，以应对更加激烈的全球竞争局面。软件开发也不例外，虽然我们的互联网产业、软件产业看起来和国际接轨，水平还可以，事实上，我们的软件从业人员，不管是技术水平还是管理能力，和发达国家相比还是有较大差距。
+
+最近几年，就我所见，开发人员的技术水平是在快速提升的，从我们这个专栏得到的反馈也确实如此。但是，技术管理者的管理水平却似乎并没有太多的进步，我想，这也许就是你的机会。
+
+但是，你想把握住机会，就不能仅仅以你的前辈作为榜样和基准，而是要进行更科学的管理方面的学习和训练。这里，我跟你分享几个关于管理的基本原理和概念。
+
+## 彼得定律
+
+彼得在20世纪70年代，研究了美国数千个组织，包括政府部门、学校、企业等各种类型的组织后，发现，在一个成熟有效的组织中，当一个员工在其岗位能够出色完成工作，就会得到晋升，被提拔到更高一级职位。如果在这个职位，他能够继续出色完成工作，就会继续得到晋升，直到他晋升到某个职位以后，无法出色完成工作为止。
+
+这是职场晋升的一般规则，看起来似乎也没什么，但是彼得在对这些得到晋升的人进行各种观察以后，得到一个结论：**在一个层级组织中，每个员工都会趋向于晋升到他所不能胜任的职位。**这就是彼得定律，事实上，我们根据晋升的一般规则，也能推导出这个定律。利用这个定律做进一步的推导，还能得到一个彼得定律的推论：**一个成熟的组织中，所有的职位都被不能够胜任它的人承担着。**这个推论也很好理解，每个人都会晋升到他不能胜任的职位，那么稳定下来以后，所有的职位都被不能胜任的人承担。不得不说这个结论实在是让人有点吃惊，但是却很好地解释了组织中的各种奇怪现象。
+
+彼得进一步对这些不能胜任自己职位的人进行观察，发现当一个人位于他不能胜任的职位上时，他必须投入全部的精力才能有效完成工作，这个职位也被称作这个人的**彼得高地**。一个处于彼得高地的人，精疲力尽于他手头的工作，就无法再进行更进一步的思考和学习，他的个人能力提升和职业进步都将止步于此。
+
+所以，一个人在其职业生涯中能够晋升的最高职位，能够在专业技能上进化的最高阶段，依赖于他的专业能力和综合素养，依赖于他拥有的持续学习和专业训练的条件与环境。和他晋升的速度无关，有时候也许恰恰相反。
+
+对公司而言，真正有价值的是你为公司解决了多少问题，而不是完成了多少工作，工作本身没有意义，解决问题才有意义。对于你自己而言，真正有价值的不是你获得了多快的晋升，多高的加薪，而是你获得了多少持续高强度训练的机会。而这两者，本质上是统一的。
+
+所以，对自己未来有更多期待，更有进取心的工程师们，应该将精力更多放在发现企业中的各种问题并致力于去解决问题，在这个过程中，你将同步收获职场晋升和个人能力提升。
+
+## 用目标驱动
+
+在技术管理领域，常见的管理方式有两种，一种是问题驱动型管理，一种是流程驱动型管理。
+
+问题驱动型管理着眼于问题，每天关注最新的问题是什么，然后解决问题。流程驱动型管理着眼于流程，关注事情的进展是否符合流程规范，是否在有序的规章制度下行事，看起来像监工。
+
+老实说，这两种都不是高效的管理方法。对于技术管理而言，更高效的管理方式是目标型管理。
+
+目标驱动的管理者关注的是目标，公司的目标是什么？部门的目标是什么？团队的目标是什么？我的目标是什么？我和我的团队做这些事情的价值和意义是什么？不断问自己：我如何做才能为公司，为客户创造价值？
+
+目标驱动的管理者并不特别关注问题，他更关注解决方案。当系统出现故障的时候，他不会关注是谁导致的bug，他更关注谁可以解决这个bug。当项目进展缓慢，他并不关注是谁导致了拖延，他更关注我们如何做才能赶上进度。他不问问题为什么出现，因为他知道，所有的问题最后都是人的问题，而纠结于人的问题，只能导致人和人的扯皮。
+
+目标驱动的管理者其实并不是不关注问题，他只是不用问题进行管理，不让团队纠结于问题之中，而是去着眼于未来和解决方案本身。管理者自身其实对问题非常清楚，但是他把问题转化为目标，引导团队前行。
+
+OKR这个词最近两年在互联网企业很风靡，OKR就是Object目标与Key Result关键结果。通过对团队和个人制定有挑战性的目标和可量化的结果标准进行管理。可以说是目标驱动管理的一种落地实践方案。
+
+通常的做法是在一个OKR周期开始的时候，每个团队和个人制定**自己的**OKR：我目标是什么，达成目标后产生的关键结果是什么。所有的OKR都需要公开，通过阅读自己合作伙伴和上级部门的OKR，了解自己的目标在组织中的作用，自己工作的结果对组织的价值，从而了解自己在组织中的位置，使自己的工作成为组织战略的一部分。
+
+在工作过程中，根据目标不断调整自己的工作方式，期间需要定期进行review：到目前为止，我产出的成果有哪些，距离我们的目标是更近了还是更远了，我们还需要做哪些工作才能达成我们的结果。
+
+需要注意的是，OKR并不是用来考核的，不应该以目标是否达成作为考核的依据，否则每个人都倾向给自己制定最简单的结果和目标。OKR是一种管理手段，通过对目标的制定和对结果的审核，将团队和员工的奋斗目标和公司的战略目标统一起来，使每个人都能理解自己工作的目标是什么，在整个公司战略中的地位是什么，使个人更加成为公司整体的一部分。
+
+## 小结
+
+管理学作为一个学科已经出现了上百年的时间，它有自己的专业工具和方法，有自己的客观规律。仅仅技术做得好并不能保证可以好管理，想转管理的同学应该专门学习一下管理学的基础知识，而不是仅仅看了两篇管理文章，觉得自己技术不错还擅长沟通就转管理了。
+
+## 思考题
+
+最后，我问你一个问题吧，也是人们常见的疑惑，OKR和KPI的关系到底是什么？
+
+欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/后端技术面试 38 讲/技术人的思维修炼/答疑丨工作中的交往和沟通，都有哪些小技巧呢？.md

@@ -0,0 +1,161 @@
+<audio id="audio" title="答疑丨工作中的交往和沟通，都有哪些小技巧呢？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ca/4d/ca70b45a1c2ee1729c51eea68aad784d.mp3"></audio>
+
+《倚天屠龙记》里有这么一段，赵敏和周芷若势同水火，非要拼个你死我活，结果张无忌来了后，几句话就让两个人情同姐妹。看的明教众人面面相觑，最后得出一个结论：能者无所不能。
+
+我认识的很多技术高手也常常给我这样一种感觉，他们不只是技术好，他们几乎无所不能。对业务的理解，对人际关系的把握，对未来发展的预见性，对事物本质一针见血的描述，常常使我既惊叹，又佩服。
+
+曾经我以为这些人是因为技术好所以样样精通，后来我猜想他们是因为样样精通所以技术好。软件开发是一个实践性很强的技术活动。要想做好软件开发，就需要有较强的社会实践能力。我在这个模块讲了一些技术之外的社会实践规律，这些规律和技术的关系也许比大多数人想象得更加紧密。
+
+关于工作中的交往与沟通，我这里再分享一些小的技巧。
+
+## 保持交际和赞美
+
+很多程序员不喜欢交际，觉得浪费时间。事实上，保持适当的交际，可能会帮你节约很多时间。一方面，良好的交际关系可以营造一种更愉快的工作氛围，自己和其他同事可以保持更好的工作状态；另一方面，处理某些问题的时候，比如，需要指出某个人工作失误的时候，良好的关系可以缓冲这类指责带来的负面影响。相反，如果你们平时见面的时候就形同路人，这个时候，他更有可能认为你是对他个人的否定，而不是对工作本身的意见。
+
+而且，保持适当的交际并不需要花费多少时间，仅仅是简单的寒暄，聊聊天气，就可以拉近两个人的距离。如果寒暄的时候，对方正好有个不错的机会想要找人合作，也许还会给你带来更加巨大的收益。
+
+除了简单的寒暄，赞美是一种更加高效的交际方法。曾经有人在网上调查，有什么技能是可以很快学到而终身受用，出乎意料地，排在最前面的答案不是驾驶、游泳、烹饪这些很硬的技能，而是一项很软的技能：赞美他人。
+
+赞美不是奉承，不是泛泛地说一些：你好棒，你真厉害。**赞美是对对方做得好的事情，明确表达你的称赞**。称赞的是对方的行为，比如对小孩子说：你摔倒了没有哭，而且自己爬起来，好棒。对同事说：谢谢你昨天晚上加班，我们今天可以按期发布项目。对方通过你的话能感受到真诚，得到正向的激励，而不是敷衍和世故。
+
+就我们目前的环境而言，赞美太少了而不是太多了，尝试多去赞美别人，你会得到意想不到的收获。此外，赞美和批评并不冲突，你可以对一个人既赞美又批评，只要你明确指出赞美和批评的具体事情，对方就可以更加明白你的标准和边界，后面的合作也会更加的顺利。
+
+## 平衡力量和温暖
+
+职场中什么样的领导最受欢迎，答案是，同时拥有力量和温暖的人。
+
+所谓的力量是指能够达成目标的能力，包括技术能力、整合资源的能力、决策力、意志力等各种能力，通过这些能力，能够完成工作目标和任务。人们愿意和有力量的人合作，追随有力量的人，因为这样获得成功的可能性就越大。
+
+而温暖是指拥有让他人产生熟悉感和归属感的能力。表明上看，这种能力是一种共情能力，可以理解他人的喜怒哀乐，进而产生熟悉和归属的感觉。事实上，这是一种构建共同的目标和价值观的能力。
+
+每个人的喜乐并不相同，如果是被动地和其他人共情，是无法深度地整合一个团队的所有人的。而通过构建共同的目标和价值观，让大家产生归属感，进而营造出一种温暖的团队氛围。
+
+如果一个人光有力量而没有温暖，那么和他合作的人可能会嫉妒他，或者对他感到恐惧。而一个人光有温暖没有力量，大家只会觉得他很萌。同时拥有力量和温暖的人，会让他人感到钦佩。而既没有力量有没有温暖的人，大家会蔑视他。
+
+在平衡力量和温暖方面，马云做得可谓出类拔萃。我在阿里巴巴工作的时候，能够强烈感觉到这种力量和温暖，一方面大家坚信公司和自己团队的事业一定能成功，另一方面又非常认可自己做的工作的意义和价值。
+
+力量和温暖是既一种内在的属性，也可以通过一些外在的行为表现。一个占据更大空间的人会给人力量感，所以不要含胸驼背，把自己缩在一起；另外，主动碰触别人和适当认错也是一种力量的体现。表达对他人的理解以及分享一些相同的经历则会传递温暖的感觉。
+
+## 学会聆听和提问
+
+在工作沟通的过程中，有时候直接提出自己的观点或者方案，并不能得到其他人的赞同和支持，因为其他人可能并不了解你的问题和场景，没有思考过你的问题，所以对你的观点和方案不置可否，不积极参与。这种情况下，可以通过一些提问的方式，将对方拉到你的思考上下文中，让对方通过自己的思考得出你想要表达的观点和方案，这种情况下再去推动事情的发展就容易多了。
+
+我在第36篇提到这样一个思考题：
+
+> 
+如果你是一个管理者，你团队中某个员工工作不认真，工作效率低，是谁的问题？是公司的问题吗？是你的问题吗？是员工自己的问题吗？如果是员工自己的问题，你该如何提醒他问题的存在，并进而帮助他提高工作效率？
+
+
+这个问题其实并不简单，员工工作态度不好、工作效率低，可能有企业文化的问题，可能有领导风格的问题（也就是你的问题），可能有项目阶段性挫折的问题。假设这里你的判断是员工自己的问题，因为团队其他人都没有态度问题，那么你该如何帮助他纠正问题？
+
+直接指出问题也许不是一个好主意，因为可能会引发员工的对立情绪：你对我有意见。你不妨可以在和员工交流的时候问一些问题，以提醒他问题的存在：如果你给自己近期的工作成果打分，你会打几分？你觉得其他同事对你近期的工作成果打分，会打几分？如果你自己是用户或者老板，你是否对自己的产出满意？
+
+通常情况下，如果真的是员工自己的问题，那么通过回答这几个问题，他会意识到问题的存在，并想要主动去改变状况。这要比你直接指出他的问题或者批评他效果要更好一些。
+
+如果他已经意识到问题，那么你还可以更进一步提问：你希望我做些什么，可以帮助到你？你下一步有什么打算，可以改进目前的状况，让你自己基本满意？你觉得完成这些改进大概需要多长时间？两周？好，那么我们两周以后再聊一次。
+
+## 小结
+
+彼得·德鲁克曾经说过，最好的管理学书籍是小说。因为管理就是将每个人的主观能动性发挥出来，为组织创造价值，但是人性是复杂的，任何刻板的管理教条都会遇到人性的阻力，进而演化成组织前进的阻碍。而洞悉人性，善于利用人性的特点，把相关各方的利益统一起来，事情会自然前进。
+
+有些同学纠结将来走管理路线还是技术路线，其实这两者之间的鸿沟并没有想象得那么大，不管是做好技术还是做好管理，都需要有很强的社会实践能力，都需要理解人性，利用人性，特别是理解和利用好自己的人性。
+
+最后，用一篇我十几年前翻译的一篇短文《软件架构师之道》作为这个模块的结尾吧！
+
+0
+
+一个杰出的架构师，
+
+团队几乎感觉不出他的存在。
+
+次一点的架构师，大家都爱戴他。
+
+再次一点的，大家都怕他。
+
+而最糟的，大家都鄙视他。
+
+1
+
+架构师任事物按照自身的规律发展。
+
+他让自己的行为符合事物的本质。
+
+同时他又跳出束缚，
+
+让他的设计照亮自己。
+
+2
+
+架构师用心旁观这个世界，
+
+而他坚信他内心的映像。
+
+他的心像天空一样开阔，
+
+任世相万物来来往往。
+
+3
+
+优秀架构师不会夸夸其谈，他只是做。
+
+当任务完成的时候，
+
+整个团队都会说：
+
+『天哪，我们居然做到了，全都是我们自己做的！』
+
+4
+
+架构师的权力是这样的：
+
+他让事物自然发展，
+
+毫不费力，也不强求。
+
+他从不失望，
+
+他的精神也就永不会衰老。
+
+5
+
+懂的人不说，
+
+说的人不懂。
+
+没有头绪的人还在讨论过程，
+
+明白的人已经开始做了。
+
+6
+
+优秀架构师乐于用一个例子说明想法，
+
+而不是强加他的意愿。
+
+他会指出问题而不是戳穿它们。
+
+他是坦率的，也是柔顺的。
+
+他的眼睛闪着锋芒，却依然温和。
+
+7
+
+如果你想成为一个杰出的领导，
+
+就不要去试图控制什么。
+
+带着一个弹性的计划和概念推进，
+
+团队会管好他们自己。
+
+你越是强加禁令，
+
+队伍越是没有纪律。
+
+你越是强制，
+
+大家越是没有安全感。
+
+你越是从外面寻找帮助，
+
+团队越是不能独立自主。