靠谱不靠谱工程师主图

工程师最经常抱怨的人是领导,因为不靠谱的领导很多(所以那么多大企业都被搞垮了嘛);但是我这些年里看到不靠谱的工程师也很多,而且当你发现一个企业的工程师多数都很烂的时候(所谓“烂透了”),就是你该考虑另谋高就的时候了——读者当如人饮水,冷暖自知。

 

靠谱的工程师和不靠谱的工程师是可以通过一些特征来辨别的,我就以这些年的所见所闻来说一说,以管窥豹,抛砖引玉。

 

  1. 靠谱的工程师解决问题,不靠谱的工程师制造问题。

更绝的是,烂工程师的人品往往更烂,他们会编造出一套精彩绝伦的ppt来,把他们制造问题的烂事描述成发现哈雷彗星的过程,告诉领导们“我们做出了多么了不起的贡献”。

这种笑话很多,在帝国末年的某公司更多。有一次某项目做build,RF calibration根本就过不了,一下子积压了上百片板子。因为这项目都已经成了北京研发中心的救命稻草,那还不得各级领导一级重视,所有debug力量全部用上去。

软件的连夜regression,硬件的一个个clock查过去,RF的忙着调matching。加了一个周末的班,最后发现RF的在做crystal的时候,加了一个对地的电容——这个画蛇添足的无以复加,想想我们做振荡电路的时候,crystal下面的金属都要多掏掉几层以减小寄生电容,你这里摆上一个电容——随便找个大学里学过Hartley和Colpitts电路的本科三年级学生,都应该知道振荡电路的电抗值需要满足条件才能起振。说的好听这叫设计失误,说的不好听叫缺乏常识,说的毒一点叫蠢。

问题是,这公司的文化是“从来不抓罪魁祸首”,美其名曰“宽容”,实则无人负责的官僚主义。工厂几百片板子要手工重工,工厂的头头不干了,跳出来说你们研发的都是干什么吃的,把我们工厂的不当人啊?RF的人心知肚明这是自己挖的坑,但是肯定是没胆量打自己一耳光说“我是蠢货”;尤其是干出这档子事儿来的烂工程师们,愣是施展ppt大法把自己闯下的祸写成了一个英雄救主的故事,把整个问题描述成一个玄之又玄的黑洞,从如何调matching到如何试参数,最终发现“啊,原来是隔了崇山峻岭的crystal出问题了,我们终于穿越了虫洞!呃,至于黑洞是谁造出来的。。。既然解决了那就不追究了”——我在会上看过这个可以当笑话看的ppt,觉得它刷新了我对工程师底线的认识。当然,更可笑的是最终的黑锅居然给派发到软件部门的头上去了——是不是因为有个“软”字所以你们觉得就好捏啊?

同样是帝国末年,也有天天泡在实验室的工程师,一块板子一块板子的调,调累了就读文档美其名曰“放松”。曾经碰到过一次二次谐波超标,大家第一反应是PA有问题,第二反应还是PA有问题;这位以实验室为家的工程师就拿了两块板子,直接焊了一根pigtail到PA输出口,一看PA直接输出的二次谐波余量大的很,按照他的判断,即便是mismatch恶化二次谐波也很难这么差,马上就怀疑到PA后面的滤波器上去了。他一边让供应商测滤波器IIP2,一边自己在滤波器的前后分别加衰减观察谐波变化:滤波器前加1dB衰减,二次谐波降低将近2dB;滤波器后加1dB衰减,二次谐波降低1dB。这样就证明了二次谐波其实是滤波器在高功率下发生非线性产生的。

(题外话:我以前面试工程师时最喜欢出的一道题:给你一台烂频谱仪测一台烂功放,发现谐波超标;再给你几个衰减器,你如何证明你在频谱仪上看到的谐波超标是真实的而不是仪表自身产生的?)

这个滤波器的问题得到证明,这位工程师只是给组里写了一封邮件,一个简单的表格描述了天线端口的二次谐波、PA端口的二次谐波、两种衰减器位置的二次谐波、供应商的IIP2测试结果,以及供应商承诺的改进计划,简单明了。

 

有人说工程师不擅长表达,写的东西干巴巴。我得承认首先把内容写的逻辑通顺易于理解是应该的,这是交流的需要;另一方面工程师最主要的工作是解决工程问题,其次才是向领导们陈述自己的工作,能够将两者结合起来的工程师当然是其中翘楚;但是如果领导们只会看花俏的ppt,以至于能够被烂工程师的胡说八道唬住,那只能不客气的说这并不仅仅是工程师的问题。

 

  1. 靠谱的工程师喜欢复杂问题简单化,不靠谱的工程师爱好简单问题复杂化。

工程问题的解决从来是化繁为简,一层层剥离细节而还原本质,最终用可行的方法予以实施。所以一个好的工程师在解决问题的时候,很可能实验过程非常耗时耗力,数据叠床架屋,但是结论会非常简明,方案会非常直接。

但是烂工程师恰恰相反,他们抓不到问题的核心,东一榔头西一棒子,做了一堆无用工,但是结论还是“没有结论”。

一开始做GSM的时候,Tx noise in Rx band很容易出问题,但是我们自己的测试系统也经常有测错的时候。有一次我们测试proto发现这个测试项出了问题,但是我把所有的不良点捡出来,发现不对劲。因为一般来说GSM的Tx noise in Rx band除非发射机噪底过高,否则主要是由Tx信号与其他信号(最常见是时钟信号)混频产生Rx band内的点噪声;但是我把所有的时钟和Tx信号的混频产物筛了一遍,我们的不良频点并不在这张表里,甚至连频点互相靠近的都没有。

于是我认为:应该是测错了。

与此同时,另一些同仁们开始怀疑电路设计有问题,诸如地分割、过孔串扰,当他们在大屏幕显示器前看了一整天的layout,然后开了一个会专门讨论这个问题(会上我一句话都没说),之后,认为可能是地分割做的不好,数字地和射频地应该在某处分开,另有几条他们认为可能引入时钟串扰的线需要隔离(问题是他们有没有先看看clock tree呢?)。

晚上加班,我让测试部的老同事搬出以前一套老的测试系统——这套系统测试并没有问题,只是界面不那么友好罢了——用它把“坏”板子重测了两遍,全部通过。测试部的同事们一看这个结果,马上回去重新检查系统去了;第二天重新校准系统之后,“坏”板子在以前测出不良的系统上重测通过。

原本沸沸扬扬的PCB改版计划戛然而止。

 

  1. 靠谱的工程师兼重整体与细节,不靠谱的工程师喜欢一地鸡毛。

曾有那么个项目,我们平台部门负责做RF模块化设计,产品部门负责把模块适配到产品中去。 很不幸产品组的射频工程师就是上面提到的那伙擅长“制造问题”的人,合作起来效果可想而知。

我会对设计有个统一的思路:首先保障所有走线方向通顺,不要有U型拐弯之类的奇葩;然后集中摆放关键器件,避免引入线长的寄生参数;同类走线平行排布,射频走线尽量避免反复跳层穿孔,诸如此类。

然而每次在设计评审中遭遇“制造问题”专家们的时候我就会非常愤怒。

我至今记得他们在评审会上各种东一榔头西一棒子的打法,诸如“我们在CDMA BC1上有更好的匹配电路“(喂喂喂,LTE B2怎么办啊),“B40的输出要走stripline而不要microstripline,这是参考设计上说的”(同学,你知道stripline要走成50ohm要掏掉多少层地么,哪有空间走其他线),还有一个非常奇葩的“Rx电路匹配要从pi型换成t型”——各位学过射频的都知道pi/t电路如何转换吧?你们有认为窄带接收机设计中一定要用t型不能用pi型匹配电路么?——不要怪我愤怒,我对这种毫无自知之明的愚蠢唯有表达愤怒。

不靠谱的工程师对工程设计没有一个整体的认识和完整的思路,出于能力所限他们只能抓到什么算什么,捡到鸡毛当令箭;所以他们无法完成一个完整良好的设计,更可悲的是,他们甚至充分阅读理解他人设计的能力都不具备。

 

  1. 靠谱的工程师不会滥用人力物力,不靠谱的工程师这些都不放在眼里。

曾经有位项目经理跟我聊起一位老前辈工程师,说他来build的时候,项目经理们因为良率苦恼不已,缠着他问这个怎么办那个会不会改进。老人家看看这个问题,说“给我们(研发)寄10片去”;看看那个问题,说“这个先不担心,下个build肯定可以解决”;再看看另一个,说“这个你们要组织30片板子做一个验证,包括xx和yy都要改,如果没问题就批量应用上去”。他说:凡是老人家指点过的,后来果然都按照预期解决了,没有多花一分力气,也没有耽误一丁点事儿。

不靠谱的工程师往往是NPI的大敌。同样在build里,不靠谱的工程师就完全心里没数,拿生产线当实验室用,从来不是自己做好了实验再来验证,而是上生产线一批批的作验证,出了问题就推倒重来,全然不顾浪费了多少时间和人工浪费了多少材料。说实话,大企业里经常惯出这样的工程师,锦衣玉食惯了,稍微给点粗粮就不出活儿;看着出身显赫名头光鲜,其实金玉其外,败絮其中。

 

为什么我们把工程师放在显微镜下观察?因为工程师是所有科技企业的基石,无论顶层如何土崩瓦解,只要基石仍在,企业大厦就还不至于动摇根本;然而基石也会动摇——或者流失,或者自我腐烂;而自我腐烂的工程师恰恰是激发逆向淘汰、致使好工程师流失的重要原因。

若要律人先正己——这句话在如今这个“比烂”的世道里真是越来越曲高和寡,但是也许重生的希望恰恰蕴含其中。

作者简介:猪头是头猪,80年代人,射频攻城狮,闲时爱好码字儿,喜欢即兴发挥,也擅命题作文。现为FindRF特约专栏作者,自己也经营着一个低产微信公众号“猪头是头猪”(没错,正着念倒着念是一样的),公众号ID:Huey-Dewey-Louie(没错,就是唐老鸭的那三个侄子)。

4 评论 关于 “工程师养成系列(一):论靠谱的工程师和不靠谱的工程师

  1. 问题回答:首先以烂的频谱仪测试烂的PA,当然信号正常输入在PA的线性区域,看谐波的peak值多大,然后在PA段加个衰减器,看谐波的peak值变化,如果不变或者不是线性变化,也可判断频谱仪或者pa有问题,反之

    回复 本层

评论 zeng dong 取消回复

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> 

required