文章强调简历工作描述应从业务角度量化，如用React开发订单应用体现收入和留存率提升等。还介绍了获取量化数据的方法，如服务重构前后做性能测试。虽部分量化指标受外部因素影响，但量化仍比不量化好，能助升职、求职。
上周发了一篇文章，由于标题的原因，没有引起大家的重视，我在知识星球也转发了链接，还是无人响应。
后来我把文章中的案例直接抽取了出来，单独展示，大家一下子就关注了：
简历中别这样写：
开发了React 应用，客户可以查看和更新订单
应该这么写：
用React开发了订单应用，收入增加了5%， 客户留存率提高了4%
别这么写：
在CDE软件公司，用Redis实现了缓存层（写了一个通用模块封装客户端对Redis的调用）
应该这么写：
在CDE软件公司，用Redis实现了缓存层（写了一个通用模块封装客户端对Redis的调用），由于不需要每次都访问数据库，API的响应时间提升了45%
别这么写：
在XYZ医疗保健公司，和产品组，用户体验组，以及最终用户紧密合作，重新设计了iOS app中的计费流程
应该这么写：
在XYZ医疗保健公司，和产品组，用户体验组，以及最终用户紧密合作，重新设计了iOS app中的计费流程， 使得客户呼叫团队的电话减少了20%
看到差别了吗？不是说“我做了什么”，而是“我为什么要做？为什么这件事重要？这件事的结果如何？”
从业务的角度去量化你的工作，这会非常让人印象非常深刻。简历不是Show自己的技术有多酷， 而是告诉对方，我的技能和你的需求匹配，我能给你提供价值。
@代码GG陆晓明 评论到 ：要让对方觉得对他有价值，才是核心。不能老说自己怎么怎么样，跟对方无关你说的越多越危险。
@杨 评论道：果然，能力，团队合作，沟通：都用不张扬的方式表达出来了。
还有不少人说：量化的数据是怎么来的呢？ 道理大家都懂，问题是如何量化呢？比如说我基本完全重构（写）了原来老的服务，新的服务性能明显提升，大大降低了操作失败的风险，但这是一个很虚的概念。我也一直想怎么量化这些，但不知道这些具体的数据从哪里拿到统计呢？
其实对于这种服务性能的提升，做重构之前应该做性能的测试，得出服务的性能数据，例如在xxx个并发用户下响应时间是多少，每秒能处理多少请求，等到重构后再测试一下，这就就计算出来量化的数据了。
这就提醒我们，在做这样的事情的时候，要以业务为导向，技术是为业务服务的，一开始就要有量化意识，等你做完了，你想量化都难了。
我也是在这里指点江山，自己做起这种量化的工作还是挺难的，很多时候老板有要求的时候才会被迫去做，心里还觉得很烦。
记得2010年在华为做敏捷咨询的时候，做了一些敏捷实践要汇报效果，怎么量化呢？怎么说敏捷实践做得还不错呢？还好当时有每个迭代的defect率，测试代码覆盖率，这样可以比一比，就能看到进步（或者退步）了。
有些量化指标有些很客观，例如API响应时间提高了45%， 代码覆盖率达到了85%。
有些其实是依赖外部因素的，例如”用React开发了订单应用，收入增加了5%” ，收入的增长不一定是技术引起的，也可能是由于促销季引起的啊！再比如这个迭代的defect率降低了，有可能是由于这个迭代的需求就很简单啊！
但是量化总比不量化好，至少能看到长期的趋势，而不仅仅是个人拍脑袋的感觉。
也许你有一个懂行的老板，心里能衡量出你在工作中的作用和贡献，但更多的老板还是要看数字，有了这些量化的数字，升职，找工作肯定占优势。
感兴趣的读者可以再看看那篇文章《好文分享：我是如何把自己“推销”出去的》， 里边不仅仅有量化指标的例子，还讲了如何用自己的技能和经验去匹配公司的需求，怎么去组织“推销”的话术，从而打动那些负责招聘的人。
往期精彩回顾
编程语言的巅峰
扫一扫
2631
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
