Change for Engineering Education

2008-12-17

        Stanford 大學工學院院長，James D. Plummer，在最近的IEDM會議上，表達了他對工程教育的看法，題目是:"Educating Engineers For The 21st Century"。相關新聞刊於EETIMES, "'Change' needed in engineering education."

        這裡摘錄一些重點如下:

展望未來，三大領域: Information technology, Environmental/energy and life sciences，都需要優秀的工程師投入。 他憂心地看到，美國，歐洲或日本，學生對工程的興趣有下降的趨勢，而在中國、印度等新興國家，主修工程學生人數，則爆炸性地成長。

他認為過去50年，過度重視專業課程的工程教育，已無法面對現今世界的挑戰----Internet everywhere, global and unpredictable career, changing technology

認為法學院或醫學院的模式較佳，研究所之前的教育偏基礎、通識，這與工學院有很大的差異。

他認為真實世界的工程，乃由下列各要素組成:

real world engineering = technology + science + art + business.

但是學校教育尚未能提供某些關鍵技能，如創業、商業、團隊合作、、等。

所以，他主張學校必須改變，培養學生:

1. ''T-Shaped" 人才，專業深，廣度也要夠

2. Innovate and be creative

3. 企業家精神

4. 團隊合作

5. Undergraduate research programs

6. Competitions

7. Global knowledge and experience

8. Better communication skills

9. Life-long learning programs

10. Why engineering is important

        這是教育界發出的反省及警訊，並且Stanford也已實際地做出改變，可參考該校eCorner。做為高等教育的領導者，Stanford的工學院，已對未來的世界所需工程的人才，做了準備。

        當然，回到現實，老美不願當工程師，潛在的問題是工程師雖屬白領，卻是高級黑手，賺的是辛苦錢，不如行銷人員 光鮮，純粹做先進技術研發的，究竟不如搞商品的多，加以新興國家工資便宜。於是工程師的工做，不是留給有色人種，就是外移(包)到海外，此之所以 Stanford要強調工程師的重要性及鼓勵學生具備全球化(跨文化)視野、經驗。

        回顧我自己的學生時代，經濟並不寬裕，我們規矩地走在 社會認同的軌道上，除了讀書，就是一些些的玩樂及一些些的苦悶。在那樣的年代，沒有老師會告訴你，要培養何種能力，未來將如何，甚至，我們也不知道，為什麼要念那些科目。這樣的一代，趕上了台灣經濟成長的大潮流。而今，台灣已然變成電子製造強國，為數眾多的上市電子股，每日成交值左右著股市的漲跌。股票分紅，曾經造就了一堆人人稱羨的科技新貴，直到最近因法令修改後，盛況才不復見。

        有人以為，在戒嚴氛圍中成長的台灣人，認命的工作著，剛好配合大量生產的需要，造就了經濟快速成長及龐大的外匯。也因此海島經濟的限制，代工製造變成顯學與 宿命，在全球經濟的食物鏈中，台灣雖佔有重要地位，但論及價值創造、生產力、生活水準，都還不算是贏家。在美國，類似Stanford的學校，能夠不斷地獲取經費做先進的研發，灑下的種子，如果能萌芽，就轉移到如矽谷之業界，接續商品化的歷程，形成一良性循環。就像肥沃的土壤下，肥大的根不停的衍生，適當的時候，就冒出芽來，長成一棵大樹，甚至一片森林。以半導體為例，播種、耕耘的時間可能要幾十年。不細 察，我們會以為產業是一夕之間蓬勃、茁壯起來的。

        我們過去的做法，是短時間內直接把外來果樹移植到台灣的土地上，如果有幸成功，我們就擴大戰果，以低價競爭，再複製，衍生。其成果是產業形成了，出口增加了，國民所得提高了。但在面臨新興國家以類似的策略競爭時，產業只能連根拔起地外移， 留下的是一片荒涼的土地。然後，下一步，想想我們還可以移植哪些熱門的外來果樹。在這不停地移植、外移循環中，要問的是，產業的根在哪裡 ? 從明顯的指標，可以發現，台灣雖然是IT製造大國，卻不是IT應用大國(BIKE 亦同)。簡言之，我們追逐短期的財富，雖過勞死，亦在所不惜。同時，這類淺碟及速食型的做法，也是造成業界管理手法或工程師的品質無法提升的元兇。

        同時間，高等教育也蓬勃發展，學生急著進入職場，出國進修比例降低，理工科系，由於大學增班，新大學設立及專校升格科技大學，錄取率幾乎大於100%。 同時間，大學教育供過於求的問題，也浮上檯面，很多大學恐將面臨招生人數不足之困境；社會、企業抱怨教育品質低落，高等教育人力無法用於提升產業競爭力， 形同社會資源的浪費。

        2005年，政府急於想要提升高等教育的世界排名，推出"五年五百億元邁向頂尖大學計畫"，第一目標是十年內產生一所排名世界百大的國際一流大學，第二目標是五年內發展出十個亞洲一流的頂尖研究中心。所謂頂尖大學計畫，是以研究為重點，各大學紛紛設立大型研究計畫，爭相搶食龐大的政府經費。如果計畫的成果只停留在人員、硬體擴充，論文篇數增加、排名提升，而對教育品質、產業環境無法發揮升級的作用，五百億元恐怕要白花了。

        遺憾的是，就大學培育人才的功能來說，我們沒有看到大學提出類似Stanford的願景，或改革計畫。遑論，關於產業政策的關聯性。

        面對百年首見的經濟風暴，無獨有偶地，美國人開始反省，紐約時報專欄作家 FRIEDMAN，"世界是平的"一書作者，在最近一篇題為"Time to Reboot America "的文章中提到，最聰明的美國人跑去做財務金融，搞複雜的錢滾錢的遊戲，而非設計汽車、手機、電腦、教學、軟體及醫療器材，以改善生活和生產力。 政府能做的不只是紓困，而是重新啟動（reboot）。面對未來的挑戰，政府必須挹注經費於: 訓練教師、科學家和工程師、研發及基礎設施以提升生產力。

        這需要學校與業界的願景，努力投入與分工合作，及十年樹木的耐心。 面對未來，我們需要何種人才及產業 ? 五年五百億元就可以有答案了嗎 ? 這塊土地該如何耕耘，才能長出豐收的果實 ? 台灣小島，歷經30幾年的成長，電子產業及高等教育的發展似乎同樣面臨了瓶頸。 過去台灣的步伐總是以美國為首是瞻，龍頭擺一下，總要一些時間的延遲，龍尾才感受到。 等而下者，後知後覺，甚至不知不覺，或者是我們竟然晚了30年。

        不禁要問，能站在全球化的觀點，籌畫出下一階段的路，或甚而引領風騷的領導人，在哪裡?

Plan the work, Work the plan

2008-12-07

        公司裡，啟動一件工作之前，我們習於企畫(PLAN)事情，無論是預估收益，執行經費，執行進度規劃，所需資源，風險評估，...........等。計畫書的架構，使我們可以檢視其內容、假設及可行性，據以說服老闆，客戶，投資者.......等，計畫利益相關人士。

        無論如何，專案的企畫，只是我們對未來的規劃及預估，基本上就是一種風險投資，本質上，不確定性很大。除了算命師，沒有人可以告訴我們，明天會如何。即便是 企畫本身，也可能面臨需要大幅更動的挑戰。當然，也有一種計畫只是主事者的一廂情願，經不起分析的願景，非屬我們關心的範疇。

        徒有有良好的企劃，並不能保證專案的成功。專案執行過程中，外在、內在環境的變化，會影響手段、甚至目標的有效性。這裡需要人的行為(ACTION)與投入，人必須在時間壓力下，找出選項，做出選擇、判斷、並往最有利的方向移動。

        更挑戰的是，決策的當下，我們經常無法得到所有的資訊，或甚至不可得，但我們無法等待。這是REAL LIFE。

        即便是夢幻團隊，也需要好的領導者，這領導者就像NBA教練，他會永遠在場中，指揮球隊，掌握狀況，絕非part time job。他得把球隊的戰力發揮出來，而非抱怨球員的失誤。儘管戰前已做過策略模擬，根據臨場的狀況，必要時得做出改變的決定。

        改變會引起團隊的衝突，經理人可能不能忍受跳脫制式流程的做法，技術人員對不確定更趨保守。如何凝聚團隊及說服利益相關人士，這是團隊領導者的挑戰了。

工程師與業務員

2008-11-03

        海角七號裡，小米酒推銷員，抓住一切機會，HOTEL，喜宴，演唱會、、、，只要有機會，就是要推銷。儘管情勢不佳，他還是精神奕奕，釘住目標，打死不退。

        如果是工程師的思維，首先，穿著鐵定不同。面對不同的客戶，台詞可能都一樣。面對拒絕，他會覺得受傷，精心研發的產品，無人親睞(為什麼這些人聽不懂?)，甚而覺得產品遭受糟蹋。兩三次以後，氣勢不見了，笑容難再。他還會懷疑，這是有問題的產品。

        聽起來，似乎工程師無需推銷，事實剛好相反，工作上，我們需要說明概念、技術、產品，遊說、說服以取得支持，這些不外是溝通，對象可能是技術人員，也可能 是非技術人員。工程師常執著於"正確"、"真理"，以為重點是WHAT YOU SAY-----引以自豪的真知灼見；殊不知HOW YOU SAY，有效溝通，才是重點。2008年10號之科學人雜誌，有一篇高湧泉教授的文章，"就像聽貝多芬交響樂"，文中引用幾個物理大師的話，"多寫文字敘 述，敘述比計算式重要"，"科學不能沒有敘事"，"有25個表格卻沒有什麼敘述的論文、、、，這與那是真的，請見表16、、、是失敗的論文，事實是沉默 的，人們需要寫或講出來的敘述才能理解"，"我們如果只會計算，卻無法以日常語言解說計算結果，那麼我們的理解仍有缺陷"。這些論述，也正好適用於工程師 的工作。當然，在溝通表達之前，我們已獲得數據，掌握狀況，並理解、形成論述、觀點。

        還有一點，可能科學家無需如此，對工程師卻很重要，所謂"見人說人話，見鬼說鬼話"，意指表達方式因對象不同而不同，更重要的是還得在正確時機說出來，或問對的問題。這需要察言觀色，審度時勢，才知道所謂時機是否適當。

        看來，溝通表達之術，難於工程。

Stuff about Architecture

2008-09-14 關於架構

Many years ago, there was a chance to work with one talented firmware engineer who were working for one of our customer. Somebody told me this guy was excellent at his job, that is, he had got good records for years, though he was still a young one. The interesting point was he always would start his job, mainly firmware coding, right after project kicked off. And he could make it at a very fast speed to meet those always tough schedule. So everybody would like to have him in project. One the contrary, there was another style. Engineer would not start coding at the beginning. He would investigate the problem, studying, specification..... But everybody, managers especially, could not wait for something realized by today, so they would think this guy was too formal and slow and keep skeptical about the outcome.

This is interesting to me about the way engineer solves problems. Though, the 1st engineer seemed to be having better EQ, I would like to remove those factor in this discussion. In general, engineer is expected to realize, implement something working. Someone would like to make some small gears at the very beginning while only a foggy idea about the final outcome, see how well it run, then modify and try again. This process will continue until whole stuff running and it seems to be reansonable for a seansoned talent. We call this is a bottom up approach. The other way, top down apporach, engineer would clarify requirement, constraint at first stage, then investigate an feasible architecture before making something realized.

I would not say which one is best, but from my experience and observantion I would like to prefer top down mixed with bottom up. Of course, it depends on case, simple tiny or complex huge one. However, I am use to think while organizing and writing something down to certain detail that I can have clear and structured image in my mind during the implementation stage afterwards. For those which are no doubt at the very beginging, we can start to make, i.e., bottom up, that concurrent development is possible. In this way, the risk to rebuild some blocks totally while integration can be mitigated. The worst case is to discard everything at some later stage. It will cause timing and resource wasted and schedule crashed.

Architecture will show its power whenever we need to know how well the product will run and how we interface other components in a big team. Moreover, in electronic product design today, we are concerning very much about design platform and reuse. It is impossible to fulfill those requirement without clear concept of architecture. Furthermore, good architecture will help in the future when we have to make some changes or when we have to fix problems, then dirty patches around the design, which eventually nobody will understand, can be avoided.

Back to real world, no company affords so-called architecture engineer, here in TW, every engineer in the team are expected to do everything as soon as possible. In reality, the winner is who can deliver the lowest price product at first time when customers with order in hand are standing in front of door today. In such situation, engineers are squeezed to get the orders. Moreover, the shorter the product life time, the worse this situation is. This is stressful to engineer and management, since we only earn shear margin after really hard working which engineer didn't get growth. And this cycle will repeat itslef for next case until finally enginner team burn out phased out, then we recruit another new team. This is really a tragical cycle.

The problem is how we save us from this kind of cycle! Improvement of the engineer productivity and quailty always help but you need to invest resource and time. No free lunch! However, enginner has to be aware of his or her situation and be willing to make change before such improvment could take effect.

[BookDigest]: 現代嵌入式系統開發專案實務

2008-09-14

＂現代嵌入式系統開發專案實務－菜鳥成長日誌與專案經理的私房菜＂, by 邱毅凌

It is unusual that a local published book targeting for embedded design practices, mainly SW and FW, in such a proficient and systematic way.

I was always wondering how those so called "SW engineers" did project. Always heard "complex, difficult, hard bugs, linux kernel, drivers, boot-loader,.......", "delay and again delay......", "customer complaint", "new feature", "release"....... one word: chaotic, no end light.

What I saw:

1. started from beginning, Do, Do, Do.......and Demo/release

2. no spec.

3. so source code management, sometimes you just couldn't get it.

4. resource not sufficient, mostly only driver engineers equipped.

5. No integration flow

6. Lack of test, verification practices

7. Lack of engineering management, but outward management

8. w/o architecture

9. They couldn't tell others in brief, ex in one slide, about what they were doing.

Strange to me, what has made this. What is our problem here in engineer training and education?

SW engineers complained that they are secondary, compared to HW engineers, even worse, they got paid less than HW engineers. One possible cause, I guess: we are making and selling HW products which really/physically count in terms of price. What is the value of SW? It supposed to be low risk. Right?

Seems now the weighting of HW and SW has already changed, the SW complexity and head counts dramaticly go up in development team. Already invested very much in HW development and manufacturing, but still too less in SW side. Further, the slower learning curve makes it worse.

Any way, this is a good book and good start for this field and for those probies like me.

[Digest] Product Design and Development

2008-09-10

(a translated book about how a product company develops a good product.)

book digest: product design and development

Just read a book, title "Product Design and Development".

The book guided reader some major concept and procedure by real product story which are all about physical assembled products like printer, screw driver.....This is a good reference for process and concept for new product development.

The 1st slide is about different kind of project category which show different situation. Think about what kind of project you are doing.

Major stages, processes and activities for players---marketing, design, manufacturing---are listed as below.

The 3rd: Project planning

The 4th: Customer needs and product spec.

Here is the area we usually don't touch or don't know how to do since we are doing OEM business.

5th: Concept development:

6th: Product Architecture:

For two items above, we used to just think, guess or follow boss' order w/o a such systematic process. Or we don't have time to consider next step so architecture is skipped.

7th: Project Management, DSM(design structure matrix, tasks: iteration, integration, sequence)

8th: Project Contract Book

BUG Making

2008-09-10

        工程師必須管理，解決，產品發展過程中所製造的BUG。工程師也提供複雜的工具，資料庫，以管理流程及BUG。聽來矛盾，詭弔？好像是工程師故意把事情搞複雜，沒事找事，以彰顯自己之不可或缺似的。

        話說人非聖賢，孰能無過！此所以有公理一曰：犯錯乃人之本性！ 是以，很多大型組織內有數不清的作業程序，防錯乃基本功能之一！搞到極致，就像作業員，每個人皆按ＳＯＰ做事，如同事先設定好指令（Program)的機 器，遇到例外狀況，只能停機，警示。但是，到目前為止，工程師的工作，尚無法如此高標準化。果真有那麼一天，我們需要僱用的是電腦或機器人工程師，他們不 會抱怨，沒有情緒，２４小時待命，無須休假，生產力高，穩定，不會犯錯－－除非機器有BUG！哈！還是又回到原點。但，可以期待的是，那時的工程師，應可過著比較正常（像人）的生活吧！

工程師犯的產品BUG，之所以如此惡名昭彰，並非只有工程師才會犯錯，而是因為交貨延遲，客戶抱 怨，電腦當機，甚至退貨；更嚴重的例子，如橋樑大樓震垮，太空梭爆炸，火星探險號當機，飛機失事、、、。如果有一個公司，只有工程師會犯錯，她應是股王！ 完美的夢幻隊伍，當然，工程師要具改善，創造，創新之基本能力。

看看有名的Murphy's Law 就瞭解我們常被臭蟲咬的遍體麟傷的原因了。援引兩條如下：

Anything that can go wrong will go wrong.

If any things simply cannot go wrong, it will anyway.

此公理二。

我看過所謂的＂不可原諒的錯誤＂，皆屬此類。可能是知識，訓練不足，或是太有自信。或者心存僥倖，先繞過(Work Around)再說，殊不知它遲早來咬你。吾人可以借鏡飛行員及腦外科醫生，無論他們多資深，每一次任務，每一檯刀，總是戒慎恐懼，如履薄冰，對他們來 說，只有別人的case是小case，自己上陣的都是大case。抱著這樣的心態，才有機會累積經驗，做出改善，一次比一次做的更好。

依Ｍurphy's Law, 即便佈下天羅地網，依然會有漏網之蟲，這就是真實世界，也無須因此過於悲觀。所以，面對問題時，最好能保持心態開放，謙卑---面對物理及人的世界，因它總不欺你。

最近坊間出版了大前研一談 邏輯及麥肯錫顧問公司的書，引起一番討論。固然，這應視為工程師之基本修練，惜文化，習性，偏見一旦成型，很難改變。東方人習於人際導向，而非數據，方 法。面對問題時，不是Try-Error，就是Jump to Conclusion，甚至連問題描述都不對，就無須期待該方案能成功了。

有趣的是，人性常會跑出來干擾我們 --難怪有人要主張人本非理性，比如防衛心態，這不可能是我的錯、、， 強烈的自我擋住瞭解決方案出現的可能，我們的心就進入無窮迴圈，跳不出來了。有一種有趣的對應方法是，無論如何，假裝自己是受命解決問題的顧問，心平氣 和，但表現專業。另一方面，組織面對問題時，如果只在乎是誰的錯，人們會開始推諉，不敢冒險，創新，團體因此失去學習成長的機會。

死腦筋工程師

2008-09-10

        工作久了，總會聽到業務人員的抱怨，這死工程師竟然在客戶的MEETING上說SCHEDULE 會有問題，害我屁股擦不完﹑﹑﹑﹑。或者在討論產品需求時，資深工程師脫口而出＂這怎麼可能？MISSION IMPOSSIBLE， 你們瘋了?＂。可過不了多久，競爭者的產品上市了。

        工程師當久了，總以為這世界是Logic Model，黑白分明的，奉物理的自然律是無上律，＄的世界也該當如此，殊不知＂人的行為＂這事遠比物理（工程）複雜，且從來就沒有準確的Model。相 較於工程，當目標確定，我們總會選定方法﹑工具﹑模擬﹑分析，評估風險對策﹑﹑﹑﹑等，步步為營，務求成功。自然養成看事實／數據／證據說話的習慣。依此模式去看行銷／業務的工作，就會覺得這些人實在不夠科學，只會耍嘴皮。反過來，業務人員則認為，這些人不知變通，很難溝通。

        雖說行銷／業務比較像是暗夜行舟於未知海域，摸石子過河，等而下之者，沒有策略及方法，只等老闆及客戶的命令行動；雖說是不同領域，且商學院號稱＂管理科學＂，恐怕是理論／實務之差距了。

        另 一方面，當客戶的聲音（需求）出現時，工程師會直觀的予以否定，＂怎麼可能？到底懂不懂？白痴問題＂。有個笑話說，一個IDEA出現時，如果工程師說這簡 單，表示這裡沒有甚麼機會；反之，則值得繼續探究。面對這類問題時，如果能保持開放心態，詳細探究顧客需求－－－通常這不是工程語言，說不定解決方案早已存在，或者那是一個很棒的產品概念。

        工程師修練之一是跟不同領域的人溝通，瞭解各領域之不同觀點及需要，解決並發現問題，保持開放心態，進而發現新的需求及機會。

xPD xPM

What xPDxPM really is?


Whatever taste you like:


Product Development
Product Design
Product Planning


Product Marketing
Product Management
Project Management
Program Management


then, what does x stand for?


again, whatever you like
successful, surviving, exciting, good, or...
shit, fuck.....

OEM/ODM 的時代

2008-Jul-04

        Recently, there was a chance to talk to my friends in the industry about what they were facing in the field, that brought me the idea of mindset of OEM/ODM which made us good days in the past, but may not for the future.

        據說今天乃米國國慶日, Independent Day 是也。

      

        回顧過去半導體高成長的時代, 米國人貢獻了很大一部分, 其中又以IT及消費性電子產品為主-------從早期電子錶, 計算機, 語音玩具, 到DVD PLAYER, DSC, 手機, TV, 數位相框.....。代工生意做不完，工廠日夜生產。然後是新興國家崛起，工廠外移，後ＰＣ，微利時代來臨，眼看高成長不再，新機會難有，進入門檻拉高， 競爭劇烈，再來能源，物料價格高漲，經濟前景悲觀，過去的成功法則（思維）再難複製。

        消費品者，價格功能取勝，跟隨季節，流行起舞，無庸顧慮售後 服務，品保，更甚者銀貨兩訖，各憑本事。雖是紅海一片，還得繼續苦守廝殺。有些人則另闢戰場，追尋夢想中的藍海；無奈，這些領域，台灣似不具優勢，一者，mindset不變－－－說穿了是想要移植ＩＴ模式；二者產業鏈，應用端脫結，也是無法脫穎而出。

          

        走出ＯＥＭ／ＯＤＭ／大規模生產模式，就優勢不再，例如＂產品設計＂思維－－由客戶／市場到產品概念發展－－就不是我們擅長的。更無論品質／品牌／價值了。

        姑且不論商業模式，工程師及工程教育是否已做好基本功，以因應改變呢？悲觀的說，看不到！