2009年8月6日 星期四

[Digest] Is Freelancer Right For You

One article on HBR, August 6, 2009, titled "is Freelancing Right for you"

DOs:
1. 你的skill有市場嗎?公司願意買你的服務嗎(當預算緊縮時)?業界情況如何?what do people want to buy?

2. 評估你的財務狀況?

3. 分攤風險的夥伴?
--衰退時,臨時工就業數也降低(USA)

4. 比較上班,問自己為何要做Freelancer?

5. proven track record

How:
1. 別期望過去full-time的待遇

2. 何時提高價格;當你忙不過來時

3. help others by free hour consultant

4. Keep contacts, get out of your house

5. keep learning per quarter

6. Self Review

7. Vocation

Elance, Guru.com, GetAFreelancer.com

2009年4月14日 星期二

Project engineer

2009-04-14
        It is interesting to look back on how we ran projects, to see why it succeeded or failed. This is a slide about mind set of project engineer.

2009年3月19日 星期四

上課了

2009-03-19
        最近有個機會在職業訓練機構講課,上課成員大都是科技大學畢業且剛退役的年青人,另外有些是經濟冰風暴的受害者。

        老實說,第一堂課是有些緊張,也花了點時間準備材料。我的想法是,入門的概論應該提及歷史的發展,應用範疇,所要解決的問題,並兼顧整體的視野;這樣,學員 可以掌握學習目的,瞭解為何要學習這門課,及課程進行的方式。其間,免不了要帶入一些枯燥的基本知識或理論,因此要用到一些英文資料。想不到課後,該機構 主辦人跑來告訴我,英文資料太多,學員吸收、瞭解有困難。起初是有些驚訝,後來我想連著名的李家同教授,都得幫他的碩士班學生加強英文,也就釋然了。

        英文可以不是問題,只要我不去看它、用它,中文網站都看不完了!

        麻煩的是,這門課要用到軟體,全英文手冊,介面,還不時得參考網站資料。

        另外,主辦人還說,講課的份量不要多,儘量安排實做。我原先的想法---由整體而局部---看來有問題,得反過來才行。於是課程的進行轉而以實做為主,講解為輔。針對每一個實做,我得把完整的方案,事先準備好,於課堂中,一步一步帶著他們完成,順道說明其間的基本概念。然後,要求他們做一些變動、修改。即便如此,當錯誤發生時,雖然電腦已回應錯誤訊息(error or warning message),他們只能求救。也就是說,缺乏問題意識及解決的能力。在這樣的狀況下,直接給問題要求他們實做,是行不通的。

        印象中看過一本,所謂"實驗"教材,裡面的內容,是把實驗步驟、動作,清楚列出,1, 2, 3, 4....,然後要學生把量測所得資料登入準備好的表格中,當然後面會有一些"問題",要學生回答。能做出"答案",即算完成該實驗。

        雖然,自己當年也不是好學生。離開學校幾十年之後,我認為,高等教育至少應訓練學生,找問題、定義問題、設計實驗、進行實驗、分析資料等能力。而不是如前述所謂"實驗"教材,亦步亦趨,以得到"標準答案"為目標。

        我的觀察是大學四年的教育,究竟沒有使他們具備基本知識與技能。這是資源的浪費,也是學校的責任。大學院校,爭相設立碩士班,努力爭取經費、學生,以研究及出版為目標,教育的主體目標(學生)反而模糊了,不見了。

        問題是,台灣需要這麼多研究型大學嗎? 我認為,某些學校不如只辦大學部,集中資源,控制品質,搞出特色,不愁招不到學生。

2008年12月17日 星期三

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年。

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

2008年12月7日 星期日

Plan the work, Work the plan

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

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

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

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

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

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

2008年11月3日 星期一

工程師與業務員

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

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

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

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

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

2008年9月14日 星期日

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.