2009-04-10

自我檢錯

阿賢請器隆轉達的資訊:以"自我檢錯"為主題,請每位工程師都寫下自己的意見由器隆用email給阿賢

由於不知道Nilson要求此一回報的需求為何,經多方討論,我描述的可能純粹就工程師的Level會太Over,當然也會有許多不足之處,請見諒!

先以以個人經驗先演繹出多面向且相對客觀的自我檢測的論述
再藉由歸納的方式盡量收斂出就工程師而言的自我檢錯

就我以過往經驗所想到的幾個相關的描述先行列舉如下並簡單舉例

  • 教育部成語典--修訂本成語--【知之為知之,不知為不知,是知也】
    EX1:最近的Calibration@RF02,從Platform的Soft Install/Remove到Seq的編寫和Calibration.
    作為白天班和小夜班的RF新手工程師沒有參與/瞭解到其過程,甚至不知道這是身為該Platform的工程該盡的責任.
    而讓主管Nilson一手包辦,若發生了任何Exception trouble,嚴格來說,是工程的錯.
    以資歷來說:
    資深的工程師必須是知之為知之的知之者,知道這樣的錯是自己的責任.
    資淺的工程師應該為不知為不知的不知者,不知道自己不知道這樣的錯也算是自己的責任.
    若不能滿足此一論述,即為不知也,那也不用討論到檢錯的細節問題了~

    EX2:根據自己所負責的場地和班次應該要認識到自己的職掌為何.
    若白天班的沒有做好客戶排測/Sample入庫;晚上班的沒有做好案件進度/錯誤回報.
    彼此不知道自己和交班的工程師的職掌,異質場地的工作氛圍和環境差異.
    幫忙互相Share/Cover工程間的工作負載,那討論到檢錯的細節問題也沒多大意義.
  • 知其然不知其所以然-教育部重編國語辭典修訂本
    就通訊和法規的層次,部門的主管們依其專業解決並滿足客戶的需求
    而就測試和操作而言,我個人透過作業系統和網路通訊的層次,以此專業故障排除儀器的問題.
    像是儀器的錯誤訊息和異常狀況(EX:TC21 Setup,USAT Setup,Exception Error info)
    盡量透過調度上切換,滿足廠地上的滿載需求.
    也清楚了解自己在什麼樣的職位上應該要有怎樣的能力,也要知道自己的不足之處.
    在諸多考量下滿足多數人的需求和自己的定位.
    如此便是知其然(工程-測試/操作-OS/Network)
    也知就我能力的Level所不知的其所以然(主管-客戶/服務-communication/Spec)的門檻和方法.
  • 見山是山,見山不是山,見山還是山 - 思考的連結 - udn部落格
    就檢錯的細節而言,因為每個人不論工程/主管,經驗上的差異和專業領域的不同
    容易有故障排除/自我檢錯上的盲點,如何透過一次次的故障排除以及和相關人員的討論理解,
    並根據自己的background選擇合適的方法吸收或拉高的自己Sense Level
    在反覆性的測試之中,縮短自己的例外性的錯誤的反應時間
    並且以Chaos的思維方式理解到,我們所面對的是一套套只能當作黑盒子一般的精密儀器
    所有的故障排除必須建立在step by step的Setup基礎之上,任何細微的差異都有可能是造成故障排除的盲點所在
    理解這樣的道理,即算是符合此點論述
  • 無限猴子定理 - 維基百科,自由的百科全書
    這個論述是我常常拿新哥跟我舉的例子用來告誡新進人員該有的認知
    以測試而言,就RF來說,如果你沒有主動故障排除,將責任和瑣事攬在身上的自覺
    RF Platform在多數時間相對於其他Platform工程的測試而言,工作負載是相對輕的
    那麼就像很久前假日曾經和Elio吃飯時,客戶提到的:RF這麼簡單,為何不找個計時的工讀生來做就好
    沒有自覺的人,就像Hendry轉述Graham所說:"RF Platform,找一隻猴子來都會測"
    是一樣的意思~
  • iThome online : : 美好的人生從Debug開始
    此一論述與上面的一些論述相呼應,僅列舉關鍵性的幾個重點:
    1.從未犯錯表示你從未做事
    2.多做不錯,少做多錯,不做全錯
    當然以上都有前提,你有投入心力在你所Focus的事情之上
    題外話,也許對人做事的業務並不像我當初所想的那樣的讓人難以接受
    只是過去偏好對事做事的我不樂意/沒有方法面對業務這樣的職掌
  • 讓自己從「必需品」變身「精品」-Manager Today經理人
    工程做再久,以公司的測試服務業定位而言,多數情況下都只有苦勞,不見得有功勞,更多的是疲勞..
    夜班在資訊不透通的工作文化/氛圍之下更是如此.
    就個人升遷的面向而言是會造成某種程度的工作投入意願和積極度.
    若沒有適當地理解/抒發/調適/進修,很容易造成非必要的個人錯誤進而導致整個團隊的僵化.
  • 多做不錯、少做多錯、不做全錯 中鋼精神-踏實精神
    這與上面的論述相呼應,茲節錄重點描述如下:
        不怕犯錯,勇於認錯
        不是故意的錯,不算錯
    當然以上也有前提,錯誤牽涉到的人員位階高低是否一體適用
    不是故意的錯,必須不再次犯錯;而不再次犯錯的應該是當初犯錯的那個人還是整個團隊?
  • 英特爾院士寄語年輕IT技術人員:不要過早轉崗管理 - CNET科技資訊網
    同上面必需品/精品的論述;適才適所,理解自己的定位對工作能力的提昇能有很大的幫助.
    EX:
    成為管理人員再回到技術崗位是非常困難的.
    必須要在某一個技術領域非常專長,這樣當你幫手下解決實際問題的時候,你才能為他們提供一些支持性的幫助,樹立起自己的威信.
  • ZDNet Taiwan - 名家專欄 - 葉木金 - 領導力 決定專案成敗
    此一論述很好的說明了管理者/工程的自主管理的領導方式
    或是所有的測試依據/自我檢錯都按照標準化與制度化的關鍵性差異:
    沒有「放諸四海皆準」的方法
    此論述有個延伸思考:將帥無能,累死三軍
    以工程的角度反思並呼應我在知之為知之,不知為不知,是知也的論述
    作為兵卒,讓將帥出手…嚴格來說比找一隻猴子來測試還讓人無言

回歸主題:就測試上的故障排除/自我檢錯,我想多數的工程同事都已經有描述到,基於時間限制,我就不再贅述了~
若有需要,請另行告知,我盡量滿足..

【tc7.09.01的Calibration回報】

To RF Platform相關人員

經多次Rerun measure_exp_activated_rfcdata(以下簡稱MEAR)
並以C:RS-PASS COMMON\rfc底下archive;data;requested的檔案修改時間和rerun MEAR的時間
作為Focus比對,將因Rerun MEAR的檔案以Notepad ++開啟查詢後發現
calc tc7.09.01所Rerun MEAR的INC之原因
是因為Refence的Base的RFC Data,有tc5.11.00 Calc Inc的Data在其中
以至於Calc tc7.09.01一直INC但卻沒人發現不是因為tc7.09.01的原因而Inc

經嘗試執行C:RS-PASS COMMON\rfc\RfcCleanup此測項(目的為Remove unwanted or wrong data from all existing RFC data files)
再次Rerun RFC Seq Calc_0410.seq(tc7.09.01的Fullband Seq)後得到[All requested RFC data is already existing and still valid.]

以此猜測tc7.09.01不用Calc,Review 前一天的Log得到tc7.09.01的Final Verdict : Not Applicable的原因如下

Warning-> Release Control: DUT Rel. 6 is not supported by the Parameter file.
--> Application, Parameter file and DUT are not to the same compliance standard
--> This test is not applicable for selected DUT, nothing to be done, EXIT test

因此tc7.09.01確定非No RFC Data而需要Calc
根據接手Calibration的情況評估,請器隆視情況幫忙Cover or Review Calibration的故障排除

但排除完RFC Data問題Rerun tc7.09.01多次時出現

Error-> LogDevInit(TCPIP::192.168.0.3::5000::CH1 - No error from CRTU-W)
Error-> RXQualityWcdmaInit(LogDevInit failed!)
Error-> Initialisation of the logical device Rx Quality WCDMA failed

因Shutdown Platform & Reboot CRTU-W ReRun多次仍然無法排除

因此暫時放棄retry tc7.09.01
請交班人員視情況Retry