大厂晋升指南_29_28_4D总结法怎么展示你的工作亮点
你好，我是华仔。
前几讲，我为你介绍了适中执行阶段的四种方法。
这些方法能够提升你拿到好结果的概率，但是不能保证让你一定拿到好的结果，因为影响最终结果的因素太多了。
首先，就算使用三c方案设计法，决策过程仍然有可能有失误。
比如，受限于团队整体的技能限制分析和讨论备选方案的时候，漏了一个重要的方案或者决策时采用的判断标准有问题，对性能要求估计过高，实际上线后业务量远远没有预期那么大等等情况。
其次，就算使用PDCA执行法执行过程仍然有可能出现偏差。
虽然PDCA方法能够有效的对任务进行规划和跟踪，但是具体执行的时候可能会受到使用者的水平和投入资源等因素的限制。
最后就算方法都使用得当，还是有可能受外部因素干扰。
比如某海外钱包团队用三c方案设计法设计出了最优的业务方案，但是当地政局不稳定导致跨境消费剧烈减少。
然后又发生疫情，导致本地消费大幅减少，最终结果可能就很不好。
所以不单做事的方法很重要，而且做事的结果也重要。
在晋升答辩的时候，评委除了考察规划和执行相关的为什么之外，还会考察和做事结果相关的？为什么？比如，你认为这个结果怎么样？你怎么评价这个结果？为什么你认为这个结果不好？为什么你的方法挺好，但是结果不好，你从这个结果得到了什么经验和教训？你可能以为结果好的事情讲起来就很容易了，结果不好才需要包装一下。
其实不是这样的，结果不好的事情，你的确需要分析原因，总结经验教训，但是结果好的事情你也需要讲清楚你对结果的贡献。
但是，大部分人在答辩环节介绍工作结果时表现都很一般。
常见的误区有四种。
第一种误区，讲的贡献是团队的总贡献，没有讲清楚自己对结果的贡献，或者拔高了自己对结果的贡献。
第二种误区，只讲自己的做事方法多么高大上，却不提最终的结果。
比如说自己引入了某某算法，却不说到底带来了什么好处。
第三种误区虽然提了一下效果，但是都是比较虚的描述，比如高可用、高性能用户转化率大大提升之类的话。
评委听完也不知道到底有多高有多大提升。
第四种误区虽然描述效果的时候列出了贡献，但仅仅是把从产品经理和运营经你那里要的数据贴过来，对于数据没有自己的理解和判断。
评委针对数据问的问题都答不上来，那么总结的时候，到底要怎么说，才能充分展示出自己的工作亮点呢？这就要用到四d总结法了。
也就是从结果用据技术和成长这四个维度来整理自己的做事收获，从而涵盖事情的重点难点核心点，有效的应对晋升答辩时可能遇到的各种问题。
第一个维度是结果，结果这个维度重点关注的是事情带来的价值。
不同类型的团队在结果价值方面表现会有一些差异。
首先是业务开发团队，首先是业务开发项目，技术优化方案还是管理措施，我都建议从业务角度进行结果总结。
对于业务开发项目来说，从业务的维度总结是自然而然的。
例如某个业务用户日活是多少？对于技术优化方案来说，主要看技术方案给业务带来的价值是什么？比如高可用方案，让业务p一故障从五次减少到零次，结于管理措施来说，主要看管理措施带来的效率和质量的提升。
比如同样的人员支撑了更多业务。
其次是中间件开发团队，结果建议从系统的性能、可用性和成本等方面进行总结。
如果中间件系统已经产品化，也可以从销售量或者流量等方面进行总结。
最后是技术支撑团队，也就是运维和测试之类的部门。
结果建议从质量、效率和成本方面进行总结。
比如测试做了一个自动化测试平台，可以降低五千人日测试工作量。
使用了这个自动化测试平台的某业务线，上年度故障数量从二十个降低为五个。
其二个维度是数据向提升了开发效率。
这种比较虚的描述，应该改成开发一个功能，从二十人天提升为二人天。
这种使用具体数据的描述，通过数据来描述结果的时候，你不但要列出相关的数据，而且对于这些数据背后的含义也要有自己的理解，尤其是对数据的评价以及评价的标准。
通过评价数据的方式，你可以培养自己的业务思维和理解力。
比如，同样是将用户活跃率提升百分之五，对于一个像微信这样成熟的业务来说，是非常难得的。
但对于一个新业务来说，还远远不够。
同样的道理，从百分之二十提升到百分之二十五，和从百分之九十提升到百分之九十五，含义也是完全不同的。
很多人在一开始尝试的时候会遇到一个疑问，感觉这个事情好像没有办法用数据来描述呀，这个时候怎么办呢？其实大部分的情况不是真的不能用数据来描述，而是你没有去搜集数据，没有养成用数据来说明的习惯。
比如以前需要写代码才能实现的业务，某个技术优化方案，采用XML配置就可以完成了。
但是之前也没有谁去搜集实际上的开发时间，所以无法进行对比，但效率肯定是提升了的。
遇到这种情况，我们可以采取临时补数据的方式，也就是找团队相关人员评估一下之前方案所需的时间。
为了避免单个人评估出现严重误差，你可以找多个人进行评估，发挥集体智慧，最后取一个平均值或者中间值。
这样得到的数据，虽然没有采用项目管理工具进行搜集，那样严谨和客观，但实际上也不会偏差太大。
当你平时积累了大量数据总结的内容，后写晋升PPT的时候，就可以信手拈来，而不用再绞尽脑汁去回想一年前做过的一个项目。
具体的结果是什么了。
第三个维度是技术。
对于技术人员来说，做完一个项目或者方案之后，技术上有哪些提升，学到了什么？新的技术对哪些技术有了更深或者更全面的理解等，都可以在总结的时候系统的梳理一下。
虽然我们在设计方案的时候已经采用了三c方案设计法，对领域进行了全面的分析和研究，但并不代表这样就可以完全掌握所有相关的知识和技能。
在具体落地的过程中，肯定还会遇到很多细节或者之前没有注意的地方。
在事情做完之后，统一的整理和总结一下，经验教训，能够进一步提升技术深度。
我在二零一三年左右使用memory cash的时候，就遇到过一个比较奇怪的问题。
开发语言是PGP五采用NGINX加PGP杠FPM来做容器，每天晚上到了零点就随机出现memory cash连接不上的问题。
最后经过排查，我发现是因为memory cash默认连接数只有一千零二十四，而业务上到了零点就可以开始新的一天的签到和奖励。
领取大量用户卡点操作，导致并发量大，连接数超过了一千零二十四个之后，memory cash就拒绝连接了。
而且PGP连接的时候采用的是短连接，即使修改连接数，在大量并发连接时也会出现连接不上的问题。
后来我们用c语言写了一个PGP连接池扩展，从而解决了问题。
这件事情要怎么总结呢？如果某项技术，你还没有按照链式学习法和比较学习法来学习，那么这就是一个很好的学习机会。
你可以按照这两种方法画出领域分层图、细节分层图和方案对比的思维导图等。
如果某项技术，你之前已经按照链式学习法和比较学习法学习过，那么你可以结合实践经验，完善领域分层图、细节分层图和方案对比的思维导图。
随着你积累的越多，这三个图会越来越完善。
第四个维度是成长，除了关注技术上的提升之外，你还需要关注个人综合能力。
成长也就是软实力提升。
比如对业务的理解能力、项目组织能力，带领团队的能升沟通能力和做事方法等。
这些能力。
在p五p六晋升的时候可能没那么重要。
但是到了p七以后，就会变得越来越重要，而且综合能力很难靠突击来提升，只能在平时工作中逐步积累。
以业务理解能力为例，做完一个项目后，你可以从这些角度去总结业务的适应场景是什么？目标用户是谁？目标用户有什么特点？解决了目标用户的什么问题，实际的效果如何？用户为什么喜欢不喜欢这个功能？一着做的项目越来越多，你通过总结得到的业务理解，信息和能力也越积越多，到了一定阶段就可以量变引发质变，业务理解能力就能得到非常大的提升。
使用四d总结法看起来要整理的内容非常多，但是熟练之后你就会发现，其实并不怎么耗费时间。
一个持续一个月的项目，可能用一个小时来总结就足够了。
总结的时候也不需要很正式，你可以用笔记的方式把一些想到的关键点列出来。
当这样的总结数量积累到一定的程度，你还可以在系统的整理一下，写成文章发表，或者拿去给团队做培训，那样效果会更好。
下面是我之前做的一个业务总结，事例对应成上部分的总结供你参考。
第一点，游戏衍生内容好坏对用户根本性影响非常弱。
这个结论为何到了最后才发现，之前的决策都是基于这个判断来做的。
改进有想法，然后快速验证。
如果一次验证失败，可以再尝试，但如果尝试一年还失败，那就要及时调整了。
第二点，没有和偶尔用竞品的竟然占了百分之九十。
这说明几个竞品没有差异化，用户只需要其中一个。
第三点没时间玩，成为最主要的原因。
是否说明用户对app的定位，就是工具型需要的时候用一下，不需要的时候根本不会去看。
第四点，用户的几个典型弱点，贪婪、懒惰、虚荣窥探。
第五点，用户的主场景礼包，最后找游戏第六点消磨零碎时间，不是用户玩手游的最主要场景，反而是百分之六十三的用户在成快的闲暇时间体验手游。
现在我们回顾一下重点内容。
第一个重点汇报工作成果时，有四个常见的误区，讲不清楚自己对结果的贡献，只有结果，没有效果，效果只有很虚的描述，没有具体数据，对给出来的数据没有自己的理解和判断。
第二个重点四d总结法就是从结果、数据、技术和成长这四个维度来整理自己的做事，收获，展示工作上的亮点。
第三个重点，当总结数量积累到一定程度的时候，还可以在系统的整理一下，写成文章发表，或者拿去给团队做培训，那样效果会更好。
好了，这就是今天的全部内容，留一道课后思考题给你。
Pdca中act阶段需要总结四d总结法也是总结。
你觉得它们的联系和区别是什么呢？欢迎你把答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。