鉴于项目的高度机密性，很多话不能说，我唯一能透露的，就是两条：同事们都很牛，然后都非常努力。我们组基本上是9点开始工作，然后晚上6点多走，老板不怎么主动管，但大家都明白如果事情做不完就得加班，因为一个一个小发布（release）的最后期限（deadline）摆在那里，不能不干。总的来说，比谷歌的其它部门要忙一点，节奏很快，不像是在大公司里工作，反倒更像是在一个初创团队里忙碌。
这四个月感觉下来，Google[x]实验室有几个很有趣的特点。其一是软硬件结合极其紧密，这一点从已有的报道里可以看出，不论是无人车(Self-driving car)，眼镜(Google Glass)还是最近公布的气球无线网络(Loon)及能测血糖的隐形眼镜(Iris)，都是软硬结合的产品。这直接导致的结果，就是我们每天面对的问题和之前在学术圈时思考的完全不同。
在学术圈，问题的已知条件和数据集都是给定的，我们要做的就是像解数学题一样，钻进去找到更好的解法，并在已知的数据集上和前人对比证明其有效性。但在Google[x]则完全不同，大项目（比如说开发无人车）摆在这里，但已知条件，解决方案，使用何种硬件，如何分配资源，都是不确定的；唯一确定的，是要以最快的方式和最小的成本把它实现出来——让一辆车能安全地自行其道，同时生产成本又最少。在这样的特定背景下，碰到一个难题，首先想的不是把它死命解出来，而是问自己是不是有必要解它，能不能绕开它而实现目标？事实证明，在这样高自由度的空间里寻找一个特定的解决方案，几乎总是能绕过学术界的难题，找到简单易行的实用方法。这就像要发明能在道路上移动的机器人，不是绞尽脑汁去研究人类两足的机理，而是用容易控制又廉价的轮子代替；要设计飞机，不去模仿鸟类形态优美却机理复杂的扑翼，而是使用固定机翼加喷气动力。
其二是几乎没有专职的研究职位。所有人既是研究员(Researcher)，又是软件工程师(Software Engineer)。基本上每个人负责一个具体的方向，对这个方向自主地分析现存的问题，并不断通过和同事讨论提出新方案，最后评估方案的效果。就算是组里的老板（Manager)，甚至是老板的老板，也要写代码查错误完成具体工作，唯一的不同点，是他们对系统有更整体的理解，遇到问题能帮忙找到下属找不到的角度。碰到许多任务同时需要完成的时候，能分清主次，丢卒保车，确保整个组的大方向正确。
对于从来没有碰到过的新问题，思考新思路和写代码开发是同时进行的，C++代码写完就直接上产品去测试看效果如何，不行就分析研究再换一种，如此快速迭代直到找到好方案为止，如果一两周里找不到好方案，那就认为这个问题是困难的，于是就要退一步思考，想办法绕开它。
因为这个原因，诸如“写代码和做研究的时间比例是多少”之类的问题就没有什么意义，因为完全看需要解决的是什么问题，写很多格式漂亮架构清晰的代码却不能解决问题没有意义，天马行空地思考不在实际数据上跑也没有意义，最重要的只是“解决问题”这四个字。
这种思路决定了研究风格是“具体问题具体分析”式的，有额外条件和额外信息就尽量用上，不会花时间思考一般情况；是“崇尚简单方案快速出结果”式的，而不会使用精巧复杂却不太直观的数学理论，也不会花几个月赌一个万能算法。这种研究方式的缺点显而易见，就是没有办法产生深远及本质的成果，但是既然目标是利用人类现有的技术，去完成一个举世瞩目的新系统和新产品，我想不出来有其它更好的推动方式了。
其三是组内信息交流的极端重要性。学术界强调钻研问题，独立工作和原创性成果；但至少在无人车组，是鼓励也必须时常和别人沟通的。一个人，特别是刚进来的新人，对整个系统的组成没有深刻理解，也不去询问同事，老板给一个问题就按自己的想法单干，结果发现三分之一工作和无人车目前急需解决的难点无关，三分之一工作已有人做出过类似工具，还有三分之一工作听起来很有道理，自成一说，但是在实际数据上一跑效果很差。这些情况是完全可能的。按学术界的思路，这些工作都可以发（不同风格的）文章，但在我们这里，全都是没有用的。
而充分交流讨论就能避免这类情况。有越多来自别人的信息，就越能明确目标直入主题；越知道系统的优劣和目前的可用工具，就越能借风使力，提高效率。有时候跨组间不经意的一两句对话，少则抵得上几小时或者几天的辛勤劳作，多则改变整个组的行进方向。无人车组里中国人非常非常少，因此英语的地位相应提高，实在是需要在业余时间多加训练才好。
对于这样一个开创性项目，虽然已经取得了重要的进展，但还是有很多棘手的具体问题需要解决，每一个细节都决定成败。并且，越接近最终目标就越为艰难，有时候为了有百分之一的效果提升，是不惜从头再来，将原来的工作全部推翻的。所以说这个项目最后是否成功，还要看全体同事的聪明才智和勤奋努力，及一点点捉摸不定的运气。
希望运气在我们这边。
相关文章：
近期新闻
热门新闻
奥松智能微信
