prototype
產品開發，在量產前一定會做原型品，確定沒問題才量產。
這是常識。
但原型品的意義很多人弄錯了。
原型品是要用來驗證的，不是拿來try的。
以一個象徵性的對話來表達這觀點：
在原型製作前（也就是花錢做之前），
PM問 : 散熱有沒問題啊？有把握，系統才要去做原型喔。
散熱回答： 到時測了就知道。
PM問 : (x2$#$$)那測了沒過呢？
散熱回答 : 改。
PM問 ： 一定改得出來嗎？
散熱回答 ： 就改。
PM問：要改幾次？
散熱回答 ：就改。
PM:...........................
這種研發，成本跟時間都無法掌握。
====================================
理想的狀況是
在原型製作前（也就是花錢做之前），
PM問 : 散熱有沒問題啊？有把握，系統要才去做原型喔。
散熱回答： 根據經過驗證的模擬，以及模型試驗，
_________九成把握不會有問題，如果有問題最差也不會與預測超過20%。
PM問 : 也就是絕不會有離譜的差距，頂多是超過一點？
散熱回答 : 是。
PM問 ： 那如果超過一點呢？
散熱回答 ： 只超過一點的話，不會影響整個產品架構，局部修改，一次就能完成。
PM問：恩，那就可以進入原型製作了。
這不是幻想的狀況喔。
個人負責過的產品以及訓練其他工程師所做的產品，
一次又一次證明這絕對做得到。
也可見設計是有系統方法的，而且是可以教學轉移的，完成一樣訓練的人都能做到。
這系統方法在不同公司驗證了，也在各種不同產品驗證了。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
設計不是拿到原型機後，才開始的。
設計早在原型機制作前就完成七成以上了，原型機是用來確認事實的確跟設計預測相同。
如果原型出來的結果跟設計預測差異超過30%以上，表示前期的設計技術有大問題。
差異超過50%，表示前期設計有做跟沒做一樣，50%跟用猜的已經是一樣的了。
在原型機上敲敲打打，東補西湊，一改再改，樣品一做再做，叫做硬著頭皮補洞；
不叫設計。 沒去改善為何成品與預測不符的原因，永遠會不斷重複一改再改的情況。
2009年4月28日 星期二
面試問甚麼？
散熱工程師
有人問面試時如何選出好的散熱工程師？
選人基本就是選 「專業」 與「 特質」。
特質的部分這裡就不講，憑的是「嗅覺」，比較難言傳。
專業的話，散熱工程師當然就是散熱專業。
我想 工作經歷這些，一定是大家都會問的；是必要的參考。
但表面上的經歷不一定能完全反映真實的能力
（不然書面審查就好啦，省時省力，何必面試；面試就是要問出實質的能力）
因此我們講其他部分；
專業的部分，當然首先要問基本的熱傳觀念。
如果基本熱傳觀念都錯誤，如何做正確設計？
如果基本熱傳觀念錯誤，工作經歷久，只表示錯了那麼久而已。
（錯太久，有時還不見得能改；我以個人經驗見證真的有這種例子）
若觀念正確，那就很可能有效的從過去經歷裡吸取了有用的經驗。
另一部份是關於模擬軟體。
若是沒經驗的人，這部分就不用問了（觀念正確，其實可以很快訓練起來）
有經驗的話，就要進一步確認能力到哪。（錯誤難改的經驗，比沒經驗更可怕）
有用過，不表示用得好。
譬如以機構為例的話，說會用Pro/E，跟能用Pro/E設計出好的機構件之間的距離可以是很大的。
再以EE為例，說會用ALLEGRO,跟能用ALLEGO設計出沒有訊號問題的電路也是可以差很大的。
這部分，個人覺得有效的方式，可以是現場直接實機給一個小題目。
這題目若是熟練者，二十分鐘內會有結果。
而這題目雖小，但可以設計得包括很多要點（若對軟體跟實務瞭解深入，設計一個這種問題不難）。
能力如何，上機立刻見真章。（用講了就算，那人人不都可以當工程師？）
問的人當然自己要清楚這題目要測試的點。
用錯人，有時代價是很高的。
白花了時間金錢以及沒有生產力不說，有時甚至拖累了其他人。
尤其很多公司對不適任的人難以處置，造成其他人負擔，很有可能反而使有能力的人不平離開。
這樣雙重損失是更大的。
如果造成產品實質問題，產生業務流失或衍生賠償，問題更是恐怖。
而用對了人，帶來的效益絕對比公司給他的薪水高。
正確時間作對一件事，往往就可以挽救原本可能慘烈的下場。
而這樣的人，絕對不是表面問問就能篩選出來的。
必要時，藉助專業經驗幫忙選人其實必要且值得。
有人問面試時如何選出好的散熱工程師？
選人基本就是選 「專業」 與「 特質」。
特質的部分這裡就不講，憑的是「嗅覺」，比較難言傳。
專業的話，散熱工程師當然就是散熱專業。
我想 工作經歷這些，一定是大家都會問的；是必要的參考。
但表面上的經歷不一定能完全反映真實的能力
（不然書面審查就好啦，省時省力，何必面試；面試就是要問出實質的能力）
因此我們講其他部分；
專業的部分，當然首先要問基本的熱傳觀念。
如果基本熱傳觀念都錯誤，如何做正確設計？
如果基本熱傳觀念錯誤，工作經歷久，只表示錯了那麼久而已。
（錯太久，有時還不見得能改；我以個人經驗見證真的有這種例子）
若觀念正確，那就很可能有效的從過去經歷裡吸取了有用的經驗。
另一部份是關於模擬軟體。
若是沒經驗的人，這部分就不用問了（觀念正確，其實可以很快訓練起來）
有經驗的話，就要進一步確認能力到哪。（錯誤難改的經驗，比沒經驗更可怕）
有用過，不表示用得好。
譬如以機構為例的話，說會用Pro/E，跟能用Pro/E設計出好的機構件之間的距離可以是很大的。
再以EE為例，說會用ALLEGRO,跟能用ALLEGO設計出沒有訊號問題的電路也是可以差很大的。
這部分，個人覺得有效的方式，可以是現場直接實機給一個小題目。
這題目若是熟練者，二十分鐘內會有結果。
而這題目雖小，但可以設計得包括很多要點（若對軟體跟實務瞭解深入，設計一個這種問題不難）。
能力如何，上機立刻見真章。（用講了就算，那人人不都可以當工程師？）
問的人當然自己要清楚這題目要測試的點。
用錯人，有時代價是很高的。
白花了時間金錢以及沒有生產力不說，有時甚至拖累了其他人。
尤其很多公司對不適任的人難以處置，造成其他人負擔，很有可能反而使有能力的人不平離開。
這樣雙重損失是更大的。
如果造成產品實質問題，產生業務流失或衍生賠償，問題更是恐怖。
而用對了人，帶來的效益絕對比公司給他的薪水高。
正確時間作對一件事，往往就可以挽救原本可能慘烈的下場。
而這樣的人，絕對不是表面問問就能篩選出來的。
必要時，藉助專業經驗幫忙選人其實必要且值得。
2009年4月25日 星期六
About reference design
產品做的好不好，跟是否具備核心能力有關。
不管是EE、電源、散熱、 機構 等等等。
沒有核心能力，往往盲目抄用所謂Reference design.
以EE為例，譬如CPU製造商的 MB參考電路。
問題是reference design 只是 'reference'，
從沒人敢說是'the best design' 或 'the optimized design'，
更沒人敢說是'the only solution'
廠商也從不擔保reference design的結果， 只是for your reference.
reference 是迅速的參考起點，但應有能力取長補短。
如果有能力進行電路訊號模擬分析，就有能力自行按需求調整設計。
同樣散熱也是，誰說CPU所提供的reference design 就是最適合你產品的design呢？
(已經驗許多案例，新設計比'標準設計' 更省錢)
如果所有人都用一樣的reference design，那所有人的產品都大同小異，
如何造成產品差異優勢？
舉例，MiniPC難道當初是CPU廠的reference design?
完全不是；主機板不是，散熱不是，機殼架構不是，通通不是。
CPU廠 看了這東西受歡迎了 ，才跟進做了近似『架構規格』；想維持『控制局面』。
真正優秀的產品，是由各種核心技術能力，互相整合，激盪出來的，
而不是拼拼湊湊就好了，事情有這麼簡單就好。
就算要利用現有設計，也要配合的巧妙，不是隨便湊就沒問題。
當然不見得甚麼設計都要自己做，
但有能力設計只是因不需要所以不改設計，
跟沒能力改、懶得改所以不改是完完全全兩碼事。
不管是EE、電源、散熱、 機構 等等等。
沒有核心能力，往往盲目抄用所謂Reference design.
以EE為例，譬如CPU製造商的 MB參考電路。
問題是reference design 只是 'reference'，
從沒人敢說是'the best design' 或 'the optimized design'，
更沒人敢說是'the only solution'
廠商也從不擔保reference design的結果， 只是for your reference.
reference 是迅速的參考起點，但應有能力取長補短。
如果有能力進行電路訊號模擬分析，就有能力自行按需求調整設計。
同樣散熱也是，誰說CPU所提供的reference design 就是最適合你產品的design呢？
(已經驗許多案例，新設計比'標準設計' 更省錢)
如果所有人都用一樣的reference design，那所有人的產品都大同小異，
如何造成產品差異優勢？
舉例，MiniPC難道當初是CPU廠的reference design?
完全不是；主機板不是，散熱不是，機殼架構不是，通通不是。
CPU廠 看了這東西受歡迎了 ，才跟進做了近似『架構規格』；想維持『控制局面』。
真正優秀的產品，是由各種核心技術能力，互相整合，激盪出來的，
而不是拼拼湊湊就好了，事情有這麼簡單就好。
就算要利用現有設計，也要配合的巧妙，不是隨便湊就沒問題。
當然不見得甚麼設計都要自己做，
但有能力設計只是因不需要所以不改設計，
跟沒能力改、懶得改所以不改是完完全全兩碼事。
2009年4月21日 星期二
工作的第一步
工作的第一步是：界定問題。
不管是產品規劃、產品分析、產品設計、產品驗證...............
這第一步是非常基本而重要的。
我們幾乎可以說大部分的問題有一半其實出在界定問題。
一個問題，必然有他的目標以及限制（不論是效能、時間、成本等面向）
需求有時是真實的、有時是假性的；障礙也是。
應盡可能把目標、限制等等具體的列出，
看看互相間時間上的關連、邏輯上的關連、技術上的關連等等..
有無衝突的地方、有無基本的抵觸，
沒有這些瞭解，我們可以說工作非常容易是機械化而盲目的，不知重點方向在哪。
系統性的檢視討論，而問題的瓶頸、風險的所在，甚至實施的方式往往就相當明顯。
問題有時不是表面以為的那麼簡單，但有時也不是表面以為的那麼困難，「系統分析」讓它有所根據，「話芭啦can（台語）」不算方法吧。
不管是產品規劃、產品分析、產品設計、產品驗證...............
這第一步是非常基本而重要的。
我們幾乎可以說大部分的問題有一半其實出在界定問題。
一個問題，必然有他的目標以及限制（不論是效能、時間、成本等面向）
需求有時是真實的、有時是假性的；障礙也是。
應盡可能把目標、限制等等具體的列出，
看看互相間時間上的關連、邏輯上的關連、技術上的關連等等..
有無衝突的地方、有無基本的抵觸，
沒有這些瞭解，我們可以說工作非常容易是機械化而盲目的，不知重點方向在哪。
系統性的檢視討論，而問題的瓶頸、風險的所在，甚至實施的方式往往就相當明顯。
問題有時不是表面以為的那麼簡單，但有時也不是表面以為的那麼困難，「系統分析」讓它有所根據，「話芭啦can（台語）」不算方法吧。
散熱工程師的養成要多久？
thermal engineer
有人問這問題。
精確一點，要界定你想要他幹嘛？
作很單一的任務，還是變化範圍很大的？
目的的不同，其實選用人的特質與訓練方式、時間都不同。
不過大概沒人想討論的那麼細，就粗略的概括吧：
工程師是人，不是機器，並不是人人受了一樣訓練就會有一樣結果
一個完備工程師(能獨立解決七成以上問題）養成需有下列三個要素：
1.適當的基本素質
（參考前文 好工程師的特質 http://rightcooling.blogspot.com/2008/12/blog-post_2176.html)
2.充分的基礎訓練
（參考 關於教育訓練前文）
3.系統性的應用於產品開發的經歷
（這不但要散熱專業，還要組織專案管理成熟）
（不用多，真的有系統性的話，一個至兩個專案，基礎就很夠了）
（做一堆糊里糊塗的案子，不如做兩個深入而紮實的案子）
一切順利的話，通常這樣大約是一至兩年（基礎訓練半年內，其他是產品應用）。
但可別斷章取義喔，逆定理不成立，沒有三要素的話，超過兩年也不表示功夫了得；
還是有四五六年、甚至更久的，仍不斷的重複一樣的錯誤；
過了不知為什麼，不過也不知為什麼，設計方法跟擲骰子差不了多遠。
有人問這問題。
精確一點，要界定你想要他幹嘛？
作很單一的任務，還是變化範圍很大的？
目的的不同，其實選用人的特質與訓練方式、時間都不同。
不過大概沒人想討論的那麼細，就粗略的概括吧：
工程師是人，不是機器，並不是人人受了一樣訓練就會有一樣結果
一個完備工程師(能獨立解決七成以上問題）養成需有下列三個要素：
1.適當的基本素質
（參考前文 好工程師的特質 http://rightcooling.blogspot.com/2008/12/blog-post_2176.html)
2.充分的基礎訓練
（參考 關於教育訓練前文）
3.系統性的應用於產品開發的經歷
（這不但要散熱專業，還要組織專案管理成熟）
（不用多，真的有系統性的話，一個至兩個專案，基礎就很夠了）
（做一堆糊里糊塗的案子，不如做兩個深入而紮實的案子）
一切順利的話，通常這樣大約是一至兩年（基礎訓練半年內，其他是產品應用）。
但可別斷章取義喔，逆定理不成立，沒有三要素的話，超過兩年也不表示功夫了得；
還是有四五六年、甚至更久的，仍不斷的重複一樣的錯誤；
過了不知為什麼，不過也不知為什麼，設計方法跟擲骰子差不了多遠。
2009年4月16日 星期四
散熱設計層級與執行模式
一個產品的散熱設計可略分為兩個層級：
系統層級與模組層級。
系統層級指的是偏架構性的部分：
包含主機板佈局，機殼機構設計，空間劃分，元件位置等
系統層級對整體散熱特性的影響是最大的，至少左右了百分之七十以上的效能。
但這部份由於往往不是實體，以及需要各單位整合協調，常常被忽視或迴避。
強調再強調的是，散熱設計絕對不是找個散熱器兜而已，產品架構就是散熱設計一部份。
只要適當的系統層級設計，就能以合理價格的模組，確保整體散熱性能。
不足的系統散熱設計，會迫使模組設計複雜以補償系統設計的不足，反而造成整體價格上升;
最糟的情況是先期系統設計散熱考量錯誤，後段花再多錢也無法設計出滿足規格的模組，造成進退兩難的窘境。 (這時就不只是錢的問題了)
模組層級指的是散熱器本身：
包含散熱器的材質，幾何尺寸，固定方式等等。
嚴格而言，系統層級設計與模組是交互關連，互相影響的。
因此理想上，最好系統設計與模組設計由同一設計單位進行，發揮的整體效益最大;
實務上，由於產業生態與人力資源問題，有許多不同的作法。
產業鍊通常分為系統廠與模組廠。
系統廠指的是產品為完整系統，如伺服器、工業電腦、數位家電等等。
模組廠指的是出貨產品為散熱模組者。
設計工作執行模式約分三類:
1.系統廠包辦系統層級與模組層級設計
. 模組廠負責模組製造
好處 ：分工明確/最佳產品散熱/設計速度快/系統產品資訊保密/產品特色強
成功條件 ：系統廠人力必須充分，技術必須成熟
2.系統廠負責系統層級規劃
. 模組廠負責模組設計與製造
好處 ：系統廠人員需求可降低
可能問題：責任區分模糊/互相推諉問題，導致設計品質低落。
成功條件:* 系統廠技術需十分成熟，以訂出合理系統條件，並督導廠商完成後續;
. ._____* 模組廠研發人員需具備系統知識，以設計有效產品。
. . ____ *兩者技術語言需近似，才能有效溝通配合
3.系統廠完全無散熱設計人員把關，相關工作全部交由模組廠代勞。
好處 ：系統廠人力精簡
可能問題 ：*設計不同步，耗時/產品資訊洩漏/
. .______ *產品專案風險高，可能發生最後做不出來的狀況 （或是成本失控增加）
成功條件 : * 模組廠研發能力需非常完整，不僅在模組層級，亦包括系統層級。
. .______*模組人員與系統廠工作需非常緊密，困難案子大概需達駐廠(on site)程度
從產品特性而言，越特殊與差異性越大的產品就越適合第一種作法。
越標準化、越簡單的產品越適合第三種作法。
系統層級與模組層級。
系統層級指的是偏架構性的部分：
包含主機板佈局，機殼機構設計，空間劃分，元件位置等
系統層級對整體散熱特性的影響是最大的，至少左右了百分之七十以上的效能。
但這部份由於往往不是實體，以及需要各單位整合協調，常常被忽視或迴避。
強調再強調的是，散熱設計絕對不是找個散熱器兜而已，產品架構就是散熱設計一部份。
只要適當的系統層級設計，就能以合理價格的模組，確保整體散熱性能。
不足的系統散熱設計，會迫使模組設計複雜以補償系統設計的不足，反而造成整體價格上升;
最糟的情況是先期系統設計散熱考量錯誤，後段花再多錢也無法設計出滿足規格的模組，造成進退兩難的窘境。 (這時就不只是錢的問題了)
模組層級指的是散熱器本身：
包含散熱器的材質，幾何尺寸，固定方式等等。
嚴格而言，系統層級設計與模組是交互關連，互相影響的。
因此理想上，最好系統設計與模組設計由同一設計單位進行，發揮的整體效益最大;
實務上，由於產業生態與人力資源問題，有許多不同的作法。
產業鍊通常分為系統廠與模組廠。
系統廠指的是產品為完整系統，如伺服器、工業電腦、數位家電等等。
模組廠指的是出貨產品為散熱模組者。
設計工作執行模式約分三類:
1.系統廠包辦系統層級與模組層級設計
. 模組廠負責模組製造
好處 ：分工明確/最佳產品散熱/設計速度快/系統產品資訊保密/產品特色強
成功條件 ：系統廠人力必須充分，技術必須成熟
2.系統廠負責系統層級規劃
. 模組廠負責模組設計與製造
好處 ：系統廠人員需求可降低
可能問題：責任區分模糊/互相推諉問題，導致設計品質低落。
成功條件:* 系統廠技術需十分成熟，以訂出合理系統條件，並督導廠商完成後續;
. ._____* 模組廠研發人員需具備系統知識，以設計有效產品。
. . ____ *兩者技術語言需近似，才能有效溝通配合
3.系統廠完全無散熱設計人員把關，相關工作全部交由模組廠代勞。
好處 ：系統廠人力精簡
可能問題 ：*設計不同步，耗時/產品資訊洩漏/
. .______ *產品專案風險高，可能發生最後做不出來的狀況 （或是成本失控增加）
成功條件 : * 模組廠研發能力需非常完整，不僅在模組層級，亦包括系統層級。
. .______*模組人員與系統廠工作需非常緊密，困難案子大概需達駐廠(on site)程度
從產品特性而言，越特殊與差異性越大的產品就越適合第一種作法。
越標準化、越簡單的產品越適合第三種作法。
另外值得瞭解的是系統層級與模組層級，兩者散熱設計的技巧及概念是有所不同的
不管用那種模式，一定要弄清特性與配套做法
錯置的結果就是未蒙其利反受其害
不管誰做，設計總是要有人做的。只是看我們要有組織有方法的做，還是用碰運氣的。
2009年4月9日 星期四
2009年3月3日 星期二
甚麼道理？
兩個工程師
接一樣數目 一樣難度的案子
一個事情上班時間都處理完畢 準時六點下班
一個時常加班到晚上十一二點
如果你是客觀的人 你認為誰的工作能力好？
你認為那個才是常態？
你認為 那個工作品質會比較高？
老是加班的人 我們可以關心 可以支持
或許只是某個環節沒想通 ，
我們應該幫助他更有效率的完成工作 ，去過更有品質的生活
但我們如果認為這樣才是對的 ，這表現比準時沒問題完成的人還好
那這是甚麼道理？
＝＝＝
兩個工程師 一樣職級 (which means 他們應該有一樣程度的能力)
接一樣難度 一樣數目的案子
一個案子從未有過問題 總是順利的完成 凡事一次作對 不用事後補救
一個案子時常出問題 總是要東補西救 邊救邊喊累
如果你是客觀的人 你認為誰的表現好？
兩個給你挑 你要用那個？
常識 對嗎？
但就有人認為 ，東補西救， 看起來 很努力、 很有表現
從未出過問題的， 反而像是沒沒無名 沒在做事
這是甚麼道理？
＝＝＝＝＝＝＝＝＝＝
管理從不在 管理的人 說了甚麼
沒人關心天花亂墜的理念
只有管理的人 在執行時 、決策時 做了甚麼才重要
做的永遠比說的要更有力、 更深遠
如果你在行為上 做了跟你說的相反的事， 你就是向所有人投了否定自己一票
---無聲 ，卻不可回復。
接一樣數目 一樣難度的案子
一個事情上班時間都處理完畢 準時六點下班
一個時常加班到晚上十一二點
如果你是客觀的人 你認為誰的工作能力好？
你認為那個才是常態？
你認為 那個工作品質會比較高？
老是加班的人 我們可以關心 可以支持
或許只是某個環節沒想通 ，
我們應該幫助他更有效率的完成工作 ，去過更有品質的生活
但我們如果認為這樣才是對的 ，這表現比準時沒問題完成的人還好
那這是甚麼道理？
＝＝＝
兩個工程師 一樣職級 (which means 他們應該有一樣程度的能力)
接一樣難度 一樣數目的案子
一個案子從未有過問題 總是順利的完成 凡事一次作對 不用事後補救
一個案子時常出問題 總是要東補西救 邊救邊喊累
如果你是客觀的人 你認為誰的表現好？
兩個給你挑 你要用那個？
常識 對嗎？
但就有人認為 ，東補西救， 看起來 很努力、 很有表現
從未出過問題的， 反而像是沒沒無名 沒在做事
這是甚麼道理？
＝＝＝＝＝＝＝＝＝＝
管理從不在 管理的人 說了甚麼
沒人關心天花亂墜的理念
只有管理的人 在執行時 、決策時 做了甚麼才重要
做的永遠比說的要更有力、 更深遠
如果你在行為上 做了跟你說的相反的事， 你就是向所有人投了否定自己一票
---無聲 ，卻不可回復。
2008年12月5日 星期五
好工程師的特質
這絕對、 當然、 肯定是個人主觀看法。
好工程師有一種特質，跟學歷經歷沒有絕對的關係；
即使非常資淺，但一開始就還是嗅的出來。
好的工程師，有問『為什麼』的特質；
他不滿足於，『大家都這樣做』、『反正會過就好』；
他想知道問題的原因，方法的意義；
他沒辦法忍受講自己都不瞭解的解釋，或是將不確定的東西蒙混過關。
好的工程師，有榮譽感。
他不能忍受自己設計的東西亂七八糟；
他不需要別人要求，就會要求自己的工作；
他不會東湊西補交差了事，被發現問題還嘻皮笑臉或推託卸責。
同輩同僚，有這樣的工程師，非常愉快；
可以真正的討論問題，交換想法，不用去猜忌他的用心。
有這樣的下屬，非常放心；
你知道所聞即所實，知道他會盡他能力完成工作；
超過的地方也會如實的講，不會誇大承諾；
能力之內就絕對完成，不會偷懶卸責。
但是，這樣的工程師真的不多。
一開始就不多，能維持的更少。
要發現並培養這樣的工程師很難；
要挫折消滅這樣的工程師卻很容易。
怎麼挫折？
很簡單，不把他當一回事。
叫他做一堆無意義的事；
耍他，辜負他的信任跟努力；
表裡不一，前後顛倒；
人情權謀擺在事情道理之前；
把他當消耗品利用。
會捉老鼠的才是好貓；
工程師的本質是解決問題，
一個好工程師的能力與關鍵時刻的作用抵過五個偽裝的工程師。
如果，你遇到或發現了這樣的工程師，請珍惜。
copyright by Y.W.T.
好工程師有一種特質，跟學歷經歷沒有絕對的關係；
即使非常資淺，但一開始就還是嗅的出來。
好的工程師，有問『為什麼』的特質；
他不滿足於，『大家都這樣做』、『反正會過就好』；
他想知道問題的原因，方法的意義；
他沒辦法忍受講自己都不瞭解的解釋，或是將不確定的東西蒙混過關。
好的工程師，有榮譽感。
他不能忍受自己設計的東西亂七八糟；
他不需要別人要求，就會要求自己的工作；
他不會東湊西補交差了事，被發現問題還嘻皮笑臉或推託卸責。
同輩同僚，有這樣的工程師，非常愉快；
可以真正的討論問題，交換想法，不用去猜忌他的用心。
有這樣的下屬，非常放心；
你知道所聞即所實，知道他會盡他能力完成工作；
超過的地方也會如實的講，不會誇大承諾；
能力之內就絕對完成，不會偷懶卸責。
但是，這樣的工程師真的不多。
一開始就不多，能維持的更少。
要發現並培養這樣的工程師很難；
要挫折消滅這樣的工程師卻很容易。
怎麼挫折？
很簡單，不把他當一回事。
叫他做一堆無意義的事；
耍他，辜負他的信任跟努力；
表裡不一，前後顛倒；
人情權謀擺在事情道理之前；
把他當消耗品利用。
會捉老鼠的才是好貓；
工程師的本質是解決問題，
一個好工程師的能力與關鍵時刻的作用抵過五個偽裝的工程師。
如果，你遇到或發現了這樣的工程師，請珍惜。
copyright by Y.W.T.
2008年12月4日 星期四
到底誰的錯
常常 專案出問題了 就聽到：
專案負責人 說『都是你做不出來』『別人可以你為什麼不行』『能力很差』
工程師說『甚麼都沒給怎做』『講甚麼都不信 只聽自己想聽的』『不尊重專業』
到底 是誰的錯？
誰對誰錯，要先界定從那個角度來看，不然只是各說各話。
以專案的角度來看，我們可以說對整體專案有利的是對，不利的是錯。
這樣還是有點模糊，因此我們要更進一步理解專案的生命過程與不同的人在這過程這中的功能。
不同角色必然有他該有的責任與功能，否則不就是不必要的累贅？
因此對角色功能在專案過程中的作用與責任的正確理解，是專案運行能否順暢最重要的隱性因素，也是釐清問題所在的依據。（但多數人對組織設計與流程設計都沒有共同的理解，往往各自以自己的想法推想行事，當然是衝突連連外加恩怨情仇。去問專案中不同的人，為什麼專案要設定不同的階段，通常你都不會有一樣的答案---如果還有人回答的話。）
正確的專案管理會包括 ，需求訂立、 可行性評估 、設計實做、 驗證這個過程。
或許教科書裡這個過程已經是耳熟能詳，但真正落實每個過程要義的專案卻是鳳毛麟角。
越是前端的決定越是影響重大，這是任何人仔細想想都會同意的事實。
但如果我們仔細看看多數產品的開發，前端的決策都通常是怎麼做的呢？
越前端的部分越是沒有實體，越後端越實體化。
一開始產品不過就是要具備甚麼規格的概念而已，但後端才實際摸的到的東西。
但一切通常已在前端決定了，前端做的錯誤的判斷，後端實體只是呈現這個錯誤罷了！
我們通常看到的前端只是少數人 用喊的，可行性評估在哪？
這點在個人的經驗裡，在傳統的歐美公司做的比較好；台灣多數公司這段做的都不夠充分。
（跟產業發展歷史以及文化性格都有關係）
如果做不出來，再炫的點子也只是海市蜃樓，甚至是白花時間金錢的鬧劇。
一個理想的管理文化是專業分工的，是專業導向而不是階級導向。
譬如『經理』這職稱以專業分工來看指的是工作內容以調度、協調、控管為主；並不是職位位階的問題。但中國人的組織裡，往往都仍帶有強烈的階級意識（官大學問大，經理＝官）。
換個方式說比較清楚，若設有專案管理部門，那麼專案管理部裡人人都是專案經理，但以階級位階來說，這專案經理與工程技術部門中的工程師是同等位階。專案管理部經理的位階才與工程技術部經理位階相同。有這點認知才能去除階級意識對於責任劃分的干擾。
在可行性評估階段，各相關專業要提出的是 ，有沒有甚麼風險因素 、有多高 、要克服需要的條件 等等 （在性能 時間 成本 三方面的評估） 。
因為專案負責人專注於整體專案控管，不可能親自負責工程技術細節，專業部門的責任就是盡專業能力提供正確工程判斷資訊。
專案負責人的責任是就各專業提出的問題在專案目標下權衡輕重，取得平衡。
如果專案負責人不理會專業提出的風險，萬一後段證實此風險時，責任事實上是在專案負責人身上。 只是一昧的說，不管就是要解過，或是『要保持正面，不能說做不到』等等帽子，只不過是不願負擔決定責任，掩耳盜鈴的說法。
但要強調的是，專業當然有專業的責任。如果專業能力不夠，所以甚麼都說不能做，當然沒有人會相信專業提出的意見。因此專業的意見提出，必須有根據，有道理；也不能說『我覺得就是這樣』，要有可信的論據。
因此，專案責任的區分，事實上可以很清楚。每個階段每個階段的目的，每個專業的任務，提出的意見，做成的決定等等，都應該具體如實的紀錄。當專案結束，檢討過程時，依據實際上的問題對照過程，可以很明顯的界定原因。
簡單說，如果專業說不能，專案負責人不理會，硬幹，結果證實失敗，責任在專案負責人；
除非能舉證同樣的條件有其他人做的到，如果這樣，是專業水準不夠。
如果專業說能，最後卻做不出來，當然是專業水準不夠。
專案管理的程序本來就要定清楚，記錄清楚。這樣責任區分是很明顯的。
但多數人仍然只是避事怕事，爭功諉過，用各種非技術非事實的方式互相推諉，從不想把事情講清楚劃分明白，或許，一旦劃分明白就沒有閃躲的空間了吧。
copyright by Y.W.T.
.-
專案負責人 說『都是你做不出來』『別人可以你為什麼不行』『能力很差』
工程師說『甚麼都沒給怎做』『講甚麼都不信 只聽自己想聽的』『不尊重專業』
到底 是誰的錯？
誰對誰錯，要先界定從那個角度來看，不然只是各說各話。
以專案的角度來看，我們可以說對整體專案有利的是對，不利的是錯。
這樣還是有點模糊，因此我們要更進一步理解專案的生命過程與不同的人在這過程這中的功能。
不同角色必然有他該有的責任與功能，否則不就是不必要的累贅？
因此對角色功能在專案過程中的作用與責任的正確理解，是專案運行能否順暢最重要的隱性因素，也是釐清問題所在的依據。（但多數人對組織設計與流程設計都沒有共同的理解，往往各自以自己的想法推想行事，當然是衝突連連外加恩怨情仇。去問專案中不同的人，為什麼專案要設定不同的階段，通常你都不會有一樣的答案---如果還有人回答的話。）
正確的專案管理會包括 ，需求訂立、 可行性評估 、設計實做、 驗證這個過程。
或許教科書裡這個過程已經是耳熟能詳，但真正落實每個過程要義的專案卻是鳳毛麟角。
越是前端的決定越是影響重大，這是任何人仔細想想都會同意的事實。
但如果我們仔細看看多數產品的開發，前端的決策都通常是怎麼做的呢？
越前端的部分越是沒有實體，越後端越實體化。
一開始產品不過就是要具備甚麼規格的概念而已，但後端才實際摸的到的東西。
但一切通常已在前端決定了，前端做的錯誤的判斷，後端實體只是呈現這個錯誤罷了！
我們通常看到的前端只是少數人 用喊的，可行性評估在哪？
這點在個人的經驗裡，在傳統的歐美公司做的比較好；台灣多數公司這段做的都不夠充分。
（跟產業發展歷史以及文化性格都有關係）
如果做不出來，再炫的點子也只是海市蜃樓，甚至是白花時間金錢的鬧劇。
一個理想的管理文化是專業分工的，是專業導向而不是階級導向。
譬如『經理』這職稱以專業分工來看指的是工作內容以調度、協調、控管為主；並不是職位位階的問題。但中國人的組織裡，往往都仍帶有強烈的階級意識（官大學問大，經理＝官）。
換個方式說比較清楚，若設有專案管理部門，那麼專案管理部裡人人都是專案經理，但以階級位階來說，這專案經理與工程技術部門中的工程師是同等位階。專案管理部經理的位階才與工程技術部經理位階相同。有這點認知才能去除階級意識對於責任劃分的干擾。
在可行性評估階段，各相關專業要提出的是 ，有沒有甚麼風險因素 、有多高 、要克服需要的條件 等等 （在性能 時間 成本 三方面的評估） 。
因為專案負責人專注於整體專案控管，不可能親自負責工程技術細節，專業部門的責任就是盡專業能力提供正確工程判斷資訊。
專案負責人的責任是就各專業提出的問題在專案目標下權衡輕重，取得平衡。
如果專案負責人不理會專業提出的風險，萬一後段證實此風險時，責任事實上是在專案負責人身上。 只是一昧的說，不管就是要解過，或是『要保持正面，不能說做不到』等等帽子，只不過是不願負擔決定責任，掩耳盜鈴的說法。
但要強調的是，專業當然有專業的責任。如果專業能力不夠，所以甚麼都說不能做，當然沒有人會相信專業提出的意見。因此專業的意見提出，必須有根據，有道理；也不能說『我覺得就是這樣』，要有可信的論據。
因此，專案責任的區分，事實上可以很清楚。每個階段每個階段的目的，每個專業的任務，提出的意見，做成的決定等等，都應該具體如實的紀錄。當專案結束，檢討過程時，依據實際上的問題對照過程，可以很明顯的界定原因。
簡單說，如果專業說不能，專案負責人不理會，硬幹，結果證實失敗，責任在專案負責人；
除非能舉證同樣的條件有其他人做的到，如果這樣，是專業水準不夠。
如果專業說能，最後卻做不出來，當然是專業水準不夠。
專案管理的程序本來就要定清楚，記錄清楚。這樣責任區分是很明顯的。
但多數人仍然只是避事怕事，爭功諉過，用各種非技術非事實的方式互相推諉，從不想把事情講清楚劃分明白，或許，一旦劃分明白就沒有閃躲的空間了吧。
copyright by Y.W.T.
.-
訂閱：
文章 (Atom)