财新传媒 财新传媒

阅读:0
听报道
闭门造车三个月,做出了gTest第一版。但是我歌没人听说过这东西啊,怎么办?谷歌内部工具的推广要走草根路线,不能指望领导替你搞定,所以接下来要集中精力干推销员。我先是写用户指南,然后找了几个项目挨个谈。一开始进展很缓慢,大家很客气但就是不动手。这可以理解:这东西从来没人用过,谁知道是不是个坑;大家都忙,花半天时间学这个要是最后发现不靠谱岂不傻了,还是维持现状最保险。我歌著名地摊文学巨匠和数学教育家王老板说,这真是人性的悲哀。
 
用户惯性大,不下点猛药不足以把他们拱出局部最低点。你不用,我帮你用,你签个字就行好吧?还好我歌的代码库是共享的,我挽起袖子帮几个组改了他们的build scripts,把gTest集成到他们的build中,再挑几个他们的旧的测试用gTest重写一遍,然后苦口婆心地解释这么做的种种好处:等以后gTest用的人多了,风格就统一了,世界大同多美好。人家一看我都到这份上了,也不好说啥,通过吧。
 
不过这种亲自上阵拉客的做法只能用在项目初创时期,谷歌这么多C++工程师,我不能挨个去求啊。能不能把这个过程自动化呢?我想的办法,是写个程序每周扫描我歌的代码库,看谁又写了新的C++测试但是没有用gTest,他们就是我下一步需要拉拢的对象。然后,程序再自动以我的名义给他们发一封劝进信,晓之以情动之以利。为了有人情味,收信人的名字不是他们的用户名,而是他们的实名。为了看起来不像群发的垃圾信,信的内容也是定制的,包括收信人最近写过的测试的文件名。考虑到用户需要时间考虑,我也不能追得太紧了。试想谁要是每个星期都跟我唠叨某产品如何如何好,我一定认为碰上了搞传销的会把他直接拉黑甚至向公司举报。所以,我的程序只会发信给最近六个月没发过信的人。
 
一般来说,越是重要的人物越难说服,因为他们都很忙,没有时间尝试很多新玩意。像我司最早的两位院士Jeff和Sanjay,收到我的邀请信后不为所动,大概是一年过后他们才被拉下水。不过,他们也是最有影响力的,一旦把他们争取过来,就会带来一大批用户。今天做创业公司的人都知道,一个明星用户的价值抵得过成千上万普通用户。
 
除了主动拉拢新用户,原有的用户也得看牢了,得想办法让他们觉得舒服。用户有了问题,我尽快解答。用户发现了gTest的bug或是不足,我尽量改进,总之要确保他们不后悔选择了gTest。因为我是一个人搞这个项目,没有固定搭档,每次改完代码要提交都要到处找人做代码审查(我歌规定,所有代码变动都必须先通过同行审查,一来确保质量,二来保证这个代码不只一个人搞得懂,如果原作者跑路了接手的人也不致于撞墙。我觉得这是一个很好的制度。)。一般来说我都是找报告问题的同学审查:首先他有动力把这个问题早解决,其次(这是我后来发现的)因为他亲自参与了gTest的开发,会对gTest有更深的感情,经常会成为它的义务宣传员。
 
再后来,用户的需求我一个人忙不过来了,别的工程师就会用他们的20%时间(我歌允许工程师花一部分时间做跟自己项目没有直接关系的工作,这个制度叫“20%时间”)帮我一起搞,我负责对设计把关。这样参与gTest开发的工程师前前后后有几十个,包括Jeff院士贡献了一个功能的实现,Sanjay院士贡献了一个提高系统可扩展性的主意。慢慢地,用户邮件表上不只我一个人回答问题了。这样,用户群和社区进入了一个正循环。两年后,公司大约90%的新的C++测试都是用gTest写的了。
 

gTest的成功推广,还必须要感谢我司测试小分队(testing grouplet)的很多努力。这个测试小分队是我司内部一民间组织,最早就是一群关心公司软件质量的员工,聚在一起献计献策帮公司提高测试水平。别看今天我们公司的员工普遍认为开发过程中要写很多测试是正常的事,这也是后来慢慢转变的,一开始我司的测试文化也不尽人意,大家拒写测试是常态。测试小分队和测试技术部做了很多工作,宣传、培训、改进工具、搞活动,慢慢地自底向上改变了公司的文化。通常来说一家公司在规模扩大的过程中文化都会逐渐沦落,我们能在这一点上向好的方向发展而且是质变,十分难得。作为小分队曾经的成员,我不得不感到骄傲自满。

上一篇系列目录下一篇

话题:



0

推荐

老万故事会

老万故事会

156篇文章 4小时前更新

老万,基层程序员。智商配置一般,主频较低,小内存患者。文化程度介于《知音》和《故事会》之间。偶尔写几个字,发在财新和微信公众号“老万故事会”(laowangushihui)。

文章