mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-01 15:46:43 +08:00
161 lines
12 KiB
Markdown
161 lines
12 KiB
Markdown
<audio id="audio" title="28 | 4D总结法：怎么展示你的工作亮点？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5f/cb/5fd1bc0c9497a49a519bd9dd7f60decb.mp3"></audio>
|
||
|
||
你好，我是华仔。
|
||
|
||
前几讲我为你介绍了事中执行阶段的4种方法，这些方法能够提升你拿到好结果的概率，但是不能保证让你一定拿到好的结果，因为影响最终结果的因素太多了。
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/2b/6e/2b99ed286a28b9346966e72663557d6e.jpg" alt="">
|
||
|
||
首先，就算使用3C方案设计法，决策过程仍然有可能有失误。
|
||
|
||
比如受限于团队整体的技能限制，分析和讨论备选方案的时候漏了一个重要的方案；或者决策时采用的判断标准有问题，对性能要求估计过高，实际上线后业务量远远没有预期那么大等情况。
|
||
|
||
其次，就算使用PDCA执行法，执行过程仍然有可能出现偏差。
|
||
|
||
虽然PDCA方法能够有效地对任务进行规划和跟踪，但是具体执行的时候，可能会受到使用者的水平和投入资源等因素的限制。
|
||
|
||
最后，就算方法都使用得当，还是有可能受外部因素干扰。
|
||
|
||
比如某海外钱包团队用3C方案设计法设计出了最优的业务方案，但是当地政局不稳定，导致跨境消费剧烈减少，然后又发生疫情，导致本地消费大幅减少，最终结果可能就很不好。
|
||
|
||
所以，不但做事的方法很重要，而且做事的结果也重要。在晋升答辩的时候，评委除了考察规划和执行相关的“为什么”之外，还会考察和做事结果相关的“为什么”，比如：
|
||
|
||
- 你认为这个结果怎么样？你怎么评价这个结果？
|
||
- 为什么你认为这个结果不好？
|
||
- 为什么你的方法挺好但是结果不好？
|
||
- 你从这个结果得到什么经验和教训？
|
||
|
||
你可能以为，结果好的事情讲起来就很容易了，结果不好才需要包装一下。其实不是这样的，结果不好的事情，你的确需要分析原因，总结经验教训；但是结果好的事情，你也需要讲清楚你对结果的贡献。
|
||
|
||
大部分人在这个环节的表现都很一般，常见的误区有：
|
||
|
||
1. 讲的贡献是团队的总贡献，没有讲清楚自己对结果的贡献，或者拔高了自己对结果的贡献。
|
||
1. 只讲自己的做事方法多么高大上，却不提最终的效果，比如说自己引入了某某算法，但却不说到底带来了什么好处。
|
||
1. 虽然提了一下效果，但都是比较虚的描述，比如高可用、高性能、用户转化率大大提升之类的话，评委听完也不知道到底有多高、有多大提升。
|
||
1. 虽然描述效果的时候列出了数据（能列出数据已经超出了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个小时来总结就足够了。
|
||
|
||
总结的时候也不需要很正式，你可以用笔记的方式，把一些想到的关键点列出来。当这样的总结数量积累到一定的程度，你还可以再系统地整理一下，写成文章发表或者拿去给团队做培训，那样效果会更好。
|
||
|
||
下面是我之前做的一个业务总结示例，对应“成长”部分的总结，供你参考。
|
||
|
||
<li>
|
||
<p>游戏衍生内容好坏对用户根本性影响非常弱，这个结论为何到了最后才发现？之前的决策都是基于这个判断来做的。<br>
|
||
改进：有想法，然后快速验证，如果一次验证失败可以再尝试，但如果尝试一年还失败，那就要及时调整了。</p>
|
||
</li>
|
||
<li>
|
||
“没有”和“偶尔”用竞品的竟然占了90%，这说明几个竞品没有差异化（定位都一样），用户只需要其中一个。
|
||
</li>
|
||
<li>
|
||
“没时间玩”成为最主要的原因，是否说明用户对app的定位就是工具型，需要的时候用一下，不需要的时候根本不会去看。
|
||
</li>
|
||
<li>
|
||
用户的几个典型弱点：贪婪（礼包、活动、抽奖）、懒惰（信息流）、虚荣（等级、成就）、窥探（笑话、八卦）。
|
||
</li>
|
||
<li>
|
||
用户的主场景：礼包、下载、找游戏。
|
||
</li>
|
||
<li>
|
||
消磨零碎时间不是用户玩手游的最主要场景，反而是63%的用户在成块的闲暇时间体验手游。
|
||
</li>
|
||
|
||
## 小结
|
||
|
||
现在，我们回顾一下重点内容。
|
||
|
||
1. 汇报工作成果时有四个常见的误区：只有结果没有效果；效果只有很虚的描述，没有具体数据；对给出来的数据没有自己的理解和判断。
|
||
1. 4D总结法就是从结果、数据、技术和成长这4个维度（Dimension）来整理自己的做事收获，展示工作上的亮点。
|
||
<li>当总结数量积累到一定程度的时候，还可以再系统地整理一下，写成文章发表或者拿去给团队做培训，那样效果会更好。<br>
|
||
<img src="https://static001.geekbang.org/resource/image/03/d3/03e22280e74a323cb7aba7772c5ac3d3.jpg" alt=""></li>
|
||
|
||
## 思考题
|
||
|
||
这就是今天的全部内容，留一道课后思考题给你吧。PDCA中Act阶段需要总结，4D总结法也是总结，你觉得它们的联系和区别是什么呢？
|
||
|
||
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。<br>
|
||
<img src="https://static001.geekbang.org/resource/image/18/03/18da357a909e28c80fab4609d552bd03.jpeg" alt="">
|