既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
上一讲我介绍了用来制定工作规划的 OKR 规划法。在完成事前规划之后，我们就到了事中执行阶段。
在执行阶段，你可能经常遇到这样的情况，领导审批或者跨部门同事协作的时候，别人对你的想法提出挑战。
比如你提出了一个方案，其他人针对你的方案提了很多疑问，而这些疑问确实是你在做方案时没有考虑到的；或者有人提出了其它的方案，你一时也无法明确地证明你的方案优于别人的方案。
所以在一开始的时候，你就要设计出有理有据的方案，这样才能让别人更加理解、支持和配合你。
3C 方案设计法
要怎么设计呢？我总结出了一个 3C 方案设计法，也就是每次做事的时候都至少设计 3 个方案，然后选择最优的 1 个或者几个方案去执行。
这里的 C 代表 Choice，选择。
3C 方案设计法最典型的应用场景就是基于上一级的 OKR 来制定自己的 OKR。
比如你是负责买量的运营人员，你的 Team Leader 基于上一级业务 OKR，分解出运营团队的某个 KR 是“新用户买量 60 万”，现在交给你来负责执行。
你会发现买量的渠道有很多种，包括抖音、快手、头条、百度、QQ 和微信等。不同的渠道用户特性不同，方式不同，投入产出也不同，你不能每个渠道都买一点，而应该聚焦几个效果好的渠道。
但到底哪几个渠道才是好的呢？你不能简单地凭感觉拍脑袋，而应该有理有据地推导出来。
具体来说，就是提出不同渠道买量的方案，对比这些方案的优缺点、投入成本和买量效果等。如果最后你判断“抖音买量 50 万”和“百度买量 20 万”这两个方案比较好，那么就把这两个方案作为自己的 KR。
向上汇报的时候，你一定会遇到很多挑战，比如“为什么是抖音而不是快手？”“百度的优势在哪里？”
但是这些问题你都有答案，因为你使用 3C 方案设计法的过程，其实就是在不断澄清各种可能的问题。
当然，3C 方案设计法不局限于业务规划和业务方案设计，它也可以用来做技术方案，也可以用来做管理方案；既适合比较重大的事项，也适合日常的判断选择。
下面是几个应用的实例：
三个阶段选出最终方案
3C 方案设计法的使用过程可以分为三个阶段，每个阶段都能够从不同的角度帮助你完善思考，提升方案的说服力。
第一个阶段是预研阶段，你需要设计出 3～5 个备选方案。
这个过程会促使你思考多种可能性，避免思维狭隘错过了更好的方案；而研究不同方案的优缺点可以帮助你系统理解某个领域的知识和技能。
你可能并不一定能很快想出 3 个备选方案，这恰恰说明你对当前的领域或者事情还没有全面的理解和思考，你需要强迫自己一定要想出 3 个备选方案，这个探索的过程就是一个自我提升的过程。
第二个阶段是讨论阶段，你需要把备选方案向上级汇报，或者给其他人评审。
这个过程会让其他人的信息、观点和疑问输入到你的大脑中，进一步全面完善你对每个方案的优缺点、依赖条件和所需资源的理解。
第三个阶段是决策阶段，你需要挑选出最终的方案。
一般来说，如果是互斥的方案，那么选出 1 个最优的落地就行了。
比如新招聘的员工表现不太理想，方案 1 是“立即辞退”，方案 2 是“不辞退，加大培养力度”，方案 3 是“延长试用期 1 个月”，你最终只能挑选 1 个方案落地。
如果是可以并行的方案，那么“3 选 2”或“5 选 3”也是可以的，但是不建议“3 选 3”或“5 选 4”，因为这样执行的时候会没有重点。
列出一些备选方案，只能说明你对领域有一定了解；选出合适的最终方案，才能说明你已经掌握了这个领域，能做到理论和实践相结合。
决策的过程会让你重新审视自己原来提出的方案，尤其是最初倾向的方案，帮助你发现方案的问题、理解的问题、乃至自己决策标准的问题。
3C 方案设计法会耽误效率吗？
你可能会担心，每次都要做 3 个方案，要花不少时间吧，这个 3C 方案设计法会不会耽误做事效率啊？
其实这是一种片面的理解。
首先，虽然前期准备的时间变长了，但是做一件事的整体效率变高了。
“前期匆匆忙忙赶工，后期急急忙忙返工”，这样的情况你肯定遇到过吧？
如果你在前期预研的时候先选出更好的方案，那么更有可能一次就拿到好的结果。一次就把事情做好，肯定比重复好几次效率更高。
其次，虽然负责人投入的精力变多了，但是整个团队的效率变高了。
“方案潦潦草草，讨论轰轰烈烈”，这种情况你肯定也深有体会吧？
如果负责人在设计方案的时候投入更多的精力，那么后续整个团队讨论决策和执行的效率都会提高。
正是因为考虑到效率，3C 方案设计法才提倡准备 3～5 个备选方案。
如果超过 5 个，讨论和决策时需要投入的时间和精力太多。但是少于 3 个也不好，1 个方案容易出现思维狭隘的问题，2 个方案容易出现选择困难的问题，所以说：
1 个方案是陷阱，2 个方案是困境，3 个方案是选择。
对晋升的帮助
我指导团队成员晋升或者自己担任晋升评委的时候，经常遇到这样的场景：
申请者在自述环节自信满满地介绍他做过的某个漂亮的项目，列出了 3～5 个闪光点，并且贴出了详细的数据来证明效果。
然而到了答辩环节，评委只是简单地问了一句“你为什么采取这个方案”，他就卡住了，要么支支吾吾，要么就说一些比较虚的内容，比如这个方案性能高、可靠性高之类的。
然后评委再问一句“性能有多高，跟谁比性能高”，他就彻底答不上来了。
有时候我甚至能从申请者的眼中看出不可思议的表情，仿佛在说：“采取这个方案不是自然而然的吗？还有什么为什么啊？我都列出了这么多优点，选这个方案还用说吗？”
他们当中的大部分人在晋升失败后，都不会认为是自己专业能力不行，而会觉得是自己的口才不行，临场反应不好，甚至有人真的开始去买本书来尝试提升自己的口才。
其实这样的理解是错误的。明明是自己做得很漂亮的事情，结果却在晋升的时候答得不好，根本原因不是口才问题，而是在做事的时候没有深入思考和真正理解。
我也见过所谓口才好的申请者，临场反应能力很强，随便问个问题都能说上 2～3 分钟。但是在评委听来，他说的内容完全是临时拼凑，甚至是瞎扯淡。
有时候评委实在受不了了，还会直接打断正在滔滔不绝地讲废话的申请者。
与其这样回答，还不如直接说不知道。
站在评委视角看，他们在判断申请者能力的时候，需要甄别把事情做好的真正原因：
是因为他自己掌握了相关能力？
还是因为有个厉害的主管直接告诉他怎么做？
又或者是他直接照搬了其他项目的经验？
甚至只是因为他这次运气好？
……
而最常见的甄别方法，就是问“为什么”：
为什么你采取这个方案？
为什么你觉得这个方案好？
为什么不采用另外一种方案？
为什么有某某缺点你还是选择这个方案？
……
所以，如果你想提高自己的晋升成功率，首先要认识到回答问题不能光靠临场反应，更重要的是在平时做事情的时候就要逐步积累，正所谓“台上一分钟，台下十年功”。
晋升答辩的时候，在评委看来：
你能够想出 3 个以上的方案，说明你对领域有系统和全面的理解，或者做事考虑非常周全；
能够详细的分析多个备选方案的优缺点，说明你对领域有深入的理解；
而能够从多个方案中选出落地的方案并最终拿到结果，说明你有一套成熟的评价标准或者原则，展现了你的决策能力。
有的主管可能只是简单地跟你提出“你要加深理解”“全面思考”“深入思考”“明白背后的原因”等比较虚的要求，你听完后还是一脸懵逼。
但是学完这一讲，我想你就知道应该怎么做。只要按照 3C 方案设计法来做事，就自然就能满足这些要求。
我曾经带过一个团队成员，他之前 3 次晋升 P7 都失败了，自己总结的原因都是“太紧张了，口才不好”（他确实比较腼腆内向一些）。
我跟他指出，口才不是关键原因，关键是平时的思考和积累太少，然后在接下来的一年里严格要求他按照“3C 方案设计法”来实践：
重大技术方案设计要做 3 个备选方案
团队管理相关的措施想三个可选方案
每年的团队规划方向也要求想 3 个
一年之后，他再次申请晋升，答辩结束后他就跟我说：“我不怎么紧张了，因为大部分评委的问题，我平时自己都已经想过了。”最后果然顺利地通过了。
小结
现在，我们回顾一下这一讲的重点内容。
PDCA执行法：怎么推动落地才能“步步为赢”？
你好，我是华仔。
在事中执行阶段，最核心的方法当然就是 PDCA 执行法了。毕竟一开始工作规划得再好，如果没有落地执行，那么也产出不了任何价值。
PDCA 执行法
所谓 PDCA 执行法，就是把事情的执行过程分成四个环节：计划（Plan）、执行（Do）、检查（Check）和行动（Act），从而把控执行过程，保证具体事项高效高质地落地。
具体流程如下图所示：
这个方法来源于美国质量管理专家休哈特在 1930 年提出的 PDCA 循环。
20 世纪中后期，美国另一位质量管理专家戴明利用这个理论指导日本企业进行质量管理，极大地提高了日本企业的市场竞争力，也让 PDCA 循环得以在世界范围内推广。
这也反映出 PDCA 执行法是一个普适性的方法，适用于各行各业。不过它的实际效果如何，还要取决于使用者有没有掌握各个环节的具体技能。
因为 PDCA 执行法在不同行业的最佳实践有很大的差异，这一讲我就分享它在互联网行业的使用技巧。
先说明一点，使用 PDCA 执行法，意味着你要完成制定计划、拆解任务、协调资源、安排责任人和检查结果等工作，所以它比较适合“负责人”这个角色，比如 Team Leader、虚拟团队负责人和领域负责人等。
而如果你平时只是执行具体的事项，现阶段还不需要用到 PDCA 执行法。比如你是刚刚毕业的 P5，承担某个项目的某个功能的开发或者测试工作，那么只要遵循项目计划就行了。
不过就算是这样，为了能更快地晋升，你最好也能先掌握这个方法。接下来我就分环节一一讲解使用技巧。
计划（Plan）
第一个环节是计划（Plan），确定具体任务、阶段目标、时间节点和具体责任人。
OKR、3C 方案设计与 PDCA
看到这里，你可能会有疑问：OKR 规划，3C 方案设计和 PDCA，它们好像都和规划有关，那么它们之间的区别和联系是什么呢？
如果你看过日本人写的关于 PDCA 的书，比如《高效 PDCA 工作术》，就会发现他们既用 PDCA 来规划，也用它来推动落地。
但是我在实践中发现，这样做可能会把长远规划和短期任务混在一起，把长远目标和短期结果混在一起，从而导致你在和团队成员讲解计划和目标的时候，很难准确地区分和平滑地切换。
所以，我把 OKR 定位成专门用来做规划的方法，把 PDCA 定位成专门用来做执行的方法。它们的对比如下表所示：
至于 3C 和 OKR 的关系，我在上一讲已经提到过：3C 方案设计法最典型的应用场景就是基于上一级的 OKR 来制定自己的 OKR。
比如业务规划的 1 条 KR 是“新用户增长 100 万”，运营团队 TL 分解出“买量 60 万”的 KR。针对这一条买量的 KR，从什么渠道去买，抖音、快手还是微信，就可以用 3C 方案设计法来挑选。
等确定是从抖音买量 60 万之后，这 60 万要分几个阶段去买，每个阶段要做什么事，具体责任人是谁，就是 PDCA 的计划环节要确定的。
所以它们之间的关系是：OKR 制定整体规划，3C 选择实现方案，PDCA 落实具体任务。
业务案例：用户增长
我用一个最简单的业务例子，用户增长，来为你说明它们之间的关系吧。
Step 1：OKR
业务负责人制定了业务 OKR，如下图所示：
运营 TL 对照 KR1“6 个月内新用户增长 100 万”，基于自己的专业分析和判断，认为“买量”是一个有效的手段，于是为团队初步分解出一条 KR，“买量 60 万”。
Step 2：3C
买量的具体渠道有很多，运营 TL 对比不同渠道买量方案的优缺点、投入成本和买量效果，最后确定把“抖音买量 60 万”作为团队的 1 条 KR，汇报上级后获得批准。
Step 3：PDCA（计划环节）
运营 TL 拆解“抖音买量 60 万”这条 KR 的具体任务，明确时间点、阶段目标和责任人，如下表所示：
注：
表格信息仅为示例，你不用关注具体含义。
Plan 中的结果数据之和是超出 KR 描述的，你可以想想背后的原因。
你可以根据自己的需求自由定制表格中的列，比如可以加上“预算”“风险”和“依赖”等，让计划更全面。
计划环节技巧
这个环节的技巧，主要有 3 条。
\1. 处理紧急的事情要长短结合
很多负责人在处理紧急事情的时候会陷入一个两难的境地：
如果采取临时措施，虽然能够快速处理，但没有从根本上解决，后面还可能出现其他问题。
如果采取长远措施，虽然能够从根本上解决，但是投入很大，短期内无法快速落地。
正确的做法是长短结合，先快速解决表面的问题，避免损失，然后规划长期的方法，从根本上解决问题。
比如 Redis 出现未授权访问漏洞（通过公网可以访问 Redis），你可以先通过防火墙或者访问控制来应对，然后通过升级 Redis 到最新版本来彻底解决。
\2. 重要但不紧急的事情拆分多个小项目
很多人负责人都有这样的经历：
对于重要但不紧急的事情，团队都知道，也都想做；可是一旦准备要做，就发现投入太大，没有足够的时间和人员投入。
于是团队每天都忙于处理各种紧急的事情，这些重要但不紧急的事情就一直拖着。
我遇到过这样一个存储系统，因为设计的缺陷（没有采用分库分表，未归档海量历史数据，缓存设计不合理等），线上经常出现性能问题。每次系统一出问题，都是“DBA + 测试 + 开发”团队一顿操作猛如虎，结果一看，还是会影响业务几十分钟甚至几个小时。
团队也知道要优化存储系统设计，但是一看投入这么大，业务版本又那么紧，就一拖再拖，导致各种性能问题反复出现。
正确的做法是拆分为多个小项目来落地，可以按照事情类别来拆分，也可以按照时间迭代来拆分。
我在接手这个存储系统之后，就开始进行优化。我先把措施按照类别拆分为分库分表、大表归档和缓存优化等几个类别；然后发现，分库分表也是大工程，所以就进一步采用时间迭代的方式来拆分，5 月份完成 A 表，6 月份完成 B 表……
经过这样的拆分，原本预计要投入 5 个人一直做 3 个月的工作，分散到各个业务版本中逐步落地。虽然前后花费了 6 个月时间，但不需要从团队抽 5 个人专门来做优化，业务开发基本不受影响。
\3. 学会利用上级的力量来协调资源
对于某些项目，一开始并不能明确需要投入的人力。作为负责人，你很可能在分析之后发现，需要的人力投入比最初预估的要多。
如果你是 TL，并且你自己团队的人就可以满足需要，那么你就自己安排就可以了。
比较麻烦的情况是，你发现需要借调其他团队的人才能完成。你可以先尝试自己去跟对方的 TL 协调，如果你们之间的关系不错，还比较好商量；但如果没什么交情的话，可能就会碰钉子了。
这个时候要怎么办呢？正确的做法是，找上级来协调，然后成立正式的工作组。
首先，上级人脉多，面子大，可以协调和安排的资源更多。
其次，有上级出面，对方团队也更乐意接受安排，因为他们知道这件事情做好了，上级会清楚他们团队的贡献。
另外，如果对方团队真的有困难安排不了，上级也帮你会想其他办法，就算实在想不到办法，至少他也知道了事情的困难。
协调到具体的参与人员后，你需要成立虚拟的工作组，让参与的人员工作有名有份，取得进展和成果之后，也要向上级进行汇报。
执行（Do）
第二个环节是执行（Do），按照计划落地各项具体的活动，比如技术人员完成方案设计、编码和测试等工作。
这个环节的技巧，主要有 2 条。
\1. 根据情况采取相应的管理风格
在指导团队成员执行的时候，负责人经常犯两种错误，一是管得太多，一种是管得太少。
管得太多体现在因为担心团队成员出错，事无巨细都要亲自参与，结果一方面导致自己很累，另一方面让团队成员没有发挥空间，很难得到成长。
管的太少体现在只做任务分配，不做具体指导，万一出问题就找个人背锅，这样虽然自己很轻松，但团队成员仍然得不到成长；而且团队的成果会有很大的不确定性，成员如果能力一般，很可能得不到好的结果。
正确的做法是，根据情况采取相应的管理风格，包括独裁式、民主式、专家式、教练式和授权式等，这方面的内容我会在后面的专项提升部分详细介绍。
\2. 做好信息同步
很多人都有的一个坏毛病就是，收到了上级的任务后就只知道埋头干活，只要上级不来问，自己就不说，甚至出了问题都不上报，期望自己搞定，不要打扰上级。
这是一个非常严重的错误做法，特别是出了问题如果你不跟上级说，一旦他通过其他渠道得知，对你的印象都不会好。
一方面他会觉得尴尬，自己团队的问题都不知道，还要等别人来告诉自己；另一方面他会觉得你故意隐瞒问题。
正确的做法是，及时同步信息。根据信息的不同，同步的方式也有差异：
对于问题相关的信息，必须立即同步，在问题发生的第一时间、问题取得和得到解决的时候都要及时汇报，不要等到解决完了再汇报，更不要以为自己把问题搞定了就可以当作什么事情都没发生。
对于任务相关的信息，可以定期同步，比如通过周报、双周报或月报的形式来汇报就可以了。
如果有里程碑的事件，也需要及时同步。
检查（Check）
第三个环节是检查（Check），对照计划来检查实际执行结果，明确哪些符合预期、哪些不达预期、哪些超出预期以及存在什么问题等。
这个环节的技巧，主要就是 1 条。
使用 5W 分析问题根因
大部分人在分析问题原因的时候，都倾向于归结为表面的外部原因或者客观原因，而不愿意归结为深层的内部原因，尤其是自己的原因。
所以在分析问题原因的时候，存在一种常见的现象，只要某个人说了一个外部原因或者客观原因，感觉团队成员都长舒一口气，然后分析也就到此为止了。
比如团队 A 负责的某个项目延迟了，团队成员分析原因是负责某外部关联系统 X 的团队 B 没有人力支撑进行联调。
表面上看起来，的确是因为团队 B 人力不足。但实际情况是，X 系统是一个中台系统，所有项目都应该提前申请和排期。但是团队 A 的人员在分析联调配合关系的时候，遗漏了 X 系统的关联关系，没有预先向 B 团队申请联调支持，结果临时去申请正好遇到 B 团队没人支撑，导致联调暂停。
正确的做法是，采用 5W 根因分析法，不断追问更深一层的根本原因。具体做法我会在下一讲为你详细介绍。
行动（Act）
第四个环节是行动（Act），基于检查的结果，总结经验和教训，明确下一步需要采取的措施。
如果 Check 的结果是目标已经实现，那么当前 PDCA 循环结束。
示意图中行动（Act）和计划（Plan）之间用虚线连接，就是因为并不是每次行动都一定要回到计划。
如果 Check 的结果是目标没有实现，那么就需要调整计划，把经验和教训作为输入，开始新一轮的 PDCA 循环，如此重复直到目标达成或者取消。
这个环节的技巧，主要有 2 条。
\1. 做好总结汇报
你可能会问：“执行环节不是已经同步了各种信息吗，这里还要总结汇报什么呢？”
其实这两个环节的汇报有很大的区别：
执行环节是同步信息，主要是问题、进展和重要的里程碑事件。
行动阶段是总结汇报，主要是结果是否符合计划的预期，能总结什么经验教训，后续是否需要采取什么措施。
总结汇报不一定要写个 PPT 来汇报，很多时候写个邮件就差不多了。
\2. 每次最多挑选 3 个改进点落实到流程
行动环节最重要的产出就是经验和教训了。
一个常见的误区是，认为经验和教训越多越好。有些负责人会收集团队全体成员的意见，甚至根据意见的数量来判断团队成员的主动性，于是得到的经验和教训的数量非常多。
我曾经遇到这样的情况，某个团队总结的经验教训有将近 100 条，项目成员 40 个人针对经验教训讨论了 3 个小时都没有讨论完。
事实上大部分经验和教训都是无价值的。
首先，全员收集就会存在凑数的问题，团队成员会拼凑几个没有实际意义的经验教训来证明自己的主动性。
其次，很多经验教训都是偶发的，并不是普遍现象，比如某个成员因生病导致自己负责的部分延迟。
最后，如果来一条经验就落入流程，来一个教训就出一个改进措施，结果只会导致流程越来越臃肿，改进措施越来越多，最后谁都记不清到底有多少。
即使经过筛选和讨论，最后认定有价值的经验和教训，也不是一股脑地固化到流程就可以了。因为任何措施都是有实施成本的，如果成本太高，最终的效果可能大打折扣，甚至会带来新的问题。
比如为了规避某个成员生病导致项目延迟，某团队规定，任何任务都必须有备份人员一起参与，而且备份人员能够随时接手任务。
但是这样做却让原本人力就吃紧的开发团队雪上加霜，整个团队同时支撑的开发项目数量大大下降，严重影响了业务的上线速度，经常被业务方吐槽。
正确的做法是，不要想解决所有问题，而是关注可能重复发生的、影响很大的问题。我建议每次总结的时候，最多挑选 3 条经验教训相关的改进点落实到流程。（其实 3 条都已经比较多了，如果每年做 10 次类似的总结，就可能有 30 条改进措施了。）
小结
现在，我们回顾一下这一讲的重点内容。
5W根因分析法：怎么找准问题源头才能治标又治本？
你好，我是华仔。
上一讲我介绍了 PDCA 执行法，它把执行过程分为四个环节。其中在检查（Check）环节，最容易出现的问题就是，分析原因的时候，只看到表层的原因，而没有去深挖深层的根本原因。
这就会导致我们给出的解决方案治标不治本，虽然短时间内做了应急处理，但是按下葫芦浮起瓢，相关的问题之后还会接连不断地冒出来。
5W 根因分析法
怎么解决呢？这就要靠 5W 根因分析法了。它又叫 5Why 分析法或者丰田五问法，最初是由丰田集团创始人丰田佐吉提出的，后来成为丰田汽车公司获得成功的重要方法。（老板提出来的，应用也是自然的 _）
那么，5W 根因分析法到底是什么做的呢？根据丰田汽车公司前副社长大野耐一的描述，就是重复问五次“为什么”，问题的本质和解决办法就会变得显而易见。
大野耐一曾经举过这样一个例子：
问题 1：为什么机器停了？
答：因为机器超载，保险丝烧断了。
问题 2：为什么机器会超载？
答：因为轴承的润滑不足。
问题 3：为什么轴承会润滑不足？
答：因为润滑泵失灵了。
问题 4：为什么润滑泵会失灵？
答：因为它的轮轴耗损了。
问题 5：为什么润滑泵的轮轴会耗损？
答：因为杂质跑到里面去了。
如果到了问题 1 就停止追问，那么工人的措施就是更换保险丝，一段时间后保险丝肯定还会烧断。
如果到了问题 4 就停止追问，那么工人的措施就是更换轮轴，一段时间后轮轴又会很快坏了。
只有当追问到了问题 5，才能找出停机的根本原因，这时工人的措施就是给润滑泵加上防杂质的滤网，从而彻底解决问题。
现在，5W 根因分析法在其他很多企业已经得到了广泛应用，并且融入到了各种管理方法中，比如持续改善法（日本持续改善之父今井正明提出）、精益生产法（美国学者研究丰田后提出的管理哲学）和六西格玛法（摩托罗拉提出的管理策略，杰克·韦尔奇推广到通用公司）等。
虽然它起源于生产过程中问题分析，但是作为一种思维方式，可以应用到很多场景，比如业务分析、技术学习和管理改进等。
接下来，我就针对这三类应用场景分别举例说明，这些都是我亲身经历的例子。
业务分析
第一个场景是业务分析。
在某交易平台的业务规划目标讨论会上，我通过 3 个为什么，了解到了业务目标背后的深层考虑。
问题 1：为什么今年的业务目标是成交金额翻番？
答：因为只有成交金额翻番我们才能达到盈亏平衡点。
问题 2：为什么今年要求达到盈亏平衡点？
答：因为集团要求我们的业务能够自负盈亏。
问题 3：我们本质上还属于创新业务，为什么集团要求我们的业务能够自负盈亏？
答：因为疫情的影响，集团需要开源节流，减少非盈利业务的持续投入。
你可能觉得有些奇怪：怎么这个例子只问了 3 个为什么就结束了呢？
因为 5 个为什么只是一个形象的说法，实际操作中可以是 3 个，也可以是 7 个，关键在于通过追问找到根本原因。
虽然在这个例子中，我们还可以继续问下去，比如：“集团为什么要开源节流，创新业务难道不重要吗？”
但这样的问题，业务团队很难得到确切答案，因为集团的决策背景和讨论信息只有高层才知道，而且就算知道答案，也不会对业务规划目标的理解有更多的帮助。
技术学习
第二个场景是技术学习。
在某次 Netty 培训课上，我通过 5 个为什么，来验证大家是否真的深入理解了 Netty 网络高性能的核心原理。
问题 1：为什么 Netty 网络处理性能高？
答：因为 Netty 采用了 Reactor 模式
问题 2：为什么用了 Reactor 模式性能就高？
答：因为 Reactor 模式是基于 IO 多路复用的事件驱动模式。
问题 3：为什么 IO 多路复用性能高？
答：因为 IO 多路复用既不会像阻塞 IO 那样没有数据的时候挂起工作线程，也不需要像非阻塞 IO 那样轮询判断是否有数据。
问题 4：为什么 IO 多路复用既不需要挂起工作线程，也不需要轮询？
答：因为 IO 多路复用可以在一个监控线程里面监控很多的连接，没有 IO 操作的时候只要挂起监控线程；只要其中有连接可以进行 IO 操作的时候，操作系统就会唤起监控线程进行处理。
问题 5：那还是会挂起监控线程啊，为什么这样做就性能高呢？
答：首先，如果采取阻塞工作线程的方式，对于 Web 这样的系统，并发的连接可能几万十几万，如果每个连接开一个线程的话，系统性能支撑不了；而如果用线程池的话，因为线程被阻塞的时候是不能用来处理其他连接，会出现等待线程的问题。
其次，线上单个系统的工作线程数配置可以达到几百上千，这样数量的线程频繁切换会有性能问题，而单个监控线程切换的性能影响可以忽略不计。
第三，工作线程没有 IO 操作的时候可以做其他事情，能够大大提升系统的整体性能。
这种场景在晋升答辩的时候也会经常发生。评委在考察申请者能力的时候，很喜欢用“夺命连环问”，连续追问为什么。如果平时没有训练和积累，你很可能被问到哑口无言的地步。
这样在晋升答辩的时候，你就能从容应对，不用再害怕评委针对技术深度展开“夺命连环问”了。
管理改进
在某次项目延迟问题的讨论会上，我通过 6 个为什么，把项目延迟的核心原因找了出来。
问题 1：为什么项目延迟了？
答：因为要等测试环境进行测试。
问题 2：为什么要等测试环境？
答：我们只有 2 套测试环境，2 套都已经用于另外两个项目了。
问题 3：为什么只有 2 套测试环境，不能搭建多套吗？
答：现在没有机器用来搭测试环境了，而且我们有将近 20 个子系统，搭建一套可用的测试环境耗时可能要一周。
问题 4：为什么会没有机器，直接申请机器不就可以了？
答：运维今年的预算用完了，不能购买新机器了。
问题 5：为什么一定要用新机器，测试环境对机器性能要求高吗？
答：测试环境对机器性能要求不高，基本能跑就行。
问题 6：那为什么不找运维申请过保机器（使用超过 3 年的机器，即使没坏也要换掉）用来搭建测试环境？
答：之前没想过这个方案。
所以解决方案很简单，直接找运维借几台过保的机器用来搭建测试环境。
不过这还只是短期的解决方案，实际上在问题 3 的回答中，我们还可以发现另外一个问题：搭建一套环境太耗时了。
于是测试开发部启动了一个基于 Docker 的快速搭建环境的项目，项目完成后，任何一个开发或者测试同学花 5 分钟就能生成一套全新可用的环境。
注意事项
通过这 3 个例子，我想你已经理解了 5W 根因分析法的使用技巧。在实际应用的时候，我们还需要注意以下 3 点：
\1. 问题数量不是关键，找到根本原因才是关键
在介绍业务分析这个例子的时候，我已经提到，5W 或者说 5 个为什么只是一个形象的说法，3 个也可以，7 个也可以，关键在于找到根本原因。
所以一个最简单的提问方法就是：下一个问题是对上一个回答的进一步深入。
虽然数量可多可少，但我建议不要少于 3 个，因为凭借 3 个以下的为什么，大概率找不出根本原因；但是也不要多于 7 个，因为如果问了 7 个以上的为什么还没找到根本原因，那就要审视一下问题本身是不是有问题了，比如关注的焦点偏移，前面问的是 A，后面变成了问 B 了。
\2. 首先要明确问题本身
5W 根因分析法起源于生产过程，通常情况下问题都是比较明显的，比如机器停机了或者次品率升高了。但是，还有很多情况下问题本身其实是不明确的，每个人的理解可能都不太一样。
如果没有明确问题就开始问为什么，无论问题多么精彩都没有意义，甚至越精彩离题越远。
比如“成交量大幅下降”，这个问题就不明确，到底下降 10%、30% 还是 50% 才算“大幅”？是同比下降还是环比下降？是某一个子业务下降很多，还是所有子业务都在下降？
如果这些问题都不明确就开始进行根因分析，就很可能得出一大堆似是而非的原因和改进措施。
\3. 避免变成大型“撕逼”现场
在连续追问“为什么”的时候，如果双方没有对这个方法充分达成认识，被问的人很可能觉得你在挑战和质疑他，讨论的现场就会变成大型“撕逼”现场，最后闹得不欢而散。
所以在一开始的时候，就要先解释清楚，待会儿将采用 5W 根因分析法来探讨根本原因，避免挑起情绪对立，引发“撕逼”。
小结
现在，我们回顾一下这一讲的重点内容。
5S问题处理法：怎么应对问题才能转危为机？
你好，我是华仔。
上一讲我介绍了 5W 根因分析法，教你通过追问 5 个为什么来找到问题的根本原因。不过，找到原因不等于解决问题。
这就好比大夫看病，光是看出来患者的病根在心脏还不够，还要明确心脏到底出了什么毛病，是只用服药还是需要做手术，如果要安排手术，具体要怎么操刀。
处理问题也是这样，它是一个复杂的系统工程，既能够反映你的专业能力，又能够反映出你的综合能力。所以问题既有可能成为拖垮你绩效的陷阱，也有可能成为你晋升的机遇，关键在于你如何有效地去处理。
那么问题到底要怎么处理呢？我总结了一个 5S 问题处理法，也就是把处理问题的过程分为 5 个步骤：明确问题（Specify）、拆解问题（Split）、定位问题（Seek）、解决问题（Solve）和落地行动（Sort），从而化危为机。
接下来，我会为你逐一讲解这 5 个步骤。
第一步：明确问题（Specify）
第一个步骤是，明确问题。
我有个朋友曾经遇到过这样的情况：
领导跟他说，最近团队士气好像不高。他立刻分析了 8 点原因，并提出了针对性的改进意见，还觉得自己反应很快，能力很强。
然后领导就让他负责提升士气，于是他组织培训和团队活动，搞各种评奖，推出各种新制度……干了一大堆事儿。
结果半年后，老板说，感觉士气还是没什么变化。
这其实是很多人都会犯的第一个错误：问题本身都没有明确定义，就直接开始采取行动。结果很可能就是，你做了很多事情，但无法衡量。
所以你一定要提醒自己，在解决问题之前，先要明确问题。（这本来是不言而喻的道理，但是在实际工作中我们往往容易忘记。）
怎么明确呢？根据问题有没有用数据量化，可以分为两种情况。
量化了的问题
首先，对于已经用数据量化的问题，关键在于确认数据是否准确。
通过数据来展现问题是比较直观的，而且很多人认为“数据不会撒谎”，所以他们看到数据之后就直接开始处理。
但其实这种情况也是需要明确问题的。因为数据可能出错，出错的原因有很多种，可能是源数据出错，也可能是计算时出错。
我就多次遇到过报表系统出问题导致业务数据异常的情况；也遇到过统计部门调整算法但是引入 bug，从而导致数据错误的情况。
怎么确认数据是否准确呢？最方便的方法当然是让数据部门去核对，但是可能耗时比较长；而最快速的方法则是通过多个关联数据互相验证。
以互联网电商业务为例，如果月销售收入下降了 20%，但是月订单量和月活用户（MAU，Monthly Active User）都在增长，那么很可能是销售收入的数据统计出了问题。
没有量化的问题
其次，对于没有用数据量化的问题，又可以分为两类。
一类是可以量化但是还没量化的，比如“业务增长放缓”，其中的“放缓”到底是什么意思，是增长速度从 100% 下降到 60%，还是增长速度从 10% 下降到 6%？不同的人理解可能千差万别。
对于这一类问题，你把量化的环节补上就行了。比如老板说：“我对当前的利润增长速度不满意，希望更快一点。”你就要明确，老板关注的指标是季度增长率还是月增长率？更快一些具体是多快，20% 还是 50% 还是 200%？
另一类是无法简单量化的，比如“团队士气不高”，其中的“士气”只是一种主观感受，很难量化。
所以这类问题是最棘手的，一是士气不高也许只是领导自己的感受有问题，并不是真的存在这个现象；二是就算真的士气不高，改善的效果也很难衡量。
你怎么证明你提高了士气，又怎么证明士气到底提高了多少呢？
直接用数据来衡量肯定是不现实的。经过实践摸索，我发现调查问卷是一种比较有效的方法。既然是主观感受，那我们就综合大多数人的主观感受来得到一个相对客观的评价。
这就像一部电影好不好，虽然不能用片长、投资金额或明星数量来衡量，但是如果看过的观众都来打分，最后综合算出一个分数，还是有一定参考意义的。而且评价的人越多，越能客观地反映影片的质量，这也是豆瓣等平台的价值。
调查问卷的设计技巧总结如下：
问题数量在 10～15 个左右，太少会导致问题分析不全面，太多会导致被调查的人不想答。
问卷数量至少 10 份以上，太少会导致单个样本对整体结果影响太大。
尽量用选择题，开放性问题不要超过 3 个，因为没几个人会认真回答开放性问题。
评分用 1～5 分，不要用 1～10 分，用 10 分制的话，区别度不大，平均分基本都是 7～8 分。
如果你的 P8 或 P9 级别的领导让你帮他分析一下团队的士气，那么你可以这样设计调查问卷：
注：仅为示例，实际的问卷内容要更多一些。
基于多份问卷的结果，就能在一定程度上分析出团队士气情况和整体成员的认知情况，从而避免个人主观判断的偏差。
不过，如果团队的人数很少，就不要用调查问卷了。比如你是 P7 的 Team Leader，手底下带了 5 个人，现在你觉得团队士气不高，可以直接找他们一个一个聊，这样效果更好。
第二步：拆解问题（Split）
第二个步骤是，拆解问题。
明确问题之后，你是不是就准备急着去分析原因了呢？毕竟你是负责人，领导还等着你的答案呢。
这就是很多人都会犯的第二个错误：把自己当成拯救世界的超级英雄，以为可以一个人搞定所有的事情。
如果问题很简单，那么确实可以这样做。但大部分问题其实是比较复杂的，甚至有的问题看起来很简单，实际上可能涉及很多方面，如果你只靠自己一个人去分析，也许花了很长时间都搞不定。
所以为了能够更高效地分析问题和更快地给出解决方案，你要学会拆解问题。
具体的做法是，对问题进行初步的分析，将大问题拆解为几个独立的子问题，然后再根据子问题的数量和规模，看看是否需要申请更多人力资源来一起参与问题处理。
简单来说，就是不要单打独斗，要学会利用团队力量。
至于按照什么维度拆解，这就和问题本身有关了。业务类的问题，可以按照业务类型来拆解，也可以按照客户群体来拆解；管理类的问题可以按照流程来拆解，也可以按照事项分类来拆解。
拆解问题有几个常见的小技巧：
拆解出来的子问题数量 2～5 个，拆太多了就很难保证互相独立。
拆解出来的子问题尽量互相独立。
明确子问题负责人，组成工作组，定期向上汇报进展。
比如电商业务的“订单数下降 30%”，你可以按照业务类型来拆解，看看不同品类各自下降了多少。
经过分析，你可能会发现，“男装下降了 20%”、“鞋类下降了 30%”、“食品下降了 20%”，其它品类的数据还是增长的。
于是，“订单数下降 30%”这个大问题拆解成了 3 个子问题，你可以分别协调对应的运营负责人来一起处理。
又比如“团队研发效率不高”，经过调研发现，团队反馈最多的前 4 个问题是“会议太多”“测试环境不足”“发布太麻烦了”和“需求变更太频繁”。
如果你一个人搞不定这 4 个子问题，你可以分别协调项目经理、测试负责人、运维负责人和产品负责人来一起处理。
第三步：定位问题（Seek）
第三个步骤是，定位问题。
我曾听过这样的案例：
半年的业务买量数据不升反降，老板让运营负责人赶紧想办法。于是他连夜构思解决方案，提出了几个大展拳脚的方案，比如 SEO 优化、增加更多渠道等。
老板大手一挥批准其中 3 个方案，半年后一看，投入多了几千万，买量的数据却没有多大起色，老板脸色很难看。
这就是很多人都会犯第三个错误：没有找到根本原因的情况下，就急于给出解决方案。
如果你只找到了表层原因，那么后续提出的方案就是无法从根本上解决问题，只能白白浪费时间和资源。
定位问题的技巧就是 5W 根因分析法，我在 26 讲已经介绍过了。需要注意的是，根本原因可能不止一个，不同的追问线索可能找到不同的根本原因。
比如“加班太多导致士气不高”，我们也许可以得到两个根本原因：“市面上的 Go 程序员较少” 和 “没有项目经理”。
问题 1：为什么士气不高？
答：因为加班太多。
问题 2：为什么加班太多？
答：因为人力不够。
问题 3：为什么人力不够？
答：因为招聘困难。
问题 4：为什么招聘困难？
答：因为市面上的 Go 程序员太少。
针对“市面上的 Go 程序员太少”这个根本原因，对应的解决方案可以是“招聘 C/C++ 程序员然后培养成 Go 程序员”。
接下来是沿着另一条线索追问的情况：
问题 1：为什么士气不高？
答：因为加班太多。
问题 2：为什么加班太多？
答：因为项目执行混乱。
问题 3：为什么项目执行混乱？
答：因为没有项目经理。
针对“没有项目经理”这个根本原因，对应的解决方案可以是“招聘专职项目经理”。
第四步：解决问题（Solve）
第四个步骤是，解决问题。
定位出问题的根本原因之后，你就需要提出问题的解决方案。
解决方案往往涉及资源的投入（增加广告投入预算）、组织的调整（成立专项小组）和系统的增强（增加配置检查功能防止运营配置出错）等，所以你需要得到上级的认可和支持。
这时很多人都会犯第四个错误：思维比较局限，只做了一个方案提交给上级。
你信心满满地把自己的解决方案提交上去，本来希望得到赞赏，结果却发现上级有更多的想法或不同的方案，反而认为你考虑得不够周全。
那么，怎么做才能很快得到上级的认可和支持呢？
你需要提供多个方案，并且给出你建议的方案和原因，最终让上级来挑选和拍板。这就是我在第 24 讲介绍的 3C 方案设计法。
第五步：落地行动（Sort）
第五个步骤是，落地行动。
方案得到批准后，你就要落地执行，真正解决问题。很多人在这一步容易犯问题处理的第五个错误：做事没有重点和优先级，眉毛胡子一把抓。
在前面的步骤中，你可能拆解出了 3 个子问题，然后每个子问题分析出 2～3 个根因，每个根因分别给出了对应的解决方案，接着每个解决方案又可以分成 3～5 件事情来做。最后你发现，可以做的事情有几十件。
你可能会认为这些事情都是有价值的，所以用一张 Excel 表格全部记录下来，然后从第一件开始一件一件地去做。
但是这样做的结果很可能是，你做了几个月，但是却看不到什么效果。
因为每件事情的价值有大有小，见效时间有快有慢，你的领导并不关心你做了多少件事，他们关心的是，问题有没有真正解决。如果看不到明显的效果，就算你做得很辛苦，也很难得到认可。
正确的做法就是先做优先级排序，然后挑选优先级 TOP N 的事情去做，尽快看到成效，让问题不断地改善。
优先级排序的技巧总结如下：
可以按照阶段来进行优先级排序，并且顺序是可以调整的。比如前 3 个月 TOP 3 的事情是 ABC，后 3 个月 TOP 3 的事情是 XYZ。
如果只有一个团队来做，建议挑选 TOP3 ～ TOP5 的事情来落地；如果多个团队合作，那么可以选 TOP 10，每个团队负责其中 2～3 件事。
短期按照紧急程度来挑选 TOP N，长期按照重要程度来挑选 TOP N。比如“运营配置 URL 出错”这个问题，短期内的 TOP 事项可以是“上线流程优化”，让测试来检查运营配置的内容；长期 TOP 事项可以是“后台管理系统优化”，增加配置 URL 合法性和有效性检查功能。
明确需要落地的 TOP 事项后，就可以用第 25 讲介绍的 PDCA 执行法来执行了。
小结
现在，我们回顾一下这一讲的重点内容：
5S 问题处理法就是把处理问题的过程分为 5 个步骤：明确问题（Specify）、拆解问题（Split）、定位问题（Seek）、解决问题（Solve）和落地行动（Sort），从而化危为机。
处理问题时容易犯的 5 个错误是：（1）问题本身都没有明确定义，就直接开始采取行动；（2）把自己当成拯救世界的超级英雄，期望可以一个人搞定所有的事情；（3）没有找到根本原因的情况下，就急于给出解决方案；（4）思维比较局限，只做了一个方案提交给上级；（5）做事没有重点和优先级，眉毛胡子一把抓。
明确问题可以通过数据量化，也可以靠调研来衡量；拆解问题是为了发挥团队的力量；定位根因、提出方案和落地执行时，可以分别使用 5W 根因分析法、3C 方案设计法和 PDCA 执行法。
4D总结法：怎么展示你的工作亮点？
你好，我是华仔。
前几讲我为你介绍了事中执行阶段的 4 种方法，这些方法能够提升你拿到好结果的概率，但是不能保证让你一定拿到好的结果，因为影响最终结果的因素太多了。
首先，就算使用 3C 方案设计法，决策过程仍然有可能有失误。
比如受限于团队整体的技能限制，分析和讨论备选方案的时候漏了一个重要的方案；或者决策时采用的判断标准有问题，对性能要求估计过高，实际上线后业务量远远没有预期那么大等情况。
其次，就算使用 PDCA 执行法，执行过程仍然有可能出现偏差。
虽然 PDCA 方法能够有效地对任务进行规划和跟踪，但是具体执行的时候，可能会受到使用者的水平和投入资源等因素的限制。
最后，就算方法都使用得当，还是有可能受外部因素干扰。
比如某海外钱包团队用 3C 方案设计法设计出了最优的业务方案，但是当地政局不稳定，导致跨境消费剧烈减少，然后又发生疫情，导致本地消费大幅减少，最终结果可能就很不好。
所以，不但做事的方法很重要，而且做事的结果也重要。在晋升答辩的时候，评委除了考察规划和执行相关的“为什么”之外，还会考察和做事结果相关的“为什么”，比如：
你认为这个结果怎么样？你怎么评价这个结果？
为什么你认为这个结果不好？
为什么你的方法挺好但是结果不好？
你从这个结果得到什么经验和教训？
你可能以为，结果好的事情讲起来就很容易了，结果不好才需要包装一下。其实不是这样的，结果不好的事情，你的确需要分析原因，总结经验教训；但是结果好的事情，你也需要讲清楚你对结果的贡献。
大部分人在这个环节的表现都很一般，常见的误区有：
讲的贡献是团队的总贡献，没有讲清楚自己对结果的贡献，或者拔高了自己对结果的贡献。
只讲自己的做事方法多么高大上，却不提最终的效果，比如说自己引入了某某算法，但却不说到底带来了什么好处。
虽然提了一下效果，但都是比较虚的描述，比如高可用、高性能、用户转化率大大提升之类的话，评委听完也不知道到底有多高、有多大提升。
虽然描述效果的时候列出了数据（能列出数据已经超出了 60% 的人了），但仅仅是把从产品经理和运营经理那里要的数据贴过来，对于数据没有自己的理解和判断，评委针对数据问的问题都答不上来。
那么，总结的时候到底要怎么说才能充分展示出自己的工作亮点呢？
这就要用到 4D 总结法了，也就是从结果、数据、技术和成长这 4 个维度（Dimension）来整理自己的做事收获，从而涵盖事情的重点难点核心点，有效地应对晋升答辩时可能遇到的各种问题。
维度一：结果
第一个维度是结果。
结果这个维度重点关注的是事情带来的价值，不同类型的团队在结果价值方面表现会有一些差异。
首先是业务开发团队，不管是业务开发项目，技术优化方案，还是管理措施，我都建议从业务角度进行结果总结：
对于业务开发项目来说，从业务的维度总结是自然而然的，例如某个业务用户日活是多少。
对于技术优化方案来说，主要看技术方案给业务带来的价值是什么，例如高可用方案让业务 P1 故障从 5 次减少到 0 次。
对于管理措施来说，主要看管理措施带来的效率和质量的提升，例如同样的人员支撑了更多业务。
其次是中间件开发团队，结果建议从系统的性能、可用性和成本等方面进行总结；如果中间件系统已经产品化（比如阿里云的 RDS 和 MQ），也可以从销售量或者流量等方面进行总结。
最后是技术支撑团队，也就是运维和测试之类的部门，结果建议从质量、效率和成本方面进行总结。
比如测试做了一个自动化测试平台，可以降低 5000 人日测试工作量，使用了这个自动化测试平台的某业务线上年度故障数量从 20 个降低为 5 个。
维度二：数据
第二个维度是数据。
像“提升了开发效率”这种比较虚的描述，应该改成“开发一个功能从 20 人天提升为 2 人天”这种使用具体数据的描述。
通过数据来描述结果的时候，你不但要列出相关的数据，而且对于这些数据背后的含义也要有自己的理解，尤其是对数据的评价以及评价的标准。通过评价数据的方式，你可以培养自己的业务思维和理解力。
比如，同样是将用户活跃率提升 5%，对于一个像微信这样成熟的业务来说是非常难得的；但对于一个新业务来说还远远不够；同样的道理，从 20% 提升到 25% 和从 90% 提升到 95%，含义也是完全不同的。
很多人在一开始尝试的时候都会遇到一个疑问：感觉这个事情好像没办法用数据来描述啊？
这个时候怎么办呢？其实大部分的情况，不是真的不能用数据来描述，而是你没有去搜集数据，没有养成用数据来说明的习惯。
比如，以前需要写代码才能实现的业务，某个技术优化方案采用 XML 配置就可以完成了，但是之前也没有谁去收集实际上的开发时间，所以无法进行对比，但效率肯定是提升了的。
遇到这种情况，我们可以采取临时补数据的方式，也就是找团队相关人员评估一下之前方案所需的时间。为了避免单个人评估出现严重误差，你可以找多个人进行评估，发挥集体智慧，最后取一个平均值或者中间值。
这样得到的数据虽然没有采用项目管理工具进行收集那样严谨和客观，但实际上也不会偏差太大。
当你平时积累了大量数据总结的内容后，写晋升 PPT 的时候就可以信手拈来，而不用再绞尽脑汁去回想 1 年前做过的一个项目具体的结果是什么了。
维度三：技术
第三个维度是技术。
对于技术人员来说，做完一个项目或者方案之后，技术上有哪些提升、学到了什么新的技术、对哪些技术有了更深或者更全面的理解等，都可以在总结的时候系统地梳理一下。
虽然我们在设计方案的时候已经采用了 3C 方案设计法对领域进行了全面地分析和研究，但并不代表这样就可以完全掌握所有相关的知识和技能，在具体落地的过程中肯定还会遇到很多细节或者之前没有注意的地方。在事情做完后，统一地整理和总结一下经验教训，能够进一步提升技术深度。
我在 2013 年左右使用 Memcache 的时候就遇到过一个比较奇怪的问题：开发语言是 PHP 5，采用 Nginx + php-fpm 来做容器，每天晚上到了 0 点就随机出现 Memcache 连接不上的问题。
最后经过排查，我发现是因为 Memcache 默认连接数只有 1024，而业务上到了 0 点就可以开始新的一天的签到和奖励领取，大量用户卡点操作导致并发量大，连接数超过了 1024 个后 Memcache 就拒绝连接了；而且 PHP 连接的时候采用的是短连接，即使修改连接数，在大量并发连接时也会出现连不上的问题。后来，我们用 C 语言写了一个 PHP 连接池扩展，从而解决了问题。
这件事情要怎么总结呢？
如果某项技术你还没有按照“链式学习法”和“比较学习法”来学习，那么这就是一个很好的学习机会，你可以按照这两种方法画出领域分层图、细节分层图和方案对比的思维导图等。
如果某项技术你之前已经按照“链式学习法”和“比较学习法”学习过，那么你可以结合实践经验，完善领域分层图、细节分层图和方案对比的思维导图。随着你积累的越多，这三个图会越来越完善。
维度四：成长
第四个维度是成长。
除了关注技术上的提升之外，你还需要关注个人综合能力成长，也就是软实力提升，比如对业务的理解能力、项目组织能力、带领团队的能力、沟通能力和做事方法等。
这些能力在 P5/P6 晋升的时候可能没那么重要，但是到了 P7 以后就会变得越来越重要，而且综合能力很难靠突击来提升，只能在平时工作中逐步积累。
以业务理解能力为例，做完一个项目后，你可以从以下角度去总结：
业务的适应场景是什么？
目标用户是谁？
目标用户有什么特点？
解决了目标用户的什么问题？
实际的效果如何？
用户为什么喜欢 / 不喜欢这个功能？
随着做的项目越来越多，你通过总结得到的业务理解信息和能力也越积越多，到了一定阶段就可以量变导致质变，业务理解能力大大提升。
示例
使用 4D 总结法，看起来要整理的内容非常多，但是熟练之后你就会发现，其实并不怎么耗费时间，一个持续 1 个月的项目，可能用 1 个小时来总结就足够了。
总结的时候也不需要很正式，你可以用笔记的方式，把一些想到的关键点列出来。当这样的总结数量积累到一定的程度，你还可以再系统地整理一下，写成文章发表或者拿去给团队做培训，那样效果会更好。
下面是我之前做的一个业务总结示例，对应“成长”部分的总结，供你参考。
游戏衍生内容好坏对用户根本性影响非常弱，这个结论为何到了最后才发现？之前的决策都是基于这个判断来做的。
改进：有想法，然后快速验证，如果一次验证失败可以再尝试，但如果尝试一年还失败，那就要及时调整了。
“没有”和“偶尔”用竞品的竟然占了 90%，这说明几个竞品没有差异化（定位都一样），用户只需要其中一个。
“没时间玩”成为最主要的原因，是否说明用户对 app 的定位就是工具型，需要的时候用一下，不需要的时候根本不会去看。
用户的几个典型弱点：贪婪（礼包、活动、抽奖）、懒惰（信息流）、虚荣（等级、成就）、窥探（笑话、八卦）。
用户的主场景：礼包、下载、找游戏。
消磨零碎时间不是用户玩手游的最主要场景，反而是 63% 的用户在成块的闲暇时间体验手游。
小结
现在，我们回顾一下重点内容。
金字塔汇报法：怎么汇报才能让领导认可你的成果？
你好，我是华仔。
上一讲我给你介绍了 4D 总结法，它可以用来做总结，让你在完成工作之后有效地展示亮点和提升自己。
要是你觉得 4D 总结法同样可以用来做汇报，那么我就要提醒你注意了，4D 总结法的确可以提供汇报时需要的一些材料，但是它并不能提供组织这些材料的思路。
如果你汇报的时候，只是把总结得到的内容单纯地罗列出来，是很容易踩坑的。比如我以前就经常遇到这样的汇报场景：
上级直接打断汇报者说：“不要讲这么多细节，挑重点讲！”
总监点评某个团队的汇报时说：“感觉你们团队做了很多事情，团队也很辛苦，但没看到有什么关键结果或者突破！”
P8 汇报完之后，某 P9 大佬问：“能不能用一两句话概括一下这一年的工作？”
为什么在这些场景中，领导都觉得不满意呢？因为汇报的逻辑和总结的逻辑是不同的，总结主要是面向自己做梳理，更强调自己个人的贡献，以及事情的价值和细节；而汇报主要是面向领导做组织提炼，更看重团队整体的结果，以及事情的逻辑和关键。
那么，怎么汇报才能让领导认可你的成果呢？这就要用到金字塔汇报法了。金字塔汇报法来源于金字塔原理，我在第 13 讲分享的 PPT 写作技巧就是金字塔原理的一个应用。这一讲，我先从理论层面再为你深挖一下这个原理。
金字塔原理
它很简单，核心思想是任何事情都可以归纳出一个中心思想，中心思想可由三至七个论点支持，每个论点可以由三至七个论据支撑，这样延伸下去，形状像一个金字塔，所以才叫金字塔原理。它的基本结构如下图所示：
有些人看到金字塔原理之后，认为这个方法名不副实，本质上就是中学作文的总分结构，巴巴拉·明托只不过是取了一个高大上的名字。
从结构上来看，金字塔原理确实是一种总分结构。但它能够风靡全世界 50 年，在各行各业都能取得很好的使用效果，肯定不只是因为采用总分结构化，它背后的 4 条基本原则才是关键。这些原则保证了你的汇报结构是重点突出、逻辑清晰、主次分明的，能够让别人快速地抓住重点，清楚地理解内容，牢固地记住信息。
1. 结论先行
如果你想向别人输出信息（文章、汇报、报告、演讲等），在一开始的时候就应该抛出结论，也就是你想要传达的中心思想。
因为如果你讲的内容比较多，别人找不到重要的结论，可能根本没兴趣认真听完；如果别人听完不明确你的结论或者把结论搞错了，最后你的输出汇报效果也会大打折扣。
所以我们要让结论先行，具体的技巧可以用六句口诀总结：
先重要（结论）后次要（结论）
先全局后细节
先总体（结论）后细分（结论）
先论点后论据
先结论后原因
先结果后过程
注：
1 和 2 针对“不要讲这么多细节，挑重点讲”这样的问题。
3 和 4 针对“能不能用一两句话概括一下这一年的工作”这样的问题。
5 和 6 针对“听下来给我的感觉就是，去年团队很辛苦、很努力、拼劲十足，但是这么辛苦最后拿到来什么结果，我却没怎么看到！”这样的问题。
按照这六句口诀进行汇报，基本上就涵盖了别人关注的内容。如果时间有限，你可以只讲口诀中需要先讲的内容，后讲的内容可以直接不讲，只要做好准备应对提问就行了。
就算时间充足，口诀中后讲的内容也不要花太久，建议按照二八原则来分配时间，80% 的时间给先讲的内容，20% 的时间给后讲的内容。
2. 自顶向下
光有结论是不行的，这个结论还得让别人信服。所以我们采用自顶向下的结构来组织逻辑，用下层的信息来支撑上层的结论。
下图展示了一个简单的金字塔原理案例：
请注意，在这张图中，“手游市场刚刚起步”就可能是一条不那么让人信服的结论，因为它的一个论据“手游厂家只有 XX 家”不足以支撑这条结论。别人听完或许会想，也可能是几个垄断的厂家特别强大，已经挤压到其他厂家没有生存空间，所以数量才比较少。
3. 归类分组
用自顶向下的结构来组织逻辑时会遇到一个问题：下层的数量几个比较合适呢？
如果你在平时的工作中采用了 4D 总结法总结做过的事情，你会发现你可以用的素材很多，尤其是如果你带了团队的话，素材会更多，如果逐一列上去，不要说用 PPT 了，可能用 Excel 表格列几十行才能完整的展示，这样在汇报的时候肯定是不行的。
所以，你需要将类似的论点或者论据抽象、归纳、提炼、总结成一组，最后形成 5 个左右的分组。
一般来说，分组数量尽量不要少于 3 个，如果少于 3 个，你就要检查一下分析是不是全面，有没有遗漏某些要点。
另一方面，极限是 7 个，最好是 5 个以内，因为人类的短期记忆是有局限的，同级别数量太多别人记不住，具体可以参考美国心理学家乔治·A·米勒的论文《神奇的数字：7±2——我们信息加工能力的局限》。
4. 逻辑递进
光通过归类分组来控制数量还是不够的，必须保证同级别的内容具备逻辑关联，主要是一致性和顺序性。
一致性是指，同级别的内容必须属于同一逻辑范围。比如苹果、香蕉、葡萄、菠萝都属于“水果”范围，而牛奶就不属于“水果”。
顺序性是指，同级别的内容是按照某种顺序排列的，比如北上广深四个城市，既可以按照地理位置从北到南排序，也可以按照 GDP 从大到小排序，如下图所示：
金字塔汇报法
标准的汇报内容包括总体结论、具体分析、关键事项、总结改进四部分。接下来，我以一个模拟的某海外移动钱包技术团队负责人的汇报 PPT 作为例子，跟你讲解每个部分的具体内容和技巧。
1. 总体结论
从全局概括整体的工作或者项目情况，得出关键性的结论，让听众整体上知道做得怎么样，形成做得好、做的一般、不达预期或遇到很大困难等直观印象。
这个部分按照金字塔原理来分析和阐述，包括一个总的结论（总体介绍）和几个主要的分论点，PPT 页数一般不超过 3 页，分论点的数量建议 1～3 个，每个分论点再给出 3～5 个论据，如下图所示：
这张图展示了基于金字塔汇报思路写的 PPT，它省略了 PPT 排版格式，只保留了干货信息，实际汇报的时候你可以写得更好看一些，也可以在金字塔方法整理的内容上稍做展开：
注：总体结论的内容可以用定性的描述，也可以是定量的数据。
2. 具体分析
对总体结论中的论据进一步阐述和分析，让别人相信论点的真实性和有效性。
这个部分同样按照金字塔原理来拆解，需要提供具体的数据和证据。
对团队方面的具体分析如下图所示：
这里的团队分析只有结果汇报，没有原因分析，因为前面没有说团队存在明显问题。如果汇报的内容有一条是“团队士气低落”，那就需要做原因分析了。
对业务方面的具体分析如下图所示：
业务结果分析更多的从定量的角度给出详细的数据，如果是技术团队主管，可以找业务负责人拿数据进行汇报。如果有做的不好的地方，需要做原因分析。
比如针对业务结果没有达到预期的原因分析如下图所示：
业务原因分析更多的是从定性的角度对业务结果进行分析。如果是技术团队主管，可以找业务负责人一起分析原因，不建议技术负责人独自分析然后给出结论。
因为高级别的领导可能会从多种途径听到同一个业务的分析结论，如果不同的途径结论差异很大，技术团队给出的业务分析结论很容易被怀疑不专业。
对于分析出来的原因，如果需要进一步论证，可以同样使用金字塔原理来进一步展开，比如“本地用户不习惯这种支付方式”，可以分解为“八达通使用率占比达到 90%”和“信用卡覆盖率达到 60%”等。
3. 关键事项
介绍做过的关键事项的情况，比如某某项目的执行过程或者某某业务的推广行动和效果等。
这部分不需要使用金字塔原理，一般是通过全局大图、演进路径和时间轴等技巧来汇报。
4. 总结改进
总结经验教训和后续改进措施，注意不要随便拍脑袋提出改进措施，改进措施本身也要求有理有据。
要注意，列出来的改进措施，一定是你接下来真的准备去做的，不要为了凑数而加上去，因为下次汇报的时候，领导很可能会想先了解一下你上次汇报时列出的改进措施到底落实得怎么样。
同时，改进措施的数量也不要太多，一般可以分为“业务”“技术”和“管理”这几种类型，每种类型列 3～5 条，如下图所示：
改进措施既可以基于前面的原因分析，比如这里的业务改进措施就是基于业务分析的原因推导出来的；也可以基于前瞻性来进行判断，比如前面虽然没有明确提出团队目前存在问题，但是从中长期来看，这样的团队结构肯定会存在风险的，所以在这里提出团队管理的改进措施也是合理的。
关键事项汇报技巧
刚才我提到，关键事项部分不需要使用金字塔原理，而是通过全局大图、演进路径和时间轴等技巧来汇报。现在我来一一介绍。
全局大图：展示整体情况
首先是全局大图，它是用来展示整体情况的。常见的类型有业务大图、技术大图和组织大图等。
全局大图的核心内容包括两个层面：
整体结构：汇报涉及的领域整体上包含哪些组成部分，各部分的关系或者层级是怎样的，和其他领域的边界和关系是什么。整体结构是领域的完整形态，已经实现的和还没有实现的部分都要展示出来。通常情况下，业务大图和技术大图用分层结构展示，组织大图用组织结构展示。
个体状态：各个组成部分当前的状态，或者取得了什么成就。通常情况下，用不同的颜色来表示不同的状态。
下面是一个业务大图的例子，供你参考。
注：图中信息仅为示例，不代表真实情况。
为了让大部分用户都能看懂，图中的组成部分都是高度抽象的。你在实际汇报的时候可以继续细化，我见过最复杂的业务大图，一张 PPT 中包含的区块有将近 100 个。
当然，也不是说越细化越好，你只要在这张图的基础上再往下分解一层就够了。比如业务中台负责人汇报的时候，可以把商品分解成很多细化的业务，商品收藏、商品快照、商品上下架和商品分类等，但是不需要再对商品收藏做进一步的细化。
同时，不同团队的人使用这张图做汇报的时候，侧重点也不同。比如业务中台的负责人汇报的重点自然是业务中台，数据中台的情况则可以简要带过，但也不能完全不知道；而中台整体负责人汇报的重点就同时包括业务中台和数据中台了。
演进路径：展示个体情况
其次是演进路径，它是用来展示个体的发展路径和当前所处阶段的。这里的个体可以是一个独立的系统，一个业务，或者一个领域。
演进路径的核心内容就是各个演进阶段，每个阶段要能够用一个词加一句话高度概括，让别人一眼就能看出不同阶段的差异。通常情况下，演进路径一般用阶梯式的图来表达，寓意步步提升，越来越好。
下面是一个推荐系统演进路径的例子，供你参考。
时间轴：展示过程
最后是时间轴，又叫时间线，它是来展示事情发生过程的。
时间轴的核心内容是时间维度相关的里程碑以及每个里程碑的关键事项或者进展，换句话说，时间轴中的节点应该都是里程碑式的，不要事无巨细地全部列上去。
通常情况下，如果关键里程碑数量不多，那么时间轴用横向或者纵向的直线就行了；而如果关键里程碑数量比较多，时间轴可以考虑用折线的形式来展示更多的内容。
小结
现在，我们回顾一下这一讲的重点内容。
四线复盘法：怎么避免成为背锅侠？
你好，我是华仔。
在事后总结阶段，正常情况下我们主要是做收获总结和成果汇报即可，但是如果发生了明显的问题，就需要做问题复盘。
复盘是一个围棋术语，它指的是对局结束后回顾记录，检查招法的优劣和得失关键，并且根据分析提出更好的招法，提升以后的对局能力。后来，这个思路被引入到了管理工作中。
问题复盘
技术人员主要参与的是线上问题复盘，比如业务或者系统出现了线上问题，在问题解决之后往往就会组织复盘。
不管团队技术多么厉害，也不管公司多么有钱，都不能完全避免业务或者系统出现问题的可能，比如 2015 年 5 月 27 日支付宝发生了大规模宕机的事故，2018 年 10 月 22 日 GitHub 发生了宕机 24 小时的事故等。
虽然无论做什么都不可能完全杜绝问题的发生，但这并不意味着我们只能坐以待毙。我们需要尽量降低问题发生的概率，减少问题导致的损失，因为就算事故不可避免，1 年发生 3 次和 10 年发生 1 次，影响和意义也是完全不同的。
问题复盘的意义就在于找到问题的原因然后加以改进，避免同样的问题反复出现，降低问题的发生的概率和影响。
四线复盘法
但是，要做好问题复盘可不是一件容易的事。复盘会议上的各种明争暗斗，可能会让刚参加工作的“萌新”惊掉下巴，甚至让一些老员工也感到头疼。尤其是一些管理比较严的公司还会通过复盘来明确责任分配和处罚措施，复盘会议的激烈程度往往不亚于电视剧中的宫斗场景。
所以，怎么组织一场复盘，怎么分配责任和避免背锅，已经成了职场人的一项生存必备技能。
问题复盘的内容涵盖事实、分析、定责和改进4 个部分，一次成功的问题复盘需要达成以下 4 个目标：
讲清楚事实：事实是复盘的基础，如果连事实都没有讲清楚就开始分析、定责和改进，无异于搭建空中楼阁，做得再漂亮也是没有意义的。
全面且深入地分析：首先需要保证没有遗漏问题，其次需要深入分析问题根因，否则以后问题还是会以其他方式反复出现。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
加一句话高度概括，让别人一眼就能看出不同阶段的差异。通常情况下，演进路径一般用阶梯式的图来表达，寓意步步提升，越来越好。
下面是一个推荐系统演进路径的例子，供你参考。
时间轴：展示过程
最后是时间轴，又叫时间线，它是来展示事情发生过程的。
时间轴的核心内容是时间维度相关的里程碑以及每个里程碑的关键事项或者进展，换句话说，时间轴中的节点应该都是里程碑式的，不要事无巨细地全部列上去。
通常情况下，如果关键里程碑数量不多，那么时间轴用横向或者纵向的直线就行了；而如果关键里程碑数量比较多，时间轴可以考虑用折线的形式来展示更多的内容。
小结
现在，我们回顾一下这一讲的重点内容。
四线复盘法：怎么避免成为背锅侠？
你好，我是华仔。
在事后总结阶段，正常情况下我们主要是做收获总结和成果汇报即可，但是如果发生了明显的问题，就需要做问题复盘。
复盘是一个围棋术语，它指的是对局结束后回顾记录，检查招法的优劣和得失关键，并且根据分析提出更好的招法，提升以后的对局能力。后来，这个思路被引入到了管理工作中。
问题复盘
技术人员主要参与的是线上问题复盘，比如业务或者系统出现了线上问题，在问题解决之后往往就会组织复盘。
不管团队技术多么厉害，也不管公司多么有钱，都不能完全避免业务或者系统出现问题的可能，比如 2015 年 5 月 27 日支付宝发生了大规模宕机的事故，2018 年 10 月 22 日 GitHub 发生了宕机 24 小时的事故等。
虽然无论做什么都不可能完全杜绝问题的发生，但这并不意味着我们只能坐以待毙。我们需要尽量降低问题发生的概率，减少问题导致的损失，因为就算事故不可避免，1 年发生 3 次和 10 年发生 1 次，影响和意义也是完全不同的。
问题复盘的意义就在于找到问题的原因然后加以改进，避免同样的问题反复出现，降低问题的发生的概率和影响。
四线复盘法
但是，要做好问题复盘可不是一件容易的事。复盘会议上的各种明争暗斗，可能会让刚参加工作的“萌新”惊掉下巴，甚至让一些老员工也感到头疼。尤其是一些管理比较严的公司还会通过复盘来明确责任分配和处罚措施，复盘会议的激烈程度往往不亚于电视剧中的宫斗场景。
所以，怎么组织一场复盘，怎么分配责任和避免背锅，已经成了职场人的一项生存必备技能。
问题复盘的内容涵盖事实、分析、定责和改进4 个部分，一次成功的问题复盘需要达成以下 4 个目标：
讲清楚事实：事实是复盘的基础，如果连事实都没有讲清楚就开始分析、定责和改进，无异于搭建空中楼阁，做得再漂亮也是没有意义的。
全面且深入地分析：首先需要保证没有遗漏问题，其次需要深入分析问题根因，否则以后问题还是会以其他方式反复出现。
[外链图片转存中…(img-qBKn3MkI-1715796014145)]
[外链图片转存中…(img-rcdwbYGr-1715796014146)]
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
