del

极客时间专栏/geek/乔新亮的CTO成长复盘/对专业成长的复盘/17 | 架构决策，是技术管理者最重要的能力.md

@@ -0,0 +1,183 @@
+<audio id="audio" title="17 | 架构决策，是技术管理者最重要的能力" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c7/4d/c76c90d07cc6ee8d1254140e0626944d.mp3"></audio>
+
+你好，欢迎来到我的专栏：「乔新亮的 CTO 成长复盘」第三章 —— 也是最后一章：「对专业成长的复盘」，我是乔新亮，很高兴能见到你。
+
+说起来真的有点感慨，自从 10 月 26 日专栏上线起，眨眼间，我们共同度过了一月有余的时光。
+
+在这段时间里，有超过 3500 人加入课程，与你我一起成长。专栏共发布了 17 篇文章，收到了超过 500 条留言，有好多同学是篇篇都留言，一路相随。基本上，每一条留言我都回复了，收获了许多感动与启发。
+
+感谢你！
+
+接下来，我们将以技术和架构思维为抓手，夯实管理者的成长基础，争取做一个底子打得扎实、向上生长快的优秀技术管理人才。最终，我们的目标是，成为一名优秀的 CTO。如果你觉得有收获，不妨把文章分享给其他人。不同的声音越多、交流的价值越大，成长的速度就越快。
+
+好，我们言归正传，聊一聊如何理解和提升架构决策能力。
+
+## 决策失误，是“技术债”的主要来源
+
+你可能会想，老乔是在吊人胃口吗？在「专业成长」部分，不赶紧讲架构设计，反而去讲所谓的架构决策能力。
+
+事实上，回顾这些年的管理经验和见闻，我认为架构决策能力不但非常关键，而且是技术管理者最重要的能力之一，而且职级越高就越重要。
+
+2012 年初，我身在 IBM，为苏宁提供顾问服务。
+
+当时，苏宁面临一个重大的架构决策问题：是继续沿用 ESB（企业服务总线）架构，还是转向分布式架构。
+
+在今天看来，这个问题或许不需要讨论 —— 很多企业都在拥抱分布式架构，放弃 ESB 架构。但在当时，苏宁是更倾向于继续沿用 ESB 架构的。
+
+因为在苏宁的技术架构内，是存在 SAP 服务和一些异构系统的，不能直接弃用 ESB，选择分布式等于同时维护两套系统。
+
+但我坚定地支持采用分布式架构，理由有很多：
+
+1. ESB 是一个集中点，风险非常大； 如果选择  ESB  架构并且让其承载大量的业务逻辑（系统间调用的处理逻辑），后续转型困难；
+1. 系统内虽然存在部分异构系统，但大部分是同构系统，分布式系统完全可以支撑；
+1. 在分布式架构中，不同服务可以直接访问，无需像 ESB 架构一样经过负载均衡系统和网络交换机，避免了资源的浪费；
+
+……
+
+虽然理由很多，但在工作性质上，我属于乙方，是企业外部人员；而持反对意见的是甲方，属于企业内部人员。大部分情况下，乙方不会在这种问题上和甲方争执到底 —— 如果甲方已经有非常明确的倾向和意见，那就顺从甲方，不是挺好的吗？
+
+但我知道，架构决策事关重大，所以坚持表达了意见。最终，苏宁的 IT 系统也顺利转型为分布式架构，没有走上歧路。
+
+最让我庆幸的是，2015 年我加入了苏宁。如果当初没有坚持转型分布式架构，三年之后，就会有一个庞大、臃肿、高风险的“烂摊子”架构在等着我收拾，那该有多么痛苦？
+
+说了这么多，并非是要突出自己聪明。恰恰相反，我相信人人都很聪明，也非常专业，但如果在一个重要的架构决策失误了，企业就可能需要花三年、五年甚至更久的时间来“还债”。
+
+你看，其实很多所谓的“技术债”，也就是由一次次的决策失误不断累加而成的。
+
+那么什么是架构决策能力呢？简单来说，就是当团队因架构方案的选择，出现争议、迟迟不能决定时，管理者需要具备的、一锤定音的能力和方法。
+
+新架构多久落地，说到底只是个效率问题。但如何拍板确定新架构的设计，则是重要的方向性问题。如果方向不对，那么无论团队里有多少精兵猛将，也只能跟着漫无目的地瞎忙，这就是所谓的“一将无能，累死三军”。
+
+## 选择“不作为”，往往更加可怕
+
+说句公道话，很多管理者虽然会出现决策失误，但至少做了决策，使业务在一定时间内可以维持增长。最不靠谱的是，管理者选择不做决策，导致团队工作无限期阻塞，严重影响业务发展。
+
+举个例子，有两个团队成员坐在会议室里，争论两个架构设计方案孰优孰劣。他们各执一词，谁也说服不了谁。这时，你作为技术管理者，应该怎么办？
+
+我大概见过三种处理方式：
+
+1. 给大家分析哪一种方案更好，现场拍板；
+1. 指出当前双方考虑不周到的地方，再给大家时间去准备，并在 Deadline 前决策拍板；
+1. 泛泛地对大家说：“不够具体”、“没有重点”，“再回去想想”……
+
+第一种、第二种其实都是正确的处理方式，建立在管理者内心已经有答案、有见解的基础上，前者追求决断效率，后者看重团队培养，都很棒。
+
+但第三种就有点值得玩味了。很多时候，这代表某种“职场生存技巧”。表面上，管理者希望团队多多思考，但实际上，他是自己没想明白。至于接下来，无非是一个字：拖。
+
+有些方案或项目甚至因此延期半年以上，这对于一家企业来讲是非常危险的。
+
+所以，在这一讲的开始，有一个关键认知，我一定要同步给你：
+
+**一把手是团队的天花板，并为团队的所有问题负责。**
+
+作为管理者，尤其是前几年，我经常用以上认知告诫自己。映射到架构决策层面，也就是一把手一定要有勇气在方案之间做取舍，并承担相应的后果。
+
+当然，架构决策也不能乱做，千万别说：乔老师说了，要敢于做决策，然后闭着眼睛挑了一个答案……
+
+关于架构决策，其实是有一套意见反馈和流程模板的。
+
+## 做好架构决策的流程和模板
+
+当管理者需要做架构决策时，就意味着至少有两个、三个甚至更多架构方案摆在面前，各有利弊，需要高层协助决策。在苏宁时，我还为此建立了一套架构决策流程，决策流程如下：
+
+1. 当事人发起架构决策申请；
+1. 由产品负责人判断：该申请是在产研中心部门内协调解决，还是上升至 CTO 办公室解决；
+1. 在产研中心部门内，或联合 CTO 办公室，完成架构评审；
+1. 将结果发还至当事人征询意见；
+1. 由当事人判断是否仍有疑虑，需要进行架构仲裁；
+1. 若需要则发起仲裁会，解决分歧；若不需要则结案归档，执行决策。
+
+过程中可能涉及的参与人包括：产品负责人、技术负责人、架构师团队、架构负责人、CTO 办公室负责人等。如果是部门内协调解决，则 CTO 办公室不参与评审；如果评审后仍有分歧，则 CTO 办公室连同其他负责人一起介入架构仲裁，快速解决问题。
+
+你可能会想，设计这么长的流程和表单，难道不是人为地加长决策周期吗？有点不太“敏捷”啊。
+
+没错，只要涉及到新增制度、新增流程，无论考虑得多完善，都会降低团队敏捷度 —— 初创团队几乎总是动作最快的，万人大厂相对来说就要迟缓一些。因此，在管理小团队时，我可能不会推行以上决策流程，因为我的精力足够覆盖团队每一次重要决策；但对于大型企业来说，上述制度就开始变得非常重要。
+
+同时，我们也要认识到，用体系化的解决方案解决组织问题，是正确的认知。但体系化的解决方案一旦在实际工作中开始落地，也非常容易“变形”。**在上述决策流程里，最困难的不是架构评审和架构仲裁，而是向下推进的动作和速度。**
+
+越是高级管理者，日程排得越满，越难约时间开会。决策流程一旦涉及到 CTO 级管理者，推进速度就可能变得非常慢，这在很多企业都是切实存在的现象。
+
+我的解决方法，是回到我们专栏的第二章第二节：《管理者最重要的三个任务（二）：加强组织协同效率》，坚决落地日历协同的文化和工具。当团队做好日历协同时，只要管理者某一时段的日历是空白的，就可以预定会议，对组织全体适用。若有特殊情况，单独沟通。
+
+所以你看，任何策略、体系化的解决方法，都很难脱离企业文化而独立存在。有一句话说得好：文化吞噬策略如早餐。
+
+管理者要优先配合下属做好架构决策，反过来，下属也要进行细致准备，节约时间、提升效率。在架构评审发起前，发起人最重要的工作之一，就是填写和提交一份意见反馈表单，表单内容大致如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/11/05/11f313a7698c1c4566d4ace1d7659a05.png" alt="">
+
+通常，当你看到这份表格，很可能会最先注意到「业务需求」、「可选方案」、「决策结果」和「决策理由」等关键字。毕竟，这几项直接构成了基本的决策流程，确实非常重要。
+
+但是请注意，当整个决策流程完成时，表格中每一项都应该被填满，没有例外。我们先来看看，表单其他部分的设计目的：
+
+- 从「待决策内容」到「决策申请编号」，这部分内容是为了更好地将决策事件归档，以备以后参考、调研、借鉴；
+- 「假设条件」是为了注明可选方案的依赖条件，以免出现建设“空中楼阁”的情况；
+- 「重要性」的标注是为了提升决策效率；
+- 「因决策而产生的需求」和「其他相关决策」，则是确保决策可以落地。
+
+不过具体到表单的某一项，模板中是没有字数限制的。填写意见反馈表的标准是：逻辑清晰、完整，能让他人能够准确理解。
+
+相比决策流程，这张表单的泛用性可能更高，作用也非常关键，我认为大概有四点：
+
+第一，这套流程和意见反馈模板，可以让当事人及各参与方，做好充分的思考和准备，避免浪费大家的时间；
+
+第二，所有分歧会落实到纸面上，能防止沟通出现歧义，也预防推诿、扯皮的现象发生；
+
+第三，可以培养所有人的大局观和架构决策能力，间接推动人才梯队建设；
+
+最后，用体系化方案解决团队问题，追求的是“一劳永逸”地解决问题。
+
+**更重要的是，无论是流程还是表格，都不仅是一样工具，更是一种思维模式**。越早养成这种思维模式，对个人成长的帮助越大。如果你能在思考、验证后，将其沉淀为文档，相信有一天，你也能起草适合自己公司和业务的架构决策模板。
+
+写到这里，我不得不承认：即便拥有了架构决策流程和模板，要高效率地进行正确的决策，对于管理者而言，依然是个巨大的挑战。各领域、各方向的架构设计往往有其独特的一面。尤其是业务架构的设计，可能还会掺杂一些“历史原因”。如果不是代码维护者，几乎很难讲清楚业务逻辑。
+
+这时，管理者怎么做架构决策呢？
+
+## 技术管理者如何做好架构决策
+
+我认为，要做好架构决策，管理者至少需要具备两项特质。
+
+**第一项特质：要学会站在全局视角看待问题，学会看到技术架构的“外部价值”**。这种“外部价值”包括：公司利润、人效、资源利用率、业务风险，等等。
+
+说到这里，请你暂停并回想一下：在这一讲的开头，我提到了 2012 年在苏宁完成的架构决策：在 ESB 和分布式架构之间，我选择了分布式架构。这个决策具备哪些“外部价值”呢？
+
+这是个有关企业技术平台的架构决策，所以和收入、利润的关联度都很小。但分布式架构确实大大降低了业务风险，也在系统交互层面提高了资源利用率。这些都是非常明显的优势。
+
+但如果只能看清“外部价值”，也不能让技术管理者做好架构决策，否则一个不懂技术的 CEO 才是最好的架构决策者。
+
+这就要求决策者具备**第二项特质：具备相当的技术深度，以及非常好的学习能力和逻辑思维。**
+
+时隔 8 年，今天再谈起在苏宁选择分布式架构的往事，总是有点云淡风轻。但在背后，是一箩筐的技术细节：你要知晓 ESB 和分布式架构支持同构、异构服务时，各自的优劣势；你要知晓两者通过 TCP/IP 和 IP 协议交互所带来的效率区别；你要知晓 ESB 架构中，负载均衡系统和交换机的存在，以及由此而来的资源浪费，等等。
+
+在前面的内容里，我们一直强调做 “T” 型人才，其中一个重要的原因就在此时得到了体现：有一条足够深入的技术栈，是你前进的巨大倚仗。
+
+那么，是不是分布式专家就只能参与分布式架构的决策呢？当然不是，CTO 几乎不可能成为真正意义上的全栈技术和架构专家 —— 在一个梯队建设较为成功的企业里，走技术路线的下属，几乎总是会在某一专业领域胜过你。
+
+这时，管理者的学习能力和逻辑思维就会派上用场。做架构决策时，我们要求写好意见反馈模板，其中一个重要意图是让当事人将架构背后的逻辑讲明白。
+
+而管理者要做的就是：通过下属的表述，快速理解业务和架构逻辑，短时间内成为这一细分问题的专家，然后进行决策。
+
+“只要你能讲清楚，我就一定能掌握”，如果通过坚持不懈的练习，养成了这一专业素质，管理者将在架构决策方面无往而不利。
+
+你可能会说，老乔啊，我们团队的成员，嘴都比较笨，真的是说不明白。没关系，管理者可以多加引导，一个很好用的小技巧是：引导对决策存在分歧的双方，就方案合理性互相“攻击”。
+
+你可以要求当事人 A 首先阐述方案，并进行提问，比如：你凭什么说这个方案就能节省资源？在当事人 A 回答完之后，询问当事人 B ：你对他刚才的阐述难道没有疑问吗？
+
+这样一来二去，方案背后的逻辑就会更加清晰，管理者也就更容易进行决策了。
+
+## 结语
+
+今天，我们聊了聊有关架构决策的认知、体系框架，以及高层管理者需要具备的基本素质。
+
+对于初级管理者来说，要尽早培养自己的架构决策能力，尤其重视思维模式的培养、个人技术栈的深度扩展以及逻辑思维能力的锻炼。
+
+对于高级管理者来说，则要做好认知层面的储备。很多 CTO 面对下属的架构决策求助，回复都是“我忙着呢，过两天吧”、“你自己再想想，晚点再说”。
+
+高级管理者不能总是瞎忙，如果你真的意识到，架构决策是技术管理者最重要的任务之一，就一定会为类似的决策会议腾出时间。
+
+拖延做决策的管理者，要么是不懂，要么是战略懒惰，很少有第三种情况。而所谓“战略懒惰”，常常表现为管理者自己冲到一线“拼杀”，却对团队的方向性问题反应迟钝。
+
+当然，做管理的时间一长，确实也会怀念“带队冲锋”的感觉，我觉得没什么问题。但要注意，“冲锋”这个动作，一定发生在战略决策之后。而善于做决策，又敢于冲锋的管理者，在现代商业环境中，一定大有可为。
+
+好了，关于架构决策，我们就聊这么多。
+
+让我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对专业成长的复盘/18 | 架构设计，专业分工和协作精神的体现.md

@@ -0,0 +1,146 @@
+<audio id="audio" title="18 | 架构设计，专业分工和协作精神的体现" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/43/21/43120070dyy6139e04b7858c4b8ffc21.mp3"></audio>
+
+你好，我是乔新亮。今天，我想和你聊聊，关于架构设计的一些认知和体会。
+
+作为技术人，最常接触的概念，恐怕就是架构设计了。即便是初出茅庐的新手程序员，可能也听说过 6 大设计原则与 23 种设计模式。因为，要成为管理者或技术专家，架构设计绝对是你绕不开的槛。
+
+因此，关于架构设计的书和课程非常多，多到简直学不完。如果用我们专栏文章的形式来讲，写出一百篇文章都不为过。
+
+但在今天，我们只聊一点认知，我认为，也是架构设计最核心的认知：**好的架构设计，就像优秀的组织协作一样，既能帮助 IT 系统做好各模块的专业分工，又能体现模块间的协作精神**。
+
+认知讲完了，是不是感觉有些熟悉？
+
+没错，其实在很多架构设计思想里，我们都能找到这句话的影子，比如“高内聚、松耦合”、“单一职责原则”、“接口隔离原则”，太多了。
+
+你可能会想，老乔坑人呢，作为一个 CTO ，在架构设计这一讲，就交付了一个这么基础的概念。
+
+没错，这个概念确实很基础，但我想告诉你，其实架构设计，尤其是业务/应用架构的设计，原本就没有那么复杂。
+
+工作了近 20 年后，我发现，如果一名架构师存在职业发展瓶颈，那么他的问题大概率是简单的设计方法没有执行好，而不是复杂的设计方法没学会。
+
+复杂的学会了，简单的却没做好，听起来很奇怪吧？下面，我们详细聊聊，这究竟是怎么一回事。
+
+## 从程序员到架构师，什么能力在提升？
+
+2020年，刚到彩食鲜的时候，我去审查团队技术需求的分配和实现，发现了一些不合常理的情况：对于部分业务流程改造工作，我认为很容易实现，团队却需要花费大量的时间才能落地。几天就能改好的代码，花掉一个月的时间都是有可能的。
+
+有时，团队甚至会觉得，单是为了实现需求，就已经很吃力了，从整体的逻辑上看就很不合理。
+
+仔细一查，我才发现问题的根源所在：表面上看，是逻辑不合理，实际上是架构设计不合理。
+
+生鲜/电商类业务的架构一般会包括 OMS（订单管理系统）、WMS（仓库管理系统）、TMS（运输管理系统）等系统。其中 OMS 处理用户订单，负责调度；WMS 负责仓储管理；TMS 负责安排物流运输。可以看到，其实功能的划分很明确。
+
+但很多业务在研发迭代时，并没有做过架构方面的考量，比如将与订单相关的逻辑直接放在 WMS 处理了：WMS 接到 1000 斤蔬菜的订单，检测仓库内只有 500 斤，于是发送请求到采购系统，要求再采购500 斤回来，然后将订单交付。
+
+这样的逻辑能保证功能实现吗？当然可以，但长远看来，就会出现架构层面的设计问题 —— WMS 越来越臃肿，最终导致新需求的处理速度严重下降，影响业务的增长，这就是很多企业正在为之头疼的现实。
+
+你可能会想，这个例子里的架构师真傻，连 OMS 都不知道。
+
+真的是这样吗？事实上，类似的错误，很多企业每天都在犯，尤其是 IT 服务于自身生态的甲方企业。大家习惯于基于业务需求写代码，而不是基于架构设计写代码，反正来了需求先实现了再说，尤其是在业务刚刚起步时。
+
+比如，在业界，你会发现一个很普遍的现象：许多企业投入大量的资金和人力进行 IT 建设，但每隔几年就要进行一次架构上的大调整，甚至直接推翻重写。
+
+大部分人甚至已经习惯了这种行为，觉得重建很正常，而且是一名架构师能力的证明。
+
+事实上，如果架构师严格按照“专业分工、充分协作”的思想去迭代需求，这样的重建根本就不应该出现。**一名优秀的架构师应该像个“隐形人”，似乎什么都没干，但其负责的架构就是能快速响应业务的需求。**
+
+什么叫做“快速响应业务的需求”？就是说，在同样的业务复杂度下，在系统建设的不同阶段，可以使用相近的工作量完成需求。
+
+那么，所谓的“专业分工、充分协作”，到底是做了什么呢？回到架构设计实践里，无非是一个先拆分再合并的 “V” 字型设计过程。
+
+拆分是指将一个负责的功能按角色、按职责拆分，核心特征是单一模块的功能既单纯又简单。比如，要从零实现一个淘宝网，是相当复杂的事。但我们可以将其拆分成订单中心、用户中心、商品中心、库存中心等许多模块；订单中心还可以再拆分，比如拆分成订单创建、订单查询、订单履约等功能；如果实现仍然复杂，我们还可以继续拆分，直到能够用简洁优雅的代码去实现。
+
+合并是指将类似的职责放在一个模块完成，抽象出可重用、复用的部分，提升业务响应效率。比如订单创建、订单查询都需要对数据库进行操作，那么与数据库的交互就应该统一封装。
+
+**抽象地看，架构是由元素（element）和关系（relationship）组成的。在架构设计中，那些稳定、可复用的部分应该变成组件或应用模块，对应着架构中的「元素」；而面向不确定性的设计，则需要变成协作方式，为可能的扩展作准备，对应着架构中的「关系」。**
+
+这就像一个足球队，有人司职前锋、有人司职中场、有人司职中后卫，分工明确才能组成一个有战斗力的队伍；中场可能回撤参与防守，后卫也可能前插参与进攻，这样才能对可能的变化作出响应。
+
+如果什么设计都没有，就只能变成一群追着球玩的小孩。
+
+那么「元素」是拆分得越细越好吗？当然也不是，5 个模块能搞定的功能，你非要写 100 个模块，只能是给自己徒增烦恼。
+
+所以，从初级架构师到高级架构师，什么能力是一直存在并持续提升的？其实就是对复杂业务的拆分能力、对可复用部分的抽象能力、对拆分过程的颗粒度把握，以及对未来变化的考量和设计。如何让架构有足够的“应变能力”，则与架构师对业务的理解程度息息相关。
+
+如果用一句话总结，那就是：**对架构层面的「专业分工」和「协作精神」的理解，是一名架构师的基础与核心能力。**
+
+## 认知延伸：如何看待微服务和中台架构
+
+你可能会想，老乔讲的对是对，可有什么用呢？
+
+别急，我们通过前面讲的架构设计思想，反过来看看近几年大火的微服务和中台架构。
+
+关于微服务，首先我们要知道，它的功能和数据处理是封装在一起的，这和  SOA  架构非常类似；其次，服务交互、服务治理、服务监控、服务隔离等很多基础性能力已经封装在框架中，可以让开发团队聚焦在功能实现上；再者，通过和 Kubernetes 集成，微服务的功能、数据、基础设施被再次封装，技术架构也再次进行了升级。
+
+看得出来，在微服务框架下，技术架构部分的很多职责已经被抽象出来，并对框架进行了处理，隐含着相关理念的最佳实践。
+
+同时，微服务也有一个很基本的原则：**让系统的分工更明确、责任更清晰**。所以你看，还是我们上面讲的那些内容。
+
+对于业务侧架构师来说，即便是使用了微服务架构，工作还是会集中在架构设计方面，比如：业务功能如何进行归类。具体到微服务改造的过程中，就会碰见一个典型问题：微服务拆分的颗粒度怎么把控？微服务，英文 MicroService，划分粒度一定要很细吧？
+
+其实这个问题压根没有统一答案，为什么？因为我们前面讲过了，即便没有微服务，架构师也要做功能的拆分，至于对颗粒度的把握，既受业务本身的特性影响，也受架构师的能力影响。
+
+换句话说，一名对架构的“分工”和“协作”理解得足够好的架构师，很少会困惑于微服务拆分的颗粒度问题。因为从本质上来讲，这些都是一码事。从单体应用到各功能独立服务，其实是处于功能拆分的两个极端，但**架构设计本质上是一种“中庸思想”，如果单纯考虑功能设计，我们的目标只有一个：让架构响应业务调整的速度更快。**
+
+那么架构如何才能实现更快的响应速度呢？就是在**保证各「元素」职责清晰的情况下，抽象出稳定的功能或组件，用业务流程去串联起来**。在一定时期内，一家企业的技术架构的功能或者组件基本是稳定的，而业务如何运转，却是动态变化的，甚至每周都在变。可以说，以不变应万变是架构设计的精髓。
+
+这个设计思想又和中台架构如出一辙。企业搭建中台，最重要的目标之一，就是实现企业营收层面的“开源”，承担企业架构快速响应市场需求的任务。其关键词包括：消除烟囱、架构解耦、统一中台、服务重用……
+
+没错，和我们前面谈的架构设计核心思想又是基本一致的。
+
+关于中台，业界很多技术人都踩了不少坑。刚开始听说中台概念的时候，大家一拥而上，做得多了才发现，中台到处都是坑。以至于在当下，许多人对中台是嗤之以鼻的。
+
+为什么呢？我认为很重要的一个原因，是大家忘了架构设计的“初心”，错认为中台是个全新的设计理念。
+
+其实从架构的视角看，中台这个概念并不新鲜，它只是突出了“可重用部分的抽象”这部分工作。那么， 如果你的 IT 系统可复用部分不多、业务量不高，建设中台的意义何在呢？如果你的中台对业务没有帮助，建设中台的价值如何体现呢？
+
+**你看，时刻牢记架构设计的核心原则，能帮助我们更清晰、更透彻地看待当下的许多“时髦理念”**。
+
+当然，这里可不是说，中台的兴起，就是一群不专业人士的狂欢，绝对不是这样的。苏宁在 2012 年就开始中台建设，2013 年上半年完成。后来在利用中台接入天猫业务时，团队仅花了七天七夜的时间就完成了融合，速度非常之快。
+
+关于企业数字化转型、中台建设，我在公众号里，曾经分享过一个系列，共 9  篇文章，用大概  4  万字左右的篇幅，描述了一个关于中台的“[指挥官体系](https://mp.weixin.qq.com/mp/homepage?__biz=Mzg2NjI1MDk0NQ==&amp;hid=8&amp;sn=5098693d64a4e0ebbffc79829e375ce9&amp;scene=1&amp;devicetype=Windows+10+x64&amp;version=6300002f&amp;lang=zh_CN&amp;nettype=WIFI&amp;ascene=1&amp;session_us=gh_29a69e00e273&amp;pass_ticket=%2FTbRTIlXcJMcB%2B3ejcKbOJV9JSakqAQOodTiZPotxt0lh0RHK1FjS7uTtMyRns2s&amp;wx_header=1&amp;uin=MjI1OTA5NDUwMQ%3D%3D&amp;key=07730a946a3186fb96024f450086917d0fb6060e575afb1a958a5395b9a2fdf7dd49ffb49246e3292e44f5c4d6df32c8404254b20c20916f1492a07d04383b033e00f7070c2accc32a69a32f86fddb41ef0731742508878a645f3cb54793b67182c0fc6a77a3ca2045cd5d28ff70e8a4bba24d2c636684a8dc17de141f895405)”，大家可以读一读，理解下中台和微服务设计的具体内容。
+
+**所以，无论是微服务还是中台，都有其巨大的实践价值，但二者只是架构设计核心原则的一种成熟的实践模式和承载方式，不是解决架构问题的“灵丹妙药”。**
+
+简单来说，如果你能按照架构设计的核心原则，做好模块拆分，那么微服务架构可以非常好地承载这种设计思想，为你提供服务治理、监控等一系列工具。但如果你在架构设计层面就做不好拆分，微服务也不能直接帮你解决颗粒度问题。
+
+如果你问我，老乔，我没有“专业分工”的设计意识，也做不好功能的拆分，是不是用了微服务就搞定了？我只能回答，怎么可能呢？天底下没有这样的美事。
+
+## 复杂架构设计如何落地执行
+
+下面我们再来聊聊，复杂的架构设计究竟是如何落地的。
+
+在  IBM 工作的那段时间，我曾经内部分享过一门专业架构师培训课程，包括为期 5  天的 Enterprise Architecture（企业架构）培训课程、为期 3  天的 Architecture Thinking （架构思维）培训课程、为期 3  天的 Component Modeling（组件建模）培训课程，以及为期 3  天的Operation Modeling （运营建模）培训课程。
+
+我尽量用最简单的方式，将功能性架构设计中，最简单直接的方法和步骤抽象总结出来，分享给你，其中也包含了少数我们上面提到的内容。
+
+1. 关键认知：在个人视角里，整个世界都可以按照确定性内容和不确定性内容做简单区分；
+1. 架构将其抽象为元素和关系，元素对应着确定性内容的处理，是看待这个世界的稳定视角；关系对应着不确定性内容的处理，是看待这个世界的响应视角；
+1. 人类的理解能力有限。包含内容过多的元素，会导致理解困难，需要将其拆分；
+1. 同理，将元素归类的时候，也不能贪多，不然会导致理解困难。优秀的架构师，会将合理数量的元素进行归类，归类后的整体一般被称作 component  或  module，也可以直译为“组件”。比如，我们永远以“元素数量为 10 ”作为一个衡量点，只要一个组件包含的元素/职责超过10个，就要进行拆分；
+1. 元素归类一般采用 “V” 字型分析法，即流程分解为功能，功能聚合为组件；
+1. 如果组件明确了，意味着职责就建设好了，架构的元素（element）建设问题就解决了。组件对外暴露的能力，我们统一称之为服务；
+1. 那么，架构的关系（relationship）建设问题该如何解决呢？稳定的关系，用来表达确定性的交互，使用  SOA  架构，做好服务调用就可以；不稳定的关系，用来表达不确定性的交互，使用  EDA  架构；
+1. 在每一个新需求到来时，尤其是大版本的更迭，架构师需要介入产品经理和程序员的沟通中，判断新需求是否大幅增加了某些组件的复杂度，并决定是否调整组件职责，或对现有组件进行拆分。所以，从实际的业务发展来看，组件的数量是逐步增长的，如果一开始就很多，基本属于过度设计；如果业务复杂度已经翻倍了，组件数量却没变，基本属于缺乏设计。
+
+那么以上就是落地复杂架构设计时的一些关键认知，要结合前文的阐述，多多体会。如果有疑惑，欢迎留言提问。
+
+## 结语
+
+今天我们聊了聊架构设计的核心理念：专业分工和协作精神，具体来讲，就是做好功能的拆分，抽象其中可复用的部分，并保留面向未来的扩展空间。
+
+这里我们聊的仅限于功能型架构的设计，关于高性能、高可用、高并发、风险控制等非功能型架构设计，我们将在后续内容里逐渐展开。
+
+我猜，即便看到这里 —— 这一讲的结尾，你可能仍然会想：这个理念是不是太简单了。
+
+其实很多知识恰恰是这样：说简单也简单 —— 容易理解，也容易操作；说难也难 —— 即便是首席架构师、技术总监，可能也还是会被类似的问题困扰，重复犯类似的设计错误。
+
+究其本质，在于我们要用发展的眼光，看待个人成长、架构设计这类相对宏伟的命题。就像我常常说的，要做时间的朋友。
+
+做架构设计的同学都知道，罗马不是一天建成的。同样，对架构设计核心原则的理解，也不可能在一年、两年内达到满分，这种理解往往会随着技术人的成长而持续加深。
+
+其实，人类在解决很多复杂问题时，都会采用类似的思维流程：**将复杂问题拆解为简单问题，逐一解决再合并，并将可复用的知识抽象，以实现举一反三**。我们今天所聊的架构设计，其实就是这种思想在软件设计层面的复现。
+
+希望你也能将这个看似简单、实则复杂的知识点吃透、嚼烂，最终做到返璞归真，成为一个优秀的架构师或技术管理者。
+
+我们下一讲再见。

极客时间专栏/geek/乔新亮的CTO成长复盘/对专业成长的复盘/19 | 产品思维，契约精神是基础，洞察人性才能成就卓越.md

@@ -0,0 +1,152 @@
+<audio id="audio" title="19 | 产品思维，契约精神是基础，洞察人性才能成就卓越" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a5/44/a5350f72a4bafd07f62230yybb188e44.mp3"></audio>
+
+你好，我是乔新亮。今天，我想和你聊聊，如何培养产品思维，以及我个人与之相关的复盘和思考。
+
+多年以前，我其实也没什么所谓的产品思维，主要的工作还是做好架构设计、解决方案，做什么产品呢？
+
+后来，我的职位越来越高，也逐渐开始为公司的业务发展负责，我逐步意识到：产品太重要了，对于高级管理者很重要，对于 IT 组织的每一个人都很重要。
+
+为什么呢？要解释这个问题，我们首先要聊聊产品的企业价值和个人价值。
+
+## 产品，是企业及个人价值的最好载体
+
+你可能还记得，在「管理复盘」的第一讲，我们就提到：要将职能型组织转变成产品型组织。为什么要这样做呢？因为对于企业而言，做需求重在“过程”，做产品重在“结果”，**产品是企业对外提供服务的载体，也是企业核心竞争力具象化的载体**。
+
+许多投资人、企业家，都喜欢聊「竞争壁垒」这个概念，比如：腾讯在社交、文娱等行业有强大的竞争壁垒；阿里巴巴在电商领域有强大的竞争壁垒。几乎所有的大厂都有壁垒，导致新兴势力很难与之掰手腕。
+
+但这个神奇的「竞争壁垒」，具体是指什么呢？很多书中都有解读，「壁垒」可能包括品牌效应、规模效应、网络效应、要素垄断等，但因为涵盖的要素太多，反而让人难以理解。如果我们尝试从另一个维度看，问题可能瞬间就会变得清晰：对于企业而言，所谓「竞争壁垒」，主要指代的其实是产品。
+
+作为一个整体，企业有对外提供服务的产品，也有对内提供服务的产品。而且外部产品、内部产品可以互相转换。**一般来说，随着产品能力的提升，内部产品有机会演变为外部产品。我认为，这也是培育公司“第二曲线”业务非常切实可行的办法。**
+
+举个例子，阿里孵化了自己的技术平台，那么平台成熟后，就成为了属于阿里的 IT 基础设施类产品；Netflix API 做得好，那么就成为了 API 产品，不但可以服务内部，还可以对外售卖；再比如，许多大厂人才梯队建设的好，那么相应的选用育留方法论，也可以构成产品；一些公司擅长生产内容，就可以形成内容产品，比如 QCon 、ArchSummit 、GTLC 大会。
+
+以上所有产品，需要时间来迭代，需要持续耗费人力、物力进行打磨，就会逐步形成企业的竞争壁垒。因为在这一垂直领域，相较于同阶段的其他竞争对手，你已经占据了巨大的先发优势。
+
+说完了企业价值，其实产品的个人价值也就凸显了。
+
+在大部分时间里，个人价值来自于企业价值的增量部分。如果你所做的工作，对企业的成长没有任何的帮助，是不可能跨越成长台阶的。所以，团队中的每一个成员，都要为了创造企业价值的增量而努力。
+
+那么长期看来，企业价值如何体现呢？答案是做产品，所以企业里的每一个渴望成长的人，都要学着做产品，都要有产品思维。这是我一直提倡的一个简单逻辑。
+
+有些人会说，没有产品思维我不一样写代码、做架构？
+
+这话说得没错，如果只想老老实实的做个企业的“螺丝钉”，做个普通的程序员、测试人员、架构师，确实没必要培养产品思维；但如果你追求个人成长、追求卓越，就必须具备产品思维。
+
+## 培养产品思维的核心脉络
+
+大道理讲完了，那么究竟该如何培养自己的产品思维呢？
+
+大部分人的第一反应是去找一堆产品经理的书来看。可看着看着就有点懵：书里举的例子要么是 iPhone，要么是微信，让人忍不住感叹：天才的乔布斯，神奇的张小龙。可书里的故事很传奇，现实工作却很骨感，专业名词学了不少，就是用不太上。
+
+没错，对于大部分技术人来说，培养产品思维的目标在于重构自己的部分认知，并把它应用于自己的日常工作、生活中，不一定非要成为乔布斯，或是独立开发一个爆款 APP。
+
+那么，我们如何用简单、实用的认知，构建自己的产品思维呢？
+
+我个人认为，**有两个关键词最重要，一个叫做“契约精神”，一个叫做“洞察人性”，前者让你拥有入门级的产品思维，后者让你可以成为卓越的“产品经理”。**
+
+所谓“契约精神”，是指工作时，要有“**一诺千金**”的意识，具体可以分成四点来理解：
+
+1. 将自己的每个工作成果都当作产品，并将产品交付或售卖；
+1. 尝试理解这个产品的用户到底是谁；
+1. 在用户付出了时间、精力或金钱后，明确你的产品到底交付了什么？又承诺交付了什么？
+1. 不惜代价信守这个承诺。
+
+比如，京东物流作为一款物流时效性产品，给用户的“契约”是“当日或次日送达（偏远地区除外）”。那么京东物流的订单系统、调度系统、仓储系统、配货系统等，全部都要为这个契约的交付而努力。
+
+再举一个例子，唯品会作为一款产品，给用户的“契约”可能是“用更便宜的价格买正版的鞋服”。那么不光是 IT ，整个企业都要为了守住这个契约而努力。
+
+彩食鲜的“契约”是提供可信赖的安全食品，那么在基地管理、采购管理、工厂加工、仓储作业、配送服务等各个环节都要确保食品安全，例如对于蔬菜批批检，信息可查询、可追溯。
+
+所以你看，企业想做好产品，关键在于每一个模块的责任人，都有契约精神。任何一个环节出现问题，都会导致企业的信誉蒙受损失。
+
+你可能会想，嗨，我知道，契约就是按约定交付嘛。是的，“契约”这个概念，本来就非常容易理解。但要注意，理解起来很容易，执行起来可就难了。
+
+就像大部分人都知道欠债要还钱，老赖却还是很多。因为信守承诺不仅仅是态度问题，还涉及能力和方法问题，需要通过明确契约、开展设计、信守承诺三步法将契约落实到位。
+
+在日常的研发或管理过程中，当 Deadline 临近时、当工作量过饱和时，你还能不能守住契约精神，将“契约”规定内容，分毫不差地交付给用户？说实话，真的挺难的。但只要你能守住底线，**把简单的事情重复做到位，就可以超过绝大多数人和企业**。
+
+关于产品思维的另一个关键词，叫做“洞察人性”。
+
+即便在最具极客文化的互联网公司里，也可能存在很多反人性的产品。比如版本发布产品，大部分公司都会将发布时间设计在凌晨，甚至需要研发和测试一起值班，确保生产环境没问题后，才可以睡觉。
+
+可是这多难熬啊！那么我们在设计版本发布产品时，能否在保证业务不受影响的情况下，让发布时间更人性化？比如根据业务流量的特性，选择其他时间进行灰度发布；比如研发建设 7 x 24 小时无人值守的发布系统，附有秒级发布、秒级回滚功能，将团队从人工监测中解放出来……
+
+总之，方法有很多，只要肯去想，就一定能提升。
+
+这还是比较明显的“反人性”设计，很多情况下，研发同学未必能意识到产品的“反人性”设计。这时，就需要我们带着同理心，下到终端环境里，和真正的用户去交流。
+
+一个好的产品经理，通常有着极强的同理心，能够设身处地替用户着想：用户在这个场景下的诉求是什么？有什么痛点？目的是什么？
+
+在这一环节，**产品经理的个人价值观不同，就会塑造出有着所谓“不同世俗意义”的成功产品**。但我一直认为：科技是向善的，产品应该让人们的生活变得更美好。某些在商业上比较成功的产品，在我看来，就是有问题的、不成功的，因为它给用户的导向是不好的。
+
+**洞察人性是要树立“以人为本”的理念，了解产品使用者的真正诉求，用户通过使用产品，会觉得自己更棒了，让自己变得更卓越。先成就用户，然后成就产品**。
+
+在彩食鲜，销售人员每个月都需要对账，所以对账系统就会成为一个标准产品。如果该产品三分钟可以完成准确对账，销售人员的工作就可以更轻松，用更多的时间挖掘客户、努力签单，让每个销售人员都更加成功；
+
+如果该产品可以实现无人值守、自动准确对账，销售人员将被彻底解放。那么，销售人员一定会觉得自己工作效率更高了，自己的工作更棒了。从公司的角度看，这也让公司的运转更加高效。
+
+我们公司的 IT 人员就是在为了这样的目标努力，并且已经卓有成效。
+
+只要守住了“契约精神”和“洞察人性”这两大关键词，我相信你对于产品的初步认知就已经形成了，对于产品知识的学习就不会盲目。
+
+了解了“契约精神”和“洞察人性”这两大关键点后，我们如何在工作中实践应用呢？我认为，有六大步骤比较关键。
+
+## 产品思维六步法
+
+看到这里，你可能会想，怎么什么都是产品啊？物流是产品、API 是产品、代码发布还是产品，老乔是不是在偷换概念啊。
+
+当然不是，我可以确定地说，一切皆产品。**实践产品思维的第一步，就是面对所有的工作，都要习惯性自问：我到底要交付一个什么样的产品？**
+
+你在做的工作，甚至你的职业生涯，都可以看作一个产品去打磨。不是只有那些 APP 、手机才可以叫做产品。唯一的区别在于，你是否愿意关注这一切的长线价值，做时间的朋友。
+
+这一认知，是让产品思维逐步成熟的第一步。接下来，还有五个步骤，我们来逐一解读一下。
+
+**第二步，明确产品的用户到底是谁。**
+
+对于外部产品来讲，要做到精准识别用户，相对比较困难，这与公司的商业模式强相关。但对于公司的内部产品而言，用户群体可能是相当固定的。你的用户可能是其他工程师、同公司的销售、同公司的财务，也可能是身处一线的物流工人、司机，认识他们、了解他们，相对来说没有那么困难。
+
+困难的是，在设计流程、写代码、做测试的时候，时刻记住这样一群人，告诫自己：我的用户，并不是我自己。与真正的一线用户聊聊产品体验，看看自己是不是感到沮丧，感到有些受挫？下终端会让自己有不一样的感受，有助于提升自己的同理心。
+
+**第三步，明确服务契约。**
+
+要明确地问自己，自己的产品，到底为用户提供了什么样的服务契约，用户通过产品实现什么样的价值？拿出纸笔写下来，看能否数字化，是否够具体。在前文关于销售对账系统的例子里，我们的交付目标要么是 99%  的销售使用 3  分钟内完成、准确率在 98% 以上的对账产品，要么是  100%  的销售使用无人值守的、准确率为 100% 的对账产品。
+
+用数字来组成契约，用 “SMART  原则”来检查契约。
+
+**第四步，将产品打磨至卓越。**
+
+我们曾经多次强调过，社会、企业、组织会更多地奖励卓越的人或事，对「平庸」缺乏兴致。做产品也是一样：只有卓越的产品，才能对你的个人成长产生牵引作用。如果你总是想着：差不多就行了，不要跟自己较劲了，那还不如直接放弃。
+
+那么，怎么在微观视角打造出一个卓越的产品呢？我个人总结了关于**卓越产品的“三个一”思考法，即“一站一键一秒”**，意思是在场景和目标确定的情况下，让用户在一个位置，点击一个按键，在一秒内达成目标。试想一下，使用这样的产品，用户一定会觉得自己很棒，这就是产品的价值。
+
+当然，“一站一键一秒”是站在微观视角来谈的，要孵化一个完整的产品，往往需要不断地将产品的微观能力进行组合，不断重复上述步骤，最后和公司的商业模式、战略方向协同，以创造产品的行业竞争力。
+
+**第五步，要习惯于成就用户，时刻谨记：以人为本。**
+
+大多数时候，在 IT 的日常研发工作中，都存在更省时、更省力、更取巧的代码或设计方法，但这些方法却未必是对用户友好的。**技术人需要时刻提醒自己，产品设计的第一驱动力应该来自于用户价值，而不是技术方案的优劣**。
+
+产品建设要以人为本，不断去寻找价值，匹配价值，成就用户。
+
+**第六步，关注数据，持续完善。**
+
+产品迭代一定要有数据，要思考如何用数据来衡量产品的卓越程度，用数据衡量产品的价值增长，用数据成就伟大的产品。
+
+最后，还是那句话：大道至简。要培养卓越的产品思维其实并不复杂，以上六个步骤都很简单。我建议你学过之后就要行动起来，在工作中实践、思考、总结，固化成自己独有的产品思维方法，持续学习、学以致用、终身成长。
+
+## 结语
+
+今天，我们聊了聊培养产品思维的关键认知和方法。
+
+遵守“契约”，可以打造一个 90 分产品。以人为本、洞察人性、使用“一站一键一秒”等方法，则可以打磨出一个卓越的产品。
+
+没有产品导向的项目建设如同没有灵魂的肉体，会让工作流于平庸；而**产品思维，本质上是一种长期的利他主义思维**。设计任何产品的出发点，都应该是让用户的生活变得更美好。当然，利他就是利己，要明白：自己的努力对于社会是有价值的，这样的人生才会越来越充实、越来越有意义。
+
+作为 IT 行业从业者，十年、二十年之后，会为世界留下什么？我想，首先应该是属于自己的、卓越的产品。我就常常想：多年以后，我可以向自己的子孙吹牛：你看爸爸做了这么多产品，让别人的生活变得更美好了。
+
+而且人生还有这么长，你怎么就知道，自己无法打造出一个现象级的卓越产品呢？只要坚持长期主义，我认为还是非常有可能的。而且我一直觉得，这是让一个人坚持克服困难的最大动力。
+
+我常说，人生是一场修行，选择一个职业，在其中经历磨难，领悟人生的道理，最终殊途同归。我建议你如果有时间，也可以去慢慢琢磨、领会这个道理，因为那种融会贯通的感觉是非常美好的。
+
+最后，预祝你能持续打造一个又一个的卓越产品。
+
+我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对专业成长的复盘/20 | 高可用设计，让产品没有后顾之忧.md

@@ -0,0 +1,137 @@
+<audio id="audio" title="20 | 高可用设计，让产品没有后顾之忧" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1f/a9/1fd581c97f5be851cd9ac8dcb86336a9.mp3"></audio>
+
+你好，我是乔新亮。这一讲，我想和你聊聊，关于高可用设计的那些事儿。
+
+一提起高可用设计，很多同学立刻就会想到“冗余设计”、“故障转移”等关键词。确实，在大部分与高可用相关的分享里，这两个词往往会被重点强调。
+
+所谓“冗余设计”，是指要通过集群来替代单点服务，做好冗余备份。单点架构是高可用的大敌，“把鸡蛋放在不同的篮子里”是高可用最朴实、最有效的设计思路之一；“故障转移”则是为了缩短故障时间，保证故障发生时，业务可以快速恢复。
+
+如果你对高可用设计了解得更多，可能还会给出如 “CAP 理论”、“异地多活”、“双机架构”一样的更多概念，并且详细解释应用方法。
+
+像这样面对问题，能立刻在大脑知识地图中检索并给出应对举措或方案，是一个优秀的特质，能帮助你通过许多高难度面试。但不知你有没有想过，**为何自己在面试中对答如流，在实际工作中却仍然会遇见许多高可用难题呢？为什么还是无法主导一家大型企业整体架构的高可用设计呢？**
+
+问题或许是多方面的，比如企业现阶段的发展状况特殊，缺乏实战机会，导致个人资历不够；或者相关部门不太配合，组织人员能力差，代码 Bug 太多，让你一想就气不打一处来……
+
+以上原因都有可能，也都客观存在于很多公司。但我认为，最重要的原因是，缺乏对高可用设计自顶向下的、比较通透的理解和认知，因而在实践中常常迷失在技术细节里，难以窥见架构的全貌。
+
+那么这一讲，我们就来尝试一下，看能否通过一些简单的梳理，建立对高可用设计的完整认知。
+
+## 解剖高可用设计
+
+在架构设计部分，我们讲了：粗略地说，想做好架构设计，第一步是将一个 IT 系统从应用层级至底层基础设施，全部拆解为一个个应用模块，我们也可以称之为“元素”或“组件”；第二步是保证各个模块间不能孤立存在，还要做好充分的协作，协作通过应用模块对外暴露的“服务”来承载，我们也可以称之为“连接”。
+
+所以说，应用模块和服务，或者叫做元素和连接，共同组成了所谓的架构。那么，要实现架构的高可用，就意味着实现所有元素、连接的高可用。
+
+至此，其实我们已经得出了一点非常重要的认知，再重复一遍：**真正的高可用，是指实现所有元素、所有连接的高可用。只要一个元素或一个连接没有做高可用设计，都意味着风险的存在。**
+
+比如，公司要求每天必须按时上班，只要迟到就罚钱，那么你如何保证自己的“出勤系统”是高可用的呢？一定是全链条做高可用设计。闹钟至少有两个——互为主备、要保证衣物都在、要为堵车准备预案、要保证高峰期能挤上电梯……你甚至得保证身体健康，不然可能因为拉肚子而迟到。
+
+要注意，在这个例子里。闹钟可能不响、堵车可能会发生，没问题，只要在老板眼里，你永远按时打卡就行，只要整个系统是高可用的就好。**更准确地说，所谓高可用，是要保证“业务的连续性”，即在用户眼里，业务永远是正常（或基本正常）对外提供服务的。**
+
+怎么样，是不是有点难？是的，在实际工作中，大部分企业的架构设计没有做到高可用，原因可能只有两个：
+
+1. 相关负责人压根儿就没考虑高可用设计；
+1. 做全套高可用的代价太大了，钱不够用，时间不够用。
+
+先前有位同学在专栏下方留言说，乔老师传达的理念就是“**trade-off**”。我一看，禁不住为他鼓掌喝彩——说得太对了。在企业层面，很多难题不是“简答题”，而是“选择题”。所以在专业成长这一章，我们会先讲“架构决策”，再讲其他内容。
+
+其实人生也如此，职业生涯也如此，如果都有唯一的正确答案，那太简单了。很多教程回答的都是“唯一正确答案”，听着很有道理，实际做的时候，发现根本不是这么一回事。
+
+作为成年人，我们必须得清醒地认识到，人生这道选择题，根本没有标准答案，你能做的只有在不完美中寻找完美，不断trade-off。
+
+做好决策，在很多情况下，并不意味着风险就消失了 —— 风险始终存在。根据墨菲定律，如果事情有变坏的可能，无论概率有多小，它一定会发生。那么假设你我就是企业架构的总负责人，现在要保证企业整体业务的连续性，应该怎么办呢？
+
+有一个很通用的办法，叫做“**冗余设计**”（我们在文章开头提过了）。所谓“**集群**”、**“分布式”**，这些名词大体上都是在描绘“冗余设计”的概念。
+
+但冗余设计也不是万能的，它只能解决底层物理机器，也就是某一个实例的不可用问题。如果是代码逻辑出现了问题，冗余设计就失效了 —— 一个恶性 Bug 在生产环境爆发，后果是所有集群都会遭殃。
+
+没钱做 100% 的高可用设计，又想尽量提供系统的抗风险能力。作为架构负责人，应该怎么办呢？
+
+这里你可以停下一分钟，略微思考一下。
+
+**第一个解决方案是，在风险爆发、系统出现问题的情况下，对外提供“降级服务”**。也就是说，当团队没有时间去设计、测试并确保当前组件高可用时，如果因为未知原因，导致组件出现故障，我们需要提供一个逻辑相对简单，并且一定可用的服务替代原来的服务实现，实现服务对外的高可用。
+
+以电商系统的物流时效产品为例，正常情况下，该系统需要通知用户已购商品的到达日期。比如，邻近区域当日送达、跨省隔日送达、偏远地区三日送达，等等。具体的物流时效和用户和仓库的距离、仓库作业能力、车辆配送能力很多因素都有关。
+
+但如果因为一个 Bug 或一个配置文件修改错误，导致物流时效产品崩溃了，用户在四级页、购物车，订单确认页调用该服务时失败，怎么办呢？
+
+一个解决办法是：由服务器端技术人员写一段程序，保证任何用户查询物流情况，都显示 3 天送达。出问题的时候，使用此服务进行替换。然后，全体技术人员努力恢复服务，系统恢复后替换回正常的物流时效服务（如果有兴趣，这里你可以想想，为什么这段代码应该是服务端技术人员来写？答案藏在架构设计一节）。
+
+看到这里，你可能就笑了：老乔你这是欺骗用户呢，这还叫什么高可用？
+
+可这就是“降级服务”，实打实的高可用保障手段。在用户眼里，业务是连续的，只是可靠性降低了。其实对于架构师而言，高可用和高可靠应该是两个不同的概念，只是很多人将其混为一谈。
+
+**在最理想的情况下，我们既保证高可用，也保证高可靠；但出现问题时，我们优先保证高可用，其次保证高可靠**。这是另一点关键认知。
+
+其实在不同领域里，有很多类似的做法。比如在流媒体领域，当用户观看直播出现严重卡顿时，很多企业的第一反应不是查服务器 Log，而是为用户自动降码率。因为比起画质降低，卡的看不了显然会让用户更痛苦。
+
+如果“降级服务”还解决不了问题，应该怎么办？答案是提供“熔断服务”，让出现 Bug 的模块从系统中“熔断”，虽然用户会看到物流系统报错，但整个业务依然是正常响应的，不会被一个系统的 Bug 拖死。
+
+现在我们总结一下：**高可用意味着对系统全部元素、连接都进行高可用设计，在物理实例层面主要表现为冗余和集群设计，在代码逻辑层面，方法则多种多样。当你的资源和精力不足以实现全链路高可用时，提供“降级服务”和“熔断服务”，优先保证高可用，其次保证高可靠。**
+
+企业里面有些核心服务是不能降级的，对于这类服务，就一定要通过研发流程管理，确保服务的高可用、高可靠。一名合格的技术管理者，要能够识别核心服务，并引导团队重点关注。
+
+## 高可用，不只是个“设计问题”
+
+在我的职业生涯中，有两次生产事故让我印象最为深刻。
+
+一次是机房停电，一次是知名开源软件 ZooKeeper 出现严重 Bug（几年前的一个版本 Bug，连接数超过阈值就会停止服务，不知道现在是不是修复了）。这两次事故发生时，我基本都处于焦头烂额的状态，甚至几天几夜不能睡觉。它们一个属于底层物理实例出现了问题，一个属于代码逻辑出现了问题。
+
+对于你而言，我觉得代码逻辑导致的系统故障可能更为常见，机房停电、爆炸、地震毕竟发生几率比较小。
+
+如果将“放大镜”对准代码逻辑导致的系统“不可用”问题，我们就会发现**高可用设计真正的敌人是“变化”。**
+
+设想一下，如果生产环境不发生变化 —— 不发布新版本、不修改配置文件、不修改数据库脚本，系统大概率会一直保持正常（你可能会说，老乔，服务器压力激增也会导致问题。前面我们讲了，这属于架构设计中的“流控”设计，通过容量规划设计，流量控制问题很容易解决）。
+
+此时，生产环境发布新版本就会成为一个影响巨大的变量，极有可能对系统的可用性造成挑战。
+
+所以，**研发管理水平的高低，决定了你在版本发布方面的成功率和信心。**
+
+单就版本发布问题来说，你需要关注研发管理的三个关键点：
+
+1. 记录系统的任何一次发布和变化，包括发布系统/组件、发布时间等；确保自己可以随时定位任何一个时间段内的任何元素及任何发布动作，包括但不限于代码、配置文件、SQL  脚本、设备参数修改等；
+1. 发布时不影响业务；
+1. 保证任何发布都可以回滚。尤其当一个大版本的发布时，能否精确识别回滚单元，并做到秒级回滚。
+
+只要做到以上三点，哪怕你在上午十点发布新版本，又有什么关系？根本就不必等到半夜嘛。
+
+当然，总是回退也不是办法。作为一个研发组织，我们还可以从另外一个角度，提高系统的抗风险能力。这里，我要先问你两个问题，如果有时间的话，请你思考一下：
+
+1. 由代码逻辑导致的系统风险，是如何进入生产环境的？
+1. 生产环境出现严重故障，是不是毫无征兆地发生的？
+
+首先回答第一个问题，风险是经由开发环境、SIT  环境、压测环境、PRE  环境，进入生产环境的。所以我们要做的，是严格检查各个环境下的异常，**研发管理规范，应该为代码版本进入下一个环境设置准入标准，对于任何异常，都有负责人进行修正。如果异常通过了评估，审核者要对其负责**。
+
+第二个问题，答案当然是否定的。就像人在生病前，会在各项生理指标上有所表现。**系统 Bug 在导致生产故障前，也往往会有各类异常，我们要做好监控并正式的处理掉它**。
+
+这里我想说点题外话，在我们这个技术行业，每年都有猝死的情况发生，每次看到这种消息，我都觉得很遗憾。大家要关注自己的身体健康，关注身体给出的各种警告，爱自己、照顾好自己，才能爱家人。只要关注自己的健康、想办法，猝死大概率不会发生的。
+
+回归正题，在极少数情况下，一个严重 Bug 会藏在生产环境里，始终没有触发。但当它被触发时，可能就会导致生产环境“暴毙”。前面我讲的关于 ZooKeeper 的例子就是这样，到连接数超过阈值后，系统突然就挂了，所有人措手不及。
+
+对于这种情况，一旦碰到了，某种程度上就要认命。我一直讲，人生，运气也很重要，非常重要。如果已经尽全力了，还是出现了问题，要学会接受自己，承认自己的运气不好，将这当作是成功路上的经验、教训，这才是真正的成长性思维。拒绝不完美，渴望成长，当然很棒，但很多心理问题的源头也在这里，要学会接受自己。
+
+所以，开源软件其实是存在一定风险的。但开源软件依然代表了软件研发行业的一种主要潮流，毕竟你免费用了人家的软件那么久，有些许风险不是很正常吗？所以我依然允许团队向生产系统引入开源代码，只是从那次事故以后，我要求：引入开源代码的技术人员，必须通读并掌握其代码。
+
+还有许多研发管理方面的注意事项，包括代码 Review 文化、DevOps 等，我们就不再展开细说了。**关键在于要注意，真正的、为业务负责的高可用设计，不是画框图就能解决的，它是一个面向 IT 组织的整体设计。**
+
+## 结语
+
+到这里，我们这一讲的内容就接近尾声了。
+
+高可用设计，意味着“Design For Failure”，最重要的是让我们做产品没有后顾之忧。如果后院天天起火，研发团队每天胆战心惊，也就无从谈起“将产品打磨至卓越”了。所以，做好高可用，一定程度上就是在实践“慢就是快”的认知理念。
+
+如果你有仔细揣摩以上内容，或许会发现：虽然我们或许不能保证所有服务高可靠，但我们是可以保证所有服务高可用的。其关键点在于，面向所有的元素和连接，都要做设计。任何没有被设计过的元素和连接，往往都是不可靠的。
+
+任何一个要达到的目标，都要被量化；任何一个量化的目标，都是一个契约，要有契约精神；任何一个契约，都要进行设计。没有设计的内容，怎么可能如你所愿呢？何况，什么才是你的“所愿”呢？
+
+从这个角度来看，做一名卓越的架构师，真是个苦差事，但也充满了乐趣。
+
+你可能也会想，老乔，那我学的 CAP 理论、异地多活还有用吗？是不是都白学了？
+
+这些当然是有用的，但它们都有具体的使用场景限制。比如对于 CAP 理论来说，在分布式基础设施层的应用有些用，在应用层就受限了，许多人是学完了就忘了，设计架构时该怎么干还怎么干；至于异地多活，已经超过了国内大部分企业的现阶段的业务需要。而且我认为，异地多活最大的优势在于，对架构可扩展性和可维护性的提升，而不仅仅是高可用。
+
+学习，尤其是学习技术和管理知识，其实要有“功利心”。学完了一定要去实践，这样才能真正化为己用。我总是跟你讲：持续学习、学以致用、终身成长，有太多同学就是没做到学以致用，才导致“学了也白学”的结果出现。
+
+希望你在以后的学习生活中，能始终做到学以致用，保持高速的成长，终身成长。
+
+我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对专业成长的复盘/21 | 高性能设计，一切都围绕着契约精神.md

@@ -0,0 +1,173 @@
+<audio id="audio" title="21 | 高性能设计，一切都围绕着契约精神" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/yy/5d/yy882558928ef8a1f751401b854b065d.mp3"></audio>
+
+你好，我是乔新亮。这一讲，我们来聊聊如何实现架构的高性能设计。
+
+前面我们讲过，产品思维有两个核心关键词：“契约精神”和“洞察人性”。其实高性能设计，也和契约精神是密切相关的。我将其总结为：高性能设计，一切围绕着契约精神。
+
+你可能会想，高性能设计不就是可以支撑大流量、高并发的架构设计吗？和契约精神又有什么关系？
+
+其实关系很大。所谓的高性能，实际上，是与业务强相关的。比如，对于一台网络游戏服务器来说，可以支撑 400 名玩家同时在线，就算高性能；对于一台流媒体服务器来说，可以支撑 10,000 用户同时在线观看，就算高性能。
+
+当然，数据可能不准确，但逻辑大体如此。在实际的业务场景中，还会有许多其他技术指标被引入。比如游戏需要关注连接稳定性、视频需要关注延时，等等。
+
+明确了性能和业务的关系，下面我们就来聊聊，如何进行高性能设计，也借此加深对契约精神的认知和理解。
+
+## 契约精神是高性能架构设计的“拦路虎”
+
+首先，我们要清楚，高性能设计可以大体拆解为两大步骤：
+
+1. 清晰描述、定义性能目标；
+1. 设计并实现这个目标。
+
+而高性能架构的设计目标，是通过三类指标来具体定义的，分别是：
+
+1. 系统响应时间，一般指服务/交易处理的时间，也包括网络响应时间；
+1. 系统吞吐量，一般指系统的每秒交易量，通常需要结合并发量共同描述；
+1. 系统容量，通常代表系统的可用资源数量，包括硬盘容量、网络带宽等。
+
+但要注意：虽然我们有三类高性能指标，但彼此不能孤立地看待，否则就会出现问题。比如，在定义系统响应时间目标时，如果不与系统吞吐量关联起来，就会变得缺乏实践意义 —— 一旦流量的压力高峰到来，系统往往就不遂人愿了。
+
+这意味着，我们要学会识别架构设计中的组件（或服务），首先弄清哪些组件需要明确高性能指标，再针对性地用以上三个指标做清晰定义。
+
+除此之外，对于系统响应时间，我们还有一个更直观的监控指标，叫做 Top 百分数 （Top Percentile），简称 TP。比如， TP 90 = 2s，意思是，90% 的请求的响应时间都在 2s  内；那么  TP  99 = 2s 的意思就是 99%  的请求的响应时间都在  2s 内；我们一般说的  RT  =  2s，指的是平均响应时间，可以作为参考，但实际意义可能并不大。我个人一般会重点看  TP  90  和  TP  99 的数据。
+
+当我们明确了  TP  90  或者  TP  99 这一有关系统响应时间的指标时，一个交付给用户的“契约”就出现了。守好诸多类似的契约，也就是保证了高性能设计。但学习需要适当地进行延展思考，比如此时，我们应该多问自己一句：这个契约意味着什么？
+
+对于没有经验的程序员或架构师来说，这里其实存在一个隐含的假设，某种意义上，也算是一种侥幸心理：如果该系统在业务流量低峰场景下，满足了响应时间等性能指标，也就意味着，该系统在任何场景下，都能满足这些指标。
+
+你可能会觉得有点绕， 那我换个说法来描述刚刚签订的高性能“契约”：本系统、组件、服务承诺在任何情况、任何资源、任何压力高峰下，都保证  TP  90  =  2s 。
+
+是不是立刻就有了不一样的感觉？好像契约发生了变化，光是读出来，就让人心里一抖。
+
+其实到此时，还谈不上契约是否发生了变化，因为打从一开始，这个契约就是不明确、不清晰、不具体的。
+
+注意，这里还没有谈架构设计和研发能力，问题就已经出现了。很多时候，我们会被工作中出现的一些实际问题所困扰，其根源往往不在于相关责任人缺乏设计能力，而在于签订的“契约”并不明确。团队不可能实现和保卫一个“空中花园”。
+
+所以，我总说，高性能设计，一切围绕着契约精神。所以接下来，我们的内容都将围绕着“如何将契约描述清楚”这件事来展开。
+
+## 有上限的“契约”才能交付
+
+我曾经培养过许多架构师。一开始在做高性能设计时，他们常常会这样描述给用户的“契约”：
+
+“该架构最高支持 200 万并发流量，TP 90 = 2s 。”
+
+在不考虑业务需求的情况下，这个契约看似是没问题的。这意味着：对于第 1 名连接服务器的用户来说，TP 90 = 2s ；但对于第 300 万名连接服务器的用户来说，契约又是什么呢？答案是，没有，或者说比较模糊。
+
+**如果目标不清晰，隐患就埋下了。高性能设计非常看重系统响应时间的一致性，尤其是在不同的服务阶段，并发量和吞吐量发生变化的时候。**
+
+对于管理者或架构师而言，理想的契约应该是“保证设计流量内的用户 TP 90 = 2s，超出并发限制的用户，则暂时不在契约承诺的范围内。”。
+
+这就要求我们通过四大步骤去思考所谓高性能架构的设计问题：
+
+第一步，当服务器不超过 200 万并发用户时，TP 90 = 2s 。
+
+第二步，当连接服务器的并发用户数量超过 200 万，达到 250 万时，保证有 200 万用户的 TP 90 = 2s ，拒绝其他用户的连接请求。
+
+第三步，为设计容量外的用户提供服务器排队机制，并附带具体、明确的系统提示。
+
+第四步，3 分钟内完成扩容，保证并发用户数量小于等于 250 万时，任何在线用户的 TP 90 = 2s。
+
+其实，这样才构成了一个可以履行的契约：无论流量波动如何，该架构始终支持 200 万用户的 TP 90 = 2s；高峰时期，其他用户会被拒绝访问或进行排队，但系统能在三分钟内完成扩容，支持 250 万并发在线用户，并且保证其中任何一个用户的 TP 90 = 2s  。
+
+在某种程度上，这也是对业务诉求的精确表达，对于业务发展来说至关重要。很多同学设计的架构和契约，压根没有控制上限。他们想当然地认为，流量不可能出现太大的变化或波动。对于用户来说，这无异于一张“空头支票”。
+
+所以说，要做高性能设计，一定要明确目标，并交付给用户；没有清晰的目标，也就没有针对性的设计，怎么能实现高性能的架构呢？
+
+目标清晰后，我们再来看看，高性能架构如何设计并落地。
+
+## 实现高性能架构的关键技术点
+
+落地也不难，有三项工作最为关键，分别是：
+
+1. 为架构做好“保护系统”；
+1. 使架构具备扩容能力；
+1. 提升系统各组件处理能力。
+
+**保护系统，是为应对容量规划外的过载而设计的，通过流量控制来具体实现。**
+
+所谓流量控制，就是当实际并发压力，超过设计性能的时候，人为阻断服务器连接，告知用户需要排队或“稍后再试”。
+
+经常玩游戏的同学可能知道，对于网络游戏来说，流量控制是个基础设计，基本上所有的服务器都有“排队机制”。
+
+流量控制有两种具体的实践，一种是面向连接数做控制，一种是面向用户数做控制。前者让用户在不断尝试连接时，有一定成功的可能；后者则保证用户对系统的期望是一致的 —— 要么可以登录、要么不能登录。具体应该选择哪种方式，取决于业务的实际诉求。
+
+**而对于扩容能力来说，一般要包括储备额外的计算资源和具备快速弹性扩容能力。**
+
+你可能会说，既然已经有计算资源了，为什么不提前进行扩容呢？
+
+工作经验比较丰富的同学可能会知道其中的“隐情”：一般来说，该做的系统扩容，通常很早就完成了，架构设计真正缺乏的是应急手段。毕竟，你不能“不分青红皂白”，将每个系统的应急扩容都提前做好。一个经营稳健的企业，是不会允许这样的开销出现的。
+
+另一个关键要素在于扩容速度。扩容工作是需要一小时、一分钟，还是一秒钟完成，其差别非常之大。“天下武功，唯快不破”，就算架构设计做得不好，如果响应够快，很多情况下，也是能解决问题的。
+
+无论是利用公有云扩容，还是私有云扩容，目标都应该是一致的。想象一下这样的场景：
+
+双十一来了，你通过监控平台，看到在线用户数量快速增长，很快突破了 200 万，流量控制机制开始生效，新用户进入排队序列。你考虑了 3 秒钟，然后做了一个决定：系统需要扩容。于是，你轻轻地输入一个数字，按下回车。3 秒钟后，排队序列消失了。你对旁边的同学说，继续监控吧！然后悠闲地端起茶杯，离开了座位。
+
+这将是一种多么美妙的工作状态？更棒的是，以上场景完全有可能实现。
+
+至此，我们聊过了契约，也聊过了应急处理，也就意味着，我们把握住了高性能设计的“头”和“尾”。最后，我们再简单谈一下“中间”部分，也就是对系统各组件处理能力的提升。
+
+在高性能设计中，对于每个组件/服务都要确定目标，进行设计，然后进行评审和测试，确保满足性能需求。对于架构负责人来说，性能设计一定要尽早开始，具体工作内容包括：
+
+- 需求早期收集
+- 容量分析
+- 估算与建模
+- 技术研究
+- 设计、开发、跟踪
+- 测试计划执行
+- 风险与绩效管理
+- 实时监控与容量管理
+
+工作内容和流程可能有些多，但这更多属于标准化的研发管理流程，这里列出来仅供参考，实际执行的时候，需要参考具体的业务和企业情况做调整。
+
+**在这中间，有一点需要额外注意，我们称之为“对系统资源的争抢问题”。**
+
+对于一个组件或服务，并发压力增大，响应时间却没有变化，意味着在请求的处理过程中，没有发生对资源的争抢和排队。同理，当响应时间随着并发压力的增大而变长时，一般都意味着这些请求引起了对系统资源的争抢。
+
+**对于无状态的服务，理论上可以通过集群扩容，无限增加系统的并发处理能力，简单、直接地解决问题；**
+
+**但对于有状态的数据服务而言，比如缓存或数据访问，就要考虑资源争抢问题，并针对性地设计、处理**。
+
+所以，高性能架构在设计落地时，一个重要的任务，就是去发现那些可能出现资源争抢的模块，并一一进行隔离。
+
+谈到“隔离”，在架构维度有两种方案，一种是在应用层进行隔离，也就是说，在业务功能层面就开始隔离；一种是基础软件层面进行隔离，比如与数据库相关的“读写分离”概念，就是在基础软件层面进行隔离。
+
+对应到具体的实施方法上，有三种主要的“隔离”技巧，你可以多做了解：
+
+1. 缓存机制，适用于部分场景，可以解决数据库资源的争抢问题；
+1. EDA 架构，适用于处理时间较长的代码逻辑，需要提前区分哪些模块可以做同步处理，哪些模块可以做异步处理；
+1. 提前进行预处理，以空间换时间，这也是一种卓有成效的处理手段。
+
+当然了，方法还有很多，听完这节课后，你可以单独再做了解，并将了解到的方法，在评论区分享给大家。
+
+做好隔离后，我们也要注意提升架构的可扩展性，具体方法可以参考[《架构设计，专业分工和协作精神的体现》](https://time.geekbang.org/column/article/317135)，这里不再重复。
+
+至此，关于高性能设计的三个最重要的步骤就讲完了，我们总结一下，分别是：
+
+1. 为架构做好“保护系统”：做好系统的流量控制；
+1. 使架构具备扩容能力：储备额外的计算资源，提升弹性扩容的速度；
+1. 提升系统各组件处理能力：识别高并发情境中的资源争抢情况，同时注意保留架构的可扩展性。
+
+最后，我们也要对测试工作保持关注。可能你在 PRE  环境做过压测，但后来发现，实际的业务复杂度是远远超过想象的。
+
+针对这种问题，行业内的解决方案更偏向“全链路生产压测”，说白了，就是在生产环境准备数据、进行压测。如果一个系统通过了全链路压测，那就可以基本确认没有性能问题了。
+
+## 结语
+
+从我的角度来看，**技术行业发展到今天，基本不存在太多的技术挑战了。**
+
+如果你能将业务问题抽象为一个技术问题，那么不管是寻求同事的帮助，还是 Google、看书、到知识平台付费学习，都能解决你的疑惑。
+
+所以，在理清高性能架构设计的整体思路后，困惑、焦虑，应该从你的认知中消失。具体到数据库设计、缓存设计、队列使用等技术细节，我认为都不是问题。关键之处，是要守住契约，按照我们今天所讲的三大步骤尝试落地。
+
+过去的几年间，我曾在多个企业内建设高性能的 IT 系统架构，很好地服务了用户，使用的就是我们今天所讲的各个方法和思维框架。我个人感觉，过程也是相对轻松的。
+
+需要注意的是，如果时间充足且落实到位，系统确实不会出现高性能问题。可是实际情况是，团队没有时间做完整的高性能设计，没有预算做全链路压测，所以埋下了隐患。
+
+这时，我建议相关负责人要去识别最关键的服务，针对性地进行设计、测试，确保关键服务没有问题，并且，为非关键服务提供降级和熔断处理的开关。
+
+另外一个比较常见的情况，是企业决策层将高性能的设计问题和技术问题混为一谈：看似是技术能力太过欠缺，其实是契约和设计没有做好。**任何复杂问题都可以被拆解为简单问题，只要拆解得足够细致。一定要牢记这一点，这种思维能力是技术人的安身立命之本。**
+
+当然，如果你有问题或想交流的内容，也不要犹豫，立刻在评论区写出来，我会认真回复。
+
+我们下一讲再见。

极客时间专栏/geek/乔新亮的CTO成长复盘/对专业成长的复盘/22 | 扩展性设计，看透业务的本质.md

@@ -0,0 +1,154 @@
+<audio id="audio" title="22 | 扩展性设计，看透业务的本质" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/23/af/23c7dd9e6e951ef2b6b5bac5521009af.mp3"></audio>
+
+你好，我是乔新亮。
+
+这一讲，我想和你聊聊，如何做好扩展性设计。
+
+说到扩展性设计，可能你的第一反应是业务拆分、集群扩容等等。说得没错，这些都能增强系统的扩展性，但仅仅局限于架构和技术层面。我的下属经常兴奋地向我描述，说他实现了一个非常厉害的、高性能、高可扩展性的系统。我的回答经常是，你说的都对，然后呢？
+
+这个问题背后隐含的意思是：对于一名追求成长的技术人来说，只从技术维度思考问题是不够的。这只能让你胜任目前的工作，但不能让你变得卓越。
+
+一名追求卓越的技术人，应该学会思考：我的工作是如何成就业务的，我的产品如何让用户变得更卓越？如果对业务、对用户没有帮助，做再多的技术工作都是无用功。
+
+在职业生涯的早期，每一个工程师都会因为一些技术上的进步被领导夸奖，这很正常。因为在那时，做好基础的代码编写工作，就是你的主要任务。
+
+但如果三年、五年后，你仍然将全部注意力放在技术细节上，就要小心了。比如，很多读者都在专栏下方向我提问，其中一些问题是非常相似的：乔老师，我是一名工作了 7/10/15 年的技术总监，现在感觉非常焦虑，应该怎么突破职业瓶颈，怎么继续成长呢？
+
+如果要将我的回答总结为一句话，我觉得应该是：**让自己变得专业，专业才能成就卓越。**
+
+这个专业不单是指技术越来越厉害了、写代码越来越快了。更重要的是，你在架构设计方面是专业的、在团队管理方面是专业的、在业务发展方面也是专业的。因为专业所以做出了好的产品，通过产品成就了用户，因此也帮助公司业务取得了成功。
+
+回归到今天的主题 ——「扩展性设计」上，我们同样要考虑：如何做扩展性设计才是专业的？一定不是只会扩展集群，提一些服务器采购需求。
+
+扩展性设计，是为了支撑业务快速发展而出现的概念，目的是保证在企业发展的不同时期，在业务复杂度相近的情况下，业务上线所需要的研发时间不会大幅增加，甚至是基本不变的。本质上，所谓扩展性设计，就是在面向业务的不确定性做设计。
+
+因此，要想做好扩展性设计，设计者要具备企业发展的全局视角，从业务发展的角度出发，倒推出 IT 建设的整个链条，再针对链条中的某个节点，针对性地推进设计工作。
+
+听起来是个很“宏大”的工程，有点让人望而却步。但别害怕，接下来，我们就一步步将其拆解，学习如何做好企业级的扩展性设计。
+
+## 一条重要的前置思考脉络
+
+要做好企业级的扩展性设计，意味着你要强迫自己像 CEO 一样思考，首先理顺一条重要的前置思考脉络。
+
+如同前文所讲，无论是高可用、高性能还是今天聊到的扩展性设计，出发点都应该是业务发展，所以我们首先可以明确，**这条脉络的第一个节点，是公司的年度或季度业务发展目标。**
+
+那么，企业用什么形式来支撑业务的发展和增长呢？如果你认真听了前面的课程，此刻心中应该会有答案。没错，答案是产品。所以**第二个节点，是企业的产品建设。**
+
+产品，本质上是一种顶层设计，底层要由众多应用/业务组件支撑。所以**第三个节点，是企业的应用架构设计。**
+
+而应用架构又由众多技术组件在底层提供基础能力支撑，所以**第四个节点，是企业级技术架构设计**。
+
+以上四个节点，最终都是由人来完成的。所以我们还要考虑组织的人才梯队建设，包括 A/B 岗配置、同赛道竞争机制等。一旦将团队纳入设计，就要考虑协同效率的问题，不能因为业务增长、团队增长而引入协同问题。这两点，则全部属于团队管理范畴的问题。
+
+其实没有那么复杂，对吧？我们来梳理一下，要提升扩展性，需要在以下四个层面进行设计，分别是：
+
+1. 公司的年度/季度业务发展目标；
+1. 企业级产品建设；
+1. 企业级应用架构设计；
+1. 企业级技术架构设计。
+
+同时，我们也要将团队管理内容纳入考量，分别是人才梯队建设和提升协同效率。
+
+如果用云计算领域的概念来比喻，那么「产品建设」就像 SaaS、「应用架构设计」就像 PaaS、「技术架构设计」就像 IaaS/PaaS，三者共同固化为企业的核心能力，在团队管理方法的辅助下，实现业务可持续的向前发展。
+
+这四点就像一张“寻宝地图”，下面我们来分析一下，如何通过这张“地图”，实践扩展性设计。
+
+## 保证企业级年度/季度业务发展目标实现聚焦
+
+制定「企业级年度/季度业务发展目标」，需要在公司战略确定、商业模式确定的情况下，充分考虑市场竞争情况，确定目标的优先级，明确每个季度的工作目标。
+
+此时，我们主要考虑节奏问题。这里的“节奏”是什么意思呢？从企业发展的角度讲，一切能力都需要提升，但顺序不一样，节奏就不一样，效果上的差别也非常大。所以，做好战略规划很重要，要分析各战略步骤的依赖关系、重要性、紧急程度，最后确定执行顺序。
+
+所谓“扩展性设计”，通常是当大环境或创始团队的认知出现变化时，公司需要重新调整业务目标，各团队也要配合调整。具体到每个季度的目标，则一定要清晰、聚焦、上下对齐。关于战略执行效率的问题，我们在“[管理三板斧](https://time.geekbang.org/column/article/307105)”部分进行过讲解，可以参考一下。
+
+此外，初/中级管理者很难像 CEO 一样透彻理解业务目标，但要尽力去理解、去沟通，每个季度要主动和公司目标进行对齐。认知越透彻，对自己的工作和成长越有帮助。
+
+## 用业务目标指导产品建设
+
+确定了业务目标后，在规划产品建设时，团队可以通过三步做好扩展性设计：
+
+1. 通过架构思维，将产品拆解为一个个功能模块；
+1. 针对每个模块，用穷举法思考其他扩展可能；
+1. 以 ROI 为出发点，对所有可能进行收敛，最终确定要落实的扩展性设计。
+
+对于步骤一，我们就不再展开详谈了，可以参考[《架构设计，专业分工和协作精神的体现》](https://time.geekbang.org/column/article/317135)这一讲的具体内容；对于步骤二，相关负责人既可以根据市场趋势来穷举，也可以根据相关竞品来穷举，其实更像一场头脑风暴。
+
+关键在于步骤三，如果收敛得不好，会让产品变得臃肿，变成过度设计；如果收敛得太过，又会使产品缺乏扩展性。如何准确计算 ROI，是一个大学问。而计算 ROI 的重任，一般都会落在产品经理的头上。
+
+ROI 的意思是投资回报率，也叫做投入产出比，常用的计算公式有五种以上。在技术管理领域，我们可以简单将 ROI 理解为“收益/投入”。
+
+业务侧人员一般重点关注工作收益，不关心工作投入；技术侧人员则非常重视工作投入，不关心工作受益；产品经理则要学会综合考虑。
+
+无论是业务侧、技术侧还是产品侧，这三方人员的业务思维越好，产品需求的收敛工作就完成得越快、越好。前面我们讲过，IT 团队的每个人都要懂业务，其意义就在于此；相应的，业务人员也需要培育产品思维，这样才能最终实现公司的业务  IT  一体化。
+
+当然，产品建设一方面从业务侧收集需求，完善产品；另一方面，优秀的产品经理也会帮助业务筛选客户，确定产品方向。二者循环往复，互为补充。
+
+举个例子，一个生鲜类 To B 产品的报价系统，通常需要和对标对象做价格比对，并做相应调整。通常，一个没有扩展性思维的团队，接了需求就会直接开始写代码，反正也没什么难度。
+
+但一个有扩展性思维的团队会思考：在北京需要与对标对象 A 比对价格，在福州可能就是与对象 B 比对价格了，不同的地区可能会对系统功能有不同的需求。
+
+进而，我们可以将一个价格比对产品的功能模块进行抽象，包含：对标对象设置、对标商品映射、价格设定规则（上浮或者下调）、对标周期等，这样就可以满足全国各个区域的任何价格比对需求，支持业务的快速发展。
+
+所以，产品能否具备高扩展性，是与产品经理的业务思维和抽象能力密切相关的。同时，如果产品设计做得好，应用架构的设计工作就会简单很多。
+
+讲完了业务目标和产品设计，也就来到了关于扩展性设计的第三个节点：做好企业的应用架构设计。这里，我们需要重点区分两个概念：架构设计的确定性与不确定性。
+
+## 扩展性设计，为“不确定性”而设计
+
+笼统地讲，任何业务架构都存在确定性和不确定性的部分，但二者并不是恒定不变的。所谓的确定性部分，可能无法适应业务的演进和发展，因此出现大量改动；而所谓的不确定性部分，也可能随着时间的推移，逐渐固化为产品能力，变成设计内的确定性内容。
+
+企业级应用架构设计可以包含：
+
+1. 交易体系；
+1. 协同体系；
+1. 监控指挥体系；
+1. 生产体系。
+
+这是做拆分的基本思想，无论在顶层还是底层，都非常适用，需要做的只是不断进行拆分。经过这些年的工作实践，我觉得，无论是组织管理、架构设计还是产品设计，很多时候就像“套娃”。刚开始做企业架构规划时，我觉得非常难以入手，彻底掌握后，我发现这和做系统架构设计简直一摸一样。
+
+对于生鲜行业的 To B 产品来说，查询、下单、发货、签收，是始终不变的业务流程，属于确定性部分。这部分的实现归属交易体系。**交易体系处理确定性问题，一般采用 SOA 架构。**
+
+但在实际的业务场景中，意外会经常出现。比如，客户下单购买了 500 斤白菜，但在发货时，仓储系统却显示备货不足，无法正常发货。
+
+此时，产品预设的服务流程就被打破了。企业一般会指派客服人员与客户联系，尝试着商量一下：“不好意思，我们的白菜只剩 300 斤了，剩下的 200 斤给您换成芹菜吧，芹菜多好吃呀！”
+
+这个时候，我们就需要让采购人员、销售支持、销售人员联系客户，进行充分沟通，确定最终的商品品类及数量。这个流程属于协同问题，充满不确定性，也就是说，相比交易体系，更有可能随着公司的管理优化而进行变化。**协同体系用于处理不确定性问题，一般采用 EDA 架构，且要和交易体系进行集成。**
+
+所谓「不确定性」部分，其实正是业务架构做扩展性设计的核心。交易体系和协同体系的分离，等同于分离了业务的确定性和不确定性部分，因此非常有利于业务功能的扩展。
+
+**分离不代表完全无关，交易体系和协同体系的集成点，我称之为 CP（control point）。一般来说，任何一个 CP 都要被监控、分析、控制，这就是企业的监控指挥体系。监控指挥体系和公司的管理密切相关，往往是公司数据化管理的重要抓手。**
+
+监控指挥体系可以分为监控、分析、洞察、控制等几大功能，大数据和  AI  部分的技术内容也在这个体系中。监控体系解决了公司的很多问题，但怎样保证产品高效地迭代和优化呢？这就是生产体系要解决的问题。
+
+**生产体系解决公司研发管理地速度问题**。我的观点是，技术管理者要学会引入“流水线”式设计思想，尝试极大简化开发人员、测试人员的工作复杂度。如果将研发的整体流程看作一条“流水线”，代码开发完成后，工作要自动流转，正常、异常都要自动流转至对应人员进行处理，这是有关 CI、CD、CO  的内容，我们不展开详解， 但它非常重要。
+
+做好了应用架构层面的扩展性设计，我们也就来到了第四个节点 —— 企业级技术架构设计。
+
+技术架构设计设计的关键在于：**不要重复造轮子，至少不要在公司层级造轮子**。 “局部最优，整体很差”的情况，很多时候都是因为重复造轮子导致的。
+
+所以，要实现技术架构体系中的各个技术平台，可以通过两步完成：
+
+1. 自研；
+1. 购买相应的套装软件或云服务。
+
+对于非核心系统，在需求较为匹配的情况下，建议选择购买套装软件或云服务；对于高度定制化的企业核心系统，也就是在核心价值链上提供服务的系统，则建议自研。
+
+是不是很简单？到这里，我们就将扩展性设计的四个关键节点全部分析完毕了。
+
+其实真正的扩展性设计，往往与单一维度的技术问题无关，也与某个人的架构设计能力关系不大 —— 扩展性设计，是团队整体认知、博弈与决策的结果。
+
+这意味着，如果你想在一家公司内，充分践行以上设计思想，需要锻炼并掌握一定的表达技巧，与领导、同事、下属保持充分的沟通，更与组织管理能力息息相关，要多治治“腼腆内向”、“不善沟通”等技术人“职业病”。
+
+## 结语
+
+这一讲，我们聊了聊如何进行扩展性设计。
+
+可以说，**真正优秀的扩展性设计，建立在看透业务本质的基础上，面向不确定性，但要从不确定性中寻找确定性。**
+
+这里需要注意，越是行之有效的方法，越不会太过复杂。比如说，研发速度快，对于产品或架构而言，也是一种扩展性 —— 我们没做过什么扩展性设计，但团队的研发速度很快：今天发现需求，明天就能上线。
+
+这样靠谱吗？当然靠谱，就像我们之前说的，“天下武功，唯快不破”。只是长期看来，唯有体系化的思维和解决方案，才能真正从根本上解决问题。
+
+如果你有问题，欢迎在评论区向我提问；如果你觉得有帮助，也欢迎分享文章到朋友圈，让更多人参与进来，共同学习。
+
+我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对专业成长的复盘/23 | 考虑限制，让自己的产品不入险地.md

@@ -0,0 +1,190 @@
+<audio id="audio" title="23 | 考虑限制，让自己的产品不入险地" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4a/e8/4a05697cde713b44c6b0yyaa3324d3e8.mp3"></audio>
+
+你好，我是乔新亮。
+
+在实际的工作中，可能你经常会承担许多难以按约、按时交付，甚至是无法交付的工作。对于个人成长来说，这无疑是个大问题。
+
+虽然我常常向团队强调一个公式：「**认知到位 + 彪悍执行 = 成功交付**」，但这是建立在对项目的客观评估基础上的，否则，对于某些工作任务或产品需求来说，无论你多么努力，也可能无法保质保量地交付。
+
+无法交付的原因可能有很多：或许，该需求远远超出了团队现阶段的技术能力；又或许，是该需求违背了项目执行的客观规律，等等。总之，因为你承诺了自己根本做不到，或风险极高的“契约”，因而导致自己无法按约交付，最终对自己的成长和信誉造成了损害。当然了，对于公司而言，这一结果也是最差的。
+
+举一个夸张点的例子，有一天，老板找到你说，小王啊，公司最近要自研一款分布式数据库，决定让你来负责项目实施，一个月能不能搞定上线？
+
+你可能会在心里想，天啊，一个月，时间太紧了，怎么可能？老板看出你有点犹豫，又补充道：小王啊，要抓住机会，好好表现啊！
+
+你一听，顿时觉得，不就是加班吗？拼一把吧，于是点头应承下来。结果，一个月后，项目因为种种意外延期了，你则因为长期加班累了个半死……
+
+我们不妨再举一个例子，公司的新产品要上线了，老板和产品经理们一同规划了一艘“航空母舰”：功能极其强大、性能业界领先、UI 非常漂亮，同时希望一个月就上线。结果呢，团队奋战了几个月，不但产品的设计和研发处处受阻，上线时间还遥遥无期……
+
+以上两个例子，相对来说都比较夸张，但夸大是为了便于理解。类似的情况，其实每天都在各大公司内上演，只是更加隐蔽，不易察觉。你可能认为这是一个有关“自知之明”的问题：没有金刚钻就别揽瓷器活，自己能干多少活还不清楚吗？
+
+但我要说，**无论是什么问题，只要存在，就一定有其合理性；进一步讲，无论是什么问题，只要合理，就一定有专业的解决办法，因为那些专业人士总是能确保自己不掉入陷阱。**
+
+在这里，我们同样有一套专业的思考和解决方案，适用于架构设计、个人成长等诸多方面，它的名字，叫作“考虑限制”。
+
+其实，在前面的几讲内容里，我们已经多少聊过一点“限制”思想。比如，对于高可用架构设计来说，要做好流量控制，否则，所谓的“高可用”只能是空谈；对于产品设计来说，要明确给用户的契约，不能做无边界的承诺。
+
+但关于“限制”，我们还需要更加系统化的理解和实践。接下来，我们就来详细聊聊，如何做好限制，让产品不入险地。
+
+## 限制产品的输入与输出
+
+首先，我们要知道，只有专业的人，“懂”的人才能做好限制，这个道理在高可用、高并发、高性能等各个领域都是通用的。
+
+那么，如何才能变得专业，让自己跨越从“不懂”到“懂”的鸿沟呢？这里就再次应用到了架构设计思维，对应的第一步，就是做好拆解。
+
+任何产品都存在“输入”和“输出”两部分。如果你是产品的负责人，“输入”就是其他人对你承诺的“契约”；“输出”一般理解为承诺给用户的“契约”，指的是产品的对外能力，通常受到输入的严重影响。
+
+比如，因为资金有限、服务器不够，所以我们无法承诺服务器在 300 万并发压力下保证 TP 90 = 2s，反之，只有当并发压力不高于 200 万时，我们才可以做出承诺。
+
+具体应该如何考虑输入限制呢？有两大维度我们要去重点评估和考量，一类叫做业务限制，一类叫做技术限制。
+
+**业务限制**主要包括以下六点：
+
+**第一，Time（时间）、Resource（资源）、Scope（范围）三要素。**
+
+这三类要素构成了产品最主要、最基本的“输入”，它们就像一个等边三角形，撑起了产品的落地路径。其中，时间和资源的含义都比较明确。范围一词略微有些模糊，我们将其理解为产品的功能规划或能力范围。范围出现变化，时间和资源也会相应出现变化。
+
+最可怕的事情，莫过于像我们文章开头所举的例子一样，一个月的工作量要求一周做完、十个人的工作量要求用一个人做完、产品的范围被扩充成“航空母舰”。只要三要素不合理、不匹配，产品基本都会“难产”。
+
+**第二，法律法规与政策限制。**
+
+这两年的 P2P、金融创新、社区团购等业务可以算是典型案例。但法律法规和相关政策的变更，大部分是为了在国家角度控制市场风险。对于相关行业从业者来说，不应该视为障碍。就像我们先前讲过的，**好的产品设计是向善的，这是始终不变的**。
+
+**第三，组织文化限制。**
+
+不同的组织结构、组织文化，都会对产品的输入造成限制。这也是管理者为什么要聚焦「管理三板斧」，建立好的企业文化 —— 没有合适的组织，一切设计都是空谈。
+
+**第四，地域因素限制。**
+
+不同地域也会对产品落地造成限制，但可能不会造成直接影响。比如具有高技术壁垒的底层基础设施产品，如果放在三线城市进行孵化，就会面临团队人才不足的情况；特定项目在上海临港新片区孵化可能会相对容易，在其他城市可能就会相对困难。这些都是客观存在的。
+
+**第五，风险承受能力。**
+
+举例来说，薄利多销且过于依赖场景的业务，风险承受能力可能就会有所欠缺。比如今年，疫情对许多线下业务几乎造成了毁灭性的打击。
+
+**第六，市场因素限制。**
+
+市场因素也是我们要重点考虑的，这就需要对市场动态保持一定的敏感度，不能闭门造车。
+
+除了业务限制，还要考虑**技术限制**，具体包括五类限制因素：
+
+**第一，遗留系统限制。**
+
+企业在系统建设的过程中，会引入一些商业套件软件或者自研系统。但同时，数字化资产管理可能没有做到位，导致很多设计文档缺失，相关负责人也不断变动。所以，后来人员很难再对系统进行升级。
+
+究其原因，主要是架构设计缺乏、研发管理缺失。遗留系统越多，对于后来迭代开发速度影响越大。
+
+新系统上线的时候，架构师的一个重要工作便是做系统的上下文架构设计、明确周边依赖，对于需要和周边遗留系统进行集成交互的组件或模块，要高度重视。这些都是关键的限制因素，可能因为一个小小的环节疏漏，就最终影响了工作的推进。
+
+**第二，团队技能限制**
+
+团队成员本身的能力，也是一大限制。一些团队刚刚经历了“大换血”，新成员需要成长。此时若要保证产品输出不变，势必需要在其他维度有所补充。
+
+**第三，现有基础设施限制。**
+
+前面我们讲过，企业的竞争壁垒来自于产品，IT 基础设施也是产品。基础设施强，团队能力就强，输入限制就少；反之，基础设施弱，团队能力就弱，输入限制就大。
+
+比如资源扩容的时间、访问数据服务的复杂程度、测试回归的能力等，都是非常重要的限制因素，对于研发速度、研发质量都有巨大的影响。
+
+**第四，标准规范限制。**
+
+一般来说，随着企业IT治理水平的提升，都会逐步建立企业范围内的标准规范。这些规范是企业最佳实践的总结、规划，但同时也对产品建设构成了限制。
+
+比如，一些企业会对研发语言有所限制。在某些情况下，精通 Java 语言的可用工程师比较少，但仍然要求用 Java 语言完成开发，这也会对输入产生限制。
+
+**第五，实施限制。**
+
+在实施方面，企业往往也会有所限制。比如，流程性的规定一般会对研发时间有所限制，做排期时需要纳入考虑。
+
+你看，一个产品从设计到落地，会受到如此多的输入限制。如果不考虑它们，一定会对“成功交付”造成很大的影响，最终影响工作目标的达成。
+
+讲完输入限制，我们再来理解一下所谓的输出限制。
+
+输出，是给用户的契约，我们在产品思维、高可用设计等章节都有所提及 —— 要给出清晰、可量化的、符合 “SMART 原则”的契约。可以说是“对契约做限制”，也可以理解成“要让契约更明确”。
+
+比如，在对系统进行容量规划后，架构师要对超出处理能力的流量进行流量控制。这就是一种明确的限制手段；再比如，如果机房只有一根光纤，就不要承诺系统 7 * 24 小时高可用；如果生鲜产品需要早上 7 点送达目标企业，那么原则上，晚上 10 点后就不再接单……
+
+这些都是限制，需要将其加入服务契约中，和用户形成共识，一诺千金。明确限制，是为了更好地服务用户，这是对用户负责的态度。
+
+## 产品迭代背后的项目管理
+
+在实际工作中，每个技术人员都会通过做项目的方式，参与产品的迭代。而做项目本身，就是一场关于“限制”的重头戏。
+
+你可能会想，做项目有什么可说的？我们的项目经理每天就会催、催、催，这活我也能干。
+
+其实，项目管理是一门专业度极高的学问。很多项目看似是因为一些意外情况延期、取消，实际恰恰是项目管理做得不够专业。
+
+在一个项目组里，有四类角色非常重要，分别是：
+
+- PM（Project Manager），项目经理；
+- PM（Product Manager），产品经理；
+- Architect，架构师；
+- Specialist，某一领域技术专家，比如 DBA ，分布式缓存专家，大数据专家等。
+
+在大型项目里，这四类角色可能分别对应着四个人，甚至更多；在中小型项目中，四类角色也可能只对应着一个人，这意味着，团队内有一个成员很强，可以同时承担这四类角色的职责。
+
+项目的成败，整体掌握于项目经理之手，因为项目经理要做好 WBS（工作分解结构）。项目在落地过程中，所有的节点监控、风险管理等工作，都依赖于 WBS 。
+
+WBS 有三大分解原则：
+
+1. 将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；
+1. 每个任务原则上要求分解到不能再细分为止；
+1. 日常活动要对应到人、时间和资金投入。
+
+前面我们讲了，业务因素和技术因素都会对输入产生限制，但具体如何对时间、人力、资源产生影响，影响程度怎么样，可不是拍脑门决定的。
+
+现在，很多项目经理做工作拆分的流程是：将所有相关人员叫到一起，分别询问各工作项的预估执行时间。可能各模块负责人自己也不太清楚，秉持着“ Timeline 要虚报”的原则，直接拍脑袋给了个上浮过的整数时间，比如：一个月、两个月……项目经理说，好！于是 Timeline 就这么确认了。
+
+这就是典型的非专业项目落地，最终不但造成项目时间的不可控、项目执行的低效，长期来看，也导致了业务各方、企业各层间的博弈，比如，老板会说，你们能不能更快点？你们是不是在“放羊”？
+
+有经验的项目经理在预估排期时，往往会问每个模块的负责人：“为什么这些工作需要 x 天的执行时间？有没有什么执行难点？”如果对方答不上来，或者该负责人也没有相关的项目经验，项目经理就需要找到有经验的人、有发言权的人，继续问：“这些工作需要多久做完，为什么？有没有什么执行难点？”
+
+看起来并不复杂，但实际上，是需要专业能力支撑的。项目经理凭什么做拆解，并确定任务间的依赖关系？答案是，要么组织产品经理、架构师、技术专家，一起分解任务；要么一人身兼四种角色，独立完成。
+
+WBS 制定完成后，产品经理以产品设计匹配业务需求，明确业务目标和业务流程；架构师负责整体的框架设计，明确对应组件的整体视图；技术专家负责扫清相关的技术难点。最后，Developer（开发人员）、Tester（测试人员） 进入项目，解决工作量问题。
+
+到头来，我们要明白，以上工作都是在输入、输出受限的情况下，保证产品不会因为执行问题而违背契约。反过来讲，执行团队本身也是输入的限制条件。也就是说，当缺乏优秀的项目经理、产品经理、架构师或技术专家时，就要相应地继续下调输出预期。
+
+而且，**项目同样受到 Time（时间）、Resource（资源）、Scope（范围）等多方因素限制，在执行时同样要考虑限制条件，其本质就是有“不完美”成分存在的。通过不断的迭代，产品最终变得完美，但项目不会一次就缔造一个完美的产品。对项目期望的合理管控，本身就是在考虑限制。**
+
+在做项目执行时，认识到这一点是非常重要的。
+
+## 延展思考：向上管理的“限制”问题
+
+把控好了输入、输出的“限制”，也做好了项目执行过程中的“限制”，基本上就覆盖了产品从 0 到 1 的整个流程。
+
+理论上讲，我们的产品应该不入险地，始终“高可靠”地完成契约交付。
+
+但实际情况未必如此。
+
+问题出在哪里呢？一个意外是，项目经理在做输出限制时，通常会遇到来自上层的阻力。
+
+比如，项目经理要立项研发企业 OMS 系统，但企业基础设施建设程度一般、团队技术实力较差，因此输出的契约是“三个月上线 OMS 系统”。老板看到了，可能就会问：“怎么这么久，一个半月行不行？”
+
+这时，一个很常见也很难解的命题就出现了：如何做好向上管理？
+
+在前面的文章里，我们其实分享过，要做好向上管理，第一要务是具备全局思维能力，和老板站在同一个维度思考。所谓的沟通技巧，只能锦上添花，不能雪中送炭。
+
+很多同学当时很有感触，但在沟通中，我发现，大家的认知可能还有偏差。全局思维，是为了对齐目标、统一话语体系，但在具体表达的时候，一定要体现自己的专业性。
+
+你的结论是：OMS 系统三个月上线；老板的想法是：OMS 系统一个半月上线。此时，你第一件要做的事，就是利用自己的专业知识和行业一般数据，将与 WBS 有关的思考和推断表达出来，尝试让项目按照正确的节奏落地。
+
+第二点同样重要：要从更快交付的目标出发，同时将多种限制因素考虑在内，比如团队疲劳度、凝聚力、激励措施等，和老板一起想办法，把自己想象成一个专业的 CEO —— 这公司就是自己的，进而思考应该如何安排工作、如何制定 WBS。
+
+你可能会说，老乔，那如果讲不清楚，应该怎么办啊？其实没啥办法，如果你不够专业，或者讲不清楚，那也只能认了。所以我对中层管理者的能力考察，包括：专业能力、汇报能力 —— 技术人不但要能干活，还要能专业地讲出来。
+
+最后，要千万注意：**具备全局思维、让自己变得更专业、提升自己的表达能力，这一切工作都不是为了和老板在项目目标上进行博弈。我们的目的是，通过更合理的实现路径，最终达成业务的增长目标。**否则，除非你非常优秀，是不可或缺的人才，不然一般都会在博弈中处于下风，对个人成长造成影响。
+
+## 结语
+
+今天，我们聊了聊面对产品，如何做好限制，尤其强调了对输入、输出以及项目执行的限制。在架构设计、高可用、高性能等内容里，我们无时无刻不在强调限制。
+
+很多同学，尤其是比较有上进心的同学都会想，强调这个干嘛呢？无论是什么工作，尽力去做不就好了吗？做成什么样算什么样，反正尽力了。
+
+其实，恰恰是因为有上进心，才应该尽全力交付为用户承诺的契约，所有组织最终都是结果导向的。产品有限制，说明当下仍有许多不足，知不足，才能知进步。
+
+限制，在企业层级，也意味着在企业发展的某个阶段，选择放弃某类用户。有放弃，才能聚焦，进而倒逼自己看到全局，和企业目标对齐。聚焦当下，学会取舍；放眼长期，持续进步、持续改进。
+
+到这里，关于如何做好限制，就基本讲完了。我们的专栏，也正式进入了完结倒计时。还是老样子，如果有问题，欢迎在评论区提问。
+
+我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对专业成长的复盘/24 | 监控设计，让一切都有迹可循，尽在掌控.md

@@ -0,0 +1,167 @@
+<audio id="audio" title="24 | 监控设计，让一切都有迹可循，尽在掌控" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/78/57/78fba3dd9b1e6d3e9c19f09da8505257.mp3"></audio>
+
+你好，我是乔新亮。
+
+这一讲，我想和你聊聊如何做好监控设计。
+
+你可能会想，为什么要聊监控呢？做监控不是很简单吗？
+
+所有做技术的同学，基本都会根据公司的日志规范，在代码中打印 Log ，以记录告警和报错。许多企业，也会将日志收集分析，以此形成对系统状态的监控。如果条件允许，团队还可以使用各类免费或付费的服务器监控报警服务，多方便啊，这有啥好讲的呢？
+
+其实在我眼里，这些都只是构成了监控的一部分，并非完整的监控体系。要想深刻理解监控的概念，我们首先要学会问自己：为什么要做监控系统？这就像许多工作方法论里强调的一样，做事先问目的 —— “start with why”。
+
+**监控的目标是及时发现系统的问题，并尽可能快地做出相应的动作，让系统一直处于健康的状态**。监控，可以拆分为“监”和“控”分别理解，其含义恰好对应着两种主要手段，也就是“**监视**”和“**控制**”（中文真是博大精深）。
+
+比如说，生产环境出现了个 bug，怎样定位问题？这需要做好“监视”；发现问题根源后如何正确响应？这需要做好“控制”。
+
+比较无奈的情况是，研发人员知道系统出了问题，但无法定位问题；更悲催的情况是，研发人员能够定位问题，但无法控制问题，只能眼睁睁地看着故障发生。但无论哪种情况发生了，从结果来看，其实区别都不大。唯一的区别可能是，前者至少让人心存希望，后者则让人感觉整颗心都“冰凉冰凉”的。
+
+说到这里，我不禁有点感慨：监控、监控，意味着既要监视也要控制，没有控制的监视达不到目标，没有监视的控制无法形成行动计划。
+
+从业至今，我曾处理过许多因认知不足，而导致的系统监控问题。下面，我们就选取其中一件比较典型的案例，尝试着一同复盘下。
+
+## 技术团队的“怪现象”
+
+这个案例发生于某日下班后 —— 大约是在傍晚 20:00 左右，团队发现了一个出现在生产环境的异常。该异常来自一个可以连接众多终端设备的程序，其具体表现为：所在服务器的 CPU 负载突然飙升。但发现异常后，团队既无法将其恢复，也无法定位问题。
+
+发现问题后，共有十几位工程师先后参与了问题分析。很快，两个小时就过去了，监控系统仍然显示 CPU 占用异常，问题还是没有解决。这下，产品负责人着急了，向我求助，并将我拉进了问题调查组的电话会议。
+
+进入会议后，我立刻问了大家一个问题：
+
+“最近线上有什么版本变动吗？都回退了吗？”
+
+团队回答道：“都回退了。”
+
+我几乎没有任何犹豫地说道，不可能，一定没有全部回退。
+
+要知道，计算机是非常可靠的。如果一套代码在一台机器上可以正常、稳定地运行，那么在外部环境没有发生任何变更的情况下，一周、一个月、一年后，它大概率能继续保持正常、稳定地运行。
+
+你可能会想，老乔又开始信口胡说了，难道就没有意外情况吗？
+
+有，我也确实遇见过，但在近 20 年职业生涯里，我只遇见过一次（ZooKeeper 因虚拟机连接数过多而崩溃事件，在“高可用设计”部分，我们曾简单提到）。所以，这种情况几乎是“可遇不可求”的，在大部分时间里都可以直接忽略。
+
+果然，在我的追问下，负责发布的同学说，系统没有回退到上一个版本，而是按研发同学的指挥选择性回退的。
+
+好呀，真相大白，我命令他迅速按公司研发制度回退。
+
+没成想，回退到上一版本后，系统依然不正常。于是，团队继续查看前端、服务端、数据库等各类监控数据，试图分析问题到底出在哪里。
+
+我再一次找到团队，问道，真的都回退了吗？
+
+团队可怜兮兮地回答，真的都回退了！
+
+我的回答是，不可能，鬼才信你们…… 于是，我开始继续不依不饶地追问。
+
+终于，在我的“威逼利诱”下，有位同学一拍脑门，犹豫地说道：“我在数据库里加了条索引，不过这肯定不会导致负载异常……”
+
+还没说完，我就哭笑不得地打断了他的话，谈这些做什么？赶紧回退去。
+
+当这个改动回退后，一切都恢复了正常。
+
+最终，一个本该三分钟内被搞定的生产问题，用了几个小时才解决。幸亏发布窗口是业务低峰期，否则已酿成重大损失。在许多公司里，相关人员几乎一定会受到处罚。
+
+事后复盘时，我问团队，当我询问版本有无全部回退时，为何不及时声明？
+
+那个同学委屈地说，我以为那条索引不可能惹出这么大的问题……
+
+请注意，在这个故事里，当事人员并不是毫无经验的新手；公司并非没有监控系统，相反还做到了可视化、图形化。
+
+既然如此，为何团队还会被一条小小的索引命令阻滞这么久呢？这是一个非常奇怪的现象。而且，在参加 GTLC 全球技术领导力峰会时，我在和一些同学的沟通中也发现：这种现象并非孤例，很多团队都曾出现过类似的情况。
+
+于是，我不得不去思考，IT 团队的系统监控体系，到底出了什么问题？
+
+## IT 团队的系统监控体系，到底出了什么问题？
+
+当陷入思考的泥潭时，我们往往需要将思维抽离，尝试站在更高维度探寻问题的本质。此时，我们不妨将这个案例暂且放一放，重新思考一下监控的本质含义。
+
+在文章开头，我们讲过了，**监控是为了让系统一直处于健康状态，具体的手段包括“监视”和“控制”两种**。简单来说，就是当生产环境出现问题时，我们要能知道哪里出了问题，并具备相应的控制手段。
+
+生产环境应急恢复的最大挑战在于根因分析，即找到问题的根本原因，这往往是耗时最久的工作。
+
+但如果没有控制手段，那么即使找到了根因，团队也是无能为力，只能干着急，或者静静地期盼奇迹出现，好像系统在下一分钟就能自动恢复健康。
+
+所以，当生产环境发生异常时，大部分团队会这样组织故障恢复工作：
+
+1. 发现问题后，立即联系各相关系统负责人，以便共同排查问题；
+1. 要求大家在一分钟之内回复：自己治下的系统或服务是否健康（这里要将“健康”的定义想清楚，如，响应时间是否增加超过 30% 等）；
+1. 进行根因分析，确认导致问题的系统、服务；
+1. 完成系统恢复工作。
+
+对于步骤  1、2 ，其实挑战都不大，真正的挑战在于步骤  3、4。步骤 3 依赖于相关分析人员的专业程度。一般情况下，随着企业业务的复杂度逐渐增加、系统和服务的数量逐渐增加，人员规模也会越来越大，在步骤 3 上花费的时间就会脱离控制。
+
+此外，对于步骤  3 中涉及的不健康组件，我们需要分析：这种不健康状态是原因，还是结果。关于分析方法，其实也比较简单：
+
+1. 首先，我们要确认异常是外因导致，还是内因导致。比如，服务响应慢，既可能是因为外部调用量变大，也可能是因为内部进程繁忙，导致 I/O 、内存、网络资源发生争抢。这步判断相对来说比较耗时间，只有当调查足够充分时，结果才可能浮出水面；
+1. 无论是内因还是外因，都要“顺藤摸瓜”，继续进行排查，最后进行恢复。
+
+说到这里，我们不难得出结论：生产应急保障体系的建设，并不像大家想象的那么简单。从系统复杂度到人员专业性，任何不足都会导致问题定位、根因分析花费更多的时间。因此，以上故障恢复流程也存在很大的隐患。
+
+那么，难道生产系统出了问题，我们就只能坐以待毙吗？有没有一个对团队专业度依赖较低的方法呢？答案是，有的。我把它总结为：**流控和版本回退，简单、粗暴、实用**。
+
+流控，就是做好程序的并发流量控制；版本回退，就是在生产环境的发布出现问题时，及时回退到上一个版本。
+
+**生产环境出现问题，原因通常只有两个字：变化**。常见的“变化”大致有三类：
+
+1. 外部用户请求量增大；
+1. 产品发布，一般包括代码发布、配置发布、SQL 脚本发布等；
+1. 依赖资源变化，一般是计算、存储、网络基础设施情况变差，比如磁盘存在坏道等。
+
+这样看来，当故障发生时，我们不一定要组织团队进行复杂的根因分析 —— 那是故障恢复后的事儿。相反，只要我们控制住了服务的近期变化，也就等于控制住了故障。思路一变，好像就豁然开朗了。所以， 我们不妨将生产应急恢复方法修改为以下 4 条：
+
+1. 发现问题后，立即联系各相关系统负责人，以便共同排查问题；
+1. 要求大家在一分钟之内回复：自己治下的系统或服务是否健康（这里要将“健康”的定义想清楚，如，响应时间是否增加超过 30% 等）；
+1. 此处组织两批研发力量，并行工作。第一批解决专业问题，继续跟进问题的定位和调试；第二批负责消灭变化，对有变化的模块进行回退，对于外部请求数量升高的模块启动流控；
+1. 恢复系统。
+
+你看，这样就降低了故障恢复对于团队专业性的要求。只要我们保证，对于任何组件，都有以下两种手段同时存在：
+
+1. 流控手段；
+1. 发布回退手段。
+
+是不是很简单？在 IT 行业，对于专业团队而言，一般没有太过复杂的工作；如果工作过于复杂，往往是因为负责人不够专业。还是那句话：大道至简。
+
+问题的关键在于，生产环境是不允许查找 bug 的。**在生产环境，研发人员应该寻找并消灭“变化”。从寻找 bug 到寻找变化，是一个非常大的认知转变。**
+
+此时，再回顾文章开头的案例，答案就比较清晰了。团队在执行生产环境故障恢复工作时，接连犯下了三个错误：
+
+错误一：负责发布的同学，没有按规定回退至稳定版本，而是询问开发同学的意见，并以其意见为准；
+
+错误二：相关负责人，因为假设“一条索引不会导致故障”而知情不报，导致系统无法完全回退；
+
+错误三：十几名团队成员没有将精力聚焦在线上业务恢复方面，而是试图在生产环境查找 bug。
+
+三个错误如出一辙，全部来自于技术同学的思维惯性。在大家的认知里，制度就是拿来参考的，对应模块的负责人才是专业的，出了事先找人再问制度规范，或者压根不问制度；在大家的认知里，bug 要用排除法解决，“确定”没问题的模块就要排除在外；在大家的认知里，能一眼发现错误的程序员，才是技术高手，如果动不动就回退，和“网管只会重启”有什么区别？
+
+但是我想说的是，当问题发生时，你的潜意识是要找到 bug ，还是找到变化，对应的结果可能是完全不同的。我们的目标是，**即使找不到 bug，依然可以做好故障恢复**。
+
+这样的思维惯性有多么普遍呢？我们举个例子：你是否曾在下班回家的路上，被老板电话叫回公司，查找线上 bug  ？
+
+也许你会觉得这样做很合理，但听完这节课以后，希望你能够意识到这种做法的局限性：线上有 bug ，为什么需要研发立刻回公司？先回退就好了嘛。否则，研发现场写程序，压力也是挺大的。
+
+更别提，一些团队还经常出现喜剧性的一幕：生产环境出现了问题，研发火急火燎地改了个版本，结果系统做不到秒级发布，单是发布就用了半个小时。好不容易上线了，还没来得及高兴，就发现了个新问题……
+
+我们必须不断强调并加深印象：**生产环境永远不允许调试问题，出现问题立刻回退，查问题要去测试环境**。
+
+你可能会想，老乔啊，你这就有点纸上谈兵了，很多大型发布涉及多个系统，怎么可能随便回退呢？
+
+其实这个问题，亚马逊在十几年前就给出解决方案了：**大版本立项，小版本上线** —— 梳理好各模块的依赖关系，将各个系统、各个服务独立发布。当然，这也需要依赖服务版本化和 CI  能力的支持。
+
+以上我们讲的是对企业系统的监控。除此之外，我们也要做好对企业业务的监控。
+
+也就是说，对于企业任何一个未处于理想状态的业务环节，都要进行监控：做好问题的可视化展现、明确管理执行动作，通过数据化管理，不断完善企业的运营效率和运营质量。道理其实还是相通的。
+
+如果能做到监视一切，分析一切，控制一切，“眼”能看见所有，“脑”能洞察一切，“手”能一手遮天，一切业务数字化，一切数据可视化，一切控制可触发，那么，这个企业的数字化水平一定已经很高了。
+
+## 结语
+
+今天，我们从一个实际案例出发，主要聊了聊关于企业生产环境系统监控的认知和方法：**监控的目的是让系统一直处于健康状态，具体手段则可分为“监视”和“控制”两种；要做好控制，一个重要的方法是做好流控和版本回退。因为在大部分情况下，消除变化就等于消除异常。**
+
+实际上，不单是技术、业务系统需要做好监控，研发管理、团队管理都要做好监控。
+
+关于研发管理，我们在“高可用设计”部分曾提到：风险是经由开发环境、SIT 环境、压测环境、PRE 环境，进入生产环境的。所以我们要做的是严格检查各个环境下的异常。所谓研发管理规范，应该为代码版本进入下一个环境设置准入标准。对于任何异常，都有负责人进行修正。
+
+对于团队管理，我们常常说，组织是结果导向的，但管理工作是过程导向的。关注过程自然就会得到好的结果，只盯着结果往往什么也得不到。对于一个项目、一个产品，乃至于团队的健康度，管理者有没有在关键节点设置监控？有没有针对异常做好控制？其差别是巨大的。
+
+如果你认真学习了前面的内容，可能也会发现，无论是管理还是专业技术，很多关键认知都是相通的。很多时候，是“一理通百理明”。在学习的同时，前后交叉思考，也有助于你在更高的维度上掌握这些知识。
+
+今天，我们就聊到这里，下一讲再见。

极客时间专栏/geek/乔新亮的CTO成长复盘/对专业成长的复盘/25 | 异常设计，让错误无处遁形.md

@@ -0,0 +1,132 @@
+<audio id="audio" title="25 | 异常设计，让错误无处遁形" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/bd/7c/bd36aa257f192yy62604d87256aab27c.mp3"></audio>
+
+你好，我是乔新亮。
+
+今天，我想和你聊聊有关异常设计的话题。
+
+如果你认真听了前面的内容，那么对你来说，异常设计应该不是一个新鲜概念了。在高可用设计、监控体系建设部分，我们都聊到了对异常的管理。
+
+那么，为什么今天我们又要单独聊异常设计呢？因为异常管理虽然属于监控体系的一部分，但并不完全依赖于监控体系或高可用设计。**在企业的监控体系建设完成前，异常设计一般就可以独立发挥作用，达到快速见效的目的。**
+
+异常管理可以提升 IT 团队快速定位问题的能力、降低生产系统异常出现的频次和数量，更重要的是，它是让 IT 团队从面向技术，转为面向产品、面向用户的关键步骤，所以我们这里独立出来讲。
+
+那么，在开始之前，我们有必要明确一下，究竟何为异常？
+
+你可能会想，导致系统不能正常工作的问题就是异常呗。
+
+说得对，但不全对。有些异常，可能当下未必会对生产环境产生影响，但不代表未来也不会；有些异常，可能在流量压力小时未必会出问题，但不代表流量压力大时也不会。
+
+就像在平时，每位同学都会打印 Log，有 Warning，有 Error。大部分同学关注 Error，而不关注 Warning ，甚至有时 Error 也是选择性忽略的。反正打印这些，也不一定会导致线上服务受影响，看看就得了。
+
+但很可能恰恰就是这些被忽视掉的 Error 和 Warning，最终导致了严重故障的出现。
+
+所以，所谓**异常，指的就是那些让产品无法履行当初承诺用户的契约的问题。**
+
+下面，我们通过几个具体的例子来理解一下。
+
+## 那些被忽视掉的异常
+
+早些年，经常网购的同学，可能听说过电商界的两个绰号：“二手X”、“无货X”。
+
+商品缺货、出现品质或质量问题，一直以来就是电商界的两大“顽疾”。但严格地说，这些都是因仓储系统、订单系统、质量监测系统不够完善，而导致在业务运营层级发生的概率性问题，并非研发同学心目中的“恶性故障”。
+
+但随着用户规模的增大，原本“不值一提”的低概率问题就会被无限放大。举个例子，一家电商平台缺货的概率可能只有 2%，也就是说，配货成功率高达 98%，看起来没啥问题。但当平台用户数量达到一百万时，就会有多达两万人受到缺货问题的困扰。这两万人中，可能只有 30% 的用户有在社交平台发帖的习惯。可即便如此，也会有 6000 人出现在各大社交平台上，发帖吐槽该电商平台的缺货、质量问题。
+
+“好事不出门，坏事传千里”，于是，“无货 X”、“二手 X”的绰号就出现了，企业声誉严重受损，用户对企业的信任也极大降低，企业需要付出更大的努力来赢回用户。
+
+所以，许多你不太关注的异常，最终会在产品层面对用户体验产生恶性影响。一般情况下，产品经理对这类问题的感知更敏锐，但职能型研发组织中的产品经理往往不参与代码编写，一般也不会深度参与开发过程；对于程序员来说，通常也不会主动和产品经理沟通类似问题。
+
+于是，这类问题往往会顺利通过开发、测试，最终进入生产环境。在没有异常设计的情况下，让用户买单。**那些用户经历的坏体验，对于开发人员来说，可能只是一个简单的错误提示而已。**
+
+当然，这是业务和产品层面的异常。对于很多普通技术人来说，对于底层技术层面的异常，可能更为熟悉。
+
+我曾听一位做 C++ 服务器开发的同学，讲过他们企业发生的趣事。他们经常会处理许多到不同 CDN 节点的高频下载请求，但会有一部分下载超时或耗时增加的异常出现。
+
+他们当时的做法是，当下载耗时超过 200ms 时，在 Log 中打印 Warning ；当下载因超时而失败时，设置定时重试，并在 Log 中打印 Error 。
+
+我好奇地问，然后呢？
+
+他回答，然后就没什么啦，重试一般都能成功。
+
+我继续问，如果一直不成功呢？
+
+他挠挠头，那可能就会导致业务出问题了，研发就得起床查 Log 了。
+
+我又问，如果重试可以成功，但当并发压力增大时，来不及多次重试呢？
+
+他尴尬地笑了下，没说话。
+
+你看，往往我们在做所谓的“异常设计”时，并没有实现给用户的契约。对于电商平台而言，没有实现“成功下单 = 成功配送”的契约；对于那位做 C++ 服务器开发的同学来说，没有实现给其他系统模块的“准时下载”的契约。
+
+大家通常认为，当下的异常没有导致生产环境出现严重问题，所以以后也不会出问题，但实际情况往往不是这样。
+
+在我看来，没有兑现契约，即为异常，就应该控制起来。
+
+那么，到底怎么做好异常设计呢？我们大致可以分为三部分来理解，分别是认知、方案和治理。
+
+## 对于异常设计的认知、方案和治理
+
+首先，对于异常设计，有五点认知一定要明确，分别是：
+
+1. 异常一定要消灭：有异常，基本就意味着系统存在风险，一定要消灭异常；
+1. 异常一定要管理：消灭异常是个长期工程，短期要通过管理行为来进行控制；
+1. 对异常的处理水平，会极大影响产品的用户体验：用户规模越大，异常的影响往往越大；
+1. 每个异常都要有具体的负责人：没有和具体的负责人一一对应，往往就意味着管理流于形式；
+1. 与终端用户相关的异常，要以最高优先级处理：即便是 IT 研发，也要以用户为中心。
+
+有了对异常的正确认知后，我们就需要在体系上对异常进行管理。
+
+前面，在高可用设计部分，我曾经分享了“交易体系”和“协同体系”的设计差别。简单来说，交易体系负责处理相对稳定的业务流程，协同体系则是当异常出现时，需要接入的流程。比如客户要订 500 斤白菜，由交易体系来完成，库存满足、正常履行；库存不足时，则需要协同体系完成剩余流程。
+
+但很多同学只做交易体系，不做协同体系，只抛出异常，而不处理异常，因此常常会引领用户走上“断头路”。在某些情况下，用户无路可走，只能找客服投诉。
+
+认知到位后，下面我们一起来看如何落实异常设计。**异常设计一般包含异常注册、异常事件触发、异常协作流程以及异常统计。**
+
+要管理好异常，我们首先要完成对异常的注册，注册内容大概分为以下几项：
+
+1. 异常的 ID 和名字；
+1. 对异常的描述；
+1. 异常出现的代码位置；
+1. 负责此异常的研发、测试和产品人员；
+1. 异常发生时的代码版本；
+1. 当时使用的异常处理程序。
+
+同时，企业也要建设异常中心，各个系统都要在异常中心注册异常，一旦运行阶段出现异常，就要抛出异常事件，触发异常处理的协同流程。
+
+当然，很多企业在还没有很好地管理异常时，就已经建设了大量的系统，因此很难再做异常设计。但很多异常都被记录在了日志里，因此研发同学可以通过收集日志中的异常，继而进行归类处理，再通过异常治理完成异常的注册，这样就间接达到了目标。
+
+异常注册、收集后要做什么呢？当然是交由相关负责人进行处理了，这时我们就进入了异常的治理流程。不是所有的异常都要从 Log 中消失，但对于保留下的异常，一定提交管理层进行审批，说明保留原因；理由不够充分的，需要按排期规划并解决。
+
+比如到 CDN 节点的下载行为有一定概率会失败，我们就要调查究竟是服务商提供的节点有问题，还是系统程序在编写方面有问题，又或者是相关机房的网络情况不好。总之，问题一定要明确并解决掉。
+
+管理层也要关注异常的处理情况，包括：
+
+1. 异常的数量；
+1. 异常的发生频次；
+1. 系统内异常数量的增速或降速；
+
+……
+
+在季度末、年末，我们会对管理层进行绩效考核，并将异常管理情况纳入考核体系，以此实现异常治理的闭环。
+
+你可能会想，写个代码可真难啊，越来越麻烦了。不要怕麻烦，要关注投入产出比。做好异常设计，我们既可以做到高可用、高可靠问题的防微杜渐，还可以帮助研发和测试人员快速定位 Bug。最重要的是，在企业层面，我们可以**实现用户体验驱动内部经营完善的经营逻辑**。对于一个技术人来说，这无疑是能帮助你上台阶、再成长的。
+
+在苏宁的时候，我主导研发了“神鉴”系统，目标就是为了做好企业的异常管理。在彩食鲜，我们也在不断完善异常管理，虽然时间不长，但相关工作已经卓有成效。前几天，相关人员还汇报道，我们科技中心所有产品的异常码都已经被统一管理起来，相关异常编码、响应信息都会被实时收集、归类，保证可视化、可统计。
+
+你看，当我们能把繁杂的技术细节，纳入体系化的管理流程里时，还有什么样的困难我们克服不了呢？
+
+当你用这种思路去管理异常时，就可以对一家企业有更深入、更近距离的了解。**只要仔细观察一家企业是如何对待异常的，就可以判断这家企业的精细化运营和管理水平。**
+
+## 结语
+
+今天，我们聊了聊与异常设计相关的话题，最终的目的，是让企业的潜在产品和研发问题，全部暴露出来，达成最好的产品体验。
+
+但在落地异常设计时，也一定不要着急。要知道，异常，是会和我们长期共存的，对异常的处理和记录，也会逐渐成为企业数字资产的一部分。
+
+**对于直接影响用户体验的问题，要有契约精神，快速迭代；对于企业宏观角度的异常治理，要坚持长期主义，不断优化。**
+
+此外，企业的一个核心竞争力就是持续进化的能力。因此，在保持进化的过程中，企业发生的任何问题，都要纳入到异常管理流程中，将异常管理数据化、产品化、系统化，通过持续的治理和数据分析，让企业不断进化，最终建立竞争优势。
+
+相信你一定能将异常管理做得越来越好，让一切错误无所遁形。
+
+我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对专业成长的复盘/26 | 上云设计，融合云计算的未来.md

@@ -0,0 +1,159 @@
+<audio id="audio" title="26 | 上云设计，融合云计算的未来" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/99/2f/997c3513a3d944e10ac637f27fa2692f.mp3"></audio>
+
+你好，我是乔新亮。
+
+如果不考虑本周五将要更新的“结束语”，那么实际上，我们已经来到了整个专栏的最后一讲。在这一讲里，我打算和你聊聊有关“上云设计”的话题。
+
+为什么要在这样的时刻聊起云计算呢？
+
+这其实和当代 IT 产业的发展趋势有关，可以说，云计算产业的成熟，直接影响了很多问题的思考方式。
+
+前段时间，我找到团队内的一位核心架构师，请他去调研关于企业上云的可行性，培养他做架构决策的能力和思维。其实，对于我来说，调研的结果并不重要，因为我早就在心里打算好了：我们一定要上云，彻底拥抱云计算。让团队去调研可行性，更多是为了做好团队的能力培养。
+
+说到这里，你可能会觉得有些似曾相识。没错，在专栏里，我曾多次提起对云上资源的规划。
+
+比如，在“高性能设计”一节，我们谈到拥有云上秒级扩容能力，会给运维工作带来哪些帮助；在“扩展性设计”一节，我们提议，对于非核心系统，在需求较为匹配的情况下，直接选择购买套装软件或云服务。
+
+类似的例子还有很多，最终可以归结为一个结论：企业要上云，并且未来一定会上云。
+
+当然，我不是一拍脑门或是收了赞助费，所以跑来建议大家上云。而是整个 IT 产业的发展趋势，迫使我们顺应时代。如果不能形成正确认知，与趋势为敌，一定会影响企业或者自己的发展。
+
+所以接下来，我们要站在全局视角，尝试看透 IT 和云产业的价值与发展。
+
+## 对 IT 技术和云计算的发展趋势判断
+
+整个 IT 产业的发展历程，起始于硬件方面的发明创造。
+
+1946年，英国剑桥大学成功研制出第一台冯·诺依曼机器： EDSAC 。近十年后，相关的编译程序和编程语言才出现。
+
+但直到 1964 年 IBM 推出 System/360 以前，所有的计算机都是面向用户定制的，没有统一标准，设计上也没有连续性。IBM System/360 的出现，标志着计算机开始走向通用化、系列化和标准化。
+
+1981 年，IBM 推出了世界第一台个人 PC，体型大幅缩小，是计算机走进千家万户的开始。站在历史的角度看， IBM PC 尤其有重要意义。
+
+但如果让一个生活在 2020 年的程序员来看， IBM PC 无疑差到令人发指 —— 它的内存只有 16k，存储还要靠盒式录音磁带或 5.25 英寸软盘，售价却高达 1565 美元，真是又贵又难用，性能都不如现在一款价值几百元的老年手机。
+
+当然，IT 软件的发展也没比硬件好多少。如果你是计算机软件专业出身，很可能学习过汇编语言，也就是面向机器的程序设计语言。现在看来，汇编语言非常难以理解，编码也很复杂。到现在，已经很少有软件公司，会用汇编来开发软件。
+
+那时，人们很难想象，会有 Java、Golang 这样的语言应用在软件开发行业，极大降低研发成本，提升了研发效率。
+
+从汇编语言到 Java ，从最早的 IBM System/360 到如今的计算设备，技术发展表现出了一个明显的趋势：底层黑盒化、价格亲民化。也就是说，**我们越来越不需要关注技术细节，同时技术的价格也越来越亲民。**
+
+当这些技术或服务，被整合成产品，连入互联网，使客户可以按需购买时，云计算就出现了。
+
+站在应用软件角度看，现在的 IaaS 软件已经非常成熟，PaaS 和 SaaS 软件也在迅速发展中。到目前为止，Salesforce 可以说是最成功的 SaaS 软件。
+
+说了这么多，关于 IT 技术和云计算，二者的发展究竟呈现出什么样的特征呢？我将其总结为以下五点：
+
+1. 形态产品化；
+1. 价格平民化；
+1. 自助服务；
+1. 按需付费；
+1. 网络访问。
+
+在某种意义上，云计算可以理解为各类云服务的统称，而所有这些服务，都是通过产品来体现的。在今天，云产品仍然在向前快速发展，站在旧有产品的肩膀上，融合进旧有产品的生态里。
+
+推动这种发展向前的力量，不是某家公司 CEO 的个人意志，而是“**技术基座不断上移**”的社会客观需求。
+
+科技不与人争利，只有人与人之间才会争利。技术进步推动了社会的进步，因此自有其普世价值，也会越来越平民化。**看清趋势，拥抱趋势，在技术<strong><strong>演进早期，选择**</strong>恰当时间，积极应用，拥抱技术红利，**<strong>就**</strong>可以为企业赢得阶段性的领先优势</strong>。
+
+在经济学概念里，如何实现社会效益的最大化？答案是，专业分工。在数字化世界里，逻辑其实是同样成立的。最明显的特征是，对于云产品来说，只要客观需求存在，就一定会有人去尝试解决，并包装成产品售卖。
+
+比如，DevOps、微服务框架、多云管理、深度学习训练服务、边缘计算服务、量子计算服务……只要你需要，基本就能找得到。
+
+对于云计算厂商来说，只要不是企业核心的业务逻辑，所有“技术基座”都可以云化，让专业的人干专业的事，客户只需要付费购买就好。
+
+对于**甲方企业来说，IT 投入是价值成本，需要持续加大投入，但迫于经济规律，<strong><strong>最终**</strong>不得不寻求公共技术的社会化</strong>。
+
+双方的深层需求是契合的，也符合让社会效益最大化的经济学原理。所以，关于 IT 技术和云计算的发展趋势，我一直认为有两大结论是非常关键的，分别是：
+
+1. 数字化转型的结果是：云会吞噬一切；
+1. 云不仅仅是技术，更是最好的商业模式。
+
+明确了这两点，我们才能知道，该如何正确地看待这场“变革”，并寻找个人或企业的发展机会。
+
+## 坚持拿来主义，不要和趋势为敌
+
+我相信，至少有五点认知，你一定要关注，并多加思考。这些认知，既适合普通工程师，也适合 CEO/CTO ，区别是，站在何种角度去思考，以及如何做决策。
+
+**第一，从业务发展的角度出发，倒推上云规划。**
+
+你可能会想，老乔这个大忽悠，按你这么说，CTO 干脆啥也别想，直接上云就可以了。
+
+当然不是了，上云是为了帮助业务降本提效，做任何事都要从目标出发。从前，我曾主导企业的 IT 设施上云规划，就在同云计算厂商的合同里，明确写道：
+
+“完成迁云后，在同等资源下， IT 年度总支出费用相比 20xx 年降低 55%。20xx 年为迁云实施阶段，年度迁云总费用不得高于前一年 IT 相关基础设施、技术平台总费用。”
+
+当然，云产品带来的价值，不仅是资源节省，还有人力节省、加速研发等，这些都可以换算成财务价值。
+
+如果你上了云，IT 开销反而更大了，那说明整个规划和管理一定存在问题，先不要上云。
+
+**第二，坚持“拿来主义”，不要在企业层面重复造轮子。**
+
+其实在前面的内容里，我们有聊到过这一点，但很多做技术的同学，依然对此十分执着。
+
+经常有同学找到我说，老乔，XX 功能我们自己完成吧，我们自己做得更好！做得更好，到底是怎么个好法呢？用我们前面讲的知识来理解，也就是要明确给“用户”的契约：“你要消耗多少成本，在多长时间内，实现一个什么样的产品，性能表现怎么样？”
+
+大部分同学，可能并没有明确这个契约。有时，老板也会犯糊涂，仅仅是听研发负责人这么一说，就不假思索、大大方方地同意了。
+
+通常，在项目刚启动时，在开源项目的加持下，可能只需要两个人参与开发，人力成本并不高。可一个季度后，负责人就会找到老板，要求将项目组扩充至五人。又过了一个季度，可能项目组就变成了十个人。老板这才发现自己上了“贼船”，该项目仿佛一个“无底洞”，自研成本早已远远超过购买云服务的开销。
+
+当下，许多的 IT 研发工作都是重复造轮子，美其名曰为“沉淀企业 IT 基因”，实际就是浪费 IT 资源，对业务发展施加反作用。企业经营要务实，对于非核心业务，坚持“拿来主义”，不要过于理想主义；对于核心业务，坚持长期投入，建立团队推进自研工作。
+
+**第三，别害怕上云，<strong><strong>和**</strong>乙方**<strong>一起**</strong>搞定障碍。</strong>
+
+很多技术管理者一提上云就如临大敌：顶层规划怎么做呀？云上架构怎么设计呀？应用怎么迁移呢？怎么把云用好呀？怎么选择云厂商啊？
+
+还没正式见过服务商们，就先把自己吓了个半死 —— 这么多问题都不懂，我们团队可能支持不了上云改造，要不计划先搁置吧。
+
+依据我在企业上云方面的经验，上云规划涉及的内容会非常多，包括：上云方案、现有系统评估、云平台成本优化建议、迁移方案、云主机的功能和指标、网络带宽指标、跨国专线带宽指标，等等。
+
+在当时，团队也是第一次做上云迁移，很多内容都不懂。这份文档的内容，部分是我们根据自身需求提出的，部分来自于云厂商对自己亮点的介绍。最终，文档在不断地沟通和商业谈判中丰富起来了。
+
+**第四，开放心态看待数据隐私。**
+
+很多人对公有云比较抗拒，担心数据隐私泄露，担心竞争对手派系的企业盗用自己数据。其实我认为，大可不必担心。我个人的观点是，云厂商不会在公司层级盗取你的数据，但有可能因为管理不善而导致数据泄露。
+
+可我们也要多问问自己，自己管理的数据就安全吗？比头部云厂商的管理更加安全吗？
+
+我看未必。当然，如果实在不放心，大可以选择私有化部署，一样能解决问题。
+
+**第五，正确看待云计算的“负面影响”。**
+
+听到这里，你可能还是不太放心，老乔，云计算真的那么好，一点负面影响都没有吗？
+
+肯定还是有的，但客观地讲，这些更多属于组织和文化层面的问题。最近几年，在和许多管理者朋友的交流里，我愈发明确了一个事实：技术基座的上移，最终会导致部分初级开发者失去工作机会。
+
+听起来有点耸人听闻，但这是事实。以前，有许多人安于码代码，拒绝思考，同时也拒绝追求卓越，自嘲为“搬砖码农”。但“搬砖码农”的数量未来一定会减少，云计算的成熟会大大加速这一过程。
+
+如果企业奉行的不是以业务为中心，以产品为核心的组织文化，不具备我们前面所讲的、优秀的组织架构，就很可能在上云问题上陷入多方扯皮。因为，这触动了部分人的“蛋糕”，打扰了部分人的浑水摸鱼。
+
+所以上云，依然是个一把手工程。
+
+以上五点，是在上云过程中，许多人都可能存在的困惑与实际问题，如果要将其总结为一句话，我认为是：坚持“拿来主义”，不要和趋势为敌。
+
+我们要明确地意识到，未来，专业分工一定会越来越明确，技术基座一定会不断上移，每家企业都可以忘掉底层技术细节，聚焦自己的核心业务逻辑。因此，这条思考脉络最终也会回到出发点，形成闭环：对于大部分商业公司（非技术产品或云计算公司）而言，技术只有在成就业务时，才具备真正的价值。
+
+## 结语
+
+曾经，许多研发同学都喜欢找到我说，老乔，你看我做的这个软件，太厉害了，我技术厉害吧？
+
+我经常打击他：有啥厉害的，你这做的就是个玩具嘛。
+
+你可能会有点不解，怎么就是个玩具呢？答案很简单，真正厉害的技术，要能包装成产品，对外售卖或提供服务。用户愿意为之付费的，才是好东西。再多的夸奖，也不比金钱更有说服力。
+
+我常常说，要站在未来看当下，用十年后的眼光看现在。由此出发，可见对于很多研发同学来说，个人成长路径其实只有两条：
+
+1. 成为技术管理者，进入商业公司，采用技术产品或云服务，洞察业务，帮助业务成功，实现业务价值；
+1. 成为技术专家，进入纯技术公司或云计算公司，设计开发技术产品，提供技术服务。
+
+无论哪一条，其实都已经注定要和云计算的未来融合在一起，云计算会成为未来的水、电、燃气、交通工具。
+
+一定要尽早形成对此事的正确认知，大胆地拥抱新的技术趋势和机会。等到大家都看清云计算的发展情况，全部开上“汽车”时，无论是我们的个人发展，还是企业的发展，也就谈不上什么先发优势了。
+
+当然，很多企业没有认真规划过自己的技术平台，因此也比较难以上云。但如果在企业内部，就存在一个底层技术平台，那么，这就很接近企业级别“云平台”的概念了。与此同时，如果我们能保持开放的心态，那么外部平台就只是一个候选方，和企业生态内的云平台并无本质区别。
+
+农业社会的核心生产力是农民，工业社会的核心生产力是工人，信息社会的核心生产力是码农。经济学原理告诉我们：个人价值是通过稀缺性来体现的。看清趋势、拥抱趋势，才会让自己变得稀缺，才能让自己越走越顺！
+
+到此刻为止，我们专栏的正文内容，就全部结束了。感谢你一直以来的陪伴！
+
+还有一篇“结束语”，马上会和你见面，我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对个人认知的复盘/01 | 职业生涯发展规划：每五年登上一个新台阶.md

@@ -0,0 +1,116 @@
+<audio id="audio" title="01 | 职业生涯发展规划：每五年登上一个新台阶" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b7/56/b721c89554be97b2ddd5606d4c424856.mp3"></audio>
+
+你好，我是乔新亮，欢迎来到专栏的第一讲。在这一讲里，我想首先和你聊聊关于个人职业发展的规划问题。
+
+作为技术人，大家学习 Java、Golang、算法、架构设计，这些都很重要，很棒！但在职业生涯初期，有一件事也很重要，那就是对职业生涯发展的认知，不然就会白白走上很多弯路。
+
+你可能会想，老乔，你又不认识我，不了解我的情况，怎么给我讲职业规划？而且这个话题这么大，有没有实在一点的方法啊？
+
+如果你确实存在这方面的担心，那么我要恭喜你，你的思考非常独立且理性。在学习新知识时，这非常关键。
+
+但我们可以换个思路想想：很多成功的 CEO、CTO ，包括我，也没有专门学过什么职业规划，他们又是如何达成职业发展目标的呢？
+
+作为一名从业 18 年的 CTO，我发现至少有一点是非常关键的，那就是：发展要快，每五年就要登上一个职业生涯的新台阶。
+
+## 不要误解“台阶”的含义
+
+每五年就要登上一个新台阶，这是什么意思？先不要急，听我讲一讲我自己的经历。
+
+我 2002 年毕业，其实 2003 年就开始带团队了，但这个转变来得有点凑巧。当时我在神州数码，团队正在开发一款工作流引擎，leader 突然调离到其他岗位了。领导就找到我说，小乔，这件事你来牵头做吧。
+
+我当时快吓死了 —— 我才刚毕业，学了几个月的 Java，没有任何的管理经验，就要承担这么大的一份责任，带比我经验丰富的老员工。不过我这个人遇事喜欢顶上去，于是就硬着头皮接了下来，最后确实做成了。
+
+所以，在整个职业生涯的前五年，我是一边在工作中锻炼技术能力，一边学习带团队、做管理。到 2008 年时，我加入了 IBM ，那时已经是一名很核心的技术管理者。在 IBM 的时候，我的成长非常快。IBM 的人事有一个硬性规定：除非员工作出特殊或突出贡献，否则必须在一个岗位干满两年才能升职。但我好像只有一次升职符合人事标准，其他时间都是不到两年就升职。
+
+就这样，我在 IBM GBS，从咨询经理一路做到副合伙人。后来我又去了苏宁，做到了副总裁。前后一算，差不多刚好用了 15 年左右的时间。
+
+你可能会一拍脑门：噢，我懂了，新台阶指的是新职位，从程序员到管理者是一个台阶，从管理者到总裁办公室又是一个台阶，对不对？
+
+错，大错特错。新台阶指的不是新岗位，更不是入职的企业规模、获得的薪资报酬。我认为，大部分技术人的职业发展可以笼统划分为三个阶段，分别是：
+
+1. 做事（Do）。这一阶段，你的工作偏向执行，主要负责解决个人承担的技术任务；
+1. 带团队（Manage）。这一阶段，你的工作偏向管理，主要负责协调组织，让团队实现更大价值；
+1. 业务决策（Lead）。此时你的工作应该是思考公司的业务发展，能站在公司的角度进行战略决策，更像一个创业者。
+
+从一个阶段迈入下一个阶段，就是“跨台阶”。
+
+为何不用职位作为台阶划分的标准呢？因为每个公司的情况各有不同。有些人虽然 Title 是技术总监，可他实际属于创始团队，他的意见对于公司战略举足轻重；有的人 Title 是副总裁、CTO，可在企业决策层毫无话语权，本质上还是一个“包工头”的角色。
+
+刚刚毕业一年，我就在以 Leader 的角色落地项目，可那时我能算名副其实的管理者吗？其实不能，本质上，我还是主要负责自己这摊事，主要谋求个人技术能力的成长。
+
+以职位作为划分标准，非常容易陷入误区，对自己的实际情况产生误判。当然，拿薪资做标准就更不靠谱了，我个人有一次上台阶甚至是降薪达成的，收益在于未来几年的高速发展。
+
+## 为何五年必须上一个台阶
+
+那么，为什么我们必须五年登上一个台阶呢？七年行不行，十年行不行，不上台阶行不行？多累呀！
+
+在你个人的角度看，完全没问题。可能当下你就身处一家不错的公司，薪水也很高，工作也很舒心，好像没必要折腾。
+
+但在老板的角度看，这件事儿完全是个简单的性价比问题。时间不断流逝，员工只是资历更深了，个人能力却没有迈上新的台阶，那么性价比就会下降，人力成本和个人价值开始不成正比。在大部分商业公司里，能力差不多的情况下，雇佣一名 35 岁的程序员和一名 25 岁的程序员，哪个性价比更高？答案是显而易见的。
+
+没有迈上新台阶，往往就意味着你的个人成长已经停滞了。比如，你开始变得很闲，觉得写代码很简单，大不了在 GitHub 上复制粘贴一段，稍微改改。但除了 Copy 代码之外，你又没有更多、更大的挑战，于是一直这么闲下去，眨眼就成为了公司的“待清理对象”。
+
+很多人没有意识到这个“慢性死亡”的过程，因为这种停滞有时会被掩盖住。这一点在当下快速发展的头部企业内，表现得尤为明显。
+
+在我看来，身在阿里、腾讯的许多总监，其实都身处危机之中。看似他们的职业生涯在高速发展，升职、加薪，但那是因为企业在高速发展，你身处的平台处于上升期。
+
+就像我在苏宁时，团队内的很多人都被阿里挖走了。为什么阿里会去挖他呢？当然，部分原因确实是他工作做得很不错。但客观来看，肯定还有苏宁这个平台和品牌的影响在，高频的“挖人”通常只存在于大厂和大厂之间。
+
+倘若脱离了苏宁、阿里、腾讯，你还能贡献同样乃至更高的价值吗？在思考个人成长时，**一定要清晰地区分平台价值和个人价值**。
+
+说句最实在的话，如果你的成长停滞了，那么即便是一名应届生入职，对你来说都可能是种压力。我刚毕业时可是很拼的，与我合作的老员工，很可能会感觉到压力。
+
+当然，到此为止，我们所说的“上台阶”都是围绕「技术人走管理路线」来讨论的。也有很多同学就是喜欢技术，也想在技术领域深耕下去的。
+
+我个人的建议是，如果你恰好入职了一家纯技术公司，比如数据库公司 PingCap ，那么你就拥有了成为技术专家的好契机，确实可以尝试始终走技术路线。
+
+但如果你入职的是业务驱动型公司，如苏宁、海尔，就要小心了。**成为技术专家比成为管理者更难**，一般要做到一个城市、一个行业屈指可数的顶尖专家，才能拥有更广阔的发展前景。更要命的问题是，在业务型公司内，技术本身没有直接价值的，也不具备太高的壁垒，同行业、同城市有太多的人可以替代你的位置，这时你的个人价值就会被稀释。
+
+管理岗位则不一样，管理注重的是团队协调和集体的价值实现，能管 1,000 人和能管 10,000 人是截然不同的概念，适用于中国大部分公司的发展需求。
+
+这也是为什么，在中国，大龄管理者的数量远远高于大龄程序员。
+
+所以我以大部分技术人的职业发展路线为例，以五年为一个界限，来讲今天这个话题。为何必须是五年呢？其实也没有那么绝对，但一个阶段五年，三个阶段就是十五年了。你想一想，人的一生能有几个黄金十年啊。如果太慢了，年龄会成为你成长的最大障碍。
+
+## 登上新台阶的时机与方法
+
+明确了五年登上一个新台阶的含义和必要性，要了解时机和方法则很简单。
+
+上台阶的时机，我在前文其实提到了，就是你开始闲下来、成长停滞的时候。
+
+至于方法，大致有两条，全部与个人成长息息相关，不存在取巧的成分：
+
+1. 首先，多学习，尤其是年轻时，一定要安排时间用来学习。我相信目前在读专栏的你，已经有这个意识了，恭喜你，你很棒！
+1. 其次，找到一个好的导师。比如，找到你们公司的技术大牛，请他吃饭。大部分时间里，一起吃饭就会增进感情，这事儿很简单、也很划算。尤其是刚毕业时，千万别太抠！
+
+你可能会说，就这样？这就完事了？
+
+并没有，“五年登上一个新台阶”，是个重要且成熟的认知，但在实践时却经常跑偏。
+
+有些人是时机把握不好，担心过早走上管理岗位，会导致技术基础不够扎实，为以后的发展埋下隐患。在业务型公司，这点非常好验证。业务型公司采用“自顶向下”的模式来验证技术水平，比如你支持的系统稳定性如何、扩展性怎么样、性能怎么样、故障时间控制得怎么样，这些都是标准。
+
+也有人会过高评估自己的能力，抱怨公司有眼不识千里马。遇见这种情况，我通常会建议大家出去面试、找工作，通过双向选择，验证一下自己的能力。
+
+有一次我和团队开玩笑说，如果觉得公司待你不公平，可以出去面试，拿到 Offer 后回来找我，我给你涨薪到新 Offer 的水平。当然了，如果你真的想这样验证能力，注意寻找情况类似、处于同一发展阶段的公司，如果是资本大量进入、正在高速扩张、不计员工性价比的公司，一般薪资会有溢价。
+
+我觉得最不靠谱的是，一些同学因为工作不顺心，就去创业了。创业是迈上一个更高的台阶，对个人能力的要求很高。如果你在平台的加持下，都做不好分内工作；失去了平台的帮助，就能成功了？我不这样认为。有些创业者确实运气很好，但我相信 99% 的人没有那样的好运气。
+
+当然，我也不是说，大家只要努力学习、找到一个好的导师、正确把握时机，就能飞速成为 CTO，那就是鸡汤了。
+
+事实是，业内存在相当一批管理者，个人能力是有点欠缺的，很容易成为下属的成长瓶颈。在他们的管理下，你很难迈上新台阶，**该跳槽的时候，要果断跳槽**。
+
+我常对我的团队说，你们只管长本事，长了本事后，如果我不给你加薪，你就跳槽，我还可以帮你介绍工作。这对我自己也是一种逼迫，逼着自己制定好团队的激励措施。
+
+无论如何，你要记住：成长、登上新台阶、再成长，这一循环是我们做许多决策的出发点。
+
+## 结语
+
+时间过得很快，专栏的第一章第一讲，到这里就接近尾声了，我们聊了很多关于职业规划的认知问题。
+
+最后我想提醒你，能够五年登上一个新台阶，已经算是成长得非常快了。如果你没做到，也不要为此苛责自己，继续努力，让自己能进步，相信自己能进步，然后登上新台阶。
+
+其实在工作的早些年，我自己也没意识到成长速度和阶段性规划的重要性。回过头去看，如果我能早点意识到这一点，在迈上第一个台阶前，多多留意管理方法；在迈上第二个台阶前，多多学习财务知识，那么我的发展会更好。
+
+今天，我把这份认知分享给你，希望也能帮到你。
+
+如果你在读过之后，能有所收获，那我就非常、非常开心了。

极客时间专栏/geek/乔新亮的CTO成长复盘/对个人认知的复盘/02 | 到底该怎么理解工作与薪资的关系？.md

@@ -0,0 +1,151 @@
+<audio id="audio" title="02 | 到底该怎么理解工作与薪资的关系？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3e/54/3e3ba6b3a26b65595cfecb3aea244254.mp3"></audio>
+
+你好，我是乔新亮。今天，我想和你聊聊关于工作状态和薪资报酬的问题。
+
+为什么要聊这个话题呢？在第一讲中，我们聊到每五年就要登上一个职业生涯的新台阶，很多同学觉得这很难。我必须得说，确实不容易。至少，很多人都还不具备快速成长的先决条件：一个良好的工作状态。
+
+你可能会想：哈，这一定不包括我，我天天加班。注意，这里的工作状态可不等于工作时长。
+
+作为一名 CTO，我经常观察下属的工作状态，发现许多人状态很差：有的人工作在严重焦虑之中，有的人每天都郁郁寡欢，有的人则过于情绪化，显得烦躁易怒……你看，这就是差劲的工作状态。
+
+这些糟糕状态很多时候都存在一个“病因”：薪水太少，或者觉得绩效奖励不公平；少数情况是在组织协作中受了委屈，越干越是生气；其他原因占比一般比较少，我觉得几乎可以忽略不计。
+
+就像马云说的，员工突然提离职，要么是工作时受了委屈，要么是觉得薪资太少。而且，我觉得后者尤其常见 —— 在大部分关于工作的不如意之中，或多或少都有“钱”的影子。毕竟，工作就是为了赚钱，这是绝大多数人天然生成的认知。
+
+但我要告诉你，如果一个人始终为了薪资而工作，工作状态一定会出问题，反而极大地影响薪资的增长。
+
+这可不是我对你实施 “职场 PUA”，而是来自我个人成长经历的真实反馈。
+
+## 从年薪 20 万到年薪 200 万，我是如何成长的？
+
+2003 年的时候，研究生刚毕业的我，在神州数码工作。
+
+在深圳做项目的时候，同期毕业的研究生同事，联合起来向公司提出加薪，目标是每个月涨 500 块钱（相当于涨薪 12.5%）。当时这个项目很重要，事情也闹得很大，很多人都加入了“求涨薪”的队伍，只有我和少数几个人没吭声。
+
+在北京总部的领导高度重视，特别飞到了深圳，请大家吃饭，一起坐下来聊聊这件事。了解情况后，总部决定：该涨薪的就要涨薪。就这样，事情也算妥善解决。
+
+事后，领导好奇地问我：小乔，你怎么不要求涨薪啊？
+
+我说，再过个一年半载我就准备离职了，还涨什么薪？
+
+当时，领导笑了，说，你说话倒是直率。
+
+其实，对着领导，我只说了一半原因；另一半原因，在于我知道，程序员一个月可以赚 20,000 元，500 元只能算是“苍蝇肉”，我看不上。
+
+看到这里，你可能会笑：一个月 20,000 也不多啊，现在名牌大学的应届研究生就能拿到这份薪水。可你要知道，那是 2003 年，博客网和淘宝刚刚上线，互联网、程序员，还属于平民百姓心中的新生事物。
+
+我是来自内蒙古的农村孩子，小时候家里有在外做生意的亲戚说：如果老老实实地上班，一个月是不可能挣到 20,000 块的。但我不信，因为我哥的月薪超过了20,000 —— 他比我大 9 岁。所以，回到 2003 年的深圳，我的内心其实很看重薪资，我的目标是月薪 20,000。
+
+后来我辗转加入了 Vitria （麒麟远创）、BEA （一家著名的 Java 中间件公司）、IBM，薪资确实翻了数倍。加入 IBM 时，因为恰好没有高级岗位空缺，所以我选择降薪入职。我记得当时的月薪差不多是 16,500 元/月，相当于年薪二十万左右，与同期毕业生相比，还算不错。
+
+但挣钱这种事儿，怎么会有满足的时候呢？因为在北京贷款买房、结婚，生小孩，生活压力越来越大；工作方面，我对自己的要求也很严格。表面上，我没有天天想着钱，可真要做到忘了钱、忘了薪资，也确实不容易。
+
+很快，问题来了，2009 年的时候，我确诊了重度抑郁症，差不多用了半年多的时间才康复。康复后，我查了很多资料，学习了很多相关知识，也自我总结了下病因：房贷、结婚……说白了，我就是缺钱。虽然相比同龄人，我的薪资不算低，但我还是很焦虑。
+
+当然，我不是说看重薪资、没实现财务自由，就会得抑郁症 —— 那就太耸人听闻了。但我发现所有为了钱而工作的人，工作状态或多或少都会出现问题。严重些的就像我，轻一点的也会导致成长速度变慢，甚至停滞，薪资增长自然也就停滞了。为了钱而工作，反而没赚到什么钱，这是很讽刺的一件事。
+
+你可能会想：老乔你又忽悠我，你怎么知道别人的状态有问题？我还真不是忽悠你，抑郁症康复后，我尤其关注自己的心理、精神和身体状态，久而久之，也能很敏锐地捕捉到别人的状态变化。
+
+言归正传，意识到这些问题后，我开始有意识地看淡薪资、看淡房贷，对自己的状态变化异常敏感。直到今天，我还和我儿子说：“如果有一天爸爸没钱了，咱家就吃馒头、咸菜撑一撑”，还能饿死不成？
+
+只靠自我开导还不够，我有幸遇到了一个优秀的 Leader。我清楚记得，有一段时间，我什么都没想，就是在专心工作，结果我的 Leader 总是周末给我打电话：“新亮啊，告诉你个好消息！因为 xxx 项目表现得好，你又要加薪啦！”、“新亮啊，又有个好消息！因为 xxx 项目很成功，你要升职啦！”……
+
+那时，我几乎月月都能收到好消息。当我忘记薪资时，许多压力和担忧都消失不见了。我会大胆地挑战自己，毫不害怕犯错，因为我的目标是成长，而不是薪资。就这样，我的工作状态逐渐达到最佳状态，表现越发出众，到2015年，年薪翻了10 倍多。
+
+这听起来有点像骗子，不惦记薪资，调整好状态，薪资就能翻十倍？当然不是，努力一定是成功的基础，我工作可是非常拼命的。但我完全可以确定，如果没有一个“忘记薪资”的好心态，即便我再努力、再拼命，也绝不会是今天的样子，或许走到技术总监岗位时，就已经停步不前了。
+
+## 为何工作状态如此重要？
+
+讲到这里，我们不妨换个角度问问自己：钱重要吗？重要，至少对我来说，它能帮我解决孩子的教育问题，让我的孩子能在大城市有个家，好好上学。但如果你仅仅为了钱而工作，心态就有可能出现问题。
+
+最差的情况是：自我感觉付出和回报不成正比，工作带着一股怨气。不愿意做事，没办法成长，每天上班都不开心。
+
+好一点的情况是：你依然努力工作，但内心十分焦虑。原因可能有很多，比如房贷、车贷、家里要用钱，或者感觉同龄人赚得都比你多，又或者你开始清晰意识到“中年危机”的存在，等等。
+
+无论是怨气，还是焦虑，都是个人成长的大敌。请注意，这里不是危言耸听，下面我们细说。
+
+**首先，心态不好，就休息不好，打硬仗时就会掉链子。**
+
+很多人对我说，乔总，你不觉得累吗？经常加班，经常给自己安排额外工作。其实我也累，有时候到家就瘫倒在床上，脸都不洗就睡了。但睡醒之后，我又可以满状态投入工作。为什么？因为我虽然身体累，但“心”不累。
+
+所以，如果某天我觉得状态不好，我完全可以“任性一次”：不加班，直接回家 —— 第二天就好了。但很多人是今天状态不好、明天状态也不好、后天状态还不好，每天都觉得很累，累到只想离职在家躺着。你以为是工作强度太高，其实部分原因是心理状态太差。
+
+**其次，心态不好，有些工作任务几乎不可能完成。**
+
+2012 年的时候，我在 IBM 负责企业客户的架构规划。有一天，我突然接到一个任务：将苏宁（当时 IBM 服务的重要客户之一）现有的 IBM WCS 套装软件切换至多 WCS 架构，具体说，就是系统处理能力要横向扩展 10 倍。
+
+在 IBM 内部，大家对这个项目的 Timeline 预估是半年交付，但客户的要求是两个半月做完，不然没法支撑“双十一”的流量压力。最先接手项目的部门已经进行了大概一个月，发现有风险，然后才想到：乔新亮或许能做成这事儿。可这时，时间只剩一个半月了。
+
+说白了，大家对这个项目的认知是：不可能完成。
+
+这里我们不妨换位思考一下，如果是你，在心态不好的情况下，会怎么办？
+
+我觉得，可能你压根就不会接这个项目。这不就是“背黑锅”吗？半年的工作，一个半月完成，你搞不定就甩给我了？不失败才怪。
+
+但是我就觉得应该做，而且一定要做成。因为我不是为了钱而工作，我是为了自己的成长而工作。做别人做不到的事，就是巨大的成长机会。接下项目后的一周内，我快速组织各部门，完成了项目的拆分、验证和工作分配，拆分出来的工作居然多达 200 余项。在剩余的一个半月时间里，我没给自己规划任何休息时间。
+
+如果心态不好，管理者一般会陷入极大的焦虑之中，所有做过乙方业务的朋友，应该都能有所体会。
+
+首先，项目组共有近 200 人，任何一个模块延期了，都将导致整个项目的失败。这个项目之所以挑战很大，在于不确定性太多，你根本不知道能否按时完成，以及会出现什么样的意外。
+
+不分青红皂白地加班还算小事，焦头烂额、夜不成眠才是大事，有人甚至脾气也会变得火爆。旁观者可以说两句大道理：“焦虑是不能解决问题的”，但没用，如果心态不够好，一个人是很难从负面情绪中挣脱出来。
+
+而我当时的情况是：深夜下班时，我还组织团队打扑克、打“双升”（也就是大家常说的“拖拉机”、“升级”），特别开心。我记得很清楚，打完了扑克，我们还一起去吃西瓜，完全不像正在推进一项“不可能完成”的任务。
+
+也正是这种轻松的心态，不但没有耽误项目进度，反而成为了我完成项目的充分必要条件。
+
+**所以直到今天，我对于状态不好的中层管理者，一直有一个硬性要求：一定时间内，必须调整好工作状态，不然就下调或者换到其他岗位。**
+
+可能你会想，这是不是有些夸大其辞、过于严厉了？就算我不打扑克、不吃西瓜，每天焦虑，也能撑住一个半月并且完成项目吧。可心态对于一个人的影响远不止这么简单，许多关乎成败的细节，你未必能够意识到。
+
+## 微妙的细节，决定了项目的成败
+
+在推进这个多 WCS 拆分项目时，我团队的一名核心骨干工程师 —— 张洋（化名），突然找到我，坚持要请假去首尔度蜜月，时间是一周，机票、酒店都订好了。如果是你，会怎么回复他？
+
+恐怕有太多的管理者会因此心跳加速、大脑充血：“本来项目就只有一个半月，你作为项目核心成员，就非要在这个节骨眼上出去旅游吗？”
+
+其实，这样的回复方式，就是心态不好的体现。本质上，这属于领导者将个人的焦虑心态传递给了下属，进而激化矛盾。那么，当一个人心态很好时，会如何应对这种情况呢？我的思路和心态大致可以分为三点：
+
+1. 要给团队传递信号：这个项目一定要成功，作为管理者，我一定能搞定；
+1. 任务分派后，搞不定的人，要去承担项目失败的全部责任；
+1. 告诉自己：我一定要处理好所有的意外情况，和张洋一起想办法，寻找个人和公司间的共赢方案。
+
+所以我对张洋说，度蜜月很重要，首尔也很漂亮，我支持你，一定要去！但项目也很紧张，工作一定要完成，我们一起想想办法，看怎么解决这个矛盾。
+
+最后张洋和我说，只要保证他顺利度完蜜月，一周之后，别管考勤系统显示几点上下班，他有信心通过自主安排工作时间，追回所有进度。我欣然同意，而他也确实兑现了自己的承诺，保证了项目的顺利交付，我们也成了很好的朋友。
+
+几年后，当张洋离职时，还向我提到了这次“蜜月事件”，说非常佩服我的处理方式。而我也有点感慨：以我对张洋的了解，如果当初滥用领导权威，逼他为了组织“牺牲小我”，十有八九会导致他临阵辞职，搞砸整个项目。
+
+相对于整个项目，这件事只能算作一个小插曲，但我们常说，细节决定成败。**如果一名管理者的心态不好，有太多微妙的细节，会导致你走向失败。**
+
+## 结语
+
+前面我们讲到很多关于好心态的必要性，也提到了“薪资”对“心态”的影响。到今日，我认为以上所有思考都可以归结为一句话：**薪资只是工作的附属，工作的真正报酬是成长。而所谓的涨薪，不代表你的工作岗位更值钱了，而是你的个人能力足以匹配更值钱的岗位。**
+
+我们不妨稍微延伸一下，很多人喜欢违背公司规定，私下打听薪资。打听完了，心态也失衡了：他的工资凭什么是我的二倍？这不公平！对，许多事就是不公平的，但那不重要，因为你不是为了钱而工作的。如果你的能力够强，薪资自然会上涨；如果不上涨，你还可以跳槽。总之，前景是光明的。
+
+所以，我不断告诉自己，没有任何一个老板诓我、骗我，真相就是这样。工作的核心目标只有一个：提升能力，进而匹配更高阶的岗位需求，钱、公平，都是次要的。
+
+你可能会想，老乔，你说的这都是大道理，我也懂，可我就是做不到啊！你的秘诀是什么？
+
+其实我也不是什么天才。刚毕业时，我没有为了 500 元钱闹着要涨薪，仅仅是因为觉得 500 太少，本质上还是以薪资为目标工作。但所幸，我的运气还不错：
+
+第一，我有一位足够年长的哥哥，他将成长经验分享给了我；
+
+第二，我有幸在 2008 年前后加入 IBM，遇见了一位非常好的 Leader，频繁的正向激励和反馈，是我转变的关键；
+
+第三，我患上了重度抑郁症，但幸运地走出了阴影，反哺了自身的认知和精神成长。
+
+怎么样，我的运气是不是挺好？不过你也别沮丧，如果你认真体味了这篇专栏，我相信你也能形成正确的认知，就像我从前在 IBM 获得的一样。**成功总是存在运气成分的，但学习成功的经验则不需要运气。**
+
+至于如何践行认知，对于每个人来说，都有所不同，我无法给出标准答案 —— 你肯定不愿意像我一样患上抑郁症吧？这样的学习成本未免太高了。
+
+我常常说，工作的秘诀是“认知到位，彪悍执行”，此时也一样。**如果你相信我，希望你能带着这份认知做到“彪悍执行”，为了践行它而“无所不用其极”**。你可以做一名精神胜利的“阿Q”，欺骗自己、给自己洗脑、将薪资选择性遗忘、拒不参加有攀比成分的同学会，等等。只要让自己形成正确的认知，就是取得了最终的胜利。
+
+我们始终在强调认知，因为认知实在很重要。至少此时你应该理解：当马云说自己对钱没兴趣时，并不是在装圣人，而是客观描述了自己当时的心态。可能你还是会忍不住反驳：“没兴趣还赚那么多钱？没人不爱钱。”
+
+也许你是对的，但那并不重要。重要的是一个人自己是否相信，工作并不是为了赚钱——这是形成正确认知的路径之一。
+
+当然，不计较薪资，和对公司抱有“愚忠”还是有区别的。如果你的收入压根没法养活自己，还是要优先考虑薪资。我们追求的是成长，不是把自己饿死。
+
+最后，希望你也能从这份认知中，收获成长的快乐，我们下一讲再见。

极客时间专栏/geek/乔新亮的CTO成长复盘/对个人认知的复盘/03 | 看透本质：研发出了生产事故，到底要不要罚钱？.md

@@ -0,0 +1,104 @@
+<audio id="audio" title="03 | 看透本质：研发出了生产事故，到底要不要罚钱？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d5/9e/d57a1475c98c4f7e4a13de6e407c499e.mp3"></audio>
+
+你好，我是乔新亮。“本质”这个词现在已经烂大街了，我看很多的公众号文章，动不动就说本质、底层原理，这也侧面说明我们每个人面对复杂问题时的心态：我们想直击问题的关键点，找到问题背后的本质。
+
+但，你我也都知道，看透本质终归是一件很难的事。昨天我就还遇到一件让我自己头疼的事情，思考很久之后，还是没有找到好的方法。当时，我就扪心自问：我有没有看清楚这件事的本质？
+
+我小声告诉自己：还没有。但就同样这件事情，相比数年前，我有没有进步？我自认进步还是很大的，做决策的成功率也越来越高。
+
+所以，今天我想和你聊聊，我们应该如何看透问题的本质。
+
+## 一项制度引发的思考：研发出了生产事故，要不要罚钱？
+
+如何看透问题本质？这问题对我来说，更像是一项可以通过长期训练而习得的能力。我从很早开始，就试图搞清楚各种问题背后的本质和根源，但印象最深刻的一次实践，始于 2014 年。
+
+从那一年开始，我接手了苏宁集团的“双十一”保障任务。到  2019  年，苏宁大概存在 4000 多套系统、1 万多名研发人员，日高峰发布接近 4000 余次。面对这个庞大的系统，你可以想到，任何一个细小的动作都可能引起研发事故，我要思考的是，怎么保证“双十一”这种大型促销日系统不出问题。
+
+很难。我查了下历年的复盘文档，发现不管前期准备得多么严密，双十一当天总是会有意外发生。
+
+如何保证大型电商企业“双十一”服务的高可用性，这是个高复杂度的系统性问题，在极客时间上已有很多专家给出了答案，但这些解决方案不是我们今天要讨论的重点。今天我们只谈其中一个微小但十分重要的分支：**虽然技术部门准备得十分充分，但线上还是出了事故，要不要针对主要负责人罚钱？**
+
+保守地说，业内起码 90% 的企业都会罚钱。原因很简单，线上出事故，领导认为根本原因是负责人不够认真、不够投入，出了事故就应该承担责任。你看，这个观点里，事故发生，是现象；负责人不够认真，是本质。你是不是觉得逻辑很清晰？
+
+一开始我也是这么做的，并未觉得有什么不妥。直到有一天，团队一个技术负责人找我谈心，他说：“老乔啊，你这制度设计不合理。多做多错，少做少错，不做不错，你这是变相鼓励团队少做事。”
+
+我一愣，觉得这位负责人说得有些道理。因为，对于大促这种高并发的场景，最容易出问题的往往是最核心的模块。相对来说，一个边边角角的简单系统，就不那么容易暴露问题。
+
+试想一下，一个能力很强的人，包揽了团队最重要、最累的工作，结果出了问题反而被罚了 3000 块钱；一些庸才付出得相对较少，一个月安安稳稳的，反而一分钱没扣。这个逻辑显然是有问题。
+
+于是，我对这件事的本质认知开始动摇，但压力也随之出现：出了事故就罚钱，好像不太对劲；但如果不罚钱，那团队是不是就会因此松懈下来？我喜欢看兵法，打了败仗，部队里可是要问责的，这罚钱肯定是问责最直接的方式了。
+
+这时，我意识到，关于“研发事故的处罚措施”这件事，有必要重新思考其背后的本质问题。如果管理者只会罚钱，大概率是在将压力转嫁到一线人员身上。
+
+## 问题本质的追寻之旅
+
+我并不相信一句“多做多错，少做少错”，就能概括问题的全貌，最好还是广开视听，交叉验证一下。
+
+所以，我很快找到公司的 HR 部门聊了聊，HR 同学惊讶地说道：“话不能这样说呀！核心部门虽然容易出现事故，压力比较大。但他们的奖金额度高，薪资水平也普遍高于其他部门，升职机会也更大。”
+
+听起来也有道理，好像被处罚的员工也并非单纯的“受害群体”。围绕这个问题继续思考，我很快发现：出了事故就罚钱，这与自己提倡的有些企业文化也是相违背的。
+
+比如，我鼓励“勇于试错”，动不动就罚钱，那谁还敢试错？我提倡“团结紧张严肃活泼”的团队氛围，在这种制度下好像也很难实现；一旦开始罚钱，事故所牵涉的部门就会开始互相推诿，团队协作和氛围就会出现问题，这也不是管理者们希望看到的。
+
+这时候，我停下来，又推演了一下惩罚制度设立的初衷。它不是为了“恶心员工”，克扣工资；而是尽量保证同一个问题不要再犯，或者说，降低犯错的次数。
+
+在大型企业，一个 CTO 级管理者因为位置太高，很容易脱离实际的生产情况。如果不做深入观察，CTO 可能会气恼地发现：IT 部门根本就是不停地犯错！只有当他深入追查问题来源时，才有可能意识到：发生在核心业务上的生产事故，往往涉及多个部门、多个团队，实际情况常是 A 部门刚刚犯错被罚了钱， B 部门又犯错了；B 部门被罚钱没多久， C 部门又犯错了……
+
+其根本问题在于，A 被罚了钱，并不能让 C 免于犯错，甚至也不能让 A 保证不再犯第二次，反而让所有人胆战心惊。
+
+综合所有了解到的情况，我们很容易就能得出结论：罚钱确实让员工更重视问题了，但并不能在本质上解决问题。
+
+最后，我又换位思考，也问了问自己：“老乔，换做是你自己，你能不能保证 100% 不出事故？”答案当然也是不能，尽管我对自己的工作能力和责任心都很有信心。
+
+至此，我终于得出结论：**生产环境出现事故，与员工的责任心和能力没有绝对因果关系，故而不能靠单一的惩罚条例，其背后本质，是管理者是否能够体系化地解决问题。**
+
+从罚钱到不罚钱，在我眼中，变化的是对问题本质的理解。当然，我也围绕新的认知制定了许多相应的体系化措施，包括：
+
+- 一个事故要有七个改进点：每个改进点保证 100% 不重犯；
+- 犯错的人负责牵头落实复盘，分享失败的经验；
+- 解决问题的手段产品化，人会犯错，但产品不会犯错；
+- 允许每个人犯错、试错；
+- 根据事故统计定期颁发“烂草莓奖”和“金苹果奖”；
+- 管理产品化、系统化、数据化。
+
+一旦对问题本质形成了新的认知，解决方案就会自然而然地涌现出来。在新制度下，事故系统的当事人不会再受到金钱上的惩处，但很可能会收到“烂草莓奖”，激发团队的荣誉感和责任担当。
+
+到此，我仍然不能确定自己真的抓住了问题的本质，因为所有结论都需要谨慎验证。
+
+所以从苏宁到环球易购，再到彩食鲜，几年间，我围绕新的认知，开始灰度实施“不罚钱”的体系制度，其间不断针对实施效果复盘，看看哪里还能迭代，哪里还能精进。到今天，我可以放心地说，新的认知结合新的制度，确实起到了不俗的效果，极大降低了事故发生率，团队的士气也很好。
+
+## 经验抽离：看透本质这件事，究竟难在哪？
+
+好了，以上就是我在面对“生产环节出现事故，要不要罚钱”这一问题时，探寻本质的过程。其中，我发现有几点对结果尤为关键。
+
+**第一，大胆假设，小心求证。**
+
+探寻问题本质，为的是指导自己进行决策，更好地解决问题。你一定要注意这个前提条件，不能漫无目的地脑洞大开。在此前提下，大胆假设，提出自己的观点自然成为推演的开始。
+
+有了假设，下面就是结合具体情况进行验证，如果基于假设的处理方式和其他一些管理理念有冲突，那说明假设需要完善。直接在金钱维度对下属进行处罚，与许多正确的企业价值观和理想氛围相冲突，这是我进行再思考的重要依据。
+
+**第<strong><strong>二**</strong>，刻意练习自己的思辨能力。</strong>
+
+日常的学习积累很重要，再厉害的百米冠军，也要从走路开始学起，平时你可以通过学习来培养自己逻辑分析、数据分析的能力。这里我推荐两本书，一本叫做《数据化决策》（**道格拉斯 · W · 哈伯德 著**），一本叫做《深度思维》，尤其是第一本书，对我影响很大。
+
+另外，你也要刻意练习自己的思辨思维，之前我看过一句话说，“思辨能力的缺乏，是一种新的无知”，深以为然。比如说前面我举的研发事故的例子，其实就是典型的思辨能力，罚钱的时候，有人提出“干的多错的多“，那你能不能思辨的去看这事，而不是非得别人提醒才行？
+
+同样，和同事讨论问题的时候也是，上周我们在分析某个业务问题的时候，有同事说因为销售做了某件事，所以营收一下子有大幅增长。我当时就警觉性地问他，那为啥上上周销售也做了这个动作，但是收入上却没有变化呢？一番讨论之后，我提醒他说，那两件事情看着有联系，但其实只是先后顺序关系，而非因果关系。
+
+你看，这就是一次思维练习。我在工作中，经常提醒自己，要有思辨能力。
+
+**第<strong><strong>三**</strong>，**<strong>相信**</strong>所有的问题都可以被解决</strong>。**如果不能解决，那一定是自己认知没到位。**
+
+这还是一句需要辩证看待的话，你可能会说，“老乔，吹牛，你给我上个天试试？”
+
+是的，客观上说，人的能力有上限，而问题是可以无穷大的，这也是我们常说的要有敬畏之心。但从成事的角度来说，我更愿意把所有的问题都归结于自己，所谓“行有不得，反求诸己”。
+
+很多时候信心很重要，遇到问题，探寻本质的过程中迷惘很正常，不要着急，相信真相就在那里。感受、思考、总结、验证，循环往复，只要不放弃探寻，本质一定会有一天浮出水面。
+
+说了很多，其实还是挺抽象的。没办法，咱们聊的就是一个抽象的话题。那么，我再问问自己，**看透本质这件事，究竟难在哪？**
+
+我认为，最难的是坚持，这是真正的门槛。从质疑研发团队的处罚措施，到得出新的结论、建立新的认知，并没有占用我太久的时间，但接下来的几年间，我都在不同的公司内对所思所得进行实践、验证和复盘。这是一种时间上的连续投入，很多人都没能做到。大家往往习惯了草率下结论、草率验证，并对待调整的部分不闻不问，错便错了。
+
+作为一种能力，其本身也需要长时间的锻炼。关于研发事故的思考，只是众多事例之一。个人发展，需要看透本质；企业发展，需要看透本质。事事都需要对本质内涵的洞察，都需要不断重复以上五步。实践过程大概率是苦兮兮的，纠结、疲累，一点都不高大上，在认知上的推翻重建时有发生。在时间的维度上，其跨度可能长达十年、二十年，乃至终生。
+
+对于我本人来说，苦归苦，但也乐在其中。如果你也想学习看透问题的本质，并愿意站在时间的宏观角度验证它，不妨从现在就开始实践。若在实践中遇到困难，欢迎在评论区提问、讨论，我相信，交流能创造更大的价值。

极客时间专栏/geek/乔新亮的CTO成长复盘/对个人认知的复盘/加餐（一）| 大学毕业，我要不要留在一线城市互联网公司？.md

@@ -0,0 +1,77 @@
+<audio id="audio" title="加餐（一）| 大学毕业，我要不要留在一线城市互联网公司？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/85/01/8563216331a637de68eaa8e630516d01.mp3"></audio>
+
+你好，我是乔新亮。前面我们聊了许多有关职业发展的基础认知。在加餐部分，我想将这些认知串联起来，回答一些在成长中，你可能会实际遇到的问题。
+
+前段时间，我和团队内外许多年轻的同学们聊了聊，大家都在讨论“那位28岁退休的字节跳动程序员”，还引用了网络上比较火的一个词，叫做：“逃离北上广”。几番思量后，一些刚刚毕业的同学干脆问我：“老乔，我到底要不要在北京/上海/深圳工作？我要不要入职国企？感觉互联网公司太累太辛苦了，并且35岁以后，还可能被淘汰。”
+
+嗯，其实有这种顾虑很正常，说心里话，选择二线城市或者回老家工作，我觉得也挺好。每个人的人生理想都不太一样，获得幸福的方法也是千差万别，但“007”确实很苦，这倒没什么争议。
+
+关键在于你自己有没有想清楚：如果“逃离北上广”，得到了什么，放弃了什么？留在北上广，得到了什么，放弃了什么？若干年后，得失有什么变化？你真正想要的是什么？**无论在哪，能过得开心真的很重要。**
+
+从毕业开始，我就选择留在一线打拼，这点从没犹豫过。刚毕业的时候留在北京，是很自然的选择。后面有压力的时候也没有想过退却，主要是因为在这里真的能认识很多优秀的人，能够从他们身上学到很多东西，持续让自己进步。
+
+我也有朋友毕业后选择回到老家，客观来讲，生活的确实很舒适——早早买了房和车，结婚生了小孩；每天很早就下班了，接孩子回家，还能打打羽毛球。怎么样，很惬意吧？
+
+但有时深入聊天，我也能察觉到他未必是真的开心，至少不像我们这些看客设想的那样——这样的日子让你看是一回事，如果亲自去度过就是另外一回事了。当一个人在二十几岁就无所事事，开始不断重复接下来很多年的每一天时，有可能很难真正开心起来的，至少我会无聊透顶。
+
+也有人想，毕业选择回老家，以后想去一线城市工作的话，再做打算呗。
+
+但以我个人成长、团队建设和人才培养的经验来看，从老家回归北上深的难度是有点大的。一线城市更像一个平台，留在一线城市，你会随着城市的上升而一同成长，这是大环境的惯性 —— 你能遇见更多的值得学习的人，抓住更好的成长机会，这种力量是很强大的，有句话讲的好，“与智者同行，你会不同凡响”。
+
+在北京工作两年，和在一个小县城工作两年比，成长幅度能一样吗？当你的成长速度日复一日地落后于他人，其实就已经在同台竞争中处于天然的劣势。
+
+我也设想过未来退休后的日子：在保证父母、子女生活条件的情况下，买一辆房车，一边周游世界，一边写写书。但在当下过这种日子，还是不想的，还想在年轻的时候做些更有挑战、更有价值的事情，毕竟什么时间做什么事，该快的时候快， 该慢下来的时候再慢下来。
+
+**这就是选择的权利。**
+
+反过来我们要问问自己，如果选择留在一线城市，意味着什么？任何事情都是有好有坏，不能只要好处，不要坏处。
+
+首先，必须得承认，确实苦、确实累、有压力，但这很正常，一旦你下定决心，就要时时刻刻告诉自己，这是我自己选择的道路，再怎么苦、再怎么累，都是自己选的。
+
+**有心的同学会注意到，从「认知复盘」这一章开始，我其实一直在提一个“隐藏”建议：人一定要在认知上将自己解脱出来——辛苦是相对而言的，身体累不可怕，心累才可怕。**其实我现在每天也很辛苦，早上 6：00 起床，一个小时后离家去单位；现在已经快晚上 10 点了，如果不是为了制作这篇专栏稿件，我应该还在工作。
+
+但我心里并不觉得累，因为我知道自己选择的路本来就不容易走，都是为了最快的成长。
+
+现在我们经常听说：996、007、大小周，让人愤怒、委屈、沮丧。如果你没有能力去改变公司制度，或者离开这家公司，就只能努力调节自己。这种负面情绪的核心在于，你认为自己是被迫的：我被迫执行 996 加班、大小周规定；我被迫接受了一项高难度任务，以至于每夜睡不着觉……
+
+其实你可以选择更轻松的城市、更轻松的工作，甚至部分同学可以啃老不工作，但你没有。如果你选择留在一线城市，就决定了自己的生活一定是充满挑战的，没有人强迫你。成年人，所有的决定，都是自己做的。如果你觉得焦虑、压力大，不妨如此告诫自己。
+
+那么话说回来，选择留在一线城市，要受这么多苦，究竟是为了什么呢？有人说是为了钱，我觉得更多是为了成长。
+
+如果你觉得是为了钱，那就给自己埋下祸根了。前面我们讲过，2009年的时候，我得了抑郁症，真是很痛苦，现在去看，部分原因就跟房贷压力有直接关系。
+
+你肯定也会想，工作最初的目的就是为了赚钱，你让人家不要为了钱工作，不是坑人吗？
+
+如果用人才梯队建设的视角来看待职场新人，应届生、3年左右工作经验的程序员都属于人才资源池里的鱼苗，薪资差个 500、1000，其实意义不大。多久能跳出资源池、多久能迈上职业生涯的下一个平台，才会真正影响你未来的钱包大小。
+
+如果单从钱够不够用的角度讲，说句难听的，谁还能饿死呀？开个玩笑，天天吃鲍鱼做不到，一个月吃一次行不行？一月一次做不到，一年吃一次行不行？（虽然我觉得鲍鱼根本就不好吃，还不如面条好吃）
+
+如果将时间倒回 2002 年，如果今天再让我选择一次，我仍然会选择继续拼，但我的状态可以更好，更多的去关注自己能力的成长，关注做事的机会，这样可以让自己少很多痛苦，希望你也能早早提升自己的认知高度，不要像我一样走弯路。
+
+这里我们提到了，留在一线城市的关键目的是为了成长；成长的关键又是什么？我认为是做事，坐在那里担心解决不了任何问题，今年有个流行语叫躬身入局。
+
+道理很简单，不在工作任务里实际锻炼，你怎么成长？**猛将发于卒伍。**
+
+很多的企业，你也清楚：稳定、轻松，老一辈人喜欢叫它“铁饭碗”。但你好好想一想，短期的稳定、轻松，长期看来就是最大的变数啊。而且这样的变数，一旦发生了，就会天翻地覆。一直追求稳定的工作，最后不稳定；不断追求挑战，在动态、压力中寻找的稳定才是可靠的稳定，这点和架构设计里面追求高可用、高可靠要基于为失败设计的理念有异曲同工之妙。
+
+**因为环境过于放松，没有逼你做事，逼你成长。当变故发生时，你不具备应变的能力和在变局中存活的实力。**
+
+我确实认识一些传统行业的 CTO、CIO 朋友，在度过了行业的黄金时间后，企业已经不能再靠过去的资源优势获得足够收益了，导致很多CIO/CTO面临着职业生涯的危局。
+
+这类案例并不罕见，它们只是在重复一个简单的道理：处在激烈竞争的生存环境中，如果不成长，就只能被淘汰。
+
+## 结语
+
+我们来总结一下，毕业后要留在一线城市，还是回归小城市？
+
+这要靠自己思考，站在整个人生的宏观视角上，以数十年为尺度，你究竟想要什么样的生活？
+
+如果选择留在一线城市，不要单纯为了钱，而要为了成长。因为在职业生涯初期，薪资的差距很小且是能力的附属物，只有跳出人才梯队的资源池，钱包才会真正鼓起来。
+
+成长的关键是做事，做事就会有挑战。要时刻提醒自己：没有所谓的不公平、没有克服不了的压力，都是为了自己的成长。
+
+听完这些，有的同学可能会问，老乔，我也不知道我真正想要什么，怎么办？
+
+我建议你，如果看不透，可以去多多找人交流，和同学、朋友、老师、亲人，都可以，不要藏着。但最终，决定权还是属于你自己，只有你自己才能决定自己的生活。
+
+希望你能做出顺从本心的选择，坚定的走在人生之路上。

极客时间专栏/geek/乔新亮的CTO成长复盘/对个人认知的复盘/加餐（三）| 选择决定上限，努力决定下限.md

@@ -0,0 +1,121 @@
+<audio id="audio" title="加餐（三）| 选择决定上限，努力决定下限" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c8/80/c823b4177c24e52dcd9b74e4a2c35680.mp3"></audio>
+
+你好，我是乔新亮。
+
+作为专栏第一章的结尾，这一讲其实是临时增加的。你能看到，在原本的目录里，并没有关于这一章的撰写计划。
+
+为什么要这样做呢？因为在上一周的更新里，很多读者给我留言，深深地触动了我。我意识到，也许你，以及很多同学，对成长的认知都仍有偏差，我需要更充分地、更深入地和你聊聊。
+
+让我印象深刻的是一位女同学，她刚刚毕业，为了解决北京户口，放弃了亚马逊、拼多多等一线企业的工作机会，入职了当下这家公司，但她很快发现，这家企业的现状远不如老板描述的那般美好。在其中，她很难获得个人成长，只是薪资很丰厚。她的问题是，是该立刻离职呢？还是先自学两年，再考虑离职呢？
+
+结合我们前几篇文章传达的认知，你可以先花 10 秒钟思考一下，应该如何选择？然后将答案保存在心里，我们等等再谈。
+
+还有一位男同学，大概已经毕业了十年左右，年过三十。在某段时间，突然感觉到强烈的中年危机以及职业生涯危机，非常焦虑、惶恐，感觉目前得不到重用，也无法成长，不知道该怎么办。
+
+同样，花 10 秒钟思考一下，你觉得他应该怎么做？然后将答案保存在心里。
+
+下面呢，我想聊聊自己的成长历程和经验，供你参考。你可以对比下，听完我的讲述后，你心里的答案是否有了变化；你自己的成长难题，是否得到了解答。
+
+## 一个基础但非常重要的认知：选择决定上限，努力决定下限
+
+在讲我自己的故事之前，我想先快速谈谈一个比较基础的认知：「选择决定上限，努力决定下限」。这是什么意思呢？
+
+前面我们讲了，工作是为了成长，五年要上一个台阶，这是大的目标。至于到底是四年半，还是五年半，这并不重要，关键是要确定一个量化的目标。
+
+但如何实现目标呢？努力是必须的，但还不够。努力是让你在当前台阶上，夯实能力，不断向上成长。当你走到下一个台阶前的时候，就需要做选择，让自己上台阶，打开自己的上限，继续成长。
+
+你想想看，如果不努力，你是不是连跨台阶的机会都没有？反过来，如果你努力了但不跨台阶，成长就会停滞，慢慢变成一个闲人。
+
+一些公司上市，造就了一批亿万富翁，就是一个很典型的例子。如果你不努力，就通不过这些公司的面试，即便通过面试了，也和股权没什么关系；如果你很努力，但你没有跨台阶，那么今天的上市，可能依然和你没什么关系。
+
+努力和选择，二者相辅相成，呈螺旋式上升。
+
+到这里，概念都很好理解，没什么问题，但还不够全面。你得知道，**选择不<strong><strong>只**</strong>决定了上限，还要拥抱不确定性；而努力不但会决定下限，还要负责将“不确定性”变成“确定性”。</strong>
+
+现在是不是就有点绕了？别着急，下面我讲讲自己的实际经历，帮你更好地理解这个概念。
+
+## 选择需要勇气，而勇气的来源是努力
+
+2015 年离开 IBM 的时候，我和唐青（ IBM 全球企业咨询服务部大中华区副总裁、高级合伙人），在望京聊到了凌晨 1:00。
+
+到今天，我还是非常、非常感激唐总，当年在 IBM 特别赏识我。她给我开出的条件是：如果不离开 IBM，可以考虑 IBM GBS CTO 的职位；如果想去南京的话，可以特批去南京工作，专门服务苏宁客户，还能得到一笔很大的安家费；部分偏销售的工作我可以不做，专注做架构、技术管理……
+
+条件好到让我觉得自己有些忘恩负义，真的是这种感觉。你不能要求一个 Leader 做到更好了，她几乎解决了你的一切后顾之忧。
+
+但那时候我想得很清楚，后来我也常常和人讲：**我觉得 2015 年是外企在中国的衰退元年**。当时这个趋势体现得非常明显：外企在中国市场开始四处受限，发展不顺；中国民营企业高速崛起……
+
+另外，在 IBM 我逐渐达到了成长的瓶颈。在一家远离总部的外企，我很难去对公司的发展贡献更大的力量，自己当然也得不到更大的锻炼。
+
+所以，我还是决定离开 IBM。你可能在想，老乔，挺厉害，抵住了许多诱惑。但夸归夸，你受到的启发也很有限，对不对？这听起来像是一个在钱和成长之间二选一的故事。
+
+但现实生活哪有这么简单呢？我从北京去南京加入苏宁，不仅仅是成长的问题，也是拥抱了巨大的不确定性 —— 这是一个极其艰难的决定。
+
+首先，入职前，我并不能非常确定苏宁一定适合我，或者我一定适合苏宁，万一试用期都没过呢？这是有可能的。
+
+另外，我一直觉得，不管工作地点变到哪里，一定要和家人在一起。所以从北京到南京， 不是一场关于我的个人冒险，而是兴师动众的举家搬迁。我清楚地记得，我是 2015 年 5 月 12 号入职的苏宁，我们全家是 6 月 7 号搬到的南京，包括我的爱人、两个小孩、岳父母，还有两个北京的保姆。我岳父岳母刚到南京就说气候不习惯，打算回天津（老人是天津人）。
+
+你看，除了工作，背后还有关于生活的一大堆事等着你去解决。这不像换工作，反倒有点像背水一战，做这样的选择该有多煎熬？
+
+**我能做的只有努力，努力去做好在苏宁的工作，努力去解决生活上的问题。选择苏宁，预期是好的，但结果是不确定的，我必须努力把这种「不确定」，变成「确定」，别无他法。**
+
+事实上我也做到了。我在苏宁发展得非常好，也再次抵达了成长的瓶颈。
+
+后来从苏宁到环球易购，情况也比较类似，我就不再展开谈了，可以和你简单聊聊：
+
+苏宁对我也非常、非常好，当我要离职时，不单是在苏宁的同事吓了一跳，我自己也吓了一跳：我儿子在南京念的是全市最好的琅琊路小学；我在苏宁职位高、薪资高、社会地位高，几乎有了在苏宁退休终老的感觉；同样，去环球易购就意味着远赴深圳，又是一次居家搬迁，从华东到华南……
+
+当时，我给自己订下的目标有两个：
+
+1. 将影响力从平台层面转移到个人层面。比如，我希望大家能因为我是乔新亮而找我帮忙，并非因为我是苏宁科技的副总裁；
+1. 主导参与一家公司业务高速发展的过程，实践技术领导者如何帮助业务成功。
+
+于是，就像你看到的，经历了辗转反侧的痛苦思考后，我还是下了决心，离职去了深圳。
+
+你可能会想，老乔你是想要什么就能得到什么啊，你的选择都成功了，我不一样。
+
+其实不是这样的。在环球易购，我的目标只达成了一半：关于个人影响力，我实现了预期目标；关于企业发展，因为一些原因，则没有完全达成。如果你关注「雪球」一类的市场资讯网站，可能会了解我的情况，这里我们就不细说了。
+
+所以，选择、努力，说起来简单，可并不能总是马到功成。但从我个人的角度讲，这像大道理一样的东西比任何“成功学鸡汤”都管用。选择不确定性很痛苦，但那是为了更长久的成功，人无远虑，必有近忧。
+
+## 关于两位读者的热心提问，我的答案是什么？
+
+我的故事讲完了，现在，让我们回到这一讲的开始，关于那两位同学的提问，你还记得自己心里的答案吗？
+
+那位女同学的问题，看起来好像很复杂、很难回答，但我觉得答案其实很简单：如果不能成长，要果断地选择离职。考虑好两个条件就可以去了：
+
+1. 平台有做事的机会；
+1. 有一个好经理愿意带你。
+
+为什么呢？选择一定是需要勇气的，需要面对不确定性的，还需要为选择做准备，选择后再努力。你能看到，我为了成长放弃了许多当下的利益。但在这个案例里，其实我觉得，这位同学付出的代价已经很小了，毕竟是刚毕业，户口也拿到了。两年后、五年后，你还能同当初入职拼多多、入职亚马逊的同学竞争吗？
+
+千万不要因为一个小小的决策失误，就把自己的前途给废了，这是我的个人看法。
+
+对于那位男同学的提问，说起来不复杂，做起来有难度。答案是先调研市场需求，再做能力储备，然后决定是申请调岗还是换公司。
+
+可能你看了我的专栏，觉得很受启发，想着：乔老师（乔大哥/亮哥……发现大家给我发明了好多种称呼）说了，一定要注重成长，我要跳槽！
+
+但一定要注意，不是所有人跳下海都能活下来，有些情况会直接“淹死”。比如对于许多向我提问的、有多年工作经验的同学，不要盲目跳槽，先问问自己：能力储备做好了吗？如果没做好储备，千万别跳槽。
+
+当然，你也别焦虑，相信我，真没啥可焦虑的。你就安下心来，认真调研市场需求、好好学习，评估个人能力的时候多和别人聊聊，问题一定能解决。要相信，自己是能成长的。
+
+## 结语
+
+其实，我觉得今天这一讲太重要了，可以说是我们整个专栏的主线之一。我建议你对照自己的经历，好好复盘一下。复盘时，有三点思考上的偏差，一定要留意：
+
+1. 我们专栏的名字叫做「乔新亮的 CTO 成长复盘」，那么什么是成长？从主观角度，你可以理解为“做选择-&gt;努力-&gt;再做选择”这一过程的循环，成长真的太重要了；
+1. 选择不是件简单的事，如果让我形容，那就是煎熬。但是即便再煎熬，也要做决策，不能逃避，要敢于拥抱不确定性，冷静地做好风险控制和分析；
+1. 不是「选择」之后就万事大吉了，**要努力将自己的选择，变成真正对的选择**。上台阶很重要，但要小心被别人一脚踹下去。
+
+前面，我几乎聊遍了自己职业生涯的十年经历，包括在三家公司工作故事：IBM、苏宁、环球易购。
+
+不知你有没有注意到一个特点：**我从来没有因为讨厌一家公司而离职**。
+
+不管是在这些公司工作，还是选择离开的时候，我都心怀感激。很多朋友在给我留言时，那种委屈是溢于言表的，我觉得这不好，主要是对你自己不好。诚然，当公司没办法满足你个人的成长诉求时，确实会有矛盾出现，具体到当时情境的某一天、某一周，我也不是没有情绪的。
+
+但时间一长，我就会恢复一个比较平和的心态，因为我能理解公司、理解 CEO。每一家公司在特定阶段都有其难处，就像大家谈恋爱一样，没有完美无缺的对象。如果确实不合适，跳槽就好，这是个理性决定，绝对不是个情绪化的决定。毕竟是这个公司给你发了薪资，是自己的衣食父母，还提供了机会让自己锻炼、成长，常心存感激，会容易快乐！
+
+如果你也能这样去想，我相信你的路会越走越宽，而不是越走越窄。
+
+我衷心希望，这一讲能解答你的许多困惑。如果还有不懂的问题，欢迎继续给我留言。只要时间允许，我都会尽量回复你。
+
+另外，如果你觉得这些内容对你有帮助，欢迎转发文章到朋友圈，我和专栏编辑敲定的 KPI 是：订阅数突破 30,000 ，找到更多的“同路人”，也发现那些需要帮助的人。

极客时间专栏/geek/乔新亮的CTO成长复盘/对个人认知的复盘/加餐（二） | 工作遇到不懂的问题：何时可以求助，如何正确提问？.md

@@ -0,0 +1,105 @@
+<audio id="audio" title="加餐（二） | 工作遇到不懂的问题：何时可以求助，如何正确提问？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/37/yy/3798803695383a35d04b4c00160be3yy.mp3"></audio>
+
+你好，我是乔新亮。上周末，咱们专栏编辑找到我说，有一位 2020 年毕业，刚刚入职两个月的热心读者正被一些问题所困扰，希望征求下我的意见。
+
+问题大致如下：工作时，经常遇到不懂的事情，大部分是技术相关的问题。想要提问，却不知道什么问题能问，也不知道怎么问比较好，担心别人因此质疑自己的工作能力。长此以往，工作效率低下，有时整整一周，手头的项目都没有进展，领导问起来都不知道该怎么回答。
+
+我看了之后有些感慨，技术新人刚刚离开学校，有这些困惑很正常，因为提问终归是一件很麻烦的事儿：你一定不想问些过于简单的问题，那样会被人看低和讨厌，是基本能力匮乏的体现；但又不能不问，迟迟解决不了的问题，会让你在周会上更加尴尬，对个人成长也大有影响。最好的情况是天生牛人，3 岁就会写代码，独立解决一切问题，但这不可能。
+
+类似问题又不一定是“初学者”才会遇到 —— 我曾遇见过许多“不会提问”的人，他们有的是程序员、架构师，有的是技术经理、技术总监，几乎遍布整个职级体系。令他们疑惑的可能不是技术问题，但“不会提问”的本质却始终没有改变。
+
+因此，在争得当事人同意且不泄露隐私的前提下，我想基于这些年来的所见所闻，谈谈自己的看法和心得。
+
+## 我麾下的管培生如何提问
+
+遇到什么问题可以求助，如何更恰当地提问？我认为，原则上讲，任何问题都可以用任何方式提问。这里没有法律规定或道德限制，每个人的行事风格也不同，并无对错。就像邓小平同志说的，不管黑猫、白猫，捉到老鼠就是好猫。
+
+但无论是我自己，还是我所认识的技术大牛、技术管理者，都比较讨厌不加思考、张嘴就问的人。我们不妨换位思考一下，如果是你自己频繁遭遇这种情况，情绪上的不耐烦倒在其次，更深层的感受是：自己的时间和精力都没有得到尊重。
+
+至于那位同学所说的，“整整一周都没有进展”，又有点矫枉过正。**根据我的观察，如果技术新人花了一整天都没解决掉一个问题，那么大概率就是解决不掉了，要及时提问，避免造成项目延误。**
+
+那么答案就呼之欲出了：工作遇到不懂/不会/不明白的问题，一定要提问，但要思考之后再问。
+
+这里就涉及到两个关键点：提问之前如何思考，以及思考之后如何提问。2015年-2019年，我在苏宁担任技术副总裁，期间曾经带过一名管培生做架构设计，他的提问就让我印象比较深刻。（注：**管培生，即管理培训生（Management Trainee），是一些大企业自主培养企业中高层管理人员的人才储备计划。通常是在公司各个不同部门实习，了解整个公司运作流程后，再根据其个人专长安排。**）
+
+刚入职时，他的提问技巧也比较初级，因为我总是会反问他：关于这个问题，你是怎么想的？为什么要这样思考？如果答得不好，我就会批评他。
+
+几次三番后，他逐渐养成了比较优秀的提问习惯：
+
+1. 永远带着白板和白板笔，随时准备将别人的答案融入自己的体系内；
+1. 半汇报半提问，提问一定带有属于自己的观点；
+
+最重要的是，围绕架构类的工作内容，他学会了按照固定的模式提问：
+
+1. 当下有哪些待决策的问题，影响了哪些业务？
+1. 谁或哪个部门提出了这些问题？
+1. 其他人有哪些解决方案上的建议？我们认为存在哪几种方案？
+1. 方案一、方案二……分别有哪些优势和劣势？
+1. 我们建议选择哪种方案，会带来什么样的影响？
+
+对于架构师来说，这其实是个经常用到的标准模板。而后，如果中间某一步出现模糊、不确定、不理解的情况，才是提问的正确时机。
+
+以上关于架构方案的提问，没接触过的同学可以再琢磨琢磨：这些其实是将做技术决策需要经历的思维步骤细化，并公示出来了，这就是思考的样子。如果更进一步，脱离架构问题的限制，上升到更高、更广的维度，你或许就能学会如何正确提问。
+
+## 思考是提问的绝对前提
+
+对于绝大部分技术问题，在横向维度上，我自己一般会按照如下步骤去思考和做决策：
+
+1. 将复杂问题拆解成足够细化的模块；
+1. 针对每个模块，判断自己是否有足够能力实现；
+1. 根据拆解情况和实现方式，制定一种或多种技术方案；
+1. 对一种或多种技术方案进行快速而谨慎的验证；
+1. 用财务思维考量技术方案背后的成本和效益；
+1. 对技术方案的选择、实施进行决策。
+
+在垂直维度上，各个步骤的难度又有所不同，我一般将其分成三大维度来理解：
+
+1. 初级问题：一般都是纯粹的技术实现问题，只是复杂程度不同；
+1. 中级问题：复杂度上升，开始涉及到多模块、多业务部门甚至是跨公司的协调，一般需要经历立项会；
+1. 高级问题：需要协调多方资源，站在公司整体层面，为公司利益负责而解决的问题。
+
+随着难度、复杂度从初级到高级的提升，思考的步骤和难度也有所变化。比如，对于初级问题来说，拆解的过程并不复杂，技术方案相对单一，涉及财务思维的考量也较少；从中级到高级，各个步骤的难度都在大幅提升，前文我提到的管培生同学的提问，就属于中级问题。
+
+另外，许多技术人晋升管理岗后，感觉部门间充满了推诿、扯皮现象，很烦。但这类现象的本质，其实是问题的复杂度上升了，协作环境没有突然变差，你只是缺乏解决问题的方式。
+
+当思维沿着上述步骤前进，就是思考，**在任何一步阻塞时间过长，都可以进行提问，这就是提问的时机**。换句话说，思考应当是提问的绝对前提，在没有经过思考的情况下，我是绝不会提问的。
+
+**提问时，要将你的思考成果和思维路径说清楚，这就是提问的正确方式**。比如你是怎么理解和拆分这个需求的？如何评估拆分后的可实现程度？具体是哪里出了问题？这样，对方会感觉你是有备而来，尊重他人的时间，不是伸手党，更愿意解答你的问题。
+
+不过，我个人很少在工作中询问基础技术问题，比如编程语言的问题、某个库或类的使用方法等。我建议大家也要尽量靠自己解决，用好搜索引擎和知识产品，很多问题是可以被勤奋解决的。
+
+## 夸赞、请客以及开会
+
+掌握了上面的提问方法，就能得到别人的诚心教导吗？以我的亲身经历和观察来看，意外还是经常出现。
+
+这类意外大多可以形容为“三言两语就被打发掉了”。对方有没有真心教你，其实提问者心里往往最清楚。可能是因为企业文化出了问题，或是因为大家都太忙了，总之，就是没人愿意认真解答你的问题。
+
+如果你刚刚走到思考的第一步，在问题拆分阶段就被难住了，愿意帮你的人可能就更少。原因也很简单：通俗地说，这等于你根本摸不到头脑，对工作任务完全没思路，教起来肯定也更麻烦。
+
+当然我们也不是完全束手无策，有一副见效慢但成本低的药方叫做：**成为“夸夸党”**，长期维护同事关系。比如，当你阐述完自己的思考，又得到了解答时，要适当地夸夸别人：“哎呀，我思考了这么久，你这么快就解决了，你太厉害了！”
+
+**更行之有效的方法是请客吃饭，维护好同事关系，适当地进行社交活动**。技术人往往不擅、不喜社交，其实特别吃亏。年轻时，我也从不主动请人吃饭，最近几年才意识到社交的重要性。
+
+当然，我从不觉得以上夸赞、请客都是虚情假意、别有用心。别人为了帮助你确实付出了时间，能够解答你的问题的人，确实要更厉害，那你为什么不去表扬表扬别人呢？
+
+另外，我觉得为了寻求知识而请人吃饭更像知识付费。许多朋友都还年轻，没什么社会资源，不能为他人提供更高维度、更有价值的利益交换，你能做的仅仅是请人家吃个饭。换个角度讲，年轻时，工资都不高，也别太在乎钱。除开孝敬父母的部分，剩下的为知识而付费有什么不好？
+
+如果有人指责你是在拉帮结伙、巴结领导，也不要太在意。**任何行为都可以被赋予各种意义，我相信，只要你内心确实以学习为目的，随着时间的流逝，事情一定会回到本来的模样。**
+
+随着能力的提升，**当你开始遇见中级乃至高级问题时，还可以通过召开会议来提出问题**。在会议上提出自己的思考，组织大家发表建议和想法，就技术方案进行讨论，是一种更有意义的学习和提问方式。
+
+当然，如果你认为他人应该为你解答问题，应该帮你跨过技能门槛，这一切是理所应当的，我也无话可说 —— 部分优秀企业确实具备这样的企业文化，乐于助人也确实是优秀的文化传统，张嘴就问也能过得不错，这是事实。
+
+但我不会选择做一个“伸手党”，至少这对个人成长极其不利。另外需要注意的是，如果你缺乏独立思考的能力，多半无法通过优秀企业的面试，谈何企业文化。
+
+## 结语
+
+说了这么多，我觉得有必要最后重申一下：世界上没有能够适配任何场景的标准答案。客观来讲，任何时候、任何问题都可以提问，甚至不存在合理性的问题。
+
+但我更愿意遵循以上提问方式：基础的问题自己解决，有难度的问题思考后解决，用为知识付费的态度来请人吃饭。
+
+因为这一切都有一个基本的前提：**将时间线拉长，站在整个人生的高度上， 用宏观视角看待当下。**
+
+当视角拔高，我发现这种提问思维对自己未来的职业发展大有好处，足以使自己受益终生；相反，他人的非议和金钱上的开销则不太重要，因为从长远看来，非议会消失，金钱的损失则微乎其微。
+
+希望这些思考也能对你有所启发，从而更快、更好地迈上人生的下一个台阶。

极客时间专栏/geek/乔新亮的CTO成长复盘/对管理工作的复盘/07 | 管理者最重要的三个任务（一）：组织调整到位.md

@@ -0,0 +1,162 @@
+<audio id="audio" title="07 | 管理者最重要的三个任务（一）：组织调整到位" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ba/de/bae17e4145b33eb6fae92ea0yy21eede.mp3"></audio>
+
+你好，我是乔新亮。欢迎来到我们专栏的第二章：**对管理工作的复盘**。
+
+在我身边，有些朋友技术很牛，别人调试了一个礼拜的 Bug，他三下五除二就搞定了；别人玩不转的高并发架构，他没用多久就设计完了。领导天天表扬，隔三差五还能给团队做个技术培训，很开心。
+
+接着有一天，公司组织调整，程序员成为了管理者，整个人就懵了：不知道该干嘛。有的人是天天写 PPT，其实内心觉得管理是个很虚的事情；有的人坐着管理者的位置，干的却仍然是写代码的活。不懂管理，这是初级管理者的典型问题。
+
+如果将视线拔高，你会发现，管理能力有些欠缺的技术总监、技术 VP，甚至是 CTO ，也都是存在的。我培养过许多技术总监，也经常收到猎头发来的“高薪求聘 CTO”的需求，说明当下在业内，仍然十分缺乏优秀的技术管理人才。
+
+确实，做管理者不容易，大家都是一步步走过来的。前面我们讲了很多次关于“上台阶”的认知，每次登上一个台阶，挑战都会很大，需要时间去学习和适应，这很正常。
+
+复盘这些年带过的精英团队、万人团队以及创业团队，我发现有一些知识，如果早一点掌握，能帮助快速搭建起关于管理的知识骨架，让你成长得更快、更系统。管理者需要做的工作很多，但如果只做三件事，会是哪三件呢？
+
+在我看来，有三大管理任务始终最为核心，最应该在团队内率先落地，分别是：
+
+1. 组织调整到位；
+1. 加强协同效率；
+1. 激发团队活力；
+
+你可能会想，这是不是过于简化了？要知道，做多容易，做少难，浓缩的才是精华，要学会将复杂的事情讲简单。
+
+而且，这三大任务并不是孤立存在、毫无联系的，它们相互促进，共同实现「促进业务增长」、「建立企业竞争壁垒」等几个主要目标，同时构成了一个企业 IT 能力建设的增长飞轮。下面，我们先来拆解一下这个增长飞轮。
+
+## 拆解 IT 能力建设的增长飞轮
+
+<img src="https://static001.geekbang.org/resource/image/93/29/934083db86162c46e0799510a538c529.png" alt="" title="IT 能力建设的增长飞轮">
+
+在这张图里，飞轮有四个“叶片”，其中「端到端的产品管理」、「增强协同-项目管理」以及「绩效与激励体系」部分，其实就分别对应着管理者最重要的三个任务。在“飞轮图”左下角的「战略层面」部分，则代表着飞轮运转之后，给企业带来的业务增长。
+
+下面我们来尝试理解一下，飞轮是如何运转的。但是你要注意，**这张图的核心是飞轮本身，并不是其中某个单独的叶片。**
+
+飞轮的 1 号叶片，是绩效与激励体系。毕竟，没人会给企业免费打工，这是企业开始招聘、开始运作的起点。虽然我始终在说，对于个人不要为了薪资而工作，但对于管理者，金钱奖励仍然是最有效的激励措施之一 —— 尤其是在初中级岗位中，拥有正确认知的同学相对较少。
+
+那么管理者要做的，就是通过团队成员的投入产出比评定绩效，通过阶梯式绩效建立有行业竞争力的激励体系。把这些做好了，在 2 号叶片 —— 项目管理部分，管理工作就有了一个好的基础。
+
+说到项目管理，你一定比较熟悉，主要是立项、项目控制、风险管理、结项等。其中，立项非常重要，在大部分情况下，一个好的立项可以大大提高项目成功的概率。那么什么是好的立项呢？有三项工作一定要落实，分别是：
+
+- 目标清晰：每个业务目标、产品目标、技术目标都要清晰且可量化；
+- 责任到人：上述每个目标都要责任到人，不能都是项目经理扛，项目经理扛不了的；
+- 承诺到位：如果需要外部组织配合，要得到外部组织的明确承诺；
+
+如果上述任何一个条件没有落实到位，就不能立项；如果企业正处于快速迭代的阶段，可以适当放松要求，但开完项目启动会的一周内，以上三项都要落实到位，否则项目进入高风险关注列表。
+
+**在用人方面，要尽量提高人才密度。**同样一份工作，宁可用两位中高级人才来完成，也不用三位初级人才来完成，主要原因是要考虑管理成本。
+
+只会做项目还不行，我常说，做项目赢在当下，做产品赢在未来。高效地落地项目，是为了产品能更好地孵化出来。在 3 号叶片 —— 产品管理部分，重要的是建立面向产品的组织架构和机制，以产品为核心让组织运转起来。也就是说，项目管理是手段，目的是建设优秀的产品。
+
+产品的在企业内成功孵化，最终是要在市场上证明自己价值的，为企业带来业务上的高速增长。这就来到了 4 号叶片 —— 企业战略层面。
+
+这一部分我们主要关注业务增长，而业务增长又可以从长期、短期两个维度来理解。当下我们围绕产品做的许多工作，并不一定能帮助业务立刻跨上一个台阶，有些可能是在半年后才会深度影响业务的增长。但要记住，业务的增长一定是和产品能力的建设密切相关的。
+
+最终，业务的增长带来企业营收和利润的增长，进而让激励体系变得更有吸引力。有关企业 IT 能力建设的增长飞轮，就正常运转起来了。
+
+那么除了业务的增长，这个飞轮还能带给企业哪些价值呢？我认为在飞轮的运转过程中，企业的品牌是在不断被建立的。此外，随着越来越多的产品逐渐组成平台，甚至是形成对外云服务，企业积累的 IT 力量在不断增强，这也将在行业内形成真正的壁垒。
+
+到这里，我们回过头，再看一下增长飞轮，任何一个叶片的缺失，其实都会导致飞轮停转。如果你只做绩效与激励体系，虽然短期内大家很开心，但时间一长，企业就要倒闭了，最终害了所有人；反之，如果只做项目管理和产品管理，不做激励体系，那你就成了“活雷锋”，花企业的钱为业界输送人才。
+
+所以，我们在讲解管理者的三大任务时，是从“激励”到“增长”，按顺序介绍的。但这是一个飞轮，你可以从任何一个叶片开始看，在不同的启动点，关注点也不同。当然，图片能展示的内容有限，要让增长飞轮转得更好，我们还有很多内容需要讨论。但那都是后话，不要着急，接下来我们先来详细聊聊管理者的第一个要务：组织调整到位。
+
+## 构建面向产品的组织架构
+
+组织调整到位，在今天这个时代，就是要构建面向产品的组织架构，对应了「IT 能力建设增长飞轮」的叶片 3。
+
+那为什么要先讲组织调整呢？因为组织架构是公司协作的基础，它决定了各团队如何思考、如何协作。如果组织架构不调整，研发团队是一条线、测试团队是一条线、产品团队是一条线，这在IT 团队里天然就形成了一定的壁垒和鸿沟，导致一些正确的战略决策落地执行慢，公司内团队协作效率差，容易扯皮。
+
+所以在你有权限、有能力，时机恰当的情况下，我建议优先调整组织架构，从**职能型研发组织结构**，调整为**产品型研发组织结构**，也叫做“Pizza 型团队”。
+
+比如，职能型研发组织架构的特征是：
+
+- 每个研发中心为一个最大产品团队；
+- 二级部门按岗位职能划分为多个专业职能部门，比如产品经理团队、研发团队，还有进一步把研发团队划分成开发团队、测试团队的；
+- 每个人员仅归属到一个职能组织；
+- 三级部门人员按编制无限扩充；
+- 三级部门团队 leader 任命从岗位职能中挑选/竞聘，比如研发能力强的当研发团队 leader，测试能力强的当测试团队 leader；
+
+产品型研发组织架构的特征是：
+
+- 每个研发中心为一个最大产品团队；
+- 二级部门按产品下分多个产品组织为三级部门，每个产品组织均形成一 个产品团队；
+- 每个人员至少归属到一个产品团队，暂不限制归属产品数量；
+- 每个产品团队约为 7 ~ 8 人，人数受限，最多 10 人；
+- 每个产品团队产品经理、开发、测试齐备，是一个可以独立作战的小分队；
+- 三级部门产品团队 Leader 可以是团队任意成员；
+- 产品团队 Leader 要求（综合能力）：专业能力、领导力、汇报能力；
+- 团队 Leader 任命原则为能者居之，能上能下；
+
+你想一想，这里面最重要的变化是什么？我觉得有以下几个方面：
+
+**第一，产品经理、开发、测试，形成了一个整体，被赋予共同的文化价值观，为共同的目标去努力，战斗力变得更强了。**
+
+愿景、文化、价值观很重要。团队成员正在做的工作，是否被赋予了意义，会对工作的执行效果产生巨大的影响。比如我们彩食鲜的愿景是：希望全国人民，在生鲜食材方面能吃上可信赖的食材。当一个包含众多关键岗位的战斗小分队，都一起为这样的目标努力时，力出一孔，战斗力肯定比单打独斗强。
+
+**第二，无论是产品经理，还是开发、测试，都开始和业务部门熟悉起来，和运营同学坐在一起，为自己的产品负责。**
+
+以前，业务觉得 IT 傻，啥也不懂；IT 部门觉得业务部门是这个时代的傻瓜，啥也不会。在我的团队里，这些都不存在，所有人都要熟悉业务，不需要熟悉业务的岗位一律外包出去。连运维都要求去学习业务，只有知晓了业务的特点，才能把运维做好。业务部门和 IT 部门是兄弟，兄弟齐心，其利断金。
+
+心在一起是团队，心不在一起就是个团伙。为什么很多公司的业务团队和  IT 团队心不在一起？其实根本原因是组织整体架构设计的有问题，局部的优化不能从根本上解决问题，需要体系化的解决方案。
+
+彩食鲜的业务部门和  IT 部门关系非常好：互相理解、互相支持；胜则举杯相庆，败则拼死相救。我相信，这是大家都向往的团队氛围。而我思考的是，怎么去营造这种文化氛围。答案是，要从底层开始进行设计，把最基础的架构设计做好。
+
+**第三，管理者开始能通过一套统一的绩效考核体系，去考核不同岗位的团队成员。**
+
+以前我们如何考核研发人员？可能是 Bug 数量，也可能是宕机时间。其实在大部分业务驱动型公司里，考核这些指标的意义真的有那么大吗？如果业务都死掉了，系统再健壮又有什么用？如果你的产品能给公司带来一两个亿的利润，偶尔宕机一次又有什么关系？
+
+最终一切都要变好，但在前进的过程中，如何去寻找平衡，这是管理的智慧。**身为管理者，你要学会灰度管理，不断在业务发展和技术能力建设中间寻找平衡**。此外，管理者要将所有人的目标调整到业务发展上，联合大家一起寻找最优解，避免各方只关注局部优势，不看全局发展。
+
+我对 IT 团队的定位是，IT 必须成就业务。我也建议你，如果能够影响公司的 IT 策略，一定要通过利润和营收，考核 IT 产品给业务创造的价值，同时考核业务部门的IT化水平。
+
+我曾经和亚马逊零售部门的专家沟通过，发现亚马逊很早就开始将业务部门的 IT 化水平纳入考核。在一定时期内，如果采购部门的系统自动化程度不够，采购单是无法人工下发的。
+
+具体到方案，你可以以产品线为单元考核，参照成熟度模型，设立有挑战的绩效目标。然后用业务价值的增量部分，按百分比抽取，回馈给产品团队。
+
+你可能会想，如何估算业务价值呢，这有点难吧？其实也不难，**业务价值参照公司、部门的收入和利润进行换算；如果出现不能直接计算的情况，按人效提升、人力节省的程度进行换算**。在这里，我们可以用“开源节流”这个概念来给工作更明确的分级：
+
+帮助企业增长、扩大市场份额的工作属于开源类工作，这些事情能做就做，要优先处理。比如让企业内连接、协同效率更高，让数据共享更透明，帮助决策更高效之类的任务，基本都属于开源工作。
+
+节流类工作的优先级次之，具体是指人效提升、人力节省等。当然，有些工作既能开源，又能节流，效果最好。
+
+别觉得复杂，有一个基本的设计原则，可以助你理解以上内容：**企业做增长，个人看成长；鼓励每个人凭借自己的成长，在团队内贡献更大的能量，赢得企业的发展，最后在越来越大的蛋糕里，共享利益。**
+
+还有很多其他的细微差别，我就不再展开谈了，留给大家在实践中体会。重要的是，这么干下来，整个 IT 部门的氛围完全变了，业务就像爸爸，贡献行业知识；IT 就像妈妈，进行科技赋能。双方共同抚养了一个既懂业务又懂技术的孩子 —— 产品。
+
+这孩子的能力构筑在平台的能力之上，拥有过去积累的所有经验，持续学习、不断进步、越来越强。当企业坚持对 IT 长期投入时，就会形成复利效应，让这个孩子所能贡献的价值越来越大。最终受益的还是“爸爸”和“妈妈”。
+
+## 如何做组织架构的选型？
+
+当然，不是说所有公司都要立刻构建面向产品的组织架构，你也不要看完专栏，就跑去找 CEO “谈心”。
+
+关于如何在“职能型研发组织”和“产品型研发组织”间做选型，我有三个比较关键的考量标准，供你参考：
+
+第一，如果公司在技术方面还存在比较大的挑战，建议选择职能型研发组织。比如说，产品经理、开发、测试的能力很差，还有很多技术挑战不好解决，这时不要冒失转型。
+
+第二，如果技术挑战所剩不多，不要犹豫，建议转为产品型研发组织结构。
+
+第三，通过设置技术管理办公室、云部门统一建设基础平台和研发管理平台，降低对于大多数开发、测试的专业能力要求。对于  200  人以下的研发团队，设置一个技术管理组织就可以，将研发规范管理和基础平台能力建设两个功能凝聚在一起；如果团队规模超过  200  人，就要尝试分成技术管理办公室和云部门，前者负责研发管理规范，后者负责基础技术平台的研发。
+
+你可能会说，我还没有权利做组织架构设计和调整，我能得到什么呢？在专栏的第一章，我讲过，要学习看清楚问题的本质，养成遇到问题多思考的习惯。现在，你就可以结合自己的工作，好好想一想，这套调整方案背后的本质是什么呢？
+
+如果你是个项目经理，可以想想做过的项目，调整自己的视角，想想如何利用类似的思维模式解决项目问题；如果你是个架构师，想想这个和架构设计有什么异曲同工的地方？
+
+无论你是产品经理、测试经理还是资深开发人员，都可以结合自己的工作，想想有什么触类旁通的问题。
+
+虽然以上管理措施，并不是每一位管理者都有权立刻执行，但要学着先听、先了解。交流得多了，你可能会发现，其实成功的高层管理者，在管理方法上，都有许多共通之处。提前接触这些内容，有助于你拔高自身认知，更清晰地看待当下的成长路径和工作目标。
+
+同时也不能看过了就扔一边去了。每过一段时间，就要记着来拿出来重温一下，会特别有好处！
+
+当然，你也不用担心此后的每一讲都与中层管理者无缘，我们的内容将涉及多个层次、多个维度。
+
+如果你已经是一名拥有决策权的高层管理者，那就太棒了，以上所讲方案均来自我在环球易购和彩食鲜的管理实践，欢迎留言与我交流技术与业务团队管理心得。
+
+## 结语
+
+到此为止，我们专栏第二章第一讲的内容，就接近尾声了，内容从认知部分跨越到管理部分，不知道你听得怎么样？
+
+作为管理者，要学着带领出一支能征善战的队伍。这一讲，就是在讲如何搭建一支能适应“现代战争”组织形式的队伍。
+
+接下来的两讲，我们会重点讲一讲如何加强协同效应、如何激发团队活力。这三讲，将共同构成技术团队管理的“三板斧”。
+
+都做完了，就可以带团队去打胜仗了：每个季度定有挑战的目标，组织团队拿下这个目标。胜仗打得多了，就会养成赢的习惯，就会将“打胜仗”当作一种信仰。当这支团队再看到有挑战的任务时，就会兴奋地冲上去，然后拿下它！
+
+希望大家都能成为各自企业内的“常胜将军”，我们下一讲再见。

极客时间专栏/geek/乔新亮的CTO成长复盘/对管理工作的复盘/08 | 管理者最重要的三个任务（二）：加强组织协同效率.md

@@ -0,0 +1,159 @@
+<audio id="audio" title="08 | 管理者最重要的三个任务（二）：加强组织协同效率" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/8f/bd/8f2f001d71b1d96f09f67ceb68b42bbd.mp3"></audio>
+
+你好，我是乔新亮。
+
+上一讲，我们聊了聊管理者最重要的三个任务之一：组织调整到位，也顺便讲解了下「IT 能力建设的增长飞轮」。因为怕有些同学忘了，所以我们再看一遍这张飞轮图：
+
+<img src="https://static001.geekbang.org/resource/image/93/29/934083db86162c46e0799510a538c529.png" alt="">
+
+在这一讲里，我们主要来关注一下飞轮的叶片 2 ：增强协同，也就是管理者的第二个重要任务：加强组织协同效率。
+
+为什么要把加强协同放在这么重要的位置来讲呢？
+
+其实我刚刚成为管理者时，也没有这个认知。但后来随着职位不断上升，薪资也水涨船高，我发现自己变得有点焦虑起来，因为我没想明白一个问题：我的价值有那么大吗？
+
+那段时间，我不断地问自己：
+
+**你凭什么拿这么多工资？**
+
+我常常讲，比较健康的情况下，薪资的来源一定是公司收入的分成：公司赚了 100 元，你拿 1 元钱。那么当你可以拿 2 元钱的时候，意味着你给公司创造了 200 元的收入。早期做普通程序员的时候，这个逻辑是没问题的 —— 一个优秀的程序员，产出确实能达到初级程序员的 2 - 3 倍，甚至是 4 倍。
+
+可是如果说拿  10  倍程序员的年薪，可能吗？对于个人来说，从概率上来讲已经很难了；但对于带团队的管理者来说，从概率上来说，可能性还是很大的。假如一支团队一年为企业贡献 1000 万利润，在你的带领下，年利润贡献变成了 2000 万，甚至一个亿，两个亿，那么管理的价值就显现出来了。
+
+管理者带领团队最大的价值是向管理要效益，让团队价值大于个体所能贡献的价值之和，通俗讲就是 1 + 1 &gt; 2。所以说，加强协同效率，是众多管理工作里，最基础、也最重要的部分之一，几乎算是管理者的“天职”。
+
+你可能会想，老乔，协同不就是要让同事快点回信息、快点写代码、尽量别吵架吗？别说得这么玄乎！
+
+当然不是了，我们这里讲的协同，可不是单纯的催同事干活。如果要用一句话去总结，我认为是：**协同，就是让所有人向着同一个目标狂奔，并妥善解决奔跑过程中的合作问题。**
+
+这里有两个关键指标，一个是「目标聚焦」，一个是「顺畅合作」。下面我来分别讲讲，为什么以及如何实现这两个关键指标。
+
+## 认知与工具层面的目标聚焦
+
+我们先来聊聊，为什么要做目标聚焦？有两个关键认知，你一定要先体会一下：
+
+- 无论你的能力有多强，需求是永远做不完的；
+- 因为需求做不完，所以要努力通过全局视角思考，做到战略上的“舍九取一”，进行单点突破。
+
+这两个认知，我们在后面的内容里会详谈，这里我们就先记住，然后思考你的公司里是否有这种情况：
+
+- 团队各做各的，心没往一起去，影响团队产出；
+- 团队间互相扯皮，出了问题互相推诿，影响团队产出；
+- IT 团队的同学，有时候会说：你看我做了一个很好的东西，但是他没有配合好，所以没有发挥价值；
+
+……
+
+你往东，我往西，结果可不就是大家原地拔河，毫无进展吗？这些问题的本质，在于大家的目标不对齐，每个人都只关注自己的一亩三分地，无视团队整体的目标。从公司的角度看，这在一定的时间内，其实就已经是浪费了公司的资源，没有最大化协同的价值。
+
+那么，怎么让团队具备全局思维，劲儿往一处使呢？
+
+首先有 4 大协同手段需要实施，下面我们来逐步讲解。在可操作性方面，以下 4 条是从简单到复杂排序的。
+
+1. 沟通协同：一般通过飞书等即时通讯软件来实现；
+1. 日历协同、会议协同：这里是指全员、尤其是管理者要做到日历公开，只要空白的时间段，就意味着可以预约会议，减少协调成本；
+1. 文档协同：一般通过石墨文档、飞书文档等共享文档实现高效协同；
+1. 目标协同：一般通过 OKR 来实现上下目标对齐。在彩食鲜，中高层每月、每季度对齐目标；执行层每日、每周对齐目标。
+
+以上几个都很简单、清晰，很容易理解，在公司内部，这属于打造协同文化的基础工作。虽然简单，但是作为管理者，要每周，甚至每天关注：
+
+- 在团队内，是否有影响协同效率的事情正在发生？
+- 哪个组织、哪个人阻碍了协同效率的提升？
+- 团队成员是否因为缺乏大局观，影响了更大组织目标的达成？
+
+……
+
+要公开表扬、鼓励协同做得好的组织和个人；对影响了协同效率的组织、个人私下进行批评、沟通。有需要的话，也可以在公开场合进行批评，这样团队很快就会知道你想要的是什么：我要组织成功，我要大家有大局观。
+
+最重要的是，一定要花心思去关注团队的协同情况，这里没什么捷径。我基本上每周（有时候是每天）都会问团队：有没有问题需要我解决？有没有意外情况？
+
+我建议你也这么干，不但如此，还要关注团队的 OKR 和任何意外情况。可能听起来有点泛，怎么保持关注？盯紧两个指标就好，一个是结果指标，另一个是过程指标。
+
+彩食鲜的产研部门三季度目标是“销售支持 100% 在线化”、“财务对账 100% 在线化”，这两个“100%”都属于结果指标；系统稳定性、生产环境 Bug 数量、千行代码 Bug 率、服务响应时间……这些都是过程指标。
+
+好的管理是什么呢？平时看过程指标，考核看结果指标。过程指标不但要每周看，而且要每天看，要养成习惯。有些管理者是只看结果不管过程；有些管理者天天盯过程，把结果指标忘了。两者都是大问题。
+
+## 尽一切可能打造极度透明、信任的文化
+
+以上我们谈的更多是协同工具，没什么稀奇的，你可能也正在用其中的部分甚至全部协同工具。
+
+从工具层面上讲，当别人靠摇旗擂鼓进行团队协同的时候，如果你拥有一台电话，就能做到相对的高效协同，就能在市场竞争中脱颖而出。
+
+如果你和别人一样，都在用邮件、微信群进行协同，协同效率就没有差别，也就谈不上太多的管理效益。
+
+但两者的关键区别是什么呢？答案是，信息的透明度不同。从旗语、鼓声到电话，再到微信群、邮件，信息同步的难易度在逐渐降低。你也能看到，其实非常多的公司化行为都是在追求信息的透明化程度。
+
+所以加强协同，从表象上是工具，是四大协同手段；本质上，其实是打造极度透明、互相信任的文化。
+
+比如，很多公司都喜欢开会。一有任务就召开一个立项会，来自产品、研发、销售等各个部门的十几号人，互相协调时间，坐下来低效讨论。我听说过的这类案例有很多，从上班开到下班，一天都在会议室里，让人很痛苦。
+
+其实你可以反过来想想：开会是为了什么？（看，前面我们讲了要学会思考问题的本质，就要时时不忘去练习）其实就是为了保证信息透明、保证协同，花费时间，努力对齐所有人的思想、目标、时间点和工作内容。
+
+是不是感觉做得不太聪明了？
+
+单纯在开会这一点上，我觉得字节跳动做得就很棒。他们开会前  10  分钟，将会议内容同步在共享文档里，参会者共同修改，对文档进行评注，然后大家一起过文档内容，效率真的提高了很多。
+
+但这样做有一个前提：信息是高度透明的，所有人都知道目标是什么、会议材料是什么，这样才能在共享文档上做有效修改。如果你连目标都不知道、项目背景都了解不足，还怎么修改，怎么协同？**不够透明的信息，最终都会花掉团队更多的时间成本。**
+
+所以协同的真正关键就是极度透明，无论是目标还是必要信息。越透明，大家的思想就越容易对齐，协同效率就越高。**没有透明就不要谈协同**，在现在的市场环境中，那只能算作低效协同，实践价值不大。
+
+## 问题必须提前暴露
+
+经常同步好消息，这点其实不难做到。但也要请大家设身处地地想一想：你会将坏消息主动同步给领导吗？
+
+比如，线上生产程序存在无人发现的内存泄漏；公司要做容器化，事到临头发现服务器没准备好；因为个人能力，进度严重拖延，马上接近公司级重点项目的 Deadline ……
+
+在很多公司里，答案都是：不一定。但这些问题才是高效协同最重要的部分：及时暴露问题，才能及时解决问题。一方出了意外，导致整个项目组都阻塞住，这是严重的协同问题。
+
+因此，我在彩食鲜制定了两项规定，不容破坏：
+
+1. 问题必须暴露，不许隐瞒，这是红线。有问题不上报，发现后直接开除；
+1. 允许犯错、试错，不以指标决定绩效评分，最终以复盘情况决定绩效。
+
+第一项规定是军令，保证协同的核心价值和底线；第二项规定则是为了给予团队安全感，给大家成长的空间，鼓励大家冲击更有挑战的目标。一项高难度的任务，即便结果不尽如人意，只要复盘时说得通透，一样能在绩效考核中拿高分。
+
+有人看到这里就想吐槽：第一条规定那么严厉，第二条规定还要创造安全感，怎么可能呢？
+
+你要注意，发现问题后主动暴露问题其实并不难，不存在能与不能的问题，只有愿与不愿的问题，所以我们严格规定。
+
+而第二项是个能力问题，今天这么多有挑战的目标，不确定性的因素非常多，怎么鼓励人人奋勇当先，不以  KPI  来进行考核。**在彩食鲜科技中心，确定性工作使用**  **KPI，不确定性工作使用**  **OKR，效果很好。**
+
+因为团队成员都是活生生的人，对于人来说，安全感很重要。没有安全感的团队不止绩效差，协同性更差，因为信息不再透明了。没人会在不信任的环境中说出心里话，兴许一个说不好就被开除了。
+
+允许试错/犯错、信息极度透明、事后的客观复盘、绩效评定的公开化和透明化，不断地持续做这些管理工作，团队成员会越来越互相信任。这反过来会提升组织的协同效率。
+
+这上面的两项规定，体现了管理的辩证思考，管理的灰度，我们后面有一讲会单独讲这点，困扰很多初级管理者的也是在这里。
+
+## 结语
+
+今天我们聊了新晋管理者的第二个重要任务：加强组织协同效率。我们大概总结一下：
+
+1. 协同就是向管理要效率，是管理岗位存在的基础意义；
+1. 管理者要通过四类工具和基础认知，时刻盯紧协同中的目标聚焦问题和意外情况；
+1. 效率是相对的，其关键是极度透明的文化，没有透明就谈不上高效协同；
+1. 工具选择只是提高协同效率的一部分工作，给团队带去有底线的安全感往往更加重要。
+
+你可能会想，老乔，等一等，前面你讲了，协同的关键词有两个：目标聚焦，顺畅合作。关于怎么做到「顺畅合作」，你还没说呢？
+
+不是不说，只是可以简单说，因为确实不难。目标聚焦部分我们其实回答过了，也讲解了协作的客观方法。掌握这些方法后，如果还会出现影响团队合作的情况，那更多的是当事人的态度或格局问题：
+
+第一，对方不愿意配合，是态度问题。管理者发现后要及时出面，说服解决；
+
+第二，对方愿意配合，但确实很忙。管理者及时出面，判断哪个需求更贴近大的目标，以公司的利益为主，大家都要在大的格局看问题、做决策；
+
+第三，无论为公为私，双方吵起来了，乌烟瘴气，以至于管理者都不好插手。这点倒是难倒了很多人。
+
+我和许多管理者聊过，相当一部分人都喜欢在这一点上纠缠不清，有一些管理者简直就是团队的“居委会阿姨”，耗费大量的时间调和团队矛盾，最后不但效果不理想，团队的风气还变坏了。
+
+其实解决办法很简单，我告诉团队，**彩食鲜 IT 团队有不同观点，要通过沟通来解决，不能决策的找上级管理者决策，但绝对不允许在办公室吵架（不是辩论），如有发现，直接开除**。然后，问题就直接解决掉了。前面我们也提到了，对于团队成员个人来说，不难做到但又影响很大的规章制度，要坚决执行，贯彻到底，没有那么多花里胡哨的管理手段。
+
+这就是保障团队间顺畅合作的秘诀，更多考验的是管理者的认知，而不是手段。
+
+此外，你也要记得，任何时候都带着辩证的思维去思考，不能听了课程就盲目照搬。很多大厂协同效率就是很低，一方面是因为企业规模变大了，一般情况下，企业规模和协同效率成反比；另一方面，可能也在于，这些公司当下压根不需要追求协同效率。
+
+如果你所在的公司商业模式优越，或者正在风口上高速增长，千万别追求什么管理的效益。我建议你忽略这些管理细节，尽一切力量狂奔，帮助公司滚雪球，把市场做大。如果这时停下来雕琢细节，有可能会丧失先机，因小失大。
+
+但我们也要意识到，任何一家公司都不会永远野蛮生长，增长曲线终有一天会趋于平缓。尤其是在今天：我们的市场正从「供不应求」过渡到「供大于求」，从增量时代过渡到存量时代 —— 这时，管理的意义就凸显出来了。可以说，任何一家公司最终都要追求管理的效益，也就是追求协同效率，这只是时间问题。
+
+好了，关于「加强协同效率」的话题，到这里就要结束了。像以前一样，如果有问题，就在评论区向我提问。
+
+我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对管理工作的复盘/09 | 管理者最重要的三个任务（三）：激发团队活力.md

@@ -0,0 +1,151 @@
+<audio id="audio" title="09 | 管理者最重要的三个任务（三）：激发团队活力" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/94/0f/949000dc5914f5a664568797123d7d0f.mp3"></audio>
+
+你好，我是乔新亮。
+
+前面两讲，我们聊了聊管理者最重要的任务（一）和（二）：组织调整到位、加强组织协同效率。
+
+有同学看完后，留言提问：这些都做了，但某个部门事情较杂，人员主动性较差，每天按部就班地工作，没什么激情，怎么办？
+
+别急，这一讲，我们就来聊聊如何激发团队活力，补上管理者三大要务的最后一块拼图。
+
+## 寻找同路人，管理要慎重
+
+我相信，现在在读专栏的你，要么已经是管理者了，要么有志成为一个优秀的管理者。那么不妨想想，如果将激发团队活力的任务交给你，你要做的第一件事是什么？
+
+- 请团队吃饭、打王者荣耀，和大家打成一片？
+- 召集大家开会，给大家发表一场振奋人心的演说？
+- 一对一和团队私聊，说说对下属的期望和规划？
+- 同步一个关于绩效和奖励的好消息？
+
+……
+
+很棒，都没错，视具体情况都可以操作，但都不是第一件要做的事。如果让我说，我认为要激发团队活力，管理者的第一个任务是找到同路人。
+
+以前大家只觉得公司找合伙人需要同路人，其实这还不够，最理想的情况是，团队内的每一个人都是同路人。如果短期内达不到，我们要试着在长期内不断追求同路人文化。
+
+激发团队活力，其实解决的是关于人的问题，而许多有关人的问题，其实都是思想问题。你看一些讲建国早期历史的电视剧，大家在路上相遇，互相称呼“同志”。同志是什么意思？同志就是志同道合的人，同德则同心，同心则同志，就是同路人。
+
+那个时候，我们经济不发达，物质条件不丰富。在最困难的日子里，全国勒紧裤腰带，展现出了惊人的凝聚力，挺过了许多天灾人祸。
+
+你想想，如果企业团队的激励能接近类似的效果，这家企业会拥有多么可怕的战斗力？
+
+反之，如果找不到同路人，你会发现自己陷入很多负面的管理细节里，一直迟到的同学怎么沟通？一直吵架的同学怎么沟通？能力差还不学习的同学怎么沟通……一大堆问题在等着你。
+
+其实会出现这样的情况，不一定是你的管理手段不够丰富，而是你没替团队找到同路人。
+
+至于怎么找到同路人，其实包含了很多琐碎的工作，比如：认真规划面试工作、企业文化宣传、激励措施制定……最关键的是，开除那些触碰底线的人，尤其是能力很强、但触碰底线的人，因为这样的人对团队其他成员的影响力很强。比如说，我们团队不允许抱怨，你可以反馈问题、随时找我商量解决方案，但不允许私下、不停地抱怨，否则立刻开除。
+
+你可能会心里有点不舒服，老乔，我感觉你这样有点冷酷。你要明白，管理者的职责不是保证每个人都成功，而是保证组织以及留在组织中的成员成功。如果管理者只做好人，最后大家短期都开心，长期组织死掉了，最终是把所有人都害了。
+
+另外，那些会导致员工被开除的制度，一般只是在工作态度上有所限制。换句话说，这些规定没有执行方面的难度，只要你愿意遵守，就一定不会犯错。
+
+在[《08 | 管理者最重要的三个任务（二）：加强组织协同效率》](https://time.geekbang.org/column/article/307105)这一讲里，我们也提过类似的问题：彩食鲜不允许在办公室吵架（非辩论），如有发现，直接开除。
+
+有时管理者做类似决策一定要果断，等到团队气氛已经被少数人破坏后，补救起来反倒比较困难。成年人都会形成自己的逻辑闭环，各类行为习惯是有惯性的，要做改变非常困难。董明珠说格力最为重视校招，很少在外招聘成熟的管理者空降，为什么？就是要保证在格力工作的，全部是同路人。
+
+当我们找到同路人加入组织后，在管理方面反而要慎重再慎重。一些同学常常不自觉地犯一个错误：对管理上瘾，在团队管理方面投入的精力越来越多，好像不多管点，自己就失去了在企业内存在的价值。短期来看，还是非常值得肯定的，管理者确实要多上心、多付出，但长期看来就有问题了。
+
+一个比较关键的认知是：管理是为了不管，管理的目的是为了将不那么能自我驱动的人，变得更主动、更积极，而不是当个监工，越管越严。
+
+**如果管理制度只是越来越多，最后公司会被制度束缚住手脚，响应外部市场的速度会越来越慢**。做的事都对，但结果是输给了市场。管理要从少到多， 然后还要从多到少，这个过程中什么发生了变化？
+
+团队成员的构成变了，团队里面出现了越来越多的自律、自驱的同路人。**先管，向管理要效益；然后慢慢不管，团队自律、自驱，管理逐步达到无为状态**。整个过程体现了用发展眼光看事物演变的辩证统一的哲学观，具体到过程中某一个点，要有灰度管理的思想。
+
+首先，如果你始终处于工作饱和状态，个人是很难上台阶的 —— 做初级管理者都天天熬夜了，做高级管理者不得天天不睡觉了？要想办法逐渐用更少的工作量，达成更好的效果；
+
+再者，应该人人都希望自己团队都是自驱力强、创造力强的成员。如果管理介入得太多、太死板，那些自驱力强的人才，就会逐渐离开团队，因为他们失去了自由和空间。
+
+最终我们理想中的样子是，所有人都很自由、都不需要管理。那么其中的另一个核心就是，团队是否具备开放平等的工程师文化，这样的文化才能激发工程师的积极性。
+
+这一点，你一定要慎重，既不能不管，也不能管理过度，要在文化上下功夫。
+
+## 赋予团队使命，打开考评与晋升通道
+
+找到了同路人，也把握好了管理的尺寸，还不够。其实使命和愿景是很重要的，有没有带着一股信念去做事，效果完全不一样。
+
+我们做的许多工作其实都是有意义的，是让社会变得更好。就看你能不能找到这个意义，并把它赋予团队。在彩食鲜我总说：以人为本，让员工、客户、合作伙伴更卓越。
+
+有时候工作也很有挑战、也很累，但你的工作让用户过得更好、更轻松了，是不是很有成就感？
+
+很多公司其实内部是贴了很多标语的，但光贴是不够的。为什么我的团队总叫我“乔老师”，因为我总跟他们一套一套地讲道理。**只有频繁地重复输出，坚持言传身教，使命和愿景才能从墙上走下来。**
+
+此外，管理者也要让团队感受到实际的业务和工作压力，制定有挑战性的目标，让大家一起去比拼工作成绩。
+
+但是这个对比，一定是同赛道的对比。如果你让员工和经理比，那赢得永远是经理；你让高级工程师和初级工程师比，赢得永远是高级工程师。长此以往，考评就失去了意义，对弱一点的普通成员也是一个打击。
+
+评奖、做绩效，每个团队都做，但考评赛道的划分，你的团队做了吗？划分赛道很关键。
+
+有了考评，就要有晋升的通道。在管理复盘的第一讲里，我们分享了职能型研发组织和产品型研发组织的区别，有一个细节不知道你有没有注意到：在产品型研发组织里，团队 Leader 的任命原则是能者居之，能上能下。为什么？是因为要让考评和激励有实际意义。
+
+我常常跟人说，如果一个 leader ，提拔上去就下不来了，无论干得多烂都在上面挂着，组织不就成为了一潭死水了吗？也谈不上什么激发团队活力了。
+
+同样，我们打开的是一条晋升通道，管理者做得不好被罚下去了，以后做得好了还可以再上来嘛。**组织内是同赛道进行对比**，他可能在管理赛道上是倒数，但在普通员工赛道就又是“优等生”，又变得很有竞争力。第一次做管理者，可能做得不好，降职了；一段时间后，第二次做管理者，可能就吸取了许多教训，变得更熟练了。
+
+从管理手段上讲，每个赛道就如一列高速行驶的火车，跑在前面，给火车带来动力的员工，要进行奖励，叫做“**给火车头加足油**”；跑在火车后面的，拖慢了火车前进的速度，就是“尾巴”，这个赛道的尾巴，要“**切尾巴**”，到下面一级赛道去。
+
+所以作为高层管理者，不要怕对下级管理者进行任免；作为小团队的管理者，也不要对任免心生抵触。玻璃心的成员是不适合当管理者的，华为内部讲：“板凳能做十年冷”。十年说得有点久了，一年还差不多。如果一点委屈都受不了，团队是不会有凝聚力的。有上有下，团队的活力才能被充分激发出来。
+
+到此为止，这一讲是不是和你想象的不太一样：说好了要激发团队活力，结果老乔讲了半天和激励无关的内容。
+
+别着急，上面我们谈的都是压力，可光有压力也不行，还要给团队动力。站在管理者的角度，就是要尽可能地发现团队每一个人的优点。
+
+## 管理游戏化，发现每个人的优点
+
+其实，这和管理者的个人风格关联度比较高，有些同学比较活泼、性子比较跳脱，做管理者时也擅长发现别人的优点。
+
+有的同学可能自我要求比较高、比较严肃，因而对下属的要求也比较严格，总觉得下属只有各方面都做得不错时，才能得到表扬。
+
+其实不是这样的，每个人都有优秀的地方，不能等他做到十全十美再去表扬。管理者要设计一套体系，努力去发现团队中优秀的个体，有些人虽然不是最勤奋的，但他是最有契约精神的；有些人虽然不是代码实力最强的，但他是进步最大的。在彩食鲜，我们设置了八个奖项，未来还要设置更多：
+
+- 金苹果奖：工作成绩好，业务价值高；
+- 烂草莓奖：还需要继续努力不断提升；
+- 最具协作力奖：团队协作做得好；
+- 最具契约精神奖：使命必达，保质保量完成任务；
+- 持续改进奖：敢于试错，在自己的工作岗位不断尝试，持续改进；
+- 最佳专业技能奖：专业技能强，技术第一名；
+- 最佳服务满意度奖：时刻将客户服务放在第一位；
+- 月度最突出贡献奖：当月团队贡献最大；
+
+这些奖项其实与奖金无关，也不是那么正式，我们每周、每月都会评奖。你说，与奖金无关，大家还会有动力吗？
+
+其实是有的，我们团队一个小伙子拿了奖高兴了半天。我开玩笑说，这又不能换钱，这么高兴干嘛？他说，那也高兴，从小到大，没拿过奖。
+
+很多人喜欢玩游戏，因为游戏是即时反馈，付出就立刻能看到效果。团队内的激励和评奖也是这样，我们要把管理游戏化，给大家频繁的正向激励。
+
+涉及奖金的绩效当然也要做，但穿插在日常工作中的激励手段同样重要，千万不要忽视。
+
+## 激活团队，重要的是细节
+
+说了这么多，其实你会发现，很多都是宏观层面的内容，有些是制度问题、有些是文化问题。
+
+但其实光喊口号是不行的，激活团队、打造文化，是要抓很多琐碎的事物，频繁的动作很重要。
+
+比如在彩食鲜，我们是要求团队每天打卡的，但打卡结果不与奖金挂钩、不需要补考勤、没有罚款，管理者也不会单纯因为迟到去批评一个团队成员，简单一句话，打卡只是记录了数据。
+
+那么为什么要打卡呢？
+
+首先，这个动作会让团队成员有时间意识；
+
+其次，当团队的产出和工作态度出现问题时，打卡数据会成为一个参考信息。
+
+比如项目在不停地延期，有个人还迟到早退，这样的情况就应该重点关注，看到底是家里有特殊情况，还是心态有问题需要调整？
+
+再比如项目做得又快又好，有人还是按时下班，说明他的能力已经超过现阶段的公司要求了，应该给他更有挑战性的任务，让他可以成长。
+
+诸如此类，关于文化和激励，都是一些琐碎的细节，但如果长期不关注，就会造成连锁的负面反应。
+
+至于激励是否与金钱挂钩，界限比较模糊，要根据实际情况来定。我更推荐按业务价值确定激励数额：业务增长，大家吃肉；业务停滞，大家就要咬牙努力。这样激励团队，得到的结果是什么？是团队时刻把成就业务放在心里。
+
+## 结语
+
+到这里，关于如何激发团队活力的话题，我们就讲完了。同时，管理者最重要的三个任务，也为你梳理完毕。
+
+你可能会想，老乔，接下来呢？接下来该做什么？
+
+组织调整到位、协同效率提高、团队活力激发，都做完后，下面就是打仗了。带着团队去打仗，把业务增长做出来，让 IT 能力建设的飞轮转起来。让团队把「赢」当成一种习惯，有时候，一场胜仗比任何管理方法都管用。
+
+如果你觉得，关于这部分内容，听得还不过瘾。别担心，在整个第二章的管理部分，我们还将沿着脉络，继续深挖技术管理者的必备素质。你可以在读的过程中，揣摩一下，哪些部分是贯穿全篇，始终强调的；哪些更偏向认知，是需要具体情况具体分析的。
+
+同样，如果有问题、有想法、有感触，欢迎在专栏下方留言。我常说，沟通创造价值，分享带来快乐。如果你觉得有用，也欢迎大家分享出去！
+
+我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对管理工作的复盘/10 | 管理的人性哲学：金刚之怒，菩萨慈悲.md

@@ -0,0 +1,151 @@
+<audio id="audio" title="10 | 管理的人性哲学：金刚之怒，菩萨慈悲" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7f/bc/7f2fb48f29d5d56e6aa5b7ee407c5abc.mp3"></audio>
+
+你好，我是乔新亮，很高兴我们又见面了。
+
+前面我们讲了管理者最重要的三个任务，也就是所谓的“三板斧”。为什么要抡这三板斧呢？是为了自顶向下地搭建优越的架构和制度，最终让业务增长，让飞轮转起来。
+
+换句话说，这是个体系化的解决方案，是顶层设计。
+
+在这一讲里，我们将视角拉低，去近距离地看看在体系内工作的团队成员，想想管理者如何在细节上彰显领导力。
+
+稻盛和夫有句话说得好：“一切管理问题，最终都是人的问题。”
+
+那么到底如何解决人的问题呢？
+
+我对这个问题的思考是：除了体系化的措施外，在很多时候，管理还是一门面向人性的哲学。如何既有“金刚之怒”，又有“菩萨慈悲”，是管理者破局的关键。
+
+## 金刚之怒，菩萨慈悲
+
+如果你经常去寺庙，可能会发现，寺庙里经常供奉着一尊名叫韦陀的佛陀护法，职责是护法安僧，穿着盔甲，拿着金刚降魔杵，很威严。在背面则会看见一尊弥勒佛像，慈眉善目，笑口常开，叫人看着就开心。
+
+两个截然相反的形象，出现在同一座寺庙里，冲突吗？其实不冲突。管理也是一样，金刚之怒和菩萨慈悲，就象征着管理的两面性。
+
+其实在管理这一章的前三讲，我猜有些同学应该是没好意思留言。因为在体系化的管理方法里，可能很多细节都显得有点“冷酷”。比如：
+
+- 办公室吵架，开除；
+- 工作受了委屈后不沟通、不解决，一直抱怨，开除；
+- 生产有问题时，隐瞒问题，开除；
+
+……
+
+看起来都是金刚之怒，一怒就把员工开除了。但你仔细地想想，这些规定真的冷酷吗？不是的。
+
+用沟通替代吵架和抱怨、用求助替代隐瞒，其实都不难做到，很多事情甚至就是一念之差。所以当我对员工宣布这些规定时，我知道，只要大家想这么做，是一定能做到的；如果有人不这么做，说明他可能就不太适合团队，不是我们的同路人。
+
+最终我们保证的是组织成功，让留在公司这条“大船”上的人能够受益，我觉得这才是真正的为了员工好。
+
+在我眼里，真正“冷酷”的行为是：发现组织气氛变坏的苗头，不及时制止；发现个别员工影响组织成功时，不及时沟通。最终，优秀的人受不了了，离开了。组织因此垮掉了，公司倒闭了，所有人都遭殃了。这才是真的冷酷。
+
+所以，常常有朋友问我，老乔，都说慈不掌兵，但我是个比较和善的人，怎么办？我是不是不适合做管理者？
+
+其实在我看来，仁慈不代表啥也不管，严厉也不代表没有人情味儿，金刚之怒和菩萨慈悲不是矛盾的。最近，我就有过两次实践，遇到了两类典型案例，此时正好与你复盘一下。
+
+## 案例一：如何与员工沟通加薪问题
+
+最近有一个团队的核心骨干，到办公室找我，要求加薪。认真听他讲完诉求后，我把他狠狠地喷了一顿。
+
+为什么呢？因为他有一句话是这么说的：“……我知道周围很多人工资都比我高……”
+
+我直接说，你这属于严重的违规啊！公司内不允许互相打听薪资，这是规定，为什么不遵守呢？
+
+你看，到这里其实属于金刚之怒：公司的规定要严格遵守，尤其是会对其他人产生影响的、文化方面的规定。
+
+不过我接着对他说：“不过客观来讲，你的薪资确实偏低了。”
+
+这个是事实，其实即使他不说，这次调薪我也会将他算进去。但这个薪资低是有历史原因的，在上一家公司工作时，他的薪资就不高。当他来到彩食鲜时，薪资也没有实现跨越式的成倍上涨，这是客观事实。
+
+当下为什么薪资低？因为你的起点低，这是自己过去的选择造成的，要为自己的选择买单；未来薪资为什么会上涨？因为你在为团队持续地产出价值，两三年以后，你的薪资可能就满足了自己的期望。
+
+他听了后，也认可了这个道理，表示就算不涨薪，也要留在团队，因为可以获得成长。后来，他还问 HR ，能不能把家里人也内推到公司来。
+
+于是，事情圆满地解决了。后面这段话，就属于“菩萨慈悲”的范畴了。
+
+所以你看，什么叫“金刚之怒，菩萨慈悲”？金刚之怒是你要按照规章制度，为团队划定界限。菩萨慈悲是指作为管理者要有同理心，你要设身处地地去理解员工的境况，真心地为他着想，二者其实是不冲突的。
+
+很多时候，作为高级管理者，对团队的情绪的感知能力是很弱的，很多问题在管理者眼里就是个数字而已。但对员工而言，那就是全部。在某个时刻，心理状态是有很多变化的，管理者要学着去理解员工，设身处地地为员工着想。
+
+面对加薪的诉求，管理者确实容易感到为难，但比这更大的挑战还有很多。在上一讲，我总说，团队 Leader 要能上能下，如果升职以后就不再降职，团队还怎么保持活力、怎么打仗？
+
+但升职容易，降职难。怎么处理绩效差的员工，怎么沟通降职问题？这也和“金刚之怒，菩萨慈悲”的管理哲学密切相关。
+
+## 案例二：如何处理员工的绩效和降职问题
+
+在彩食鲜，KPI 和 OKR 系统里的几个数字，不会直接决定你的绩效和薪资水平。因为有些同学为团队付出比较多、为业务牺牲比较大，虽然 OKR 看着不突出，但实际做了很多事。
+
+所以在每个季度结束时，我们会开一场述职会，由其他人共同现场打分，保证公开透明。打分项则涵盖了团队价值贡献、产品能力提升等各个纬度，讲得好可能绩效就好，讲得差可能绩效就差。
+
+你可能想，那技术人不成了靠嘴吃饭的人吗？也不能这么理解，在「组织调整到位」那一章，我们说了，团队 Leader 的必备能力之一就是“汇报能力”。
+
+一则，就算是技术人，也要把语言表达能力重视起来，对团队协作和职位晋升都有好处；二则，很多时候，表面看是说不清楚，实际是没想清楚。所以这个绩效考评机制，还是相对公平的。
+
+但问题是，不管有多公开透明，绩效考核总是有好有坏，有第一、有垫底的。那么绩效得分比较低的团队成员，往往就很难接受这个结果。
+
+一个多月前，在我们 Q3 的述职会上，评分倒数第一的小分队的 leader 要被降级，他本人其实就不太服气：他觉得自己付出了很多，也为组织创造了很多价值，不应该是这个结果。
+
+于是，我当着述职现场所有人的面，和他公开地聊了聊这个问题：
+
+第一，这么多人在现场公开打分，你就是倒数第一，要承认这个结果；
+
+第二，会讲很重要，要锻炼汇报能力。你做的 PPT 完全不合格，如果光凭 PPT 和汇报结果打分，你的得分应该更低。恰恰是因为大家知道你平日里的成绩，才会出现这个分数；
+
+第三，你在团队管理方面得分很低，为什么？因为你只是个专业的产品经理，很多管理工作都没有做。就连团队内部发生吵架现象时，都没有及时地介入和做调整。既然你身在管理岗位，就必须承担起相应的责任，为组织的一切问题负责。
+
+以上三点，他是接受的。
+
+其实，很多让人感觉难以操作、场面尴尬的管理问题，就是被这样化解掉的。但仅仅这样做还不够，这只是完成了“金刚之怒”部分，一个人嘴上或许会同意，心里可未必服气，时间一长，很容易在心底产生疙瘩。
+
+于是接下来，我对大家说：“虽然他评分倒数第一，但他在过去三个月间进步非常大，拿的薪资也很低。所以说，就算今天他被降职了，我还是要给他加工资。”
+
+我也直白地和大家说，按评分，他理应被降级。但目前，我手头没有更合适的 Leader 人选，所以我决定把他重新提拔上来，再给他机会去学习和锻炼。
+
+最后，我对这位 Leader 说：“xxx，你要感激。5 月份的时候，团队给了你上台阶做事的机会。你不是没做好，但却是同赛道里较差的。我认为你确实进步很大，这次的机会要好好把握住。”
+
+先把这位 Leader 降职，这是金刚之怒；再把他提拔回来，这是菩萨慈悲。整个过程中，我一句假话都没有讲，说的全都是最实在的评语。而且我也知道他是很努力的 —— 他只是需要更多的时间。
+
+当然，也要注意，无论是“金刚之怒”还是“菩萨慈悲”，都不是仗着管理者的身份滥用权力。尤其是**当你批评下属时，越严重的批评越要选择私密场合进行，一定不要骂人**；如果是通报批评，一定是有目的的、谨慎的。
+
+作为管理者，要遵守规则，你的权力不是对下属“威逼利诱”，而是督促大家和你一样，都去遵守公司的规则。
+
+## 金刚和菩萨，本为一体
+
+前面，我们讲了两个案例，都是真实发生在公司内，由我亲手解决的。
+
+我相信，你很容易就能体会到这套管理哲学的含义，甚至在读这篇专栏前，就已经接触过类似的理论了 —— 这并不是什么新奇的概念。
+
+但在这两个案例中，都有一个比较隐蔽的细节，不知道你是否注意到了：
+
+金刚之怒和菩萨慈悲，往往是同时发生的。
+
+比如在第一个案例中，我批评那位同学违规打听薪资，随后就提出要给他涨薪；在第二个案例中，我指出那名 Leader 绩效倒数第一的原因，但随后就让他“官复原职”。
+
+尤其是在最近几年，我越发深刻地认识到，只有当金刚之怒和菩萨慈悲同时出现时，管理的效果才能达到最佳。
+
+有一部分管理者，天生脾气好，只有慈悲没有严厉，只有夸奖没有批评。一段时间后，员工开始变得飘飘然，无法接受任何岗位和薪资调整。其实这就叫做“捧杀”，等于管理者间接害了这名员工，断绝了他的成长道路。
+
+还有一部分管理者，自己有压力，脾气暴躁，不尊重员工，对员工没有帮助、没有指导，功绩自己来拿，问题下属来背，团队的士气怎么可能好。
+
+我和团队经常讲的一句话是， **你们所有的问题都是我的问题，你们所有的功劳都是我的功劳**。那有了这点认知后怎么做呢，功劳都让下属拿，问题最终都让自己扛。你说，随着时间的推移，我还会发愁如何与团队建立信任感吗？你想想，这个时候，金刚之怒是不是就有了根基？
+
+夸奖员工的时候，要指出员工可以继续提高和成长的方向；批评员工的时候，也要肯定他的努力和做得好的部分。这样员工才能找到平衡，不断成长。
+
+所以，最聪明的管理者，会将金刚之怒和菩萨慈悲，辩证统一地结合在一起，时刻让团队成员认得清现实，看得见方向。
+
+## 结语
+
+这一讲，我们聊了聊管理的人性哲学。
+
+在你尝试实践的时候，还有一点需要格外注意：**管理者的管理风格和个人形象是强相关的**。
+
+比如，我是在团队中的形象是：比较有主见、有权威的管理者（我自己是这么认为的），所以我的很多沟通、措施，不会受到团队成员公开的、强硬的质疑或挑战。
+
+但如果你的形象是：脾气很好、非常民主的管理者，在套用我的一些管理方法时，可能就要针对性地做调整。
+
+在他人心目中，管理者的个人形象有很强的先入为主色彩，如果早期比较和善，后期如果想变得威严一点，也不太容易。当然，每个人的形象和风格都有所不同，不代表哪种形象或是哪种管理风格更好，只要适合当下的团队氛围，有切实的效果，能帮助团队成长、业务增长，就是最好的。
+
+金刚之怒是规则，菩萨慈悲是同理心，管理者的一体两面，从建立信任出发，持续做事赢得团队信任，最终打造一支高绩效、有战斗力的队伍！
+
+最后，虽然前面提及了许多关于人性的哲学，但我始终认为，**一个人最可贵的品质是真诚**。在前面的两个案例中，我反复强调，虽然对当事人是批评与夸赞皆有，但并没有一句假话、虚伪的话。人人都有优点，只是需要管理者慧眼识珠。你要真的去理解他、体谅他，为他着想。
+
+相信员工很聪明，相信周围的人比自己聪明，基于这点认知去做事，唯有真诚才能建立信任，笨办法就是最好的办法。
+
+我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对管理工作的复盘/11 | 全局思维和持续完善体系的建立，让团队持续成长.md

@@ -0,0 +1,137 @@
+<audio id="audio" title="11 | 全局思维和持续完善体系的建立，让团队持续成长" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/99/7e/997de6f83c86d4bebaea8fef94227a7e.mp3"></audio>
+
+你好，我是乔新亮，很高兴又与你见面了。
+
+在技术管理领域，有一个很古怪的现象，不知道你是否有注意到：很多管理者，在面对团队成员的争吵时，会选择冷处理、和稀泥，也有人干脆沉默以对，直接忽略这个状况。
+
+但你肯定知道，理论上，管理者是应该介入争吵，及时调停的 —— 不然团队士气和协作就会受损。
+
+那为什么会有这样的情况出现呢？原因可能是多种多样的，但一个主要的原因，可能是缺乏全局思维。注意，这个评价不单针对发生争吵的双方，也针对不作为的管理者。
+
+只要是争吵，情况一般都比较类似：双方各有各的道理，互不退让。作为管理者，也不想影响任何一个人的积极性，所以两头为难，干脆不管。
+
+其实，如果缺乏全局思维，就会经常面临这样的决策难题。有个成语叫作“盲人摸象”，意思是说，几个盲人要通过触摸大象，来描绘大象的形象。于是，摸了象牙的人说，大象像一根长棍；摸了象腿的人说，大象像一棵大树；摸到大象肚子的人说，大象像一堵墙……
+
+他们说错了吗？**站在个人的角度，没错；但站在全局的角度，<strong><strong>可能每个人都**</strong>错了</strong>。很多管理层面的问题，其实都可以用“盲人摸象”来形容，道理极其相似。吵架，只是缺乏全局思维造成的众多问题之一。
+
+2019 年在环球易购时，我就经历过这样一件事。
+
+## 高可用设计或许是个“伪命题”
+
+在环球易购，我们主要做的是跨境电子商务，服务遍布很多国家和地区，其中有一条线路，是通过光缆连接美国达拉斯到深圳的机房。
+
+我去了没多久，在检查基础设施的高可用建设时，发现线路居然只有一条 —— 很明显不符合高可用设计的思想。因为光缆是有可能被挖断的，底层基础传输网络的抗风险能力太差。
+
+作为技术管理者，看到了风险，当然要想办法解决了。
+
+但着手解决时，相关业务部门却不愿意为新增加的光缆付费，说目前部门的压力大，不愿意承担这个费用。听到这种说法，我带领的团队对此很是不屑一顾 ——什么压力大，简直就是不懂啥叫高可用。
+
+你看，一个典型的问题场景出现了，技术人员在想：明明有问题，不想着去补救，出问题的时候可别找我；业务部门想的是：我这业务压力这么大，你还要纠结什么架构设计，啥也不懂。
+
+站在各自的角度，他们说的都对，根源在于看问题的视角不够高，缺乏全局思维。
+
+我和我的团队说，首先，我们要学着去理解业务部门；然后，我们来分析下，对于企业而言，这种设计到底有什么样的风险。
+
+其实，这条光缆的问题不会对 C 端业务造成影响，只会影响后台的统计分析。接着，我们向上看，根据过往经验分析：如果光缆被挖断，相关业务会中断多久、影响范围有多大？
+
+最后，技术团队将相关调研整理、总结，和业务部门坐下来相互对齐，得出结论：业务影响处于可以接受的范围，结合公司情况，暂不增加备用光缆。
+
+到我离开环球易购时，其实这条线路仍然只有一根光缆。光缆也被挖断过，但无论是 IT 部门还是业务部门，都能接受这个结果，没有争执和推诿。因为这是站在全局视角，大家研讨得出的结论，虽然有利也有弊，但都在预估范围内。
+
+你看，当我们去各类技术会议学习分享时，大家经常探讨高可用、高并发的架构设计。但在实际的工作中，这类设计不一定能实现，甚至也不一定在当下对于公司是最合理的。
+
+类似的问题还常见于中台建设。
+
+这两年中台特别火。很多技术 leader 好不容易把中台研究明白了，觉得这个设计思想好啊，回去就要搞，结果业务部门不愿意，说：
+
+“你说做中台、做中台，说了半天就是架构更好了。我们这个月的 KPI 都要完不成了，还要支持你做个半年不见效的中台？”
+
+于是，技术 leader 把自己气得够呛，觉得这哪叫“技术驱动型科技公司”，没有一点长远眼光，自己留在公司就是浪费青春。
+
+那么这又是一个有关全局思维的问题，我们要回答的，其实不是中台在架构方面的优劣势，而是在半年以上的时间维度里，中台对于整个企业，在营收增加、业务增长方面的优劣势。
+
+如果说得清楚，其实业务部门也有不小的接受可能，因为大家不但需要考虑短期增长，也会追求长期增长；如果说不清楚，其实中台做了也是白做，属于管理者自己没想明白。
+
+所以，在前面的章节里，为什么我总是强调：研发团队要有业务思维，业务团队也要接受技术指标考核呢？一个重要原因，就是要赋予双方更高维度的视角，让大家在工作中有全局思维。
+
+## 全局思维与向上管理
+
+当然，以上我们说的全局思维，都是站在更高的维度，将技术视角和业务视角统一起来，学会用业务增长的思维看待技术建设。
+
+但全局思维又不仅仅局限于此。很多人觉得老板的问题很难回答，因此比较怕和老板对话，为什么呢？因为和老板相比，你缺乏全局思维，格局不够高，因此面对老板的提问，常常感觉出乎意料、难以回答。
+
+而这一点，在每一个职级都会有所体现。一般情况，在同一家企业内，CTO 的全局思维通常强于技术总监，技术总监的全局思维通常强于技术经理，而技术经理又强于普通程序员。
+
+会出现这种差异，当然有信息不对称方面的原因，但同时也有思维格局上的高下之分。比如，很多企业都在推行“公开透明”的企业文化，但基层员工仍然和高层管理者在思维层次上有极大偏差。为何？因为从上到下，没有培养全局思维的意识。
+
+每次周会，都会有许多下属讲自己的工作情况，我的回应经常是：“**你说的都对，但这个有什么用？产品是什么，用户是谁？对用户有什么好处，对公司有什么益处？**”
+
+请注意，我不是在质疑或者否定下属，而是在强迫下属站在全局的视角去思考。
+
+刚才我们讲的是自上而下的思考模式。这段时间，也有很多同学留言说，乔老师，能不能讲讲向上管理？其实向上管理，就恰恰相反，属于自下而上的思考模式。
+
+很多 CEO 其实很讨厌“向上管理”这个词，一是听起来确实让人不大舒服，像是在沟通中，掺杂了很多心机和花样；二是在很多 CEO 眼里，“向上管理”属于伪命题：是 CEO 真的需要被管理，还是下属自以为比 CEO 更明智？
+
+听起来，是不是有点耳熟？对，这其实和下属吵架有一个共同的逻辑：双方都没说错，只是视角局限在自己这一侧。
+
+所以，所谓的向上管理，其实不像很多新媒体文章说的一样：说话先赞同再反对、和老板培养感情，等等。
+
+这些当然可以做，但都只是锦上添花，属于沟通技巧，不算向上管理。**真正的向上管理，是培养全局思维，把自己的思维拔高，和老板站在同一个维度看待问题，同时保持密切、顺畅的沟通**。
+
+不然的话，你的所思所想跟老板压根不在一个频道上，怎么“向上管理”？时间长了，老板只会觉得你自以为是、恃才傲物。
+
+那么如何培养全局思维呢？
+
+说起来倒也不难，主要是**从两个维度去尝试重新思考问题：一是时间维度，二是空间维度**。
+
+所谓时间维度，是指遇事不要只看当下得失，要学会站在未来六个月、一年甚至三年的维度看得失。很多让人难以决断的问题，只要站在更长的时间维度去看，就会豁然开朗。
+
+空间维度，则是指，不要只站在自己的视角看待问题，要时常做好身份转换。比如技术人员要考虑，站在业务部门的角度，会如何考虑这个问题？站在财务部门的角度，会如何考虑这个问题？站在 CEO 的角度，会如何考虑这个问题？这是个人所处空间上的变换。
+
+你可能会想，听起来很简单，就是挺累啊，一个问题要在不同的角度思考这么多遍，烦死了……
+
+其实，这就是思维和认知能力养成的特点：说起来都不复杂，但做起来需要绝大的毅力和耐心。在我们专栏的第一章，大部分认知能力都存在这样的学习特点。但与第一章的许多认知不同，那些属于个人成长相关的认知，而全局思维属于团队管理方面的认知：管理者不但自己要具备全局思维，还要让团队也拥有全局思维。
+
+这么难养成的认知，怎么传递给团队呢？这时就需要建立持续完善体系，让团队持续成长。可以说，如果没有持续完善体系，团队根本就不可能具备全局思维。
+
+## CTO 也可能犯错
+
+在向团队灌输全局思维时，你可能会很头疼。因为有时团队就是不理解、就是不接受，甚至会表现得很偏执，让人只想在心里骂娘。
+
+这时，你要提醒自己：**既然大家都通过了公司面试，就说明基础能力还是有的，没人真的是傻瓜。团队是能进步的，要给团队进步的时间**。
+
+其实我们专栏从上架到现在，我一直在重复这句话。很多管理者，表面上支持“试错容错”的文化，但骨子里就没期望过大家会成长。
+
+哪怕是 CTO，都会犯错，何况是普通员工呢？不给大家留出成长的时间和空间，怎么带领团队打胜仗呢？
+
+2015 年年底到 2016 年年初，我在苏宁工作，曾带着团队做关于容器编排的技术选型。当时，针对容器编排管理工具，有两个选择：一个是 Swarm，另一个是 Kubernetes。
+
+当时我们确实是努力站在全局视角去思考的：
+
+在当时，Swarm 的架构简单，是  Docker  内嵌模块，部署运维成本低，在业务角度有利于降本提效；Swarm 是 Docker 的原生编排工具，支持度好，容器的启动速度高……
+
+相比之下，Kubernetes 当时的情况就有些不尽如人意，所以我们最终选择了 Docker + Swarm 来做容器化改造。
+
+结果，还不到一年，我就知道自己做了错误的决策。你可能也看到了，Kubernetes 后续的成长速度非常惊人。于是，我召集团队，承认了自己的失误，立刻做了调整。
+
+后来复盘这件事时，我发现，在做技术选型时，我们少考虑了一个关键因素：大厂的支持能力。如果再有类似的选型工作，我一定会将大厂的支持能力作为重要的选择条件。
+
+但回到全局思维这件事上，犯错实属正常，哪怕是 CTO 也一样。就像我们常做的 A/B Test，这本就是体系建立工作的一部分。
+
+所以，当你实践这一讲所收获的认知时，如果有不耐烦、不如意的时刻，一定要提醒自己：不要急，这很正常，这些都只是成长的浩瀚大海中的一朵小浪花，都是建立持续完善体系所需的正常工作。
+
+## 结语
+
+这一讲，我们重点聊了聊管理维度的全局思维和持续完善体系的建立，这是一个不断迭代的过程。
+
+一个组织就如同一个人，如何让这个组织有格局，并且能快速学习、持续迭代，是管理者一个重要的能力。迭代，就意味着前面有不完美的地方，在全局视角下具备纠错能力，用更短的周期、更快的速度持续完善，这样组织能力也会随着时间，不断登上新的台阶。
+
+最近，我和一些 CEO 聊天，问他们过去在管理上最大的失误是什么，有好几位都是想了半天也说不上来。为什么？不是因为没犯过错，而是因为对于他们来说，试错、迭代都是正常流程，被正常迭代掉的问题能叫失误吗？当然不能，那本来就是规划之内的情况。你想想，自己和这些 CEO 是否有这种认知上的差距？你能否以同样的心态，看待自己的成长？
+
+**我相信，你一定能做到快速成长。或许现在，也可能是未来的某一天，你也会是那个“没犯过错”的 CEO。**
+
+今天的内容到这里就结束了。下一讲，我们会重点谈一谈，在具备了全局思维后，如何在战略上做聚焦、做取舍，真正做到 CEO/CTO 级别的认知协同，为跨上新的台阶做好准备。
+
+我们所讲的管理者“三板斧”、管理哲学、全局思维、战略聚焦等内容，都是关联在一起的，你在看的时候，要注意前后对照，串联起来。这样的成长才成体系，才不会有失偏颇。
+
+如果有问题，欢迎随时向我提问。我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对管理工作的复盘/12 | 管理战略上的聚焦和放弃：有舍才有得.md

@@ -0,0 +1,149 @@
+<audio id="audio" title="12 | 管理战略上的聚焦和放弃：有舍才有得" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9c/97/9c7038c4d832547682e34ea2ea496997.mp3"></audio>
+
+你好，我是乔新亮，很高兴又和你见面了。
+
+上一讲，我们聊了聊全局思维和持续完善体系的构建，目的是为了拔高自己的视角，赋能整个团队。但有一个问题也会随之出现：视角拔高了，看到的问题也就变多了，需要做的工作也就变多了，怎么办？
+
+你可能会想，做啊，成长的机会来啦！
+
+心态很好，很棒！但同时我们也要认识到，管理者不是超人，一个人很难同时在多个有挑战的任务上，全部实现突破。
+
+如果你不去区分工作的重点，就可能就会引发种种连锁问题。好一点的情况是，你把任务都完成了，累得够呛，但全都没有亮点和突破，流于平庸；坏一点的情况是，你高估了自己的执行能力，多个任务严重 delay，产生协作问题，也非常影响自身心态。
+
+你可能会想，这么吓人，那我还是不要主动给自己找活干了？
+
+当然也不要这么想。我认为，企业现阶段存在的那些价值大、急迫、有挑战的工作任务，如果看到了，就可以去主动接下。但接任务的同时，要学会聚焦，在企业战略上聚焦、在管理工作上聚焦、在个人成长上聚焦，先实现单点突破，再横向扩展至其他领域。
+
+用直白的话说，就是“伤其十指不如断其一指”，越是宏大的成长目标，越要徐徐图之。
+
+比如说，我们的专栏到现在已经更新超过十讲了，单是管理者的基本任务就有“三板斧”之多，你听了、学了之后，要怎么实践呢？肯定是一点一点实践，一口一口“吃饭”。**在一定时间内，只将注意力聚焦在其中一个板块上。对于初级管理者来说，这一点尤其重要**。
+
+以前，我们常常只在讨论企业战略时谈聚焦，就像阿里巴巴曾鸣说的：“战略，就是决定该做什么，不该做什么。”
+
+但本质上，无论是对于一名普通程序员来说，还是对于一名初/中级管理者来说，聚焦都很重要。
+
+在我刚毕业时，就曾经切实尝到过「聚焦」带来的益处。
+
+## 普通技术人聚焦个人成长
+
+刚毕业时，我在神州数码做一名普通的程序员，后来跳槽至麒麟远创，薪资变成了 2.5 倍。
+
+如果你还记得专栏「认知」部分的内容，应该会知晓我的这段经历。不知你有没有想过，为什么我在工作不到两年后的第一次跳槽中，就能让薪资上涨 2.5 倍呢？
+
+在做个人成长的复盘时，我觉得其中一个重要的原因是：我在不经意间，做到了个人成长的战略聚焦。
+
+刚到神州数码，我就在负责工作流引擎的研发工作，这个工作内容持续近两年。到我离职时，我在团队内的标签就是：“工作流引擎方向的技术专家”。
+
+请注意，一个程序员身上可以有非常多的标签，比如：Java 专家、架构专家、算法专家、存储专家……但在那时，我身上的标签只有一个，也就是工作流引擎专家，这就是聚焦。
+
+而麒麟远创愿意以 2.5 倍薪资招募我，也是因为我能在非常重要的岗位上，承担起与“工作流引擎”相关的工作。这就成了我的突破点，是我能上台阶的核心原因。
+
+这就像我和咱们专栏许多读者都说过的，一定要做“T”型人才，也就是说，首先要在某个维度成为专家，广度都是深度的附属。
+
+如果在神州数码时，我今天学学存储、明天学学算法，怎么可能在这么短的时间内就有所突破呢？很多同学在极客时间是什么都学，没有目的也没有方向。这种学习精神固然是可贵的，但人的时间是很有限的。
+
+可能你还要谈恋爱、还要和朋友聚会，最后留给每一项技能的时间都不是很多。说白了，在今天这个知识爆炸的时代，学习一些基础技能很简单。
+
+我有信心在三个月内，成为一门编程语言的专家。而且，学习能力像我一样，或者比我更强的人一定很多。这就意味着，你耗时一年，分心学到的 Java 编程知识，可能还比不上别人认真投入三个月的学习成果。
+
+更别提许多人工作了三年、五年后，还不敢称自己为某一门编程语言的绝对专家。
+
+现在，我越发明显地感觉到：这个社会不会奖励面面俱到，但都很平庸的人，光环永远属于那些有明显优势、有明显长处的人。
+
+**成长就是为了变得更优秀，而优秀的含义是：做同样的事情，表现比别人更好。**
+
+我也曾见过一个朋友，在创业公司做到技术总监，去到大厂却拿不到一个高级技术专家的职称，非常可惜。为什么呢？因为无论是在分布式、数据库还是团队管理领域，他都是浅尝辄止。面试一问到深度技术问题，立刻就傻眼了 —— 完全没接触过。
+
+请注意，他可不是不努力。他也会天天加班，只是不够聚焦而已。
+
+所以，聚焦不但会影响成长的速度，还会影响成长的质量。
+
+这里，我们说的是在程序员阶段，如何在成长中贯彻聚焦的思想。因为这一阶段，你的角色是 “Do”，执行公司派发的任务。所以，所谓「聚焦」更偏向个人成长。比如，花两周的时间，让自己的代码变得优雅整洁。
+
+注意，此处的重点在于“有目标”，用目标指引自己的学习，找到工作的重点。找到重点，是为了让自己在这一领域变得更优秀。目标可以很小，但长年坚持下来，优秀就会变成一种习惯。积累得多了，更宏伟的目标就是实现了。
+
+当然，这种成长不是线性的。到了初/中级管理者阶段，要做到「聚焦」，也会相对复杂一些。
+
+## 初/中级管理者聚焦双线成长
+
+作为初/中级管理者，你的角色变成了“Manage”，职责是协调团队完成任务。
+
+话虽如此，但很多身处这一阶段的管理者，并未脱离一线工作（我也不建议大家过早脱离一线技术工作）。
+
+因此，你可能会问：乔老师，这时我到底是聚焦个人技术成长，还是聚焦管理能力呢？我感觉我的技术还没那么强，能直接聚焦管理工作吗？
+
+对于这两个问题，尤其是后一个，**如果你非常纠结，可能就说明你的技术能力还不够，两手都要抓。**
+
+当初我在下定决心走管理路线时，对自己的技术实力是有很大信心的。而这种对于技术的坚持和信心，也为我后来的管理工作提供了相当大的支持。可以说，越往高处走，越能感受到这种技术积累对自己的价值。
+
+技术与管理两手抓，肯定是加倍的累，这毫无疑问。但反过来看，这也是成长的好机会，你很幸运，这么早就有了跨台阶的机会。我们前面讲了，五年就要登上一个新台阶，多难啊，这样的机会多宝贵啊。
+
+想要加速成长，就只能付出比别人更多的努力。世界上没有容易走的路，如果走得太容易、太顺遂了，也可能会给未来埋下更大的隐患。
+
+那么，技术钻研到什么程度，才可以放心聚焦管理技能呢？我认为，当你的技术深度，足以辅导团队做技术选型和决策时，就可以聚焦管理了。但具体时机，要靠你自己去判断，因为每个团队的情况都有所不同。
+
+打好技术基础后，先别急着聚焦管理层面的工作，最后问问自己：**你真的想做管理吗？**
+
+其实在 IBM 的一段时间里，我是向公司申请在纯技术路线发展的，也为此付出了很多努力，成为了 IBM 认证架构师、全球技术学院成员……
+
+促使我转向管理岗位的直接原因，是我意识到：有许多工作价值，只能靠团队的力量实现，个人能力再强大也于事无补。我认为，管理的价值会随着团队规模的扩大而增加，在一般情况下，会超过大部分技术专家的价值。
+
+但这毕竟是我的想法，于你而言，还是要慎重考虑。
+
+如果以上问题，你都已经思考得很充分了，那么恭喜你，可以聚焦管理工作了，尝试去思考管理的价值所在，让自己在技术方面的专业度，成为做技术选型、技术决策的重要支撑。
+
+如果你没有头绪，可以按照我们前面分享的内容，一步一步聚焦「管理三板斧」的落地。
+
+比如说，先聚焦「组织调整到位」，把组织建设做好。你可能会说，老乔，我的团队只有五个人，怎么聚焦组织调整啊？你讲的那些我都用不上。
+
+错了，我们讲的许多管理内容，其实和管理者下辖的团队规模关系不是特别大。团队只有五个人？没关系，你要同直属领导说清楚：你所负责的技术或业务，要实现什么样的目标？理想状态下需要多少人？
+
+我是在 2020 年三季度末，开始接手彩食鲜的  BBC  业务。当时，整个 BBC 平台部门的人数还比较少，我接手后，直接将编制调整到原来的两倍以上。为什么呢？因为我的目标是，部门业绩要季度环比增长 70%，这个人员编制，是按我的业务目标来配置的。
+
+千万不要觉得团队有多少人，就承担多少人的工作量。如果你是这么想的，可以重读一下上一讲：「全局思维和持续完善体系的建立，让团队持续成长」，再深入地理解一下，这里我们就不再展开了。
+
+你看，上面所说的就是聚焦「组织调整到位」。当然，你还可以聚焦「加强协同效率」、「激发团队活力」或者「管理的人性哲学」，只要合理，就都没关系。
+
+重点是要聚焦，实现突破，啃下一块硬骨头，再去啃下一块。
+
+对于管理工作来说，聚焦的终极目标是「组织成功」，这是个体系性问题。要学会在一定程度上，**忘记个人的辛苦和努力，因为那只能代表你的个人成长**。
+
+## 舍九取一，聚焦和放弃紧密相连
+
+讲到这，你不妨思考一下：做好聚焦，难吗？
+
+我认为，只要认知到位了，做聚焦其实不难。很多人其实都了解「聚焦」的概念和价值，但真正去实践的人却不多。
+
+因为困难的不是聚焦，而是舍弃。
+
+许多人会下意识地忽视这一部分，心里盼望着：在一定时间里，我聚焦了重要的工作，同时又没落下其他任务。
+
+可这几乎是不可能的。
+
+我个人经常出席一些技术或管理会议，这样的分享机会让我个人非常受益，因为我的准备通常很充分，对这样的交流和分享机会也很重视。在筹备每场演讲时，我个人的时间和精力是高度聚焦的。
+
+但也有很多技术管理者，虽然参加了会议，却十分敷衍，说自己：太忙了，又要加班、又要陪家人、又要聚会，没有时间好好准备。
+
+什么都舍不得放弃，最后的结果只能是：现场演讲效果不理想，不但花了时间，还没有获得相应的收益。
+
+所以，你一定要留意：在大部分情况下，**没有放弃，就意味着没有真正聚焦；有舍弃，才有收获。**
+
+我常常说，舍九取一，只有舍弃掉 90% 干扰事项的人，才可能真正聚焦那 10% 的核心任务。
+
+那么聚焦哪些，放弃哪些，如何决策呢？这就又回到了我们上一讲的内容：培养全局思维，只有看到全局，才能做好聚焦。**看清问题全貌，是做好聚焦的大前提。**
+
+## 结语
+
+今天，我们聊了许多关于聚焦的问题，也有一些关于舍与得的思考。但对于高级管理者来说，如何在 “Lead” 的角色下，做好企业战略层面的聚焦，则没有谈。
+
+因为对于企业和高级管理者来说，对聚焦的思考，要与企业情况、产业趋势紧密相关。每家公司的情况都有所不同，是不存在标准的答案的。
+
+对于普通程序员和初/中级管理者，也要灵活、辩证地看待这个问题：
+
+第一，所谓聚焦，不是让你随心所欲地乱选发展方向。要多问问自己，企业现阶段最需要的能力是什么？行业目前最稀缺、最有市场的能力是什么？如果公司目前需要 Golang 开发，结果你去学了三个月 Java 开发，学完以后发现工作中用不上，就有点尴尬了；
+
+第二，不要因为做了聚焦，就回避其他一切任务和需求。该付出的时间和精力，还是不要吝啬，只是要时刻记得：自己是有目标的，自己是做过聚焦的，要为之努力。
+
+到这里，本节内容就基本结束了。后面，我们还有两篇关于「全局思维」和「战略聚焦」的延伸分享，更加贴近实际工作，名字分别叫作「需求做不完，应该怎么办？」（初/中级管理者篇）、（高级管理者篇），希望能给你带来更多启发，也欢迎你持续关注，多提意见。
+
+我们下一讲再见！

极客时间专栏/geek/乔新亮的CTO成长复盘/对管理工作的复盘/13 | 风险管理：世界是脆弱的，持续管理风险非常重要.md

@@ -0,0 +1,179 @@
+<audio id="audio" title="13 | 风险管理：世界是脆弱的，持续管理风险非常重要" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d7/82/d78f93b4f3fd45017ffc15be9fbb9b82.mp3"></audio>
+
+你好，我是乔新亮。
+
+这一讲，我想和你聊聊有关风险控制的话题。
+
+世界，其实是非常脆弱的。几天前，我接到一个电话，得知一个原来公司的下属，因为车祸意外去世了。我和他关系很好，但此时只能感叹生命无常；2020 年，仅仅因为国内外对口罩文化，以及一些疫情防控措施理解的偏差，新冠病毒就得以在世界范围内不断传播，难以遏制……
+
+今天，可以说我们做的任何决定都存在风险，风险可能会成为真的“险情”，也可能永远都只是个风险，这只是个概率性事件。但“墨菲定律”告诉我们：如果事情有变坏的可能，不管可能性有多小，它总会发生。
+
+刚加入苏宁的时候，我去评估各个系统的高可用方案。其中一类，就是 UPS（不间断电源，Uninterruptible Power Supply） 供电方案。提供服务的是一家世界知名公司，这家公司和数据中心团队多年前共同决策了“ N + 1 ”型保护策略，也就是说，假如系统存在 N 个 UPS，任意一个出现问题时，都不会使业务受到影响。
+
+可我本来是想要的是 “2 N” 型保护策略，也就是说，假如系统存在 N  个  UPS ，即便全都出现问题，业务也不会中断。但团队反馈说“ N  +  1 ”方案已经非常成熟，并称：很多金融机构也在使用 “N + 1”策略，多年来没有出现任何问题。当时，我对 UPS 方案不太熟悉，听到对方这么说，也就同意了。
+
+结果，怕什么来什么。有一天，“N + 1”型策略失效，一个机房断电了。意外出现后，为了确保业务连续性，我不得不连熬了三个通宵。
+
+从那以后，我就打定主意：一定要做好调研、做好风险控制，绝不接受自己不熟悉的方案。
+
+如果你是做金融、做架构的同学，对这样的故事一定很熟悉，因为无论是金融业务，还是架构设计，都对系统风险十分重视。在技术维度，如何做好风控，已经有非常详尽的教学和方法。
+
+但当我们回归管理话题，又应该怎么聚焦风险控制呢？如何在与人打交道时，做好风险控制呢？
+
+我们通过一个典型案例来聊聊。
+
+## 打卡，本质上是个风险控制手段
+
+在互联网这个圈子里，打卡是一件特别有意思的事儿。
+
+- 有的公司严格打卡（很多公司还是指纹打卡），迟到一次扣 50 块钱；
+- 有的公司虽然打卡，但可随意补签，并不严格限制；
+- 有的公司没有打卡，上班下班全靠员工自觉，HR 一般还会在招聘启事中自豪地写出来；
+- 有的公司是开始不打卡，后来开始打卡，还很严格；
+- 也有少部分公司，是一开始打卡，后来逐渐开始不打卡；
+
+……
+
+可以说，大家的做法千差万别，但整体上，可以归纳为以上几种方式。那么，哪种做法更好？
+
+我猜你一定会说，不打卡好，因为这么干更有互联网范儿，员工自驱度更高，等等。
+
+别急着下结论，我们先把思维拔高到全局视角，重新审视这个问题。在公司的角度上，打卡只是个行为，更准确地说，应该叫“考勤”。
+
+考勤，顾名思义，就是考核出勤，是 CEO 要迫使公司全体人员，遵守工作时间。简单些说，就是 CEO 想：我都按月发工资了，你们起码按时来上班吧……
+
+其实到这里，我们的思维还可以站得再高一点。**为什么要按时上班？从目标和结果来看，这是为了让团队有一个稳定的工作产出，也就是说，要给组织的价值产出定一个下限。**
+
+这背后的逻辑是：虽然同样是 8 个小时的工作时间，每个人能做出多少成绩是不确定的。但无论你的能力是强是弱，每天至少干够 8 个小时。长期来看，产出不合格的，就培养，培养无效就淘汰掉；产出超过预期的，就提拔，逐渐成为公司内的重要成员……
+
+这么一看，在互联网圈内盛行的加班文化、996 文化，就很好理解了：这是老板要提高组织产出的下限，从公司全员每天至少有 8 个小时的产出，“提升”到全员每天至少有 12 个小时的产出……
+
+但一个每天工作 8 小时的员工，和一个每天工作 12 个小时、14 个小时的员工相比，谁的价值更大呢？不确定，因为员工能力千差万别，工作态度也是千差万别。只是一般来说，在同等级别做对比，工作时间越长，价值越大。
+
+所以你看，这就是个有关风险控制的行为措施，如果全公司的价值产出始终低于生产成本，公司就倒闭了，老板要控制这个风险。
+
+## 风险控制，重要的是尺度
+
+说到这，你可能就急了。老乔，看来你是支持 996 了！还给加班、考勤找了个这么“清新脱俗”的借口。
+
+我得声明一下：我经常跟我的下属说，希望大家不用疯狂加班，一张一弛、文武之道，要合理调节自己的生活和工作节奏。
+
+但彩食鲜是需要打卡的，这点也很明确。但我们虽然打卡，却不与任何工资、绩效挂钩，没有任何实际利益上的影响。很多人不信，琢磨着：不可能，嘴上说着没影响，暗地里肯定给数据好的加薪，给数据差的绩效减分。
+
+我也很无奈，只能和大家公开去聊：到底是不是这么做的，大家注意去看就好了，时间会证明一切。如果你实在不相信，我也没办法，团队协作是建立在信任的基础上的。
+
+那么，每天让全员打卡，同时又不与绩效挂钩，打卡还有什么意义呢？
+
+答案是，**打卡是为了收集数据，作为团队健康度评定的重要依据**。
+
+如果数据显示，一个人天天五点、六点下班，工作产出却不怎么样，说明他的成绩不好，还不努力。这很可能是他干得不开心了，问题出在心态上，直属 leader 要找他聊聊了；
+
+如果一个人天天加班，但产出很不错。说明他可能工作太过饱和，或者工作方法有问题，管理者同样要去关注一下；
+
+反过来，如果一个人天天五点、六点下班，产出却还是非常好，说明了什么？说明他的能力超过了当前岗位的要求，很可能正在等待成长机会，管理者更要主动联系，给下属上台阶的机会；
+
+当然，如果一个人天天加班，产出还很差。管理者就要和他深度聊一聊，到底是哪些部分出了问题。
+
+你看，这样的组织是不是更有活力了？通过一个打卡数据，是能非常清晰地看到组织的健康程度的。彩食鲜要求打卡，就是为了长期达成这种效果。
+
+以上每一种具体行为，都是在控制风险，而且控制的范围很广，包括价值产出、团队建设、防止人才流失，等等。但在大部分情况下，管理是不能走极端的，把握好尺度是管理真正的奥义。
+
+**有的人做风险控制，会试图把一切情况都控制在手里**：指纹打卡、迟到扣钱、缺勤开除；有的人是压根没有风险控制的意识：从不打卡，也不关注，找不到人就微信问问……
+
+哪种风险控制做得对？我觉得可能都不对。前面我也讲过，要有全局思维，站在公司最终利益的角度进行决策，时刻问自己：这么干对业务增长有啥用？管理是为了不管，不是为了将一切都攥在手里。**高层应该给予团队一个关键且唯一的价值导向：我们需要并奖励那些自驱力强、有 Owner 意识、不需要我去管理的团队成员。**
+
+如果你把打卡拿捏得很死板，“打卡”这件事，就与高价值、高自驱、有创造力等企业文化导向割裂开来，变成了一个需要额外背负的“讨厌”任务。团队能清晰地感知到：leader 对我完全没有信任可言。大家会将打卡当作一个机械性的任务去完成，按时打卡却毫无建树成为组织的新常态。
+
+最终，团队内可能充斥着各类听话却没用的“老好人”。因为，这就是管理者通过实际行动给出的要求：你们必须按时打卡，其他的另说。
+
+至于完全不关注打卡的管理方法，在团队规模很小时，或许可行。但随着组织规模的快速提升，问题就会逐渐暴露：对组织健康度的感知越来越差、对组织人均投入产出比的感知越来越差……
+
+所以，很多企业的情况是：早期小而美，是个充满了信任、不需要风控的极客团队；融资一到位、规模一扩张，立刻与前一种企业殊途同归，成为管理到牙齿的“传统企业”，恨不得把 GPS 都给员工装上……
+
+哪种做法好？当然是都不好。有时过分注意风险、有时将风险完全抛在脑后，过犹不及，这都属于没有拿捏好风险控制的“度”。
+
+因此，很多人觉得管理“务虚”，其实不对，管理只是用专业的认知和技能，去给出位于“灰色地带”的团队协作方案。
+
+## 有效的风险控制：高层不能战略懒惰
+
+前面我们通过打卡考勤这件“小事”，聊了聊在管理层面，风险控制的尺度问题。
+
+有没有注意到，在彩食鲜，尺度虽然对了，但执行起来很困难？leader 要结合那么多人的打卡数据和工作产出作分析，再一对一进行沟通。这样的风险控制，工作量真的不小。
+
+所以说，管理者这个岗位，理应，也确实是非常辛苦的。也恰恰是因为这样，在实际情况中，最能偷懒的往往不是基层员工，而是高层管理者。
+
+因为员工的工作单纯明确，还会受到 N 个层级的管理者考核；而高层管理者的角色不是 Do、Manage，而是 Lead，主要解决战略问题，工作复杂模糊，能接受到的引导、考核非常有限。
+
+所以，在我的观察下，高层战略懒惰是个很普遍的现象。大部分企业懒得都快”退化“了，却仍然没有意识到问题的严重性。因为高层每天都在干着中层管理者的工作，面对战略难题迟迟不能解决。
+
+还是回到打卡这件事，管理者想要偷懒是很容易的：严格打卡，一个季度迟到 10 次绩效 B，迟到 15 次以上，直接协商离职。
+
+这么干多省事啊，通过数字定绩效，系统都能帮你搞定。
+
+但最有效的风险控制，永远是率先发生在高层的。注意，这里我要强调“最有效”。
+
+自下而上，也能做好风险控制。比如，团队出现矛盾、人才大量流失，普通员工反映到经理、经理反映到总监、总监反映到 CTO、CTO 重新做个调研和了解、CTO 和 CEO 开个会，问题解决了。
+
+而自上而下的风险控制，则是要求 CTO 先将这件事想明白，对风险有充分评估，和 CEO 开个会，将问题解决掉。
+
+显然，第二种方法更高效，更容易达成目标，对组织的伤害也更小。
+
+如果你是高层，一定要时刻提醒自己：今天有没有偷懒？有没有和中层管理者抢工作，却对战略问题、全局问题视而不见？
+
+当然，如果你是普通员工或初/中级管理者，也大可不必为此埋怨高层管理者。在前面的章节里，我曾反复强调：要有同理心、要有全局思维，每家公司在特定阶段都有自己的难处，要学会理解。**我们常常讲同理心，说的不光是高层对基层要有同理心，也包括基层对高层的同理心。**
+
+## 实际可操作的风险管理
+
+抛开高层战略不谈，基层也可以有行之有效的做好风险管理的办法，这关乎自己的成长。就像我们曾提到，项目立项有三点要求，需要尤其重视：
+
+1. 目标清晰；
+1. 责任到人；
+1. 承诺到位。
+
+这三点来自我实际的工作经验总结，非常简单实用。如果在某一次项目执行中，相关人员没做到，往往就意味着风险已经产生。所以，风险控制是个长期工作，要持续不断地推进。
+
+第一点，目标清晰，是指目标要逐条写下来，按照 “SMART 原则”公示。“SMART 原则”出自彼得 · 德鲁克《管理的实践》，其含义是：
+
+1. S=Specific，目标必须是具体的；
+1. M=Measurable，目标必须是可以衡量的；
+1. A=Attainable，目标必须是可以达到的；
+1. R=Relevant，必须要与其他目标有一定的关联性；
+1. T=Time-bound，目标必须具有明确的截止期限；
+
+第二点，责任到人，是指每条目标必须与责任人一一对应。你可能会问，老乔，我们目标比较大，下面有一堆责任人，怎么对齐？
+
+很简单，将每位参与者的名字都写在文档里。名字排在第一位的，要负责将目标拆解、分派下去，如果目标没达成，他负最终责任；当然，如果目标实现了，他也享有最大的功劳。举个例子，如果将公司业绩的总体增长量化成 OKR 的其中一个 O，那么 CEO 的名字就应该写在第一位。
+
+第三点，承诺到位，此处在有外部部门参与协作时，显得尤为重要。很多项目比较急，大家又比较忙。可能还没等到协作部门明确的承诺，大家就急吼吼地启动了。这么干肯定是不行的。
+
+以上三点，任何一点没做到位，都属于没做好风险控制，会让项目产生极大的管理隐患。
+
+不过，即便你将以上三点都做到了，也不代表项目就不会出问题。
+
+第一，余下的解决思路大致可以归纳为：要么向上求，要么向下求。也就是说，要么由高层去体系化地解决，要么深入细节，协调沟通好团队内和团队间的各类问题。
+
+“向上求”一般只能由高层完成，“向下求”的发力点则很多。每周周会，我都会问下面的 Leader 们：有什么问题需要我帮忙解决吗？同时，我在制度中规定，如果有问题，必须及时暴露问题；如果当时没有暴露问题，我会去了解原因，是当时没有意识到问题的存在，还是其他原因；如果隐瞒不报，严肃处理。你看，这就是管理的逻辑闭环，让机制能够运转起来。
+
+第二，在文章的开头，我们也说了，风险是个概率性事件，概率只能升高或降低，几乎不可能归零。说白了，即便你的架构设计得再好，如果所有机房都地震了，一样没办法。**人要有勇气接受一些风险，因为彻底规避风险的代价太大了**。这里又涉及到辩证看待问题的思维方式，如果时间允许，建议你仔细揣摩一下。
+
+## 结语
+
+俗话说得好，人无远虑，必有近忧。
+
+技术人对“高可用”设计耳熟能详，因此对风险控制也多有接触。但恰恰越熟悉的概念，就越容易成为盲区，尤其是在管理领域。很多概念在初见时，甚至会感觉是有些矛盾的。
+
+要在管理层面做完备的风险控制，出发点一定是“假设每个人都会出问题”。但结合我们前文所谈的“打卡”事件，风险控制又是要建立在信任的基础上的 —— 在打卡的同时，却不与绩效直接挂钩。
+
+因为我相信团队里的每个成员都很聪明、也很职业，相信 ta，敞开心扉与 ta 沟通。管理不能因噎废食，不能因为个别成员有问题，就拒绝相信所有人。如果仅仅因为不信任，就无限制增加各种管理手段，最终就等同于绑住了公司的手脚。
+
+我必须要再重复一遍，**管理是为了不管**。这是在经历了这么多年的技术管理工作后，我领悟到的特别深刻和精华的一点。
+
+谨记，当你陷入矛盾或者两难境地时，就意味着可能每一种选择，在特定环境下都是正确的，你需要的是全局思维、拔高视角。
+
+在高维视角来看，打卡最终的目的是提高产出，让团队自驱。这样一来，我们就很容易制定方案。
+
+我常常跟团队说，今天我们的很多制度和措施，都是建立在信任的基础上的，但是请千万不要破坏这种信任。你看，这种“耳提面命”，也是一种成本很低的风险管理。
+
+如果你还有其他好的方法，或者想要提问，也欢迎在评论区留言。我们一起交流、一起复盘、一起成长。
+
+让我们下一讲再见。

极客时间专栏/geek/乔新亮的CTO成长复盘/对管理工作的复盘/14 | 需求做不完，应该怎么办？（初|中级管理者篇）.md

@@ -0,0 +1,157 @@
+<audio id="audio" title="14 | 需求做不完，应该怎么办？（初/中级管理者篇）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a6/8d/a6b645e69bcb089yya116fd4a855a28d.mp3"></audio>
+
+你好，我是乔新亮。
+
+在前面的内容里，我们讲到，技术管理者既要具备全局思维，也要做好战略聚焦。站在 CTO 能力建设的维度上，这当然是非常关键的。
+
+具体到实际工作中，我该如何去锻炼这些能力？全局思维和战略聚焦，又如何帮助我做好当下的工作呢？
+
+所以，在接下来的两讲中，我决定暂缓专栏前进的脚步，邀你坐下来，围绕一个实际问题好好聊聊，这个问题就是：“需求做不完，应该怎么办？”
+
+相信聊过之后，我们对管理的认知会更丰满、更透彻。
+
+## 需求永远都做不完
+
+最近几年，经常有人问我：老乔，你平时是不是特别忙？其实我不怎么忙，空出来的时间都用来思考公司业务了，尤其是在最近的一年。
+
+我相信，这个答案和很多人想的不一样，可能也包括你。原因很简单，在当下的互联网大厂里，光是普通程序员，就已经很忙了，管理者身上的责任更重，那么理应更加忙碌。再者，我平常总是提倡“高层不能战略懒惰”、“高层要以身作则”，这样一来，岂不是一天都睡不了几个小时了？
+
+在某些成长阶段，这么想倒也不算错。比如，你刚刚登上了一个新台阶，成为了技术经理、总监、CTO，感觉辛苦是很正常的，睡眠时间确实也会受到影响。
+
+但我必须要告诉你，**对于任何一名走管理路线的技术人来说，工作状态长期<strong><strong>过于**</strong>饱和，都是一个危险的信号</strong>：说得功利些，这会导致你很难升职。试想一下，如果你管理 100 人都难以抽身，又怎么管理 1000 人、10000 人，并承担更多的决策任务呢？
+
+在跨上新台阶的早期，辛苦很正常；**在新台阶工作了一定时间后，还是很辛苦，就要好好反思自己的工作方法和认知了**。
+
+既然这样的状态不正常，我们就不妨简单分析一下，所谓的技术人很忙，到底是在忙什么呢？对于大部分管理者来说，我相信忙碌的原因可以用一句话总结：需求太多，做不完。
+
+程序员升任管理者之后更是如此，因为除了在一线完成项目，还需要做好团队管理、团队建设，处理和部门有关的“杂事”。很多技术人，本来还能耕耘好自己的“一亩三分地”，可自打负责整个团队后，就很少睡过囫囵觉。
+
+我猜，此时正在阅读这篇专栏的你，也是如此；又或者，以后的你，很可能会遇见类似的情况。所以，今天我打算聊聊，当需求做不完时，应该怎么办？
+
+首先，你要知道，需求永远都做不完，工作永远都做不完，这是个无限游戏。所以如果你对我说：“老乔，我太忙了，需求太多了，一个接一个。”
+
+我只能回答：“没错，你想想，需求什么时候做完过？”
+
+很多同学觉得老乔说的“管理三板斧”、培养全局思维、聚焦能力、风险意识，说的都对，可我就是没时间干。最近需求太多，每天都加班。可需求永远都做不完，忙完了这个月的，还会有下个月的，你打算什么时候开始提升自己呢？
+
+需求是做不完的，这是事实，但也不代表我们就束手无策，就应该放任自流，这会极大影响我们的成长速度。 而且我们之前聊过，在技术管理者的职业生涯里，最好每 5 年就能跨过一个台阶，不然可能会进入职业生涯发展瓶颈，遇见种种诸如“35 岁中年危机”之类的困扰。
+
+当然，你也别担心，从我的个人经历来看，解决这类问题的方法并不复杂。只是对于初/中级管理者和高级管理者来说，方法各有不同。
+
+## 初/中级与高级管理者的定位差异
+
+首先，针对“工作/需求做不完”这个问题，我认为**初/中级管理者和高级管理者应该区别看待。前者主要解决效率问题，后者主要解决价值问题。同时，效率问题要和价值问题围绕同一目标进行对齐**。
+
+什么意思呢？“价值问题”的核心是要对需求的价值和正确性作出回答，明确需求在公司季度目标中的地位，决定需求的优先级。本质上，这是个高层战略问题。
+
+而在很多公司里，初/中级管理者，很少有砍需求、调整需求的权利，在公司级战略决策里也没有话语权，所以只能解决效率问题，当需求下达时，尽量做到最好。
+
+听起来有点残酷，像个“工具人”，但事实如此，你只有接受现状，才能改变现状。
+
+看到这里，你可能会想，太啰嗦了，说这些有用吗？
+
+当然有用，做好自我定位太重要了：如果你是初中级管理者，还喜欢天天找 CEO 聊价值和战略问题，可能会“死”得很惨 —— CEO 会觉得你做的不好，还给自己找借口；如果你是高级管理者，却仍然在处理效率问题，那就是严重的失职，战略上过于懒惰。
+
+如果你已经做好了自我定位，接下来我们就聊聊，需求做不完，初/中级管理者应该怎么办？
+
+## 难度最低的办法：保持专注
+
+前面我们讲了，需求做不完，但初/中级管理者仍要解决效率问题。
+
+若是在培训体系健全、手下皆是精兵强将的企业还好，管理工作倒也挑战不大；若是下属能力偏弱，普遍缺乏独当一面的能力，情况就不一样了：
+
+1. 你被迫开始高度关注团队任务的执行情况，在早期甚至需要代替下属完成部分工作；
+1. 你被迫开始重视团队建设，因为缺乏“猛将”而苦恼；
+1. 一般初/中级管理者还承担着部分一线工作任务，工作任务繁重（这里我也不建议初级管理者脱离一线任务）；
+
+……
+
+这时，项目管理需求、团队建设需求、正常的研发需求纷至沓来，不少管理者就开始吃不消了。这同时也是最初我在技术管理岗位上的真实写照。
+
+那时我沉迷于并发式处理工作，一会回个邮件、一会回个微信，经常同时关注好几件事情，像电视剧中的职场强人一样：八面玲珑，自我感觉效率还挺高。
+
+后来因为职位不断提升，需要处理的问题也更加复杂，不得不用更多的时间专注思考一个问题。时间久了，我才突然意识到，原来“并发式”工作法弊端很大，其实专注做事的效率更高。
+
+首先，如果你一会看看钉钉（或者飞书）、一会看看邮件、一会回复个紧急需求，大脑在繁杂事项间不断切换，一天下来会很累。我认为这是导致效率降低的主要原因之一。
+
+其次，专注做事情更有目标感，相应地也更有成就感。现在许多人都会列出一天的工作清单，但成就感往往来自任务的完成数量，比如今天划掉一大片待办事项，就会很开心。这当然没问题，也算是一种从工作中找到成就感的方法。但我认为，**对于脑力劳动者——尤其是管理者来说，更好的方法是从月度、季度工作目标中寻找成就感。**
+
+我常常对我的下属说，周报不能写流水账，我不想知道你今天做了啥、明天做了啥，又不是怀疑你磨洋工。哪怕你一周就写一件事，只要对季度目标的达成有利，我觉得都没问题；反之，哪怕你一周写了一百件事，如果和季度目标没关系，我认为可能都是白费劲儿。
+
+你看，**其实专注做事的认知和目标导向等企业文化，都是相辅相成的**。
+
+## 80 分管理者：学会时间管理
+
+当然，保持专注仅仅是解决效率问题的第一步。若是给初/中级管理者打个分，此时你能得 60 分，勉强及格。那些拿到 80 分的管理者还掌握着另一个方法：时间管理法。
+
+说到这里，你可能会微微撇嘴：我当是什么了不得的秘籍，原来就是被各路畅销书、公众号重复了百八十遍的时间管理。
+
+没错，时间管理是个基础概念，任何人都可以通过看书掌握这项技能，我亦不打算一步一步解释方法论。但据我观察，知道“时间管理”这个概念的人很多，但真正将时间严格管理起来的人却很少。
+
+其中一个主要原因是，意外太多了。当你辛辛苦苦做好了一天的时间规划，一个突发情况就可能将其全盘打乱，比如领导叫你开会、线上出了个 Bug，等等。反复几次，所谓的时间管理还有什么意义？计划赶不上变化，大家常常这么安慰自己。
+
+可随着管理经验的逐渐丰富，我发现一个明显的事实：**一个始终在处理紧急问题的管理者，不可能是一个优秀的管理者，管理者不应该是职业“救火队长”**。这就意味着首先，要学会用团队力量解决部分紧急任务；其次，在时间规划中，要为紧急问题预留时间；最后，即便是紧急任务，也要有取舍，也要区分优先级，尤其是初/中级管理者。
+
+说白了，你要时刻想着自己的 KPI 、OKR 是什么，在每个季度末、月末，上级会通过哪些指标考核你？我相信，考核标准一定不是你回复领导消息有多么及时。
+
+你看，很多事情其实并不复杂，想清楚利益关系，就知道该怎么做了。优秀的高级管理者永远希望下属有思考、有权衡，能优先做最重要的事情，能成就业务；而不是只知道听老板的话，不懂得思考。
+
+接下来，我们再看看满分管理者的特质。习惯了专注做事，做好了时间管理，提升的只是你个人的工作效率，作用有限。只要团队中存在几个能力偏弱的下属，你的工作状态就可能被打回原形，继续疲于奔命，该怎么办呢？
+
+## 100 分管理者：思维陷阱和认知灌输
+
+作为管理者，经常被迫承担团队成员的工作任务，这是对初/中级管理者最大的限制条件，也常常是“需求做不完”的主要原因之一。
+
+在我摸索着做管理工作的那些年，有一本书对我影响很大，书名叫做《**别让猴子跳回背上**》。这本书里将推动任务进行的下一个步骤称为“猴子”。而对于每只“猴子”，都会存在一位解决者与一位监督者。一般情况下，下属是解决者，管理者是监督者。
+
+比如说，正常情况下，管理者期望出现的情境是：管理者下发一个任务，员工给出行动步骤并负责执行，管理者对每个步骤的关键节点进行检查。最终，任务成功完成，员工是每一个行动步骤的推动者和执行者，“猴子”始终留在员工身上。
+
+说个夸张点的场景，员工一遇到困难，就会习惯性地来问管理者：怎么办啊？管理者想了想，让你做比我自己做还累，于是说：算了，还是我来吧。
+
+在这个情境里，“猴子”跳到了管理者的身上，员工变成了监督者。在组织内，就会出现十个员工督促一个管理者工作的悲剧后果，Leader 忙的要死，员工闲着没事。
+
+这是一本小书，我读了之后启发很大，你也可以找来看看。这里我们不仅是要从这本书中获取养分，还要把理论再简化一下，聊聊我认为其中最关键的部分：授权与审查，简单说就是分配工作、检查工作。
+
+怎么样？听起来又是一个基础工作，但实践总和理论不一样，很多人什么都懂，就是做不好。尤其是初级管理者，很容易做到一半，就变成亲力亲为了——“猴子”又跳回了背上。
+
+有人吐槽，我有什么办法，项目快到 Deadline 了，下属还没做完；还有人说，我这叫团队建设，这是培养下属的能力。
+
+错了吗？没错，作为一个技术经理，明天客户就验收了，今天下属还解不完 bug，我当然要撸起袖子亲自上阵；有的人就是领悟能力差一些，手把手教了两三遍也学不会，有时确实让管理者心里有点无奈和“幽怨”，但短时间内没有更好的办法。
+
+这些事我都干过，但在做的同时，我还会多做一些重要的附加工作。
+
+首先，我会做好自己的心理建设，规避两类思维陷阱：
+
+**思维陷阱一：下属为何这么笨？**
+
+管理者下意识地将员工与自己做对比，因而开始抱怨，比如“他怎么这么笨”、“怎么这点工作都做不完”、“能力怎么这么差”……
+
+你要明白，**下属的工作能力本来就不如你，不然也不会拿着比你更少的薪水，成为你的下属**。规划下属成长路径的时候，要注意参照系，比如与同级、同经验员工对比，而不是跨阶对比。这是一大思维陷阱，要及时跳出来。
+
+**思维陷阱二：教会徒弟，饿死师傅？**
+
+初/中级管理者有很大概率遇到能力很强的下属，心中会产生一些莫名的危机感，以至于在工作中不由自主地藏私。别觉得这是耸人听闻，其实类似的事常常发生。
+
+如果你也有类似问题，一定要反复告诉自己：不要总是担心自己，让别人有发展，自己迟早会有发展，因为这至少证明你的管理能力在上升。
+
+**我认为作为一个初/中级管理者，至少要培养两名能力很强的下属，才算合格。**
+
+好，这是两类应当避免的思维陷阱，如果不多加注意，无论做什么动作都容易走形。
+
+在此后的授权与审查过程中，**每当我不得不替下属完成部分工作，我都会告诉他：这是你的工作，我是在替你完成工作**。一定要让下属意识到，“猴子”还在自己背上，不能总是指望 Leader。
+
+新人入职，管理者短时间内辛苦一下无可厚非，但要有度。一般情况下，我给高级岗位员工的适应时间是一个半月，给初级岗位员工的适应时间是一个季度。如果员工始终无法满足岗位要求，那就要坚决调整。
+
+管理者要为整个组织的成功负责，所谓“金刚之怒”的落脚点就在于此，这也是无奈和理性之举。不然，管理者一定会陷入麻烦，最终导致组织的失败。
+
+从长期看，在管理方面，你要做的就是不断重复“授权-&gt;审查”这一流程，工作自然轻松很多。
+
+## 结语
+
+不要以为职位越高，工作就一定越忙。我个人的经验是，从初级管理者到高级管理者，在工作量方面其实是更轻松了，做初级管理者时是最累的，当然，我说的是身体累，而不是心累。高级管理者，要在战略认知能力、看清全局能力和抗压能力等方面接受考验。
+
+这也是为何我们要如此关注“需求做不完”的问题 —— 管理者只有变得轻松了，才能迈上新的台阶。
+
+**保持专注、学会时间管理、做好授权审查，在我眼中，这是初/中级管理者解决效率问题最有用的手段**。
+
+但当你成为有决策权的高级管理者时，情况又有所变化，下节课我们继续聊聊《需求做不完，应该怎么办？（高级管理者篇）》。

极客时间专栏/geek/乔新亮的CTO成长复盘/对管理工作的复盘/15 | 需求做不完，应该怎么办？（高级管理者篇）.md

@@ -0,0 +1,134 @@
+<audio id="audio" title="15 | 需求做不完，应该怎么办？（高级管理者篇）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/cd/56/cdea6a09af6b2252e56f03dba107d056.mp3"></audio>
+
+你好，我是乔新亮，很高兴又和你见面了。
+
+上节课我们聊到，面对“需求做不完，应该怎么办”这个问题，首先要认识到需求是永远做不完的，但要尽量节约各类需求对管理者精力的影响。
+
+在此基础上，我们对管理者的工作重点进行了拆分，认为初/中级管理者主要解决效率问题，高级管理者主要解决价值问题，并聊了聊初/中级管理者提升效率的三个要素。
+
+在这一节，我想和你重点聊聊，高级管理者如何解决价值问题，并对最近两篇内容做一个简短的总结。
+
+## 需求处理量提升至 150%，仍然无法满足业务方要求
+
+前面我曾介绍过自己，也多次提及在苏宁的那段工作经历。
+
+我进入苏宁的职位并不算高，最初只是一名总监。一年后就获得了晋升，Title 变成了总裁助理，同时直线管理 CTO 办公室和苏宁云研发中心，管理的团队规模急剧增加。我记得，当时直线管理了 500 多人，虚线管理有近 5000 人。后来又经历了几次升迁，到最后离开苏宁时，我的 Title 是科技集团副总裁，研发团队规模已经达到 10,000 余人。当时苏宁的技术系统也很复杂，大概存在 4000 多套系统，日高峰发布接近 4000 次。
+
+可以想见，这样的团队规模配合这样的技术系统，需求量该有多么可怕。
+
+所以，在最初一段时间，我的压力非常大：业务方怨言很多，主要是需求处理不及时，积压严重。
+
+于是，我重点推行「管理数据化」，主抓技术团队的“产能问题”。其作用还是相当明显的，大概一年后，在规模不变的情况下，技术团队处理的需求量大致提升到了 150%，但业务方还是不满意。
+
+为啥呢？因为需求是永远做不完的。
+
+到这里，我有两条路可走：
+
+1. 继续解决效率问题，将需求的处理量提升到 200%、250%、300%……
+1. 像高级管理者一样，转而解决价值问题。
+
+在上一讲，我们提到，所谓“价值问题”，就是要对需求的价值做出回答，明确这个需求在公司季度、年度目标中的地位，决定某个业务需求的优先级。
+
+说白了，技术部门拼死拼活干了一整年，所做的需求并不都是有用的。谁来对这些需求的必要性和优先级作出回答？谁来衡量这些需求的价值有多少？
+
+我认为只有解决了价值问题，才能在更高维度上保证公司越来越好。
+
+同时这个选择也关乎你的个人定位。你会发现，**表面上公司是在为了需求积压而焦虑，实际上是在为业务发展的困境承受煎熬和困扰。**
+
+如果你对自己的定位是个高级管理者，那就必须直面这类问题；如果定位是初/中级管理者，我们大可以好好做架构，继续跟进效率问题，保持职级不变。
+
+你可能会说，需求处理量都提升到 150% 了，还能怎么提升效率？
+
+去除各种花哨的外表后，答案其实很简单：压榨内部团队。在这一点上，许多管理者倒挺有一套的。只是“提升效率”要适度，否则容易造成团队的抵触和人才的大量流失。不要看到华为在加班，就学着人家一起玩“狼性文化”，你的激励体系、薪酬体系、考核体系和华为不一样。
+
+**这里我想再重复一遍，高级管理者解决价值问题，初/中级管理者解决效率问题，一切取决于个人定位。**
+
+我对自己的定位和要求是高级管理者，所以我选择了路线二，解决价值问题。
+
+## 建设产品型研发组织结构，做战略上的聚焦
+
+怎么解决价值问题呢？根据这些年的经验和思考，我认为第一步是要由“项目驱动”转向“产品驱动”。反映在体系架构上，就分别代表了“职能型研发组织”和“产品型研发组织”。这一点，我们在“管理三板斧”的部分，也曾重点介绍过。
+
+在大部分情况里，技术部门会为了层出不穷的需求疲于奔命，但业务上的颓势没有丝毫缓解。比如一个CEO 的困惑：为什么我在技术部门身上投入这么多成本，在物流时效方面却收获不到应有的效果？
+
+而当“产品驱动”的思想深入组织时，人人都是产品经理和业务专家，CEO 的焦虑应当是：为什么我们的物流时效产品比竞争对手差那么多？
+
+差别在于，**在“项目驱动”的模式下，可能没人对需求的价值作出负责任的回答 —— CEO 或 某事业部总经理单个人的精力不足以覆盖每一个需求；但在“产品驱动”的模式下，所有需求都应该是对产品价值的准确回答，因为这是团队共同的责任。**
+
+我认为，最终所有组织都要转变成面向产品的形态，这就是主要原因之一。
+
+回到“需求做不完”的问题上，在对组织架构进行上述调整后，你会发现需求的数量大大减少了 —— 过去存在太多 ROI 低、优先级低的“伪需求”。从前，如果研发团队一年需要处理 100 项需求，那么如今可能只需要处理 30 项需求。整体的需求数量大大减少了，目标更聚焦、力量更集中，且与 公司季度目标严格对齐。
+
+当然，这里有一个前提，就是团队能力尚可，技术上不存在太多挑战。作为一名高级管理者，如果麾下团队还时常面对许多技术挑战，那就说明还有太多基础工作没做好，要注意为团队先打好根基。
+
+## 深度干预集团战略和激励体系
+
+好，看到这里，你可能会想：嗯，听起来很简单，我学会了！
+
+如果我告诉你，以上方法存在两大最致命问题，你能觉察到问题出在哪吗？现在你可以停下来用一分钟的时间细细思考一下。
+
+可能你在心里已经有所计较，但想法还不够清晰，不妨与我接下来所说的对照参考一下。
+
+**问题一：**
+
+当团队存在“需求做不完”的困扰时，业务方往往是已经存在大量怨言的。这很正常，因为在业务方看来，当下的业务困境大半来源于技术部门的不合格支持。
+
+作为技术部门的老大，你不但不考虑如何完成更多需求，反而准备打着“面向产品”的旗号，将 100 + 需求处理量变成 30 +，恐怕有点过分吧。况且，这里不是说由 100 项需求直接裁剪为 30 项需求，而是立足产品和公司战略，设计出全新的 30 项需求。
+
+那么， CEO 为何要说服业务部门配合调整？谁来重新定义技术部门的 KPI 或 OKR ？谁又能罗列出这 30 项需求的具体清单？
+
+**问题二：**
+
+对于团队来说，架构调整是一回事，行为模式又是另一回事。表面上看，需求数量减少了，工作更轻松了；但实际上，人人都要设法对齐 OKR 、熟悉业务、思考产品，代码背后的工作变多了。一般团队很难在心态和行为模式上作出比较好的转型，很可能全员思维僵化，继续等待需求下发，下意识认为没有需求就等于没有工作。
+
+你可能会想，此时团队应该换血，招聘新人加入。可少数新员工很难影响到多数老员工，一段时间后，反而会是新员工被老员工同化。
+
+怎么样，是不是有些棘手？实际上，这两个问题，既是解决价值问题的最重要的两个步骤，也是本文话题真正的核心难点：单凭你自己，很难对价值问题作出完整解答，也很难真正解决「需求做不完」的问题。
+
+我们先来看第一个问题，答案是：CEO 对业务和产品的认知，决定了他会不会说服业务部门；CEO 应该重新定义技术部门的 KPI 或 OKR。
+
+**所以我们常常提到的数字化转型，其实是一把手工程，一把手最重要的工作就是战略聚焦。**
+
+从概念上讲，这听起来像向上管理，但实际执行起来却不太一样。我们前面也提到过，所谓“向上管理”，是通过全局思维将认知提升到“老板层次”，然后做老板的期望管理或某一项工作任务的认知管理。
+
+而这里却要求老板对公司的组织架构和业务驱动模式来一场大修，无疑相当困难。对于初/中级管理者来说，你甚至没有为难的必要，因为你只是个需求执行者；对于高级管理者来说，影响 CEO 一定要相当谨慎，不然很容易被理解成“为绩效不达标找借口”，壮志未酬身先死。
+
+不得不说，此类问题也曾让我困扰。我失败过、困惑过，有时也践行不了自己的管理理念。 不过，经过这两年的实践，现实已经充分验证了这套“产品导向”架构体系的优越性。
+
+对于第二个问题，答案是：**重新规划考核体系，并将业务部门纳入考核；重新定义激励体系，从面向需求转为面向产品。**
+
+影响 CEO 只是第一步，第二步是要辐射到业务部门甚至人力资源部门，这更加困难。技术人的脾气是将数据和细节做到极致，最终一定会将流程里的所有变量纳入体系、进行考核。但问题是，技术部门凭什么考核业务部门？又凭什么影响人力资源部门？所以说数字化转型是一把手工程，不完全是 CTO  的工作。
+
+对于任何一个产品，考核业务部门IT化水平，考核IT部门为业务部门带来的增长，就是业务IT一体化，业务就是IT，IT就是业务。
+
+高级管理者要思考的是如何让公司越来越好。当高级管理者看到公司挣扎、彷徨的根源时，会勇于直面问题。但对很多有心人来说，这一切就只是办公室政治斗争的具现。
+
+**所以，以上两大问题，或者叫作关键步骤，都未必能在一家企业内一并解决**。有时，退一步亦是海阔天空，你可以在接下来的职业生涯中，不断去探索最优解。
+
+## 结语
+
+我们前后用了两讲的时间，对“需求做不完，怎么办”这一问题做出了拆解。这里，我们再来整体梳理一下：
+
+首先，我们要认知到，需求永远都做不完。
+
+而在此基础上，初/中级管理者主要解决效率问题，高级管理者主要解决价值问题。
+
+解决效率问题依赖专注做事的习惯和方法、高效的时间管理方法和「别让猴子爬上背」的管理价值观；
+
+解决价值问题依赖产品型研发组织的构建、对 CEO 的影响力以及对业务及其他部门的影响力。
+
+**而经过这些年的历练，我认为，追求效率要适度，追求价值则要无所不用其极。**
+
+很多管理者在战略层面懒惰，逼迫下属用勤奋来解决战略问题，期望下属做得“又快又好”。试问，若我做得足够快，怎么可能做得足够好呢？基层员工在执行上的勤奋，无法弥补高层在战略上的懒惰。而对高层乃至 CEO 的认知影响，无疑是此类问题中，最困难的部分。
+
+当然，有时解决问题的思路要更活络。在下属无法对 CEO 的决策产生影响的情况下，通过外部咨询的方式给 CEO 提供转型意见，最终也“曲线救国”，成功实现了目标。
+
+如果你也有类似经历或经验，欢迎在评论区留言，与我互动。
+
+到了这一讲，我们在管理层面的复盘，就基本接近尾声了。
+
+如果你认真学习了前面的内容，你会发现：要解决一个实际的成长问题，往往会涉及多个过往不同方向的知识点，包括“管理三板斧”、全局思维、战略聚焦、管理哲学，等等。这一切都是融会贯通，互相促进的，只有这样，才能形成管理逻辑上的闭环。
+
+在管理方面，我的讲述要结束了，但希望我们的思考不会停止。你可以随时留言，我会尽可能地回复。同样，我们专栏的最后一部分：「对专业成长的复盘」也即将到来，欢迎你继续关注。
+
+让我们下一讲再见。

极客时间专栏/geek/乔新亮的CTO成长复盘/对管理工作的复盘/加餐（一） | 如何通过演讲分享，打造自己的影响力？.md

@@ -0,0 +1,126 @@
+<audio id="audio" title="加餐（一） | 如何通过演讲分享，打造自己的影响力？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/50/f6/50bc5231e920d23e8d3145b8901eeef6.mp3"></audio>
+
+你好，我是乔新亮。
+
+私下聊天时，曾经有很多朋友问我：“老乔，我感觉你现在太有影响力了，很多朋友都知道你，我就经常听你的演讲和分享，非常棒。我自己虽然也在团队管理上有点心得，但不知道怎么讲出来，也不太敢讲。能不能给我分享分享啊，怎么提升自己的影响力？”
+
+每次听到这类问题，我都有点脸红。
+
+一方面我并不觉得自己是什么圈儿内的“技术网红”，也不是专业的演讲教练，不能给他太多专业性的意见；另一方面，在技术管理者群体里，这类困扰实在很常见。因为影响力虽然重要，但却不等同于“知识储备”或“个人能力”：代码写得好，和有影响力，是截然不同的两回事。
+
+那么，到底什么是影响力呢？百度词条写道，影响力就是用别人乐于接受的方式，改变他人思想和行动的能力。听起来是不是很厉害？和我们常常提到的“领导力”的概念很像。
+
+一位名叫“思维”的读者也曾给我留言，提到了《高效能人士的七个习惯》中定义的两个概念：“关注圈”和“影响圈” 。关注圈是生活中所有你关注的事物，影响圈则是你可以有所为、有所控的事物。
+
+大部分人聚焦“关注圈”，不停地吐槽、抱怨，却无能为力；成功人士习惯聚焦于“影响圈”，使影响圈不断扩大、扩张和成长。
+
+这么一看，就更有意思了。
+
+所幸，我觉得，**关于影响力的建设通常没有过于高深的门槛** —— 你又不是要成为明星，要上微博热搜。
+
+从我的个人经历来看，只要培养好一些基础的认知，做好一些力所能及的工作，还是非常有可能在技术圈儿具备一定影响力的。那么此后，无论是职业生涯上台阶，还是空降到另一团队进行管理，都会天然具备一定的优势。
+
+很多同学喜欢给自己打标签：纯粹技术人、内向、腼腆、不善言辞、情商低、不懂管理、不擅社交……我认为，不要总是给自己太多的负面暗示、太多的自我限制，不要将自己标签化。先去努力，如果努力后觉得实在是不喜欢，那时再考虑要不要继续。
+
+所以，我在「管理复盘」这一章的最后，安排了一份“加餐”，和你专门聊聊关于影响力提升的话题，希望能带给你一些额外的收获。
+
+## 从一上台腿就发抖，到 NPS 值全场最高
+
+像大多数技术管理者一样，我现在打造个人影响力的主要方式是演讲分享。起先是在公司内部、行业内部，后续逐渐走上各类大会的讲台，面对诸多外部听众。我相信对于大部分技术人来说，演讲分享也是成本最低、回报率最高的影响力建设方式之一。
+
+当然，刚参加工作时，我可没有这种规划，就是个普普通通的程序员，与大部分技术人一样，对演讲、交流什么的都不屑一顾。
+
+我记得很清楚，有一次和老家的亲朋好友闲聊，我说，我不喜欢那些夸夸其谈的同事，总觉得他们不干具体活，不知道一天到晚在想什么。那时我觉得，还是和计算机交流比较好，省事。
+
+你看，这就是我最初的认知：专心写代码、做自己的事最重要，夸夸其谈要不得。我想，这恐怕也是国内很多技术人的真实想法：靠嘴巴说算什么本事？程序员是技术工种，有本事写代码呀？
+
+转折发生在 2008 年，那一年我加入了 IBM 。加入没多久， Leader 就不断地提点我：“你要去扩大自己的影响力，不能光知道干活啊！要建立和客户的联结，这样人家有事才会找你呀！”
+
+虽然不喜欢，但我是个比较服从工作安排的人。于是就硬着头皮，开始尝试在公司内部请教、讨论、分享。时间一长，我发现自己其实还挺喜欢演讲的。为啥呢？因为在给别人分享的时候，其实收获最大的是我自己。这个观点你可能已经听我讲过了，但我建议你自己实践下，绝对会是不一样的体验。
+
+给别人讲东西，首先，你总不能讲错吧，要不然多丢脸？所以准备的时候，我会不自觉地从多个视角去推敲自己的内容，这能够让我思考得更为深入。其次，你总得让别人能听明白吧，要不然图个啥？你看，当你这样想的时候，不自然地就带入了用户思维，这等于你是在把演讲做成了一个产品，为了这个产品体验好，所以你会想，这地方我是不是举个例子比较好，这地方我是不是打个比方比较好，而这些打磨产品的过程，其实也是在强化你的记忆。
+
+最后，如果我讲得不错，那很快，同事们会夸我，会在各种场合给我一些正反馈。这些正反馈不管真假（现在想想，有的反馈也许就是同事的客气话），它会反过来激发我，让我觉得自己厉害，后面我做事的时候，就会给自己提更高的要求。
+
+对于我来说，在 IBM 的这段日子，我完成了从抵触分享，到喜欢分享的转变。其大半功劳应该归功于公司的培训体系和当时领导对我的提醒，少半功劳当然也属于自己 —— 大胆去做，并且付出得够多。
+
+当然，只是喜欢、只是认真还不够，还要想想，你的演讲能否打动听众呢？
+
+2016 年 10 月的 QCon 上海，主办方邀请我来做个主题演讲。还记得我当时演讲的题目是《传统企业如何转型互联网？苏宁六年技术架构的演进总结》，可以说，这场演讲对我的整个职业经历都产生了很大影响。
+
+虽然当时我已在 IBM 、苏宁参加过多次内部演讲，但还未在 1000  人以上规模的会议上做过演讲。为了保证演讲效果，我写了一万多字的提词注释，生怕自己忘词。
+
+这样的准备够认真、够刻苦吧？可那场演讲的满意度只有 73%。其实回过头看，这个数值并不低，但对比当年同场其他演讲 80%，甚至是 90% 的满意度，还是有些差。如果摆在全场 127 位讲师间进行比较，成绩可能更加“默默无闻”，为何？
+
+后来我复盘了很多次，抓住了几个细节：
+
+比如听众对理论居多、无实践案例的章节感触不大，对生动的案例则很有兴趣。比如在演讲中讲解架构理论时，观众会开始低头玩手机；当我用北京环线的城市规划比喻架构设计的核心思想时，现场正在玩手机、走神儿的观众就会把头抬起来；
+
+再者观众更喜欢走心、诚实的分享，不喜欢教条的宣讲。比如在这场演讲的开头，我谈起 2012 年还在 IBM 时，觉得苏宁就是个“卖电器的”，博得大家的会心一笑。事后想想，这也拉近了我和观众之间的距离。
+
+……
+
+从这场演讲开始，我才真正意识到：**单是乐于演讲、勇于演讲、精心准备还远远不够，还要有用户思维、产品思维，要思考观众真正想听的是什么**。
+
+其实做得多了，你总能在观众身上发现自己演讲的亮点和不足。现场演讲最大的优势，就是能和观众产生充足的互动，给你及时反馈。于是，发现了亮点，就发扬光大；发现了缺点，就复盘改正。
+
+到了 2019 年，我连续参加了 GTLC （全球技术领导力峰会）五大分站，收获了很多经验、结识了更多优秀的人、也对演讲技巧更加熟悉。我越来越发现，直观、幽默、自嘲都还只是优秀演讲的表象特征，**优秀演讲的真正内核是：从心底里放下架子、足够诚恳，明白自己是来交流的，而不是来讲课的。**
+
+很多人喜欢用成功者的叙事模式来做演讲，把自己说得很牛、很有洞见，好像从小就精通架构设计、团队管理，让观众越听越沮丧：你说的都对，但我做不到啊；你太牛了，我太差了。
+
+其实当你一步一个脚印地走过来才会发现：大家都是摸索着过河的，摔的跤都不少，爬起来的时候都是鼻青脸肿，没有那么多“技术天才”，也没有那么多“天生骄子”。
+
+这些认知反映在演讲中，就是不断告诉自己：别总说文绉绉的专业术语，多说些实在的大白话，多分享点有逻辑支持的实践经验。虽然听起来没有那么“高端大气”，但大家很爱听。在 2019 年最后一站 GTLC —— 深圳站，我的演讲满意度是 78.7%。活动结束后，工作人员告知我是全场最高，我听了很开心，但觉得还是要继续努力。
+
+2020 年，更多的企业邀请我做咨询，疫情期间我还参加了几场线上直播，接触了更多打造影响力的形式。但这个时候，打造影响力已经不是我对外演讲的唯一目标了。于我来说，演讲分享本来就是一件快乐的事，当你帮到别人并收获了反馈、感谢时，那种快乐真是无与伦比。
+
+## 认真是基础，真诚最重要
+
+遍观我的这段经历，不能算光芒闪耀，但也收获不小。我常说，努力就会有回报，很多人觉得这是鸡汤。
+
+到底是不是鸡汤，大家看看我在“影响力建设”方面的收获就知道了：
+
+1. **机会更多**：在每次工作变动时，都能有志同道合的 CEO 或其他朋友找上门来，让我免于待业在家，也无需苦苦等待猎头的消息，比如环球易购、彩食鲜、新东方、海尔集团等，我对此满怀感激；
+1. **信任更多**：无论是初来乍到，还是空降管理，我都更容易获得团队和 CEO 的信任，拥有更大决策自由和话语权，这份信任非常难得；
+1. **朋友更多**：每当我回归曾经工作、奋斗过的城市，总有许多老朋友约我聚一聚，喝喝酒。虽然出差永远很累，但我心里很快乐；
+1. **成长更快**：我更频繁地被邀请到各类场合做分享、做咨询。在这个过程里，我自己也在不断复盘、总结，成长速度大大提高。
+
+……
+
+说心里话，这些收获都很丰厚，但对我来说，它们都是附属价值。真正驱动我坚持演讲、持续复盘的原因只有快乐。所以我也建议你，如果真的不喜欢社交和抛头露面，那么尝试过就不要再继续。我觉得做“专家型人才”也很好，千万不要为难自己。
+
+有很多同学不愿意做分享，总觉得自己这点“粗陋见解”，容易让真正的专家和大咖笑话。其实每个人都是在不断成长的，许多观点和见解有一定的局限性。如果你现在不敢分享，以后也不会有勇气分享。就拿我自己或极客时间的其他专栏作者来说，谁敢说自己的分享独一无二、绝对正确？
+
+我觉得很少很少，几乎没有，但总有人会因为你的付出而受益，你自己也会在梳理分享内容的过程中成长。所以，勇敢分享不仅是一个利他行为，还是一个利己行为，真是好处多多。
+
+前两天，有读者在专栏下方给我留言，说我是唯一一位每条留言都回复的作者。我当然会回复大家了，因为看大家的留言，对我自身也有很多好处。这就是我常说的：**沟通创造价值，分享带来快乐。**
+
+当然，如果你发现了其他的路径，比如写公众号、做视频号，也不失为一个好选择，欢迎在评论区分享给大家，我们一起共同成长。
+
+**倘若你决定通过演讲和分享打造自身影响力，请一定要做时间的朋友，认真对待每一场分享和活动**。经常有朋友同我讲，工作实在是太忙，PPT 只能草草写一下，没时间准备演讲，怎么办？
+
+你不妨想想，自己一年可以参加几次对外分享？如果工作忙，就降低演讲频率，假如一年只有 1 - 2 次演讲机会，还不值得认真准备吗？前面我们讲过成长需要聚焦，关于打造影响力这事，你聚焦了吗？
+
+也是基于这个原因，我没有过多分享一些演讲的细节技巧，不是我不想，而是当你认真准备、认真复盘每一场演讲的时候，忘词、紧张、不会写 PPT、不会控场，都不应该是问题。
+
+技术人都是很聪明的，区别只是在于用何种态度对待问题。
+
+这里要注意，认真是迈出的第一步，真诚是要跟上的第二步。**大部分情况下，过度包装自己都不会带来益处**。当然，人都有虚荣心，我也有，但你要保证内容和实践经历至少是真实的，不能只顾着吹嘘自己，别总觉得自己很牛。
+
+最后，我想说，犯错、失败都很正常。理想状态下，我们当然要追求更好、最好；但现实情况是，不是只有满分演讲者才能收获好处。
+
+在 QCon 2016，我辛辛苦苦准备了万字注释，虽然满意度并不是很高，可这场演讲仍然给我带来了巨大的收益。演讲的内容被整理成文章在互联网上广泛传播（现在还能搜索到），后来很多邀请我加入的企业高管，都是通过这篇文章认识我的，其中就包括我离开苏宁后的下一站 —— 环球易购。
+
+所以你看，影响力的产生不一定是即时性的，它可能是一个“发酵”的过程，要坚信：有付出就会有收获。不要因为演讲没发挥好、文章没写好，就开始退缩，让影响力“发酵”一会，坚持做正确的事，做时间的朋友。
+
+## 结语
+
+当然了，于我个人而言，让我受益最大的影响力提升手段，是对外的技术或管理经验分享。但在不同的阶段，可能大家都有不同的方案。
+
+前几天，就有一位读者在专栏下方留言，说现在转技术管理的想法没那么大了，想在技术深度上增加自己的影响力，感觉写写博客、写写微信公众号文章也挺好。
+
+一点没错，够认真、够真诚，坚持不懈，相信你终会有所收获。关于如何做好演讲、如何打造影响力，我们就先聊这么多。如果你有其他疑惑，也欢迎向我提问。
+
+至此，我们专栏的第二章 —— 「对管理工作的复盘」，就基本结束了。后面，我会聊聊「对专业成长的复盘」，也是我们专栏的最后一个章节。
+
+期待与你在下一讲相聚。

极客时间专栏/geek/乔新亮的CTO成长复盘/开篇词/开篇词 | 削弱运气的价值.md

@@ -0,0 +1,91 @@
+<audio id="audio" title="开篇词 | 削弱运气的价值" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/71/dd/71e018b1ac860450774b59377c9369dd.mp3"></audio>
+
+你好，我是乔新亮，很高兴能在极客时间，和你聊聊我的一些认知和想法。
+
+首先，请千万别叫我乔老师，虽然大家喜欢这么称呼我，因为我说话总是“一套一套”的……但无形之中，这称呼让我自己也有点惶恐，生怕一不小心就把“学生”带错了方向。因此，我总是避免站在“老师”的角度教授知识。我更愿意作为一个朋友，与你平等地交流探讨。
+
+况且，我也不认为这世上存在“银弹”，可以直接将一名程序员变成 CTO —— 毕竟作者与读者所处的客观环境不同，难以直接套用方法论。**而且一个残酷的事实是，成功往往都有一定的偶然性，这让成功者的方法论受到局限，带有很大的“先知先觉”色彩。**
+
+有一次和 TGO 鲲鹏会一起去台湾做交流，大家讨论创业必备的基础素质有哪些，有勤奋、努力、协作能力……总之，列举了很多项，最后发现，最重要的是运气。
+
+因此，在制作专栏之初，我就打定主意，它只能是真实个人经验的总结和阐述，只能源自我个人的工作见闻与实践，只能是作为一名 CTO 的自我复盘。我必须老老实实地和大家聊聊，我是如何从一名程序员，成长为一名优秀的 CTO 的。
+
+## 为何我要向你复盘
+
+我是个来自内蒙的农村孩子， 2002 年从西安电子科技大学毕业，先后就职神州数码、Vitria、BEA、IBM，并逐渐从程序员成为管理者，开始为组织的成功而承担压力。好景不长，2009 年，我确诊了重度抑郁症，当时真像生活在地狱之中。幸运的是，我走了出来，整个人的认知和生活方式被颠覆、被改变，宛若新生。
+
+康复之后，我成长得更加迅速。从苏宁、环球易购到如今的彩食鲜，我经历了总监、副总裁、CTO 等多个岗位，管理过上万人的技术和业务团队，也拿到过千万的年薪。我给自己制定的下一阶段目标是：向优秀的CEO学习，从 CTO 变成 CEO。
+
+所以，如今我的生活节奏是，每天应对技术和业务的双重挑战，学习企业经营的秘诀；上下班的路上，我会用手机听书，学习财务知识；业余时间，我为一些企业提供咨询服务，并参加各类技术和管理会议，分享、交流。
+
+一晃 18 年过去了，我很努力，也很幸运：得到了不错的锻炼机会、遇到了不错的 Leader、受到公司频繁的正向激励、也获得了业界很多朋友的认可。可问题也恰恰出在这里 —— 我认识的很多朋友、同事、下属，并没有这样的好运气。
+
+也许他们在职业生涯的开端，没有遇到一个好的导师；也许他们恰好入职了一家疏于管理的企业，白白耽误了自己的成长；也可能，他们只是有点糊涂、有点懵，温温吞吞地就浪费了三五年时光。可对于一个人的职业生涯来说，时间还是很重要的。
+
+也许，他们依然会成功，只是过程中的弯路没少走。他们有一搭没一搭地历练，在大厂、小公司间来回求职、飘荡，感到痛苦、迷茫，可能还会遇到“中年危机”。每次出去分享，都会有这样的同学加我微信，给我留言。说真的，我感受到了他们的痛苦，我的心里也会有点难受。
+
+我想，如果我能将自己的“血泪实践”完整分享出来，一定能帮助你少走弯路。那些成功者通过好运气获取的经验，那些幸存者付出惨痛代价得到的教训，我想将它以文章和音频的形式分享给你。
+
+我希望，在你日后的无数次成功中，运气只占微不足道的一小部分，其余的皆来自努力奋斗、无休止学习、充分的交流和探索。**更重要的是，我希望你能快乐，我们还要工作30年、40年，别让这段时光显得那么漫长。**
+
+所以，我决定创作这个专栏。
+
+## 梳理成长的中轴线
+
+我们将从三个方面出发分享经验，分别是「对个人认知的复盘」、「对管理工作的复盘」、「对专业成长的复盘」。在我看来，当前时代，对于认知、管理和技术的思考，将成为大部分技术人成长的中轴线。
+
+正确认知的形成十分漫长。举个例子，在我职业生涯的前七年，我会为了钱而跳槽，为了钱而工作。我也想把自己说得牛一点，“高端”一点，但事实就是这样。
+
+2009 年以后，我经历了人生震荡，开始逐渐忘记薪资，为了成长而工作；现在，我在自己身上充分验证了这项认知的价值，开始将它传播给更多人。
+
+这是一个有痛苦、有成就、不断摸索、不断总结的过程，对这样经历的追述、总结和提炼，将是我们专栏的主要内容。我和专栏编辑也相信，用真实经历代替理论方法，也是帮助大家少走弯路的最佳形式。
+
+其他的关键认知还有很多，比如：
+
+- 如何进行职业规划？规划一定要做，且每五年就要迈上一个新的职业生涯台阶；
+- 如何保证工作任务成功交付？认知到位 + 彪悍执行 = 成功交付；
+- 如何理解平台选择和个人努力的关系？选择决定上限，努力决定下限。
+
+……
+
+基于文章体量和结构设计考虑，它们有的独立存在于一章，有的则贯穿于其他章节的字里行间。梅花创投的创始合伙人吴世春说，人的一生都在为认知买单。我非常认可这句话，**认知，或许是我们一生最大的“隐性消费”吧。**
+
+希望这个专栏，能帮助大家多成长、少买单。
+
+对管理工作的复盘，则重点面向技术管理者，以及向往管理岗位的朋友，应该也包括此时的你。从岗位职责的角度讲，管理者有三大类必须完成的本职工作：
+
+- 组织调整到位；
+- 加强协同效率；
+- 激发团队活力。
+
+无论其中哪一项，都不需要重复造轮子。比如我会建议大家将职能型研发组织结构，调整为产品型研发组织结构，也叫做“Pizza 型团队”：
+
+1. 每个研发中心为一个最大产品团队；
+1. 二级部门按产品下分多个产品组织为三级部门，每个产品组织均形成一 个产品团队；
+1. 每个人员至少归属到一个产品团队，暂不限制归属产品数量；
+1. 每个产品团队约为 7 ~ 8 人，人数受限，最多10人；
+1. 三级部门产品团队 Leader 可以是团队任意成员；
+1. 产品团队 Leader 要求（综合能力）：专业能力、领导力、汇报能力；
+1. 团队 Leader 任命原则为能者居之，能上能下。
+
+你可能会想，刚承诺过自我复盘、不讲虚的，这就开始搞理论了，能落地、能实践吗？答案是，一定能。当 2020 年 10 月 26 日，本篇文章上线并与大家见面时，彩食鲜就正在使用着上述组织结构和调整机制，连团队人数都精确复刻了，几乎等同于管理层面的“开源”。
+
+来源于实践，回归到实践，这个原则不会变。
+
+除此之外，我也会系统化地为大家分享，关于技术架构的思考和总结。管理不是空中楼阁，任何一名技术管理者，都应该有深厚的技术功底，请大家谨记。
+
+不知道以上内容是否对你的胃口？如果你有其他的困惑，也欢迎与我交流、给我留言。你的困惑可能会在加餐部分得到解答，我也会时常在评论区回复大家的提问。
+
+## 旅途的起点
+
+写下这章开篇词前，专栏编辑问我，乔老师，你做专栏的初心是什么？相对于你的个人收入，做专栏的 ROI （投资回报率）很低吧？
+
+我说，确实很低。但我会这么做也谈不上什么“初心”，没有多么高大上，只是觉得能帮到大家是件挺有意义的事儿。
+
+如果非要拔高一下立意，我认为，这是对整个社会有积极意义的。无论我们说起数字化转型，还是聊到新基建，其真正的关键永远是人，是每一家科技企业的中层技术管理者，而不是冰冷的代码或机器。
+
+试想一下，**如果我们的中坚力量都要面临如此多的成长困扰，还谈何发展、谈何进步？这也是我的真实想法。**
+
+所以，甭管这份初心是阳春白雪，还是下里巴人，我都想邀请你共赴这段学习之旅，一同复盘、一同成长。
+
+让我们下一讲再见。

极客时间专栏/geek/乔新亮的CTO成长复盘/结束语/结束语 | 做时间的朋友.md

@@ -0,0 +1,114 @@
+<audio id="audio" title="结束语 | 做时间的朋友" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6d/5c/6d12be36664bf14f7111242fd5e5b45c.mp3"></audio>
+
+你好，我是乔新亮。
+
+这是专栏的最后一讲，感谢你一路的支持和陪伴。
+
+从 10 月 26 日专栏上线至今，我们共同度过了近两个月的时光，在认知、管理、专业三个方面都进行了复盘和探讨。虽然正文内容只有短短的 26 讲，但每一讲的篇幅都不短，因此专栏的总字数依然在十万字左右。现在大家都比较关注对“碎片时间”的利用，希望这些“长篇大论”，没有消磨掉你的全部热情。
+
+我一贯的原则是“少即是多”。有好几次，撰写完的初稿只有三千多字。但在录音前，我总是忍不住四处增加内容。一则，担心内容不够丰富，给你的理解造成困难；二则，担心内容过于精炼，导致你在实践时遇到太大障碍。就这样，东改改西改改，文稿就变成了五千字，录音时长也超过了 20 分钟。
+
+好在，我相信这一切都是有价值的。
+
+2020 年，我受邀参加了 GTLC 南京站，以及由高瓴资本或其他机构、协会举办的许多垂直会议和行业峰会，基本上，全部的分享内容，都能在我们的专栏里找到出处和更系统的解读。它们有的出自「管理者最重要的三个任务」，有的出自「风险管理」，有的出自「高可用设计」……不仅如此，入职彩食鲜这半年来，我每天都在践行这些管理和专业理念，而且每次都有新的收获。
+
+可以说，我在  IBM 因专业培训而收获的知识，在咨询、架构设计、项目管理等领域的实践经验、在苏宁、环球易购推进数字化转型的痛苦实战，以及在彩食鲜的最新实践中所总结的经验、教训，在经过时光的洗礼后，全部浓缩为精华内容，沉淀在了这个专栏。
+
+所以，如果你愿意耐下心来，我相信这些文章和音频，一定能给你带来帮助。
+
+## 学以致用，终身成长
+
+你可能也注意到了，这个专栏是没有课后作业的。不同于学习一门编程语言或算法，我们很难通过一道课后习题，去检验你在认知、管理或架构思维方面的学习情况。但没有作业，不代表不需要实践。相反，专栏读完一遍还不算结束，我强烈建议你，一定要做到学以致用（毕竟你都花了钱了）。
+
+我一直认为，读书分两种，一种是读“**有用之书**”，一种是读“**无用之书**”。
+
+“有用之书”就像各类专业课程，读完了就要在当下立刻实践，光看不用，基本就算是白学了；“无用之书”并不是真的无用，它们一般很难即时生效，但长期看来，会对你的人生造成巨大影响，比如人生感悟类内容、哲学、艺术、高等数学，等等。
+
+插句题外话，大学时的计算机专业教材，我认为也属于“无用之书”，比如网络原理、计算机组成原理等。虽然对于许多从业者来说，教材不具备短时的实操意义，但认真体会后，就可能收获更高的长期价值。因为从架构的角度看，这些内容更稳定，更经得起时间的考验 —— 教材之所以能成为教材，是有原因的。
+
+整体来看，所谓“有用之书”，如果不能实践，就等于无用；对于“无用之书”，如果有时间的时候不学习，事到临头时，也很难“抱佛脚”。
+
+而我们这份关于“成长”和“复盘”的专栏，则恰好将二者融会贯通。既有可以实践的管理和专业技术内容，也有需要长期消化的认知内容。
+
+所以，我建议你在学完之后，**立刻付诸行动，在管理和专业技术领域开展实践，优先关注“有用之处”**。比如说，从「管理三板斧」里找一项，跟着做，在实践中迭代、体会；又或者，再体会一下「异常设计」，从明天开始，将所有模块的状态码都管理起来，提高产研团队的整体水平。
+
+**同时，坚持长期主义：三个月后，重读一遍专栏；半年或一年后，再重读一遍专栏，持续关注“无用之处”**……许多内容是常读常新，很多认知是只有自己经历过了，才能有更深的体会。
+
+你可能会想，老乔这是在自卖自夸吧？可对于我而言，这样既不会给我个人带来额外的收入，也不会让专栏的「订阅数」看起来更“美丽”，意义何在？
+
+归根结底，无非是想让你将收益最大化，确保关键认知到位，让自己的成长不受困扰、少走弯路，使自己的管理技能、专业技能更卓越，成为卓越的CTO。
+
+说着说着，我好像找到了做中学老师的感觉：同学们，要好好读书啊，读书可不是给老师读呢。
+
+## 全局视角，看到“灰色部分”
+
+在读这个专栏的时候，要将三章内容视作一个整体，以全局视角进行审视。
+
+**寻常人看待一件事，往往是非黑即白的。但我们要看的，是全局视角下，因黑白交织而形成的“灰色部分”，也往往是理性生长的部分。**
+
+比如，可能有的同学看完了「管理的人性哲学」，就去到团队里做实验了。结果呢？团队根本无人买账，实验彻底失败。于是，这位同学想：什么人性哲学，完全是胡说八道。
+
+但实际情况可能是非常复杂的。也许是因为管理者在技术方面有所欠缺，导致团队对其缺乏信任；也许是因为组织激励体系没有设计好，导致团队缺乏干劲；又或者只是企业文化有问题，当前手段治标不治本。
+
+这些就是所谓的“灰色部分”，需要管理者站在全局视角进行整体规划。
+
+也有一些同学，在读完专栏后觉得很焦虑：乔老师说了，五年就要上一个台阶，目前学不到东西，但又不能接受其他企业的薪资，太纠结、太着急了。
+
+**其实，一个人感到纠结，常常是因为想要的太多了。因为没有全局视角，所以容易陷入各类细节，左右为难。**
+
+我们总说，舍得舍得，有舍才有得，想得到一个理想结果，就一定要放弃其他内容。这一认知在许多思维框架下都是成立的。比如，在管理领域，这叫“战略聚焦，舍九取一”；在技术专业领域，这叫 “Trade-off” 思想。
+
+人生没有十全十美，没有人能例外。选择考研，就等于放弃三年工作时间；选择加班，就等于放弃休息时间；过度操劳，就等于放弃身体健康；选择职业生涯上台阶，就等于放弃安逸的生活；选择创业，那可能放弃的就更多了……
+
+时至今日，其实每个人的选择都不多，认真问问自己：到底想要什么？愿意放弃什么？职业生涯如此，管理如此，专业设计也如此。
+
+答案一定会水落石出。
+
+## 做时间的朋友
+
+最后，在实践时，我们需要注意什么呢？我认为是“做时间的朋友”。
+
+你不亏待时间，时间就不会亏待你。**读完专栏，找好方向，选择“有用之书”，立刻去做；选择“无用之书”，长期去做。一个月、一年不见效，怎么办？坚持去做。念念不忘，必有回响。**
+
+还记得关于“研发出了生产事故，要不要罚钱”的故事吗？得出“不罚钱”的答案后，我又用了近四年的时间，不断地完善和实践该认知 —— 作为企业决策者，我必须确保该答案是正确的。
+
+成长，真是一场“持久战”。到今天为止，我已经工作了 18 年，仍然觉得“战斗”才刚刚开始。
+
+所以，在这个专栏里，如果有你听不懂的部分，也不要着急。要善于观察你的领导和周围的专家，将他们的行为模式与专栏内容相互印证，相同的地方就要多多模仿；不同的地方就要努力思考，找出更适合自己的行为模式。
+
+努力的同时，也要注意休息，关注身体情况。有很多人，就是在事业蒸蒸日上的时期，突然查出了身体或心理上的问题，导致个人情况、家庭情况急转直下。
+
+这种情况屡屡出现，让人非常痛心。
+
+我从不认可“996”或其他加班文化。如果你还在每天熬夜加班，一定要想办法，更聪明、更高效地工作。另外，身体在出问题前，一定会给你“信号”，不要忽视它。要多多学习健康知识，人总是会为自己的无知买单。
+
+不过，这就是另外一个话题了。
+
+## 结语
+
+最后，我想说：复盘自己，真是一件痛苦的事儿。
+
+在精神上，我需要重新回忆起，许多已经忘记的故事或知识点，并对个人的知识体系进行查缺补漏，形成严密的逻辑闭环。
+
+在身体上，每次专栏更新前，我需要早晨六点起床完成修改和录音，因为更新频率的问题，容不得任何意外和懈怠。
+
+我和专栏编辑调侃过很多次：我们这是上了“贼船”了。因为，我自己好久没承受过这么大的压力了。
+
+但同时，我又很开心。
+
+随着专栏的不断更新，我个人的知识体系也在不断地被重新梳理。每当一章更新完，我都会觉得这部分认知变得浑然一体。那种“通透”的感觉，让人非常舒服。
+
+另外，专栏的每一条留言我都会阅读并回复，读的时候既深受触动，又自觉收获很大。
+
+我能感受到那些有关成长的困惑和煎熬，也因此不敢懈怠，希望这个专栏能解你烦忧；还有很多留言，写的是个人的学习感悟，与实际情况紧密结合，让人读之受益；当你有所收获、欣喜留言时，那种快乐也会传染给我 —— 我为你感到高兴。
+
+到现在，应该有两句话可以形容我的感受：
+
+1. 利他就是最好的利己；
+1. 沟通创造价值，分享带来快乐。
+
+就在这篇“结束语”定稿、推送之际，时间恰好来到 2020 年 12 月 25 日 00:01。窗外夜色如墨，我要祝你圣诞快乐！
+
+希望在未来的求知生涯里，我们还能再次相聚。
+
+也预祝你能持续学习，学以致用，终身成长。每当新的一年来临，都能遇见更好的自己！

极客时间专栏/geek/乔新亮的CTO成长复盘/编辑手记/编辑手记 | 我被老乔洗脑了.md

@@ -0,0 +1,156 @@
+<audio id="audio" title="编辑手记 | 我被老乔洗脑了" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/82/52/82eb283f28907325c6ebb38654d25152.mp3"></audio>
+
+你好，我是王一鹏，《乔新亮的 CTO 成长复盘》的专栏编辑，也是一名被老乔洗了脑的编辑。
+
+为啥这么说呢？我先给你举几个例子吧。
+
+两个月前，我出差至上海，参与落地一场线下会议。飞机还未起飞，我就同几个多年不见的大学同学约好了晚饭，誓要尝尝阿拉大上海的本帮菜。
+
+起初，一切都很顺利。飞机如期在夜幕中滑翔落地，我入住了一间距离虹桥机场十分钟车程的漂亮酒店，大概收拾了下行李，就准备出门赴宴。嘴里哼唱着那首叫做“夜上海”的小曲儿，仿佛前台小姐都感受到了我对沪上文化的无比热爱，对我报以欣慰的微笑。
+
+可大概谁都没有料到，这次外出还没通过酒店旋转门就宣告结束了 —— 两声 “Ding Ding” 将我唤回了酒店房间，然后一直工作到凌晨两点。
+
+因为我的“放鸽子”，大学室友在群里疯狂吐槽：几年不见，搞这么辛苦，到底能拿几个钱？
+
+我心安理得地回复：首先，工作是为了成长，薪资只是附属价值；其次，我正处于职业生涯“上台阶”的关键点，忙和累都是很正常的。
+
+群里一片安静，然后蹦出了十几张美食照片……事实上，从那天开始，直到返回北京，我再也没能挤出超过两小时的空闲时间，因此这次同学聚会始终未能成行。但我并不因此感到烦躁，理由正如上面所讲。
+
+另外一个例子则与女朋友换工作有关。
+
+前段时间，女朋友准备去北京东三环附近，面试一家公司的产品运营岗位。面试前一晚，她有点忐忑，问我：“如果面试官问我，对未来有什么规划，我应该怎么回答？”
+
+我说：“你就告诉面试官，你要做 T 型人才，先努力打磨自己的产品运营能力，再横向拓展，接触不同业务。目标是，能够协同团队一起创造价值，一切工作都以成就业务为目的。”
+
+次日傍晚，女朋友告诉我，第三轮面试果然问了职业规划问题，但答案让面试官非常满意。她最终成功通过了面试，相比跳槽前，薪资增长 40%。
+
+当然，类似的例子还有很多，全部都是近期真实发生的，这里就不一一列举了。如果你是专栏的忠实读者，一定知道我上面说的内容出自何处，是何含义。这种学以致用的感觉，确实很棒，对不对？
+
+我们的专栏是在 10 月 26 日上线的，但实际的策划、筹备，最早可以追溯到 5 月。就在这半年间，我嘴边经常挂着诸如“一切皆产品”、“成长性思维”一类的高端词汇，很多认知都是通透的，与自身成长长期兼容的。
+
+今年元旦前，我和团队请老乔在北京奥体附近吃饭，庆祝专栏完结。饭桌上，老乔一边啃着羊蝎子，一边指着我说：“看，一鹏这就是被我洗脑了。”
+
+是啊，我被洗脑了，可这样的“洗脑”，感觉真不错，很快乐。
+
+我认为，这种快乐主要可以分为两类：
+
+1. 困惑被解答、认知被提升的快乐；
+1. 形成逻辑闭环的快乐；
+
+## “被洗脑”的第一类快乐：解答困惑、提升认知
+
+第一类快乐，想必你很容易感同身受。一个个迷惑，如同沸水中的气泡，咕嘟嘟地冒出来，然后又在老乔传授的知识体系中破灭。
+
+- 自己的成长处于哪个阶段，是慢了还是快了？
+- 初级 leader 为何这么忙，如何“闲”下来？
+- 要成为卓越的技术管理者，有哪些工作要重点完成、优先完成？
+- 如何成为一个卓越的架构师？
+
+……
+
+或许要在实践中彻底消除这些问题，仍需要时间，但在大部分情况下，我们至少能做到不再彷徨。不需要纠结“What（问题到底是什么）”、 “Why（为什么出现这样的问题）”与“How（怎样面对问题）”，只需要确定“When（完成时间）”，再列一个 to-do list。
+
+至于认知的提升，不但对我眼下的工作有益，也有利于综合能力的长期提升。
+
+前段时间，我看到一段关于董明珠的视频采访。在采访中，记者问董明珠，在整个职业生涯里，她是否犯过错。董明珠坚定地答道，没有，一个错都没犯过。
+
+记者很错愕，在她看来，人非圣贤，孰能无过？可无论怎么追问，董明珠都是一口咬定：“没犯过错”、“一个错也没犯过”、“我的职位不允许我犯错”……
+
+后来记者指出，你要求每一位格力员工穿工作服，但自己却不穿，这算不算犯错？董明珠有点不好意思地笑道：“如果我真的犯了错，那么可能就是没穿工作服吧。除此之外，我没犯过错。”
+
+作为一名编辑兼记者，看到这一幕时，我也有些费解：这几乎不是自信，而是某种偏执了，这是为什么？
+
+这个疑惑在我的心里默默生长了很久，直到梳理专栏「认知部分」的采访录音时，我突然恍然大悟：像董明珠一般强势且处于舆论焦点的女性企业家，只能也必须这样说服自己，否则就会在狂风暴雨般的质疑下，陷入无尽的自我怀疑，其领导情况会急转直下。
+
+董明珠当然没有放弃自我纠错和改进，但这是一种**高压之下的心理建设**，其关键不在于是否符合客观规律（世上确实没有完美的人），而在于能否从内心深处说服自己。
+
+老乔曾经在专栏中多次提及如何走出抑郁症、如何培养“成长型思维”以及必要的“阿Q精神”，我相信，董明珠在镜头前的表现，只是同一类方法体系的“终极加强版”。
+
+对我来说，这是一次从普通员工到 “焦点人物”的认知同频提升，对我的采访能力大有裨益。
+
+## “被洗脑”的第二类快乐：逻辑闭环，触摸边界
+
+被洗脑的另一类乐趣，在于形成逻辑闭环，并以此触摸边界。
+
+什么是逻辑闭环呢？我们来举个例子，请你尝试按以下逻辑来思考：
+
+1. 认为工作的核心在于成长，薪资只是附属价值；
+1. 因核心目标聚焦于成长，那么相关决策和心态就会变好，所以成长得更快、更好；
+1. 因成长得又快又好，所以很可能得到上台阶的机会，为公司业务贡献更大价值；
+1. 因为为公司业务贡献了更大价值，所以可在行业内获得更优越的薪资；
+1. 因为获得了更优越的薪资，所以不再忧心生活，将目光进一步聚焦于成长。
+1. 因为进一步聚焦，所以成长得更快、更好；
+
+……
+
+有没有发现，到了第五步，该套逻辑已经自成循环，可以不断给予你正向激励？配合上一些关键的补充性认知，它几乎没有岔路、没有意外，严密合理，我们因此称之为“逻辑闭环”。
+
+这是正向的逻辑闭环，同样出自专栏的「认知部分」。我们再举一个常见的反向逻辑闭环：
+
+1. 英语老师批评我，因为他看我不爽；
+1. 因为他看我不爽，所以我不学英语，对抗他；
+1. 因为我不学英语，所以英语老师更加频繁地批评我；
+
+……
+
+很多人就是因为这个仅有三步的逻辑闭环，耽误了学习，平白给自己的人生挖了很多坑。他们不是笨，只是因为一念之差，卷入了一道奔向悬崖的“湍流”里。
+
+所以，能在人生的不同阶段，找到相应的人生导师，为你塑造阶段性的正向逻辑闭环，是非常幸运的事儿，足以将你一脚踹上成长的“快车道”。你可以放心、大胆地称赞这种好运气，“天上掉馅饼了”、“出门遇见贵人了”，怎么说都不为过。
+
+作为一个“老凡尔赛”，我不得不说，这个“馅饼”我接住了，还吃的很香。
+
+同时，我发现了形成正向逻辑闭环的另一好处：**我们因此得以触摸成长的边界**。
+
+在撰写「专业成长」一章时，我和老乔做了非常多的讨论。究竟我们是应该先画上一堆架构图，再贴上一片代码，煞有介事地讲点“技术干货”，还是应该自顶向下，讲讲老乔关于架构设计的理解、认知和经验复盘？
+
+前者看起来比较“干燥”，有助于专栏大卖；后者看起来像是“灌水”，可能不会为人所理解。我们甚至讨论过，干脆别讲「专业成长」，因为越容易理解的内容，受众越广泛，销量越高。
+
+最终，我相信我们做出了最正确的选择：「专业成长」不但要讲，而且要往高讲，不谈过多的技术细节。
+
+这是一个试图回归学习本质的决定。当下市面上存在许多教人做架构设计的文章、课程、书籍，它们讲得巨细无遗，甚至读起来有些艰深，几乎解答了一切关于技术细节的问题。
+
+但以下关乎成长的问题，却鲜有人乐于回答、敢于回答：
+
+- 啃完一本关于架构设计的大部头教程，我是否就具备了主导大型企业架构设计的能力？
+- 如果不能，我还缺乏了哪些能力？
+- 我要掌握多少知识、具备多少能力，才能成为首席架构师？
+- 我要用多长时间，才能成为首席架构师？
+- 哪些架构能力是重要基础，哪些架构能力用到的机会很少？
+
+……
+
+为了更准确地描述这类问题，我发明了个词儿，叫做“边界问题”。因为这类问题概括了能力成长的边界，也勾勒了能力成长的主干。在业界，总有值得敬佩的大牛描述各类技术细节的优雅实现，但很少有导师愿意耐心讲解“边界问题”。
+
+马拉松比赛全程为 42.195 公里，对人体的呼吸循环系统、肠胃、肝脏以及跑步技巧都有要求，这些是“边界”。只有当你知晓“边界”的存在时，才有可能正确评估自己的能力，做针对性的训练，提升成绩。
+
+可在实际的工作中，“边界”往往比较模糊，只有当我们知晓边界的存在时，才有可能触摸边界。
+
+大部分人即便是看过十本讲产品设计的书，也无法成功主导一次企业级产品设计；看了无数的“团队管理法则”，也成不了一名引人追随的 CTO……
+
+不是因为你太笨、学不会，而是你不知道边界在哪里，主脉络在哪里，因此只能盲人摸象，任凭运气左右人生成就。
+
+回顾我们专栏开篇词的标题：「**削弱运气的价值**」，说的多么贴切啊。反观整个专栏的内容，又是多么难得。
+
+你看看，我有幸形成了正向的逻辑闭环，又借此触摸到成长的边界，怎能不快乐？
+
+## 结语
+
+当然，这些收获不单源于收听音频、阅读文章，还来自于我和老乔持续两个月的专栏打磨。我经常借着采访的机会，向老乔提问一些“私货”，有的是“编辑如何实现业务价值”，有的是“如何在‘高标准、严要求’的同时，保持团队心情愉悦”……
+
+这些问题都是我实际遇到的，也得到了老乔的耐心解答。
+
+后面，我还打算策划更多的直播、讲座、训练营等活动，邀请老乔当主咖，把这种和老乔面对面交流的机会带给你，希望也能让你获得更多的收益。可能到了活动上线时，我们专栏的读者会受到优先邀请，经常留言、转发的核心读者会收到定向邀请。当然，这些具体安排还在规划中，不日就将与大家见面。
+
+目前我们能确定的是，1 月 20 日，老乔会在极客时间进行一场直播，做主题分享的同时，为我们专栏的读者现场解答一些典型问题，欢迎你准时收看。
+
+同时，我也非常期待，你能在留言板里写出自己的学习感悟、经验，我们互相印证、互相交流。回顾专栏的整个更新历程，其实只有一部分内容是来自于老乔，另一部分内容则更多来自于你的留言和反馈。
+
+所以说，这是个共创共建的专栏，作者是乔新亮，你和其他 4000 余位读者，以及一名被洗脑的编辑。
+
+2021 年，我们打算将参与共建的读者人数扩大到一万人、十万人，建设一座从程序员到 CTO 的“巴别塔”。如果你愿意参加到这个“大工程”里，欢迎多多转发、推荐本专栏，请记住：**沟通创造价值，分享带来快乐**。
+
+最后，我打算说，再见，再见，下次再见！2021 年，我的目标是让老乔回到“贼船”上，让大家于线下、线上和老乔再见一面！
+
+[<img src="https://static001.geekbang.org/resource/image/2c/e3/2c05130f59fb07e9f596a73754dc2ce3.png" alt="">](https://jinshuju.net/f/sD3ffx)
+
+别忙着退出，填写问卷、拿完奖品再走！