Re: [心得] 製程整合工程師消失

看板Tech_Job作者時間6年前 (2017/10/10 23:39), 6年前編輯推噓13(1305)
留言18則, 10人參與, 最新討論串3/4 (看更多)
※ 引述《PuzzleDragon (拼圖龍)》之銘言: : 整合哪有那麼難跟dm一樣熟記三招心法 一招絕招即可勝任 : 1.找common tool : 2.用old case當理由硬塞給module : 3.從wafer start開始嗨賴一整排 : 絕招: : 跟module說報廢單掛給你們惹 : 不能證明自己清白還有找出兇手就吞下去 希望知道我是誰的人不要把我揪出來 也不要寄信來求內推 (質疑我是學生來嘴砲的請跳過不要看) PIE的定位應該是"該產品在半導體廠內的負責人" 一個稱職的PIE要能夠做到對自己的產品特性瞭落指掌, 從GDS進來 確定LOP, 跟product engineer review hot spot,定義量測位置 根據客戶的要求來建process flow pi-run時跟module review 結果與確定過貨條件 再加上建WAT Program 在產品量產前,要利用有限的工程貨把inline / device window 看清楚 等產品量慢慢起來後,除了要跟製造部/module一起合作處理線上貨的狀況以外, 也會跟module/device team / product / QR一起合作安排實驗,split, 分析實驗的電性/良率結果給出comment 還有要根據CP 結果對照PFA, WAT, inline record 來抓問題, 最後,假如出貨時程有急迫性,也會跟PC/MFG合作一起plan 假如有reliability的問題,還要跟product/QR合作根據PFA的結果來判斷原因 再跟module 合作improve plan,plan 實驗 最後,PIE也是"工廠"對客戶的窗口, 參加客戶的review meeting,提供客戶需要的工程data 在有issue時要能代表工廠去跟客戶解釋與提供解決方式 另外,還有QER/QBR/Quality Audit這種meeting 要備詢 PIE其實比較像工廠端的PM (所以module 會恨PIE不是沒原因的) 不管是帶產品或是own projects,其實都是一個project manager /engineer 的概念 然後,因為跟各單位接觸的機會比module和MFG supervisor多 所以PIE 出身的工程師在人肉市場上比較受歡迎 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.25.186.94 ※ 文章網址: https://www.ptt.cc/bbs/Tech_Job/M.1507649941.A.6F4.html

10/10 23:41, , 1F
推心得...
10/10 23:41, 1F

10/10 23:42, , 2F
revie-->review
10/10 23:42, 2F
已更正 謝謝指正

10/10 23:45, , 3F
奇怪,問公司的PIE,都說量測位置跟flow不是他們訂的,一
10/10 23:45, 3F

10/10 23:45, , 4F
問三不知,HL module倒是挺快的
10/10 23:45, 4F
因為你遇到的PIE 不夠優秀 基本上跟前面幾篇講的一樣,PIE好壞優劣差很多。 有天份有慧根的PIE會去了解事情的來龍去脈,這樣才能說服自己也能說服別人 沒有慧根的,不知道為所為而為的,就只能打雜

10/10 23:48, , 5F
其實比起PIE 我更討厭製造部
10/10 23:48, 5F
大家都是為了工作賺錢養家,在工作上難免有衝突,看開點,笑一笑就過去了

10/10 23:51, , 6F
你確定PIE有在建flow喔? 問好幾個根本都不熟,不是一個喔
10/10 23:51, 6F
我說啦"一個稱職的PIE" 隨著分工越來越細,全能型的PIE正慢慢消失當中 所以你會遇到愈來愈多這種狀況,這是時勢所趨,就多擔待點吧 "假如"他有慧根與PIE該有的榮譽感,他會自己去搞懂,不會再讓你們羞辱的

10/10 23:52, , 7F
人肉市場哈哈
10/10 23:52, 7F
文明一點的說法"轉職時比較好找"

10/10 23:59, , 8F
PIE都不自己找證據直接叫所有module清查?
10/10 23:59, 8F
一樣的說法,好的PIE跟不好的PIE差很多 我自己因為任務的關係,不太常打module, 但是只要一出手就要有十足的把握 但是我也不否認,有人是打給老闆看的=>先打了再說 有些時候module很委屈,我了解,在台下我也替你們抱不平, 但是往光明面想,證明自己清白也是一個練習 我有認識很麻吉的module同事,已經練就金剛不壞之身, 有錯就勇於認錯找方法,有信心自己是清白的就努力找證據破案打臉PIE 優秀到我都很想挖角他來當PIE了.......:P

10/11 00:08, , 9F
偉大的GG人
10/11 00:08, 9F
這跟哪間foundry 沒關係 不過我上面講的是正統PIE(T)/PEI(U), defect team我沒做過,也不想做,所以不在討論範疇內

10/11 00:26, , 10F
家家都有本難念的經,只能盡力做好自己的本分了。
10/11 00:26, 10F
Agree! 所以我才在上面講,假如module覺得常被冤枉, 一方面請他們多擔待,另一方面也希望能夠加強自己,找出證據還自己清白順便打臉 ※ 編輯: Cinderella (114.25.186.94), 10/11/2017 00:29:23

10/11 01:02, , 11F
問題出在打臉回去了!他依然要你找真因...
10/11 01:02, 11F

10/11 01:35, , 12F
我還遇過整合打來問 flow 怎麼兜的...
10/11 01:35, 12F

10/11 01:44, , 13F
原PO講的 比較像legacy node的PIE, LOP和process flow的
10/11 01:44, 13F

10/11 01:44, , 14F
選用可以用套的, 選用metal option或devive family相符
10/11 01:44, 14F

10/11 01:44, , 15F
的前例...就可以及格
10/11 01:44, 15F

10/11 01:49, , 16F
說真的, 大部份整合所謂的"建 flow"、"建WAT 程式" ...
10/11 01:49, 16F

10/11 01:49, , 17F
其實比較像"套用", 而非從頭開始.
10/11 01:49, 17F

10/11 01:50, , 18F
這和module的"建recipe"有異曲同功之妙.
10/11 01:50, 18F
文章代碼(AID): #1PtEcLRq (Tech_Job)
文章代碼(AID): #1PtEcLRq (Tech_Job)