既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
因为业务规划存在这么大的困难，所以你千万不要觉得 OKR 规划法是包治百病、一用就见效的灵丹妙药。
毕竟方法本身不能取代经验，你还是得在工作中摸爬滚打，慢慢积累经验，加深对业务的理解才行。
不过，聚焦业务目标过程中的互怼和争执，本身也是一个澄清和完善的过程。总的来说，OKR 规划法还是比其他方法（比如 KPI 规划法）更有逻辑，更有说服力。
聚焦的目标可以是定性描述的，比如“提升用户满意度”，也可以是可衡量的，比如“市场占有率排名前三”，通常情况下不要求量化。因为 KR 中会有具体的数据描述，在目标中你只要把数据的意义提炼出来就行了。
如果你一定要在目标中体现数据，也是可以的，具体来说有两种方式。
第一种是在 KR 中直接拆解目标中的数据，KR 的数据总和大于或者等于目标中的数据，比如：
O：新增用户数 2000 万
KR1：短视频平台买量拉新 1000 万
KR2：开发新业务拉新 600 万
KR3：通过与其它平台换量拉新 500 万
第二种是在 KR 中添加辅助的指标，比如：
O：新增用户数 2000 万
KR1：新增用户数 2000 万
KR2：投入资金不超过 1 亿
KR3：新用户月留存率不低于 40%
第二步：分解关键结果（KR）
聚焦业务目标之后，第二步是分解关键结果，也就是 KR。对于每个目标，业务负责人都要提出 3～5 个 KR。
这些 KR 一方面是用来评判目标有没有实现的衡量标准，另一方面也体现了为了实现目标，可能要做的具体事情的范围。
比如业务 KR 说“新增用户数 2000 万”，那么下面的团队可能就会进一步分解出“短视频平台买量 xx 万”“开发新业务拉新 xx 万”之类的工作。
所以 KR 太多不行，比如你列了 10 条，对应的事情太多，会导致精力和资源分散，难以形成突破。
而且 KR 太少也不行，比如你只列 1 条，这既说明没有全面地考虑到各种实现目标的方法，也会导致衡量标准太单一，最后可能会为了追求短期的单个数据指标而忽视业务长远的发展。
比如曾经有业务把“新增用户数 xx 万”作为唯一的 KR，于是下面的 P7/P8 执行的时候只管砸钱买量，不管用户质量。
结果到了年底一看，新增用户数是达标了，但是支出远远超出预算，用户留存率也很差；第二年严格控制预算之后，新增用户数立马被打回原形，用户活跃率更是远远不达标。
所以，业务目标有没有实现，我们需要综合 3～5 个 KR 一起来判断。
上一讲我提到过，KR 有两种表现形式，一种是可以量化的 KPI，比如“用户量增长 100 万”；另一种是虽然不能量化但是可以衡量的里程碑，比如“2021 年 6 月实现千人千面功能”。
所以 KR 不能采取定性的描述，像“用户量大幅增长”这样肯定是不合格的，因为不可衡量。
对于可以量化的 KR，关键在于具体的数值应该定多少，太低了看起来没有挑战，太高了看起来没有希望，但具体定多少并没有明确的标准。一般来说，可以参考历史数据、竞品数据或行业数据，也可以举全公司之力来定一个非常有挑战的目标值。
阶段二：团队规划
现在，我们再来看第二个阶段，团队规划。
第一步：对齐业务 OKR
团队规划的第一步是对齐业务规划的 OKR。
对齐是 OKR 规划的第二核心理念，也是 OKR 和 KPI 在做法上的另一个核心区别。
下一级的 Team Leader 要对照上一级业务 OKR，看看自己的团队能够贡献什么价值和力量，从而让整个公司“心往一处想，劲往一处使”。
假设现在业务规划的 OKR 是：
O：总用户数达到行业第一
KR1：新增用户数 2000 万
KR2：投入资金不超过 1 亿
KR3：新用户月留存率不低于 40%
那么如果你是技术团队的 TL，要怎么对齐呢？
首先，针对 KR1，技术团队能做的包括“降低 App 包大小”“SEO 优化”“开发某某新业务”和“开发小程序”等。
其次，针对 KR2，技术团队能做的不多，除非运营明确说“某个大渠道的 ROI 偏低，主要原因是包太大影响转化”，这时你就可以直接把解决问题作为团队的目标。
最后，针对 KR3，技术团队能做的包括“优化用户体验”“新用户连续签到奖励”和“新用户引导”等。
你可以看到，光是对照业务规划的一个 OKR，我们就能够想到很多关联的事情。按照同样的思路，再对照其他的 OKR 继续分析，把想到的事情分类整合排序形成自己团队的 OKR，对齐业务 OKR 的工作就完成了。
当然，对齐的过程同样需要“聚焦”，你的判断和选择同样得是有逻辑的，不能把所有关联的事情全部都罗列出来去做。
比如刚才这个例子中，针对 KR3“新用户月留存率不低于 40%”，你想到了可以通过“优化用户体验”这个技术手段来提升新用户留存率。
但是，“用户体验”真的是影响新用户留存的关键因素吗？这就需要论证了。你不能简单地摆出“提升用户体验肯定可以提升用户留存”这样的大道理，而是应该通过数据分析或者用户调研的结果来证明它们的逻辑关系。
第二步：补充专业 OKR
对齐业务 OKR 之后，团队规划的第二步是补充专业 OKR。
如果说对齐业务 OKR 是自上而下的传导，那么补充专业 OKR 就是自下而上的提炼。TL 要结合业务目标和团队情况，提出专业上的 OKR，和业务上的 OKR 共同组成团队完整的 OKR。
以技术团队为例，假设现在的业务系统问题比较多，团队成员要花很多时间来处理各种线上问题。
虽然因为团队成员的能力很强，所以最终这些问题没有对业务直接产生什么影响，但是站在整个团队角度来看，这会降低团队成员的工作效率和质量，长期这样就会影响正常的版本开发进度。
针对这种情况，TL 可能需要提炼一个专业目标：季度线上问题平均数量从 XX 减少到 YY。
这样的目标很难通过对齐得到，只能由技术团队自己提出来。
自上而下的传导需要很强的业务理解能力，而自下而上的提炼需要有很强的专业能力，这两种能力相辅相成，用 OKR 做团队规划的时候缺一不可。
所以，OKR 规划法对于 TL 来说，也是一个不小的考验。
举例：技术团队的 OKR 是怎么诞生的
假设某个技术团队负责一款电商 App 的技术工作，现在，我们通过一个完整的例子看看这个团队的 OKR 是怎么诞生的。
第一，业务负责人确定 2021 上半年的业务目标，其中之一是用户量增长（具体来说是增长到行业第三）。
第二，业务负责人分解 KR，比如针对用户量增长这个目标，业务负责人分解出了 3 个 KR，具体如下：
第三，技术团队 TL 拿到业务规划的 OKR 之后，进行对齐。
KR1 是“用户量增长 4000 万”，乍一看好像和技术团队没有太大关系，但实际上这就是技术团队需要基于业务来思考技术的一个典型 KR。
TL 从技术的角度来分析业务的目标：哪些技术指标和用户增长量有关，它们跟哪些技术有关，团队现在具备这些技术吗，还有没有优化的空间？
比如影响用户增长量的一些技术指标，就包括“安装包大小”“App 启动时间”“App 崩溃率”和“App 耗电情况”等。
经过分析，TL 认为目前的安装包太大，并且 App 启动时间较长，于是提出了 2 条对应的 KR：
\1. App 安装包从 20M 缩减到 8M
\2. App 启动时间从 2s 优化到 500ms
KR2 是“买量支出不超过 10 亿”，一般来说这跟技术团队的关系不大，不需要关注。
但是 TL 了解到，现在运营的系统无法评估每个渠道买量效果，所以他增加了 1 条对应的 KR：
\3. 新增渠道质量监测功能
这也反映出，技术团队 TL 如果能了解更多的业务信息，就可以为业务做出更大的贡献。
KR3 是“推出新业务 A”，TL 把它直接变成了自己团队的 1 条 KR：
\4. 推出新业务 A
TL 再继续对齐业务规划的其他 OKR，又得到了 2 条对应的 KR：
\5. 改版 B 业务
\6. 后端服务器接口平均响应时间从 60ms 提升到 30ms
然后，他对这 6 条 KR 进行分类整合排序，归纳出了 2 个目标：
O1：优化技术指标，提升用户体验
O2：保证关键业务和功能上线
所以，TL 通过对齐业务 OKR 得到的结果如下图所示：
第四，技术团队 TL 结合业务目标和团队情况，补充专业 OKR。
当前阶段在技术上有没有重点要做的事情呢？TL 经过思考发现，要实现用户增长，就需要做很多新的尝试性的功能，但是团队目前的版本节奏比较慢，原因是因为版本多而测试环境不足。
为了解决测试环境不足导致版本等待等问题，他得出了一个目标：
O3：提升测试效率
为此，他也分解出了几个 KR：
\1. 添加 4 台测试环境机器
\2. 引入 Docker，支持一台机器搭建 20 套环境
\3. 一键生成全套测试环境
于是，他补充了一个专业上的 OKR，如下图所示：
TL 将业务上的 OKR 和专业上的 OKR 结合起来，就得到了团队完整的 OKR，团队规划也就做好了。
看完这个例子，我想你已经对 OKR 规划法的使用建立了整体的认知。不过你对 OKR 可能还有一些疑问，接下来，我就针对两个常见的问题进行解答。
常见问题
问题一：如果用 OKR 规划法，要怎么做绩效考核呢？
美国硅谷的很多科技公司都用 OKR 取得了很好的效果，但介绍 OKR 的文章往往都会说 OKR 和绩效考核无关。
比如 Facebook 的绩效考核方式是 360 度环评，也就是通过多人打分的方式来对员工进行绩效考核。
目前来看，中国公司推广这种考核方式的可能性似乎不大。那么如果推行 OKR，绩效考核要怎么做呢，难道还要引入另外一套机制吗？
其实我之前提到过，KR 的两种形式，KPI 和里程碑，都要求是可以衡量的。所以，根据 OKR 本身来做绩效考核并没有什么问题，我们可以像考核 KPI 一样来考核 KR。
如果是 KPI 形式的 KR，就是看数值有没有达标，跟原定目标相差多少；
如果是里程碑形式的 KR，就是看事情有没有在规定的时间节点高质量地完成。
为了方便考核，我们甚至可以在制定 KR 的时候，就直接将结果的等级包含进去，比如：
KR1：用户量增长 1000 万（合格）；用户量增长 2000 万（良好）；用户量增长 3000 万（优秀）
不过在做 OKR 绩效考核的时候，还有可能出现两种比较特殊的情况：
第一种情况是，KR 都做到了，但是目标没有实现。
比如我们假设曹操专车的业务目标是“超越滴滴”，KR 是订单数增长 200%，但到了年底盘点一看，订单数增长 300%，超额完成，但行业第一还是滴滴。
那么这种情况怎么处理呢？OKR 的关键是实现目标，从这个角度来看，团队人员的绩效不会太高。
第二张情况是，KR 没有做到，但是目标实现了。
比如某电商 App 的业务目标是“成为行业第三”，年底盘点一看，发现 KR 没达成，但是确实成为了行业第三。
这种情况怎么处理呢？我们就要继续分情况讨论，看看目标到底是怎么实现的。
如果是因为竞争对手都不给力，全靠同行衬托得好，那么这种情况下团队人员的绩效也不会特别高。
但是如果是因为一开始的 KR 确实定得太高，团队为了实现目标，没有把有限的资源浪费在盲目地追求数据指标上，那么这其实是值得肯定的。
而如果是因为外部的不可抗力，比如突发疫情或国际政策变化，团队及时放弃年初制定的 KR，探索出了新的路径来实现目标，那么这就更加值得激励了。
问题二：OKR 规划法可以用来做个人规划吗？
虽然宣传 OKR 的文章一般都会声明 OKR 同样适合个人做规划，但从实践的效果来看，如果是 P7/P8/P9 级别且带了团队的技术主管，个人的规划就是团队的规划，使用 OKR 来做个人规划其实就是团队规划。
对于 P5/P6/P7 级别没有带团队的技术人员来说，使用 OKR 来做个人规划比较别扭，原因在于这个级别的技术人员更多的是执行团队主管安排的任务，自己能掌控的规划内容并不多。
小结
现在，我们回顾一下这一讲的重点。
3C方案设计法：怎么让你的方案有理有据？
你好，我是华仔。
上一讲我介绍了用来制定工作规划的 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% 的用户在成块的闲暇时间体验手游。
小结
现在，我们回顾一下重点内容。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
Memcache 连接不上的问题。
最后经过排查，我发现是因为 Memcache 默认连接数只有 1024，而业务上到了 0 点就可以开始新的一天的签到和奖励领取，大量用户卡点操作导致并发量大，连接数超过了 1024 个后 Memcache 就拒绝连接了；而且 PHP 连接的时候采用的是短连接，即使修改连接数，在大量并发连接时也会出现连不上的问题。后来，我们用 C 语言写了一个 PHP 连接池扩展，从而解决了问题。
这件事情要怎么总结呢？
如果某项技术你还没有按照“链式学习法”和“比较学习法”来学习，那么这就是一个很好的学习机会，你可以按照这两种方法画出领域分层图、细节分层图和方案对比的思维导图等。
如果某项技术你之前已经按照“链式学习法”和“比较学习法”学习过，那么你可以结合实践经验，完善领域分层图、细节分层图和方案对比的思维导图。随着你积累的越多，这三个图会越来越完善。
维度四：成长
第四个维度是成长。
除了关注技术上的提升之外，你还需要关注个人综合能力成长，也就是软实力提升，比如对业务的理解能力、项目组织能力、带领团队的能力、沟通能力和做事方法等。
这些能力在 P5/P6 晋升的时候可能没那么重要，但是到了 P7 以后就会变得越来越重要，而且综合能力很难靠突击来提升，只能在平时工作中逐步积累。
以业务理解能力为例，做完一个项目后，你可以从以下角度去总结：
业务的适应场景是什么？
目标用户是谁？
目标用户有什么特点？
解决了目标用户的什么问题？
实际的效果如何？
用户为什么喜欢 / 不喜欢这个功能？
随着做的项目越来越多，你通过总结得到的业务理解信息和能力也越积越多，到了一定阶段就可以量变导致质变，业务理解能力大大提升。
示例
使用 4D 总结法，看起来要整理的内容非常多，但是熟练之后你就会发现，其实并不怎么耗费时间，一个持续 1 个月的项目，可能用 1 个小时来总结就足够了。
总结的时候也不需要很正式，你可以用笔记的方式，把一些想到的关键点列出来。当这样的总结数量积累到一定的程度，你还可以再系统地整理一下，写成文章发表或者拿去给团队做培训，那样效果会更好。
下面是我之前做的一个业务总结示例，对应“成长”部分的总结，供你参考。
游戏衍生内容好坏对用户根本性影响非常弱，这个结论为何到了最后才发现？之前的决策都是基于这个判断来做的。
改进：有想法，然后快速验证，如果一次验证失败可以再尝试，但如果尝试一年还失败，那就要及时调整了。
“没有”和“偶尔”用竞品的竟然占了 90%，这说明几个竞品没有差异化（定位都一样），用户只需要其中一个。
“没时间玩”成为最主要的原因，是否说明用户对 app 的定位就是工具型，需要的时候用一下，不需要的时候根本不会去看。
用户的几个典型弱点：贪婪（礼包、活动、抽奖）、懒惰（信息流）、虚荣（等级、成就）、窥探（笑话、八卦）。
用户的主场景：礼包、下载、找游戏。
消磨零碎时间不是用户玩手游的最主要场景，反而是 63% 的用户在成块的闲暇时间体验手游。
小结
现在，我们回顾一下重点内容。
[外链图片转存中…(img-fxW5okSx-1715732445127)]
[外链图片转存中…(img-NFsf6N4a-1715732445128)]
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
28万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
