那些挖坑的客户︱都说芯片原厂“高大上”，为啥我却频频掉坑里？

本人来自SoC芯片厂，也就是很多方案厂商以及OEM厂商口中提到的"原厂"，一般来说原厂的工程师在方案厂商那里都是比较难（gao）请（da）来（shang），因为原厂一般只支持大客户，其余支持工作都交给了代理商。

然而当年刚入行的时候，本人所在的部门刚刚开始推广自家的SoC软硬件方案，因为市场接受度不高，作为原厂工程师的我是有哪里需求就往哪里跑，着实成了接（ai）地（cuo）气（qiong）的工程师，那些年走访了广东深圳以及整个华南片区的很多客户，不少客户让我大开眼界，一边惊讶于深圳电子产业的发达，公司数量之多，一边又感慨各家电子厂商之间研发水平层次不齐，客户"挖坑"防不胜防。

客户A：频繁换人导致项目流产
客户A位于广州，那是我负责的第一个案子，所以当时印象很深刻。刚开始客户A那边跟我们对接的工程师是一位姓王的工程师，在接触磨合了一段时间后，客户那边对我们的方案评估也通过了，正准备进入下一阶段，即二次开发阶段，突然客户A那边换了一个姓张的工程师来接手，因为之前的王工离职了。于是我跟张工对接继续进入二次开发阶段，同时还要跟他一起再回顾方案评估阶段的信息。正当二次开发顺利推进时，客户A那边又换了一个对接的工程师李工，因为张工又辞职了。两个月内换了两拨人来对接，着实把我累得够呛，并且最终客户A的项目还是谈崩了，这里面可能也是由于人员频繁流动对项目进度产生了影响，我和第一个客户就这样拜拜了。

客户B：manual就是文档，不想太多解释
客户B位于深圳，某上市公司，当时我们的SoC方案处在推广阶段，投入了比较多的人力物力，甚至常常会到客户那边做现场支持。某天客户B那边说快要进入量产阶段了，PCB已经画好，正在调试，需要我们到现场支持。结果我到了那边一看，PCB是有了，但是负责对接的朱工是一个刚刚从学校毕业的软件工程师，不但不会编译SDK， 连Makefile也不懂。某天过来问我：你们的Makefile怎么跟网上搜出来的不太一样？我随即回复"我们的sdk基于cmake build， 具体请参考open source community cmake manual"， 于是朱工回复"请问cmake manual有文档吗？"， 当我看到这句话的时候，我的内心是崩溃的（manual就是文档的意思）。后来但凡遇到客户问类似这种问题的时候，我都为了节省时间和精力而刻意忽略"具体请参考***manual"。

客户C：遇到临时工让我和甲方老泪纵横
客户C位于珠海，是当地的高新企业，整个项目已经到了联合调试Demo阶段了，由于这个项目是甲方，我厂和客户C共同参与的，客户C是ODM厂，负责给甲方生产和贴牌。一天晚上，我们收到客户C的紧急通知，说Demo出了问题，要我们立刻去解Bug。于是我们立刻打飞的赶到客户C那边跟客户C的工程师对接。按模块排查后发现出问题的地方是客户C那边的代码，于是我们与甲方一起和客户C那边的工程师一起Debug。我们发现客户C的工程师居然对于他们自己公司的代码完全不熟悉，也不知道程序执行的流程和定位问题，他主要的调试方法就是在某个函数内部加一条printf打印语句，然后编译运行查看程序是否执行到了那个地方，如果没有看到打印语句就换一个地方继续加……我和甲方就看着他一遍又一遍地printf，build，download，run，再重复……最后甲方的负责人员都看不下去了，催他说："你能不能快一点啊，我都看懂了你怎么还没看懂"...晚上吃饭的时候跟客户C那边的工程师交流，结果震惊地发现他是个"临时工"，是个还没有从学校毕业的实习生，而且下个月就要回学校参加毕业答辩了，我们顿时老泪纵横......

那些年推广方案着实接触到了不少"坑爹"的客户，或者说是奇葩的工程师。但究其根本原因还是因为我们厂当时的方案还处在产品推广阶段，研发实力雄厚的公司不愿意冒风险使用，而敢于尝鲜的往往是一些良莠不齐的小公司，这也就或多或少会遇到各种各样挖坑的客户以及挖坑的客户需求。我的总结是：在遇到各种情况时，应该摆正心态，把重点放在如何快速高效地解决问题，才能尽快从客户的坑里跳出来。

小与有话说：那个临时工让我想到当年的自己，我给当年的FAE造成了多大的心理阴影，请原谅...