之前在某公司跟MTK合作了一段很长的时间，
看到这次发哥开奖不如往年，实在是有点感慨。
其实MTK遇到的是人多有枯枝的问题; 这种枯萎行为是有传递性;
也造成了发哥愈来愈追不上Q，
特别是CE(customer engieer，发哥是叫别的名称但我忘了，主要由陆仔担纲) 跟 RD。
如果有卫道人士要酸我薪水说不定没MTKer多，凭什么说发哥坏话;
那这篇文章不适合您观看会伤了您的眼，请您左转了。
对OEM而言，量产是最重要的，尤其是生产端回报的问题都必须紧急处理；
如果问题是出在vendor(MTK or Q)的部分无法自己解决，
首要是找出repro step，并先narrow down跟什么东西有关，然后提供给vendor debug。
举例来说，假如同样的测试DDR升频到100 Mhz不会死，200 Mhz不会死，400 Mhz挂点。
然后又发现 100跟 200 某3个模组的电都是关的，但升到400时却被打开了。
OEM的流程会是:
1. 先生出一版不要上400 MHz的ROM给工厂继续生产
2. 开eservice给MTK 或 case给Q并highlight。
3. 等vendor找出fix后导入，最后换新的ROM验証出货。
于是OEM把 400MHz会死跟开了3个模组的电告知vendor，并跟对方说明固定在200的改法。
接下来的走向:
<Q> CE拉RD一起看; 必要时daily update
<M> CE:‘嗯，你们不是有solution了吗?’ (叫我用200MHz出货?)
‘你们怎么固定在200 MHz的?’(不是已经写在eservice了吗?)
通常要三催四请才会2~3天update一次，要daily sync还会不爽。
通常遇到难解的问题，CE/RD通常会拉下一个RD。
<Q> CE/RD1 会跟 RD2解释现在的情况，OEM作了什么，目前进度到哪。
<M> RD2:‘你们怎么固定在200 MHz的?’
(为什么要跟CE/RD1问一样的问题?)
(为什么不把mail拉到最下面从头看到尾?)
然后RD3进来了，又问了一样的问题(崩溃…)
过了一周，OEM觉得一直抓log进度严重落后，决定拿台机器给vendor自己debug。
<Q> 什么时候都可以拿来，CE过去拿也行; 到时候再跟RD remote debug。
<M> ‘机器? 我在北京欸?’ 怎样就是不拿机器，一直要你抓log就好。
又过了2天，还是没结论，OEM要求concall; 请DDR升频的人出来跟那3个模组的人沟通。
<Q> 指派一个核心的RD由top view往下看问题在哪; 跟每个owner cowork
<M> ‘不吭声就跟我无关’，继续让那3个模组的人在那边烧
(谁都知道那3个根本是被害的，不是right prerson)。
又过了3天终于找fix了，OEM会再询问一些问题如:
1. 请问400MHz开了3个模组的电是否为root case?
2. 请问这个fix会影响原本100/200 MHZ的行为吗?
3. blahblah…
<Q> 会逐一问题并解释，如‘确实是root cause，原因为blahblah，我们的分析如下…’
<M> 只回答一个问题，‘是’。
(单工吗? mail多打点字会比较重寄比较慢吗?)
搞到最后OEM要再重问一次，加注‘请逐一回答’。
这种品质，被Q海放，不是很理所当然吗?