NO.1336 高手都有“上游思维”


你好,这里是罗胖精选。

昨天我给你介绍了我们得到全新策划的一个知识工程,前途丛书。这套书选取社会上各个热门的职业,对行业高手脑子里的经验和认知进行整理,是适应这个时代需求的、非常独特的一套百科全书。今天我请我们出版业务的负责人,这套书的策划人,白丽丽老师为你介绍一下,在研发这套产品的过程中,有什么有趣的事情。

你好,我是白丽丽,我是得到图书的负责人。去年的时候,提出了一个设想,做一套书,叫《前途丛书》。今年我们把前三本做出来了,很快后三本也会上市。

对于这样一个全新的产品,我们是怎么做的呢?就拿近年来最热门的一个职业——软件工程师来说吧。我们先是给这本书配备了最强的编著团队,一位叫丁丛丛,非常擅长用干净而又准确的文字表达;一位是软件工程师出身的靳冉,两个人一起搭档来做这本书。

第二步,我们要找到这个行业里最厉害的人。我们规划的每个职业,打算邀请三到五位厉害的人来采访,之所以这么做,是因为人太少的话,没有代表性;人太多,又会显得太杂。

我们想到的第一位软件工程师是郄小虎。吴军老师在《硅谷来信》中说,“谷歌中国历史上最好的工程师,没有之一,当属郄小虎”。于是我们邀请到了郄小虎老师。他在谷歌工作了12年,回国后在小红书、滴滴,现在在腾讯做副总裁,主导设计的有谷歌广告系统和滴滴交易平台系统,因此,无论是写代码的能力,还是国内外工作过的公司都有很强的代表性。

选定了第一位高手之后,我们又去各大软件工程师社区找了一圈,几乎把博客和内容都翻了一遍,看到了一位从业20多年,在亚马逊、阿里都工作过,现在自己创业,有很强的代码能力和输出能力的人,“左耳朵耗子”陈皓,业界称他为“骨灰级程序员”。后来我们还找到了代表机器学习最高水平的谷歌大脑的首席工程师陈智峰,和在百度等大厂担任过重要职位的鲁鹏俊老师。

找到厉害的人之后,要做的第三步是,把软件工程师这么大一个行业,封装到一本只有六万字的书里。这个难度有多大呢?大家知道,软件工程师的分工光大类就有六种,交互、系统、算法、数据分析、测试、运维,具体的工种更是有几十种之多,什么前端、后端,负责安卓系统的、负责iOS系统的,每个工种干的事情还都不一样。这么多内容要用这么短的篇幅介绍完,好像基本上不可能。后来我们想到了一个数学上的最大公约数的概念,就想可以找这个职业里,所有人都干的事情,所有的人都通用的能力来写。于是我们和老师一起沟通,找到了写代码、做测试、改Bug、设计程序、项目管理、攻克难题、技术决策等核心的内容,和执行能力、设计能力、抽象能力、前瞻能力、取舍能力几个关键的能力。 之后根据核心内容对四位行业高手,进行了数十个小时的深度访谈。

我们想要达到的效果是,你看完这本书,就能对这个职业有一个总体的了解。如果你想进阶,我们也会提供详备的方法和书单。

等这本书内容出来之后,陈皓老师说,感谢你们为程序员写了一本书,把专业壁垒这么高的一个行业给外行说清楚了。郄小虎老师也说,对于想进入软件工程师这个行当的人,以及在这个行当想突破职业天花板的人来说,这本书足够的好。

在这本书上市之前,我们还专门在得到站内,邀请了50位专业的软件工程师审读,请他们来把关。

在做《这就是软件工程师》这本书的过程中,我们看到了在这些高手眼里,软件工程师这个职业是怎么样的,也受到了非常多的启发。其中印象最深的一点是,厉害的软件工程师都有一个共同点,那就是他们都有上游思维。什么是上游思维呢?就是深度参与和服务自己的上一个环节,在问题发生之前就把问题解决掉。比如,软件工程师有两个典型的上游,一个是产品经理,一个是用户。那他们是怎么服务自己的产品经理和用户的呢?

我们都知道,一般是产品经理提需求,工程师负责实现。但是陈皓老师说,要做好设计,必须帮着产品经理把需求捋清楚,确定那些模糊的东西。因为在代码的世界里,1就是1,0就是0,非黑即白,没有灰色地带——只有把需求定义得清清楚楚、干干净净,软件工程师才能写出代码来。

这是什么意思呢?陈皓老师举了几个例子,他说,很多时候产品经理提出的需求非常模糊,比如“金额大一点的时候,就需要人审批;金额小一点的时候,就不需要人审批”,这时候软件工程师就要帮产品经理明确:什么是大,什么是小?3000元是大吗,还是5000元,10000元?必须有一个明确的数字。再比如,产品经理说,“面对恶意的人,我们要如何如何”“这个系统要能防住那些薅羊毛的人”,那软件工程师也要帮他明确: 什么叫恶意的人?什么叫薅羊毛?如果不帮着产品经理把这些内容定义出来,程序就没法写。

陈皓老师还特别提醒了一点,他告诉我们,绝大多数人都会把关注点放在可预期的事情上,而忘了关注不可预期的、可能出现故障的一些问题,软件工程师要特别留意。比如当这个程序走到某一步,走不下去了,怎么办?举个例子,电商网站里都有下单支付模块,产品经理想的是,用户选好商品,下单,支付,就完了,非常简单。

但是在这个过程里,如果用户下单了,却没支付怎么办?我要不要把库存分配给他?假设我不分配,直接取消订单,那用户过5分钟回来,发现下好的单失效了,心里肯定堵得慌;那假设我分配了,可用户一直没回来支付,库存一直被占着,其他人用不了,这也不行。所以工程师要帮助产品经理进一步明确,用户多长时间不付款就可以取消这个订单。在实际工作中,软件工程师要深度参与到产品经理的环节,明确各种模糊不清的需求,让整个程序跑通。

除了产品经理之外,用户也是软件工程师的上游。软件工程师要怎么服务好用户这个上游呢?

在郄小虎老师看来,好的软件工程师能在代码背后,看到用户本身。他举了一个例子,我印象很深。

很多人都拼过车,我们都知道,拼车就是几个人拼一辆车。那一定会涉及到,司机载着第一位乘客去接第二位乘客的情况。这时候就有个问题,怎么走才叫顺呢?关于这个问题,当时公司有一套数据标准:整体的时长增量或者距离增量只要不超过一个百分比,比如说15%,就是顺。

假设车上已经有一个乘客A,司机要去接下一个乘客B。A本来10分钟能到,因为接B变成了11分钟,或者本来10公里的路程变成了11公里,没超过15%,就是顺的。看起来非常明确了对不对?但好的软件工程师依然会想到:如果在早高峰时段,本来乘客A直行就能到达目的地,但是接乘客B得调头,可能调头用了1分钟,增量没超过15%,从数据上看也没错,这时候调不调头?这种路线的订单合不合理?

你看,这个问题就是看见了用户,看见了拼车的乘客。很多时候乘客赶早高峰,急着去开会呢,晚几分钟就迟到,结果司机开着开着调了个头,或者拐进小区里转来转去接下一个人,你说谁碰见这事不抓狂?

你会发现,可能调头的增量没超过15%,直行的增量也没超过15%,看数据都挺好。但这个15%跟那个15%对用户的影响完全不一样,体感天差地别。所以,郄小虎老师特别提醒了这一点,他说:“软件工程师脑子里要时刻绷着一根弦,你要知道,数据的背后都是人,系统的背后都是人,代码的背后也是人。”

我们以前一直觉得,厉害的软件工程师,主要是写代码很牛,但整个采访下来,几位老师都提到,要主动参与和服务自己的上一环节,也就是要有上游思维,这让我深受启发。

其实其他职业也一样。可以说,几乎所有职业里最拔尖的那群人都有一个特点,那就是力争上游。