我一直在IT企业的研究部门任职,迄今经历了三家公司:NEC、微软、华为。工作都是既有基础研究,又有产品开发。其实,这两者既有密切联系,性质上又迥然不同。前者在于发现或发明普适性的理论与方法,后者在于开发实用性的系统与工具。可以说,前者需要的思维方式、基本技能与素质是科学家的,而后者是工程师的。我经常提醒自己,一定要明确在具体项目中自己到底带着什么“帽子”在工作,是科学家,还是工程师?
我曾经将如何成为优秀科学家的体会整理成若干篇博文发表,而本文来谈谈如何成为优秀工程师的一些心得。我认为,做工程时应该遵循五项原则,并在实际的工作中把它们作为行为 指南。这些原则是:面对问题、解决问题,系统地解决问题,站在用户角度看问题,以最小的代价获得最大的效益,磨在细处。在这里做一总结,仅供大家参考。
面对问题,解决问题
西方有句谚语:“当手中拿着榔头的时候,你会觉得看到的东西都像是钉子”。根据自己的喜好、特长、习惯来解决问题是工程师的大忌。做工程时最重要的是要面对问题、解决问题。可取的策略应该是探明问题的本质,弄清问题的机理,用最直接、最有效的办法解决问题。经验告诉我们,拐弯抹角地解决问题,效果总是不好的。做工程时并不一定需要理论。只要能够有效地解决问题,其实什么方法都行。“不管白猫黑猫,捉住老鼠就是好猫”在这里也是适用的。当然有理论指导的方法 往往更能抓住问题的本质,以其为工具常常能把问题解决得更好。
在NEC工作时,我曾参加一个自然语言研究小组的立项会议。他们建议开发语音 系统来帮助用户遥控电视机,因为现在的遥控器操作都过于复杂,不利于老人与儿童使用。用语音声控电视,当然是很好的想法,现在仍有许多企业在进行这项应用 的开发。印象特别深的是他们断言,除了通过语音的办法,不存在其他解决方案。当时,我也认为他们的想法很有道理。
不料,没过几个月,日本的其他几家电器公司推出了用编码遥控电视的方法,更简单、更实用。遥控器的操作主要靠数字输入,每个电视节目都配上一个编码,报纸每天将编码在电视节目栏中公布,用户只要输入编码即可观看或录制相应的节目。
这件事对我的内心产生了很大的震动,自问为什么NEC的同事们只想到自然语言这条路,而忽视了其他路?不正是因为他们手里拿着自然语言这个榔头的缘故吗?
系统地解决问题
动画片《没头脑与不高兴》描写了两位少年:“没头脑”与“不高兴”。“没头脑”做起事来总是丢三落四,“不高兴”待人处事总爱别别扭扭。不久,“没头脑”当上了工程师,“不高兴”当上了演员。“没头脑”设计了一座一百九十九层高的少年宫,楼建好以后,才发现忘记了设计电梯。孩子们为了在这个大楼顶层的剧院看 戏,需要带着铺盖、干粮爬一个月的楼梯,害人不浅。其实,我们在日常生活中也能看到不少“没头脑”的作品。工程师需要构建的一定是一个系统。系统一定需要 全面、整体、有机的设计,不能有缺陷与差错。切忌成为“没头脑”的工程师。
在微软,与唐朝晖博士等合作开发了SQL Server 2005中的文本数据挖掘功能。其中的Term Extraction工具可以从数据库中的英文文本中自动抽取名词短语。这个工具的输入通常是英文文本,看似单一,但设计这个工具时,必须考虑处理其他非 正常输入,应对所有可能,比如,乱码、非英文、特殊字符、全文本大写、不含标点符号文本,等等。记得开发团队一起构建了一张巨大的逻辑图表,将所有可能的 输入列出,准备处理方案,力图做到“兵来将挡,水来土掩”。这个项目确实锻炼了大家系统解决问题的能力。
站在用户角度看问题
苹果公司的产品,如iPad,用户界面非常简单、直观与易用。据说两岁的儿童也能无师自通,自如地使用iPad。理由很简单,苹果的产品都是为用户着想,站 在用户的角度上设计的。正是因为如此,苹果的产品能够得到广大用户的喜爱和追捧。道理虽然简单,但我们会发现,许多工程师在开发系统时常常做不到这一点, 所以做出的东西,根本不好用。
在NEC参加的第一个项目是个失败的项目。目标是开发自然语言的用户界面,自动将用户输入的日语问句转换成 SQL语句,以便让普通用户很方便地访问数据库。这个项目的初衷很好,但面临的最大挑战是,语言的表现力极其强大,同样一个意思,可以有许多种不同的说法。开发到最后,系统只能接受受限的自然语言输入(当时还没有基于统计学习解决问题的想法,也许可以通过大数据、统计学习的方法在一定程度上能够解决这个问题,这也是自然语言处理今后研究的一个方向)。拿给用户使用,反馈非常差,因为对用户来说掌握受限的自然语言比掌握SQL语言还要困难。没有能站在用户 的角度上考虑问题导致了项目的失败。
以最小代价获得最大效益
汽车大王福特曾说:“对实业家来说,一条重要法则就是尽可能地以最低的代价生产出最高质量的产品,给工人发出最高的工资。”福特公司1908年出的 Model T汽车价格是825美元,当时没有多少人能够买得起,到1924年Model T价格降到290美元,成为一款大众车,在美国每两台售出的汽车中就有一台是Model T。
其原因是福特公司导入了生产流水线,大大地降低了生产成本。在流水线上,Model T的零部件被标准化,维修成本也大幅下降。工程与其他领域(如科学、艺术)的不同在于它必须考虑代价,包括开发的代价、推广的代价、使用的代价和维护的代 价。工程师开发系统与工具时,必须权衡效益与代价,力图以最小的代价获得最大的效益。
我在微软参与了Office 2007、Office 2010、Office 2012中SharePoint的开发,具体从事元数据抽取与企业搜索功能的开发。我所在的研究团队开发了文件元数据自动抽取工具,有两种方法实 现:CRF与SVM。CRF的精度比SVM高1个百分点,但就抽取部分的代码量而言,CRF是SVM的若干倍。找SharePoint的架构师 Meyerzon商量,到底采用哪种方法好?Meyerzon毫不犹豫地答道:当然选SVM,因为它的精度只低1个百分点,但所需开发维护的代码量却少得 多。对产品来说,开发的代价是不能不考虑的因素。
磨在细处
对工程师而言,上帝就存在于细处!只有精雕细琢、潜心造作,才能做好工程项目。好的系统与工具是靠一点一滴打磨出来的。工程师必须在实际工作中不断磨练自己的技能,以达到手艺精湛、技术娴熟的境地,能够像庖丁一样游刃有余地解牛,像卖油翁一样点滴不溅地倒油。
在NEC期间,一起工作的工程开发团队的负责人叫滨田,从他那里学到了许多编程的技能。特别是在他指导下,开发了文本数据分析系统TopicScope中的核心算法。我不是编程高手,编程只有普通程序员水平,但同事们都说我的代码写得很好,条理清晰,结构合理,内容精炼。
这是因为我在滨田的影响下,花了很多功夫写代码。对项目的设置、文件的分配都反复斟酌,函数、变量的命名都细心推敲,对系统的执行效率都不断优化。写好了程序,过一段时间又拿出来检查、评价、修改,直至不能找出毛病为止(可惜加入微软以后,几乎没有时间再写代码,真希望今后能做一些编程工作)。
从实际工作做起
以上这些原则都很简单,但真正做好却并不容易,可谓“知之非难,行之惟艰”。重要的是在实际工作中努力依照这些原则去做,养成成为优秀工程师的习惯。培养自己直接解决问题,系统地解决问题,从用户的角度解决问题,考虑效益与代价解决问题的能力。不断提高自己的专业技能,在工作中努力做好细节。你一定知道一些优秀的工程师,他们甚至就在身边,可以把他们作为榜样,虚心向他们请教,学习他们的长处,不断提高自己作为工程师的素质和能力。另外,敢于尝试,不怕失 败,在失败中及时吸取教训,总结经验也是非常重要的。
全部0条评论
快来发表一下你的评论吧 !