上周发了一篇文章,由于标题的原因,没有引起大家的重视,我在知识星球也转发了链接,还是无人响应。
后来我把文章中的案例直接抽取了出来,单独展示,大家一下子就关注了:
简历中别这样写:
开发了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率降低了,有可能是由于这个迭代的需求就很简单啊!
但是量化总比不量化好,至少能看到长期的趋势,而不仅仅是个人拍脑袋的感觉。
也许你有一个懂行的老板,心里能衡量出你在工作中的作用和贡献,但更多的老板还是要看数字,有了这些量化的数字,升职,找工作肯定占优势。
感兴趣的读者可以再看看那篇文章《好文分享:我是如何把自己“推销”出去的》, 里边不仅仅有量化指标的例子,还讲了如何用自己的技能和经验去匹配公司的需求,怎么去组织“推销”的话术,从而打动那些负责招聘的人。
往期精彩回顾
编程语言的巅峰