Build in .net 1.1 using Visual Studio 2005?

To target VS 2005 using the older .net framework, try Jomo’s work around – http://blogs.msdn.com/jomo_fisher/archive/2005/04/22/410903.aspx

Also check out Robert’s workaround, although it’s not working for me:
http://www.longhornblogs.com/robert/archive/2005/06/03/14156.aspx
http://www.hanselman.com/blog/BuildingNET11ProjectsUsingVisualStudio2005.aspx

The MS supported version is coming soon:
http://blogs.msdn.com/msbuild/archive/2005/11/09/490817.aspx
http://blogs.msdn.com/clichten/default.aspx

廣告

郭台銘語錄

http://www.visa.org.cn/blog/more.asp?id=307

一、如果
(1)妳只是接電話,告訴客戶不知道、沒辦法。
(2)妳只是開訂單,不連絡、不追蹤,有問題不回報、不處理。
(3)妳只是打報表,不確定數字正確性。
(4)妳只是接電話,從未希望客戶有滿意的感覺、從未希望客戶多訂一些貨。
(5)妳只是認為自己是助理,從未想過自己一言一行代表業務、主管、老闆、公司。那麼,妳不夠格做一個稱職的助理,妳的工作,任何人都可以取代 。

二、如果
(1)你從未將部門業績目標時時刻刻放在心中。
(2)你從未想過個人目標攸關部門目標達成。
(3)送樣後,從未想過結果如何,為什麼沒消息。
(4)報價後,從未追蹤為什麼沒有訂單,差多少可以成交。
(5)訂單多了,從未去想怎麼回事,隨波逐流、隨客戶起舞。
(6)訂單少了,不去追查什麼原因,毫無感覺、毫無動作。
(7)你從未想過在客戶面前更專業、更守信。
(8)工作不規劃、時間不管理、成本不控制、客戶不教育。
(9)你認為開發新客戶、新市場是麻煩的、痛苦的。那麼,你不夠格做一個稱職的業務人員,你在,是我們大家的負擔。

三、如果
(1)你不把客戶需求當作是非常的重要。
(2)你不把客戶抱怨當作優先解決的事項,主動追查檢 討。
(3)你時常不準時送貨,當作客戶永遠都會等你。
(4)業務反應客戶的問題,你嫌他煩。
(5)客戶反應品質的問題,你嫌他挑剔,視他為爛客戶。
(6)你經常把〝很麻煩〞、〝有困難〞、〝不想做〞、〝不可能〞掛在嘴邊。
(7)你每天上班當作例行工作,不主動尋找問題、改善品質。那麼,你不夠格做一個稱職的生產部主管,與你共事,我很疲勞。

每日我們在外努力,沒有良好的品質,沒有良好的服務做後盾,
一切效果會打折扣,對客戶的承諾都會跳票,我們便成口才一流、
品質二流、服務三流的公司。

四、如果
(1)有罵沒有稱讚、有懲罰沒有獎勵。
(2)對企業有利的,不立刻行動。
(3)經常把"再看看"、"再研究"掛在嘴邊。
那麼,我也只能偷偷的說,你不是一個稱職的老闆。我不能多說,畢竟你還是我的老闆。

C# 編碼原則 (C# Coding Guidelines)

誰都會寫程式碼!幾個月的編程經驗可以讓你寫出「可運行的應用程式」。但在開發團隊的運行模式下,以最有效率的方式編碼、能被小組成員順暢承接的程式碼就必需要下更多的功夫!

要知道,大多數程式設計師在寫「可運行程式碼」,而不是「高效率程式碼」。寫高效程式碼是一項藝術,必須靠紀律及學習來實踐。建立一個高效率、有默契的開發團隊更需有一定的規範及標準流程。

想要讓開發出來的程式碼穩固且容易維護,除了有必要適當地採用設計模式 (Design Patterns) 之外,也有必要採用編碼原則 (Coding Guidelines),做為寫程式時依循的準則。設計模式是在設計階段進行的,主要由系統設計者 (System Designer)負責,所以和程式員的關係比較不是那麼密切。至於編碼方針,就和程式員的關係相當密切了。

程式碼命名及格式規範的目的為建立開發團隊的默契以及效率。檢視一篇與自己撰寫風格相同的程式碼不但能減少無謂的猜測,也能快速暸解程式碼,立即進入程式撰寫的狀況。

輔助工具
在Google搜尋keyword :: “Code formatter, code beautifier",你可找到一票自動化的輔助工具。對C#來說,最重要的編程方針是美國微軟MSDN網站上的Design Guidelines for Class Library DevelopersreSharper則是目前我們使用的自動化工具。

編碼原則
Ascertaint C# Coding Standard

相關文章
迅速提升.NET程式設計技巧 – 75個訣竅幫助你減少程式中潛在的問題

管理強人郭台銘經營解秘 — 細節‧拆解‧簡化‧貫徹‧紀律

《數位時代雙週》第98期【封面故事】‧撰文/何飛鵬

創辦《商業周刊》也擔任過創刊總編輯的何飛鵬,對「管理」情有獨鍾,因此於去年12月創辦《經理人》月刊,並重出江湖擔任總編輯。在他的觀察中,鴻海郭台銘的紮根於作業現場的管理,最是樸實無華,也最有力量,在看完139條語錄後,他特別為《數位時代雙週》讀者撰文,提出台灣企業最應看重的郭台銘管理精髓。

將近三十年的財經新聞採訪經驗,讓我有機會接觸無數的台灣企業名人,近距離觀察體會他們的言行、經營奧秘。但是唯獨現在的台灣首富郭台銘,因為他竄出檯面太晚,我已經退居幕後,一直沒有機會一見。

也因為如此,許多的疑問,一直在我心中繚繞,鴻海的擴張動力及速度,為何如此巨大且快速?遠看像個獨裁者,而獨裁者又何以能有效統治龐大的鴻海帝國?這是個以速度取勝的公司;而他內部快速膨脹的團隊,又何以能手眼協調,有效運作?郭台銘應該是個高效益的經營管理者,而他的經營奧秘何在?

有亞歷山大大帝般的企圖心

這一連串的疑惑,隨著一個偶然的機會而解開,鴻海內部流傳的一百餘則「總裁語錄」,道盡了一切,我確定了一件事:郭台銘是台灣五十年來僅見的經營奇才,魄力與能力都是我淺薄的識見中的第一人。

先談魄力,魄力解釋了鴻海的快速成長、永不停息。語錄第一二八則:「成長來自什麼∣胸懷千萬里」;語錄第一三○則:「心胸有多大、舞台就有多大」;語錄第二十二則:「真正的英雄,是戰死在沙場的人,而不是來領勳章的人」;語錄第一一五則:「除非太陽不再升起,否則不能不達到目標」。

從這些話,我看到古代亞歷山大大帝的身影,郭台銘用想像構築了他的企業舞台,台灣只是起點,他的隊伍要到達他所能想像的地方,而且一定可達成、要達成,否則絕不終止。

大多數的台灣企業家,以台灣做舞台,也以台灣為限制,但郭台銘心中無懼,以意志為方向,他的舞台是世界!

能力來自於細節的累積

看起來戰鬥也是他的樂趣,崇拜馬革裹屍的英雄,這說明了「鴻海再大,仍太小」是郭台銘心中沒說出來的話。或許在最近的電視訪問中,他提出「鴻海上兆,我就要走」的退休預言,是他可以接受的目標。

「魄力」與「想像力」只是起點,「能力」則是郭台銘帶領鴻海走到今天的關鍵。

語錄第一二八則:「心思細如絲」,是郭台銘能力的原點,一切從細節出發,把細節做好。語錄第十八則:「關鍵(KPI):魔鬼都藏在細節裡」;語錄第一三四則-「對事情的觀察:望遠鏡/放大鏡/顯微鏡」。在整個郭台銘經營語錄中,我們處處看到他從細節著墨,也仔細研究細節,親力親為帶領鴻海團隊追根究底每一個細節的痕跡。

不論是企業經營四大管制:工管、品管、生管、經營到生意型態,到PC產業技術問題,到HR人資管理,他都有他獨到的觀察和洞見,我們不能想像以他這樣規模的老闆,竟然能如此清楚每一個作業流程的細節,唯一的解釋是:鴻海成長太快,他脫離黑手老闆的時間很短,親力親為每一項細節的經驗猶新。

拆解經營問題中的十面埋伏

一旦老闆知道每一個細節,組織裏就沒有任何模糊的空間,工作者更沒有打混的空間。這就是鴻海讓外界感覺一切上緊發條的原因。

追根究底問細節,只是郭台銘的態度,其方法則是「拆解」與「簡化」。他把每一件事、每一個流程都予以拆解。例如,語錄第六十則:解決問題九大步驟。第十三則:系統七分類。第六十一則:生管系統七階層次。第六十六則:主管每天要做的四件事。第十九則:「桌子的顏色」,更清楚看到郭台銘的拆解事物的邏輯,他認為:桌子的表面是我們看到的顏色,但要真正瞭解,只有把桌子拆解才知道。

問題、流程經過拆解之後要再簡化。語錄第五十五則:簡化的對象包括:客戶、料號、流程、管理策略與組織架構,簡化的方法則是簡單化、合理化、標準化……任何事情經過簡化後,就變成響亮的口號。例如:第一二○則:成功的途徑:○抄、○研究、○創造、○發明。再如:第一三二則:三對—選對的公司、選對的人、做對的事。

仔細想想這不就是尋找Best Practice(最佳實務)的過程嗎?鴻海不只在流程上如此,在觀念、思考、方法上也都要有共識,這或許是「總裁語錄」的最大功用吧!

獨裁,卻害怕成功!

郭台銘用「細節、拆解、簡化」最後建構標準化的制度,而落實制度的基本精神則是紀律。第九十五則:工廠管理的理念∣走出實驗室,沒有高科技,只有執行的紀律。第一一五則任何事都要誓死達成任務。至於郭台銘本人,則像是政治學上的獨裁者-「哲君」。第一一七則:領導者須有獨裁為公的決斷勇氣。郭台銘的指令,貫穿鴻海的每一個角落。每天主管向郭台銘的報報,被稱做「面聖」、「上朝」,而這個哲君,則帶領鴻海一再創造奇蹟,攀登高峰。

不過在語錄中,我們也看到郭台銘的害怕:他害怕成功。第一三九則:成功是很差勁的導師,它給你無知與智慧,成功是失敗的媽媽,輕而易舉的成功則是事業大忌。這說明郭台銘居高思危的態度。

郭台銘也考慮到接班的問題,第二十四則:接班人三要件:品德、責任心肯做事、太聰明者則婉拒。但是鴻海的接班布局似乎只在「條件說」,但真命「太子」尚未出現。

這或許是鴻海最值得觀察的未來。如果郭台銘真的退休,沒有哲君的帝國會如何?郭台銘的語錄提供了過去與現在的解答,但未來,要時間來解答。

RSS的缺點也正是其優點

http://taiwan.cnet.com/enterprise/technology/0,2000062852,20095473,00.htm

David Berlind‧唐慧文  2005/01/07

全球資訊網上的聯合供稿(Web syndication)技術種類繁多。一如諺語所述的情況:標準最棒的地方在於標準太多了。

若真要把RSS 1.0、RSS 2.0(其實接續的不是RSS 1.0版,而是0.94版)、Atom和其他林林總總沾得上邊的網際網路聯合供稿技術理出個頭緒,恐怕需要做碩士論文級的研究。如果在規格的層次上就有問題、而且沒辦法解決的話(依我之見有些衝突是被新聞界誇大了),那麼我們怎能指望第一線的應用會變得容易上手?本文將討論使用者設法把現有技術湊合著用的情形。

我碰到的一個RSS 2.0問題是,網路出版者通常使用不同的慣例,來刊登以RSS(真簡單聯合供稿)系統傳送的資訊。雖然這種彈性正是RSS 2.0最棒的優點之一,但如此一來,把多重RSS feeds標準化以便匯整呈現的負擔,就轉移到閱聽者這一端。儘管終端使用者應用程式(包括RSS閱讀器在內)通常內含人工智慧,可補救所處理檔案格式紊亂不一的問題(這也意味處理RSS的應用軟體前景相當不錯),但我懷疑RSS會不會也證明軟體商要兌現諾言極為困難 — 他們承諾提供為平常人開發的軟體,讓技術生手只用游標和滑鼠點選和拖曳,也能打造出複雜的、交易性(transactional)、伺服器端的應用。

畢竟,RSS是當今最能展現可延伸標示語言(XML)對普羅大眾有何用處的範例,也象徵大多數人與XML最接近的接觸。基於RSS的人氣日盛,大有可能演變成所有資料(不論結構嚴謹或鬆散)賴以採集的主要方式 — 不論用途僅為瀏覽最新的網誌(Weblog)更新內容、檢索電子郵件(嘿,那不就終結垃圾郵件了嗎?),或是透過複雜的工作流程傳遞交易資料。就此而論,RSS也可能被當作「點選式程式設計」(point-and-click programming)的一大試金石。

為了鼓勵透過ZDNet網誌領域進行線上協同作業,我們已建立一個內部的Wiki。日後或許內容會更豐富,但目前我們的Wiki首頁比較像是共享的書籤陳列室。我倒是建了一個次級網頁,展現出多重使用者系統的威力:在上面可把我所屬工作群組必須追蹤的網誌一覽無遺。我用Twiki標題外掛程式把以RSS為基礎的聯合發稿內容匯整到同一網頁,基本上該網頁相當於在網誌領域的一個角落設立入口網站,以便我們觀察我認為不該遺漏的網誌。我稱之為我們的雷達。

我加入擷取自Robert ScobleJonathan SchwartzTim BrayBob FrankstonSlashdotGroklaw等網誌的內容,不久之後,ZDNet.com副總裁Stephen Howard-Sarin又在這個網頁添加了一些,取自於Dan BricklinJon UdellDan GillmorPhil WindleyDoc Searls等人的網誌。儘管這還稱不上是「點選式伺服器端程式設計」,我認為已十分接近。

但我不滿意這個外掛程式預設的內容擷取格式,以及在網頁上呈現的方式。所以,為牽就我們的需要,我在外掛程式之外添加了一些選擇參數(optional parameters),以確定最後顯示出來的網頁是純文字(為了效能起見),而且只從各種內容來源擷取最新的五則標題。以圖示來呈現這類選擇參數、自動產生編碼,並且把程式碼嵌入網頁,這些正是我期待「點選式程式設計」能夠為我代勞的事,而不是凡事都得用硬碼(hard-coding)方式來做(我目前的作法)。

在Wiki普遍成為政治正確的作法之際,Howard-Sarin也在添加網誌內容時仿效我採用的格式。由於欠缺更簡單易用的工具,他只用剪貼方式把程式碼拷貝過來,然後提供不可或缺的替代品。對一群非專業程式設計者來說,能做到這種地步已經很不錯了吧?短短幾個鐘頭,我們兩人同心協力製作了一個入口網站,提供有意義的資訊,而且會隨每次網頁重新整理更新內容。現在,就等其他ZDNet使用者共襄盛舉,把他們喜愛的、不重複的網路內容丟進這個網頁即可。

可是,還有個問題。有些內容無法正常顯示,害得我耗費比原訂計畫更多的時間。比方說,Jonathan Schwartz網誌裡的每一篇內容,都以異於他人的方式呈現 — 在他以XML為格式的內容中,每一篇不重複的網誌內容(稱為一個item) 都省略連結欄(link field)。大多數的內容,例如擷取自ZDNet的本文,都用連結欄來儲存通用資源識別碼(URI),以直接連上個別的item(就本文為例,指的是一篇新聞報導,而不是網誌裡的一則日誌)。省略掉連結欄,Schwartz依賴GUID (全域唯一性識別碼,讀音「gwid」) 欄附帶的選項(稱為「permalink」),來儲存常駐的連結,以連上個別的網誌文章。這麼做是有道理的,因為要跨越整個網際網路連上某則特定的內容,使用專屬的連結是你所能找到、最獨一無二的方法。或許你能想出別的辦法,但何必花這個腦筋呢?基於此理,幾乎人人都把導向自己每則內容的直接連結存在GUID裡。對許多人來說,這意味在GUID裡找到的資料,與在連結欄(若他們採用的話)裡尋得的資料,是一模一樣的。

這些很重要嗎?嗯,就我而言,我覺得很重要,因為我試著想出一種可輕易重複使用的外掛程式參數組合(用「點選式程式設計」術語會稱之為「物件」,但我要等到親眼目睹才會信以為真) ,來建置我們的入口網頁,而那套組合要能夠用同一方式對待本網頁所觀測的各個內容來源。如果某物件在「普通人用的點選式程式設計」現實世界裡只是偶爾才管用,那麼沒多久,一般人就會棄滑鼠投降。

參照TWiki文件編寫採用連結欄的範例,我開始嘗試用它來提供入口網站使用者一個可回歸原始內容出處的連結。這很合理,不是嗎?然而,一旦連結欄被省略,如同Schwartz網誌的情況,即便我在入口網頁上一一附上連結,也不過是死的連結。為了研究這個問題,我進一步探討RSS的弱點 — 我不認為其他只為體驗網路聯合供稿威力的使用者必須探究得這麼深入。我發現,如果Schwartz的網誌把每則內容專屬的URI存進GUID的話(他是這麼做的),那麼我就可以倚賴GUID的目錄把使用者導回內容的原始出處。就可重複利用的能力而論,我考慮把這種作法全面套用在我們監看的所有內容上。

以下這一段是RSS 2.0的規格範例,由此可說明連結與GUID未必相同,也證明我傾向採取的解決辦法是對的:

「有關<guid>s的一個常見的問題是與<link>s該怎麼區分,不就是同樣的東西嗎?沒錯,在內容系統裡是如此,但在其他的系統就不見得。在某些系統,<link>s是連上網誌篇章的permalink。但在別的系統,每一個<item>是全文的摘要,<link>s指向該文,而<guid>s則是連上該則網誌內容的permalink。不論在什麼情況下,都建議你提供guid,並儘可能讓它以permalink呈現。這麼做可避免匯整器重複擷取相同的item,儘管這些item可能因為有修改過而有所不同。」

以上是專家建議的最佳範例,無疑是大勢所趨,也隱約暴露出許多內容供應系統依循不同慣例的問題。這正是我遭遇的問題。現在,可重複利用性已被判出局,而我甚至還沒開始嘗試用滑鼠作「點選式程式設計」咧。就每一個我加進入口網頁的內容來源而言,現在我會先研究它的XML,再決定該用哪一套參數。

但GUID相對於link的問題,並不是我們面對的唯一挑戰。

有些內容供應feeds,像是Dave Winer的Scripting News,也丟出一個變化球。Winer的網誌文章不附標題。這是個麻煩,因為要建置含20多個出處、一目瞭然的入口網站,我們決定最簡單的作法便是只顯示item的標題,然後附上導向全文的連結(使用前文提到的item連結或GUID,視哪一種比較適用而定)。但是,就Winer的XML來說,能擷取的東西有限。沒標題可選,只能擷取其他三種 — GUID、item的發表日期(pubDate)、或是item(敘述)的全文。但item的全文長度從寥寥數字到堂堂數段不等,沒道理拿它來當作超文字連結(hyperlink)。

如同Schwartz的網誌,Winer的GUID也是連上全文的URI。換言之,能供我們用來當連結的文字只剩下發表日期。顯然Mozilla.org對無標題item的感受和我們一樣。Firefox瀏覽器採用一種稱為Live Bookmarks的功能,用來追蹤RSS feeds;該瀏覽器在碰上無標題item時,為了產生可點選的內容連結選單,也提供發表日期作為連上原文的線索。事實上,在處理規格不一的RSS應用方面,Firefox的表現一級棒,就連碰上在同一網誌裡有的item附標題、有的又不附標題的John Robb頻道時,也能機動應變。把Robb的網誌加入Firefox的Live Bookmark後,產生的選單即顯示出Firefox從每一item就地選材,有的擷取發表日期,有的擷取標題。這印證前文所言,就網路聯合供稿而論,供應端所做的選擇,其衍生的後果一概由閱聽者這端承擔。換句話說,控制權從供應者這方轉移到內容出版者這方。值得注意的是,此現象似乎與全球資訊網的走向背道而馳。(基於Internet Explorer使用者眾多,和許多網站用Firefox無法正常顯示,以後見之明來看,即可驗證供應端總是會順應需求端來作調整。)

同理,再度驗證通常軟體會代使用者做複雜的決定和演算法,Dave Winer的網站內容匯整器也作了令人讚許的貢獻,就是把各式各樣的內容慣例標準化,形成單一介面,再透過該介面把源自不同頻道的文章攙雜在一起,按照匯整器擷取的時間倒序排列。比方說12點15分時,某頻道可能顯示出五則,但其中最早刊出的一則也許不比排在它前面、出自另一頻道的文章來得新。不過,不論是哪一則,都是根據終端使用者所在地的時區來顯示發表時間。網路匯整器可不可能自動判知終端使用者的時區,我不清楚;但就Firefox和Newsgator這類美國境內執行的RSS匯整器而言,是辦得到的。看出未來的成長空間了嗎?

起初,我暗地咒罵Winer竟然不附標題。但一旦開始追蹤Winer的網誌後,我就領悟到這種抉擇自有道理。他的網誌只是意識流似的日誌。人在思考時,會先下標題嗎?不會吧。Winer不會,也無此必要。他和別人的網誌之所以可讀性高,與附標題的新聞報導與眾不同,就是因為網誌就像日記一般。這些網誌有許多篇章是想到什麼就援筆立就,若是作者必須停下來先為每一篇定個標題,可能就跟不上奔馳的思緒。這些是特例。另一人氣鼎盛的網誌,作者是微軟的Robert Scoble,就不管每則篇幅多短,都一律冠上標題。以最近談微軟執行長Steve Ballmer評論蘋果iPod的那一則為例,標題幾乎與全文等長。如果他給網誌文章下的標題少一些,或根本不定標題,或許我們更能深入了解Scoble腦子裡的想法。

為了建置一套可重複利用的參數(以便別人只需剪剪貼貼即可),我不得不緊盯著Winer的內容,我愈是瞪著它瞧,就愈發現自己掙扎於兩種選擇之間的取捨:該用發表日期作為我們TWiki架構入口網站的連結文字呢,還是乾脆把他的全文(儲存在各個item的敘述欄內)下載並顯示在我們的入口網頁呢?畢竟,我們內容顯示的程度僅止於最新的五則,而Winer每天定期刊出五則以上,所以若是列出一串發表日期,除了告知每一則何時刊出以外,提供的資訊聊勝於無。我們真正需要的訊息,是全文的內容為何。碰到Winer這種不附標題的內容,我們唯一的選擇,就是擷取全文(端視外掛程式允許的容量而定)。

事實上,一口氣完整的擷取(包括GUID、敘述、發表日期和某來源提供的其餘材料),逐漸看來是最適合我們入口網站的通用方法。就這麼搞定。我總算可以回頭做我日常的工作了吧?哎,還不行。

誠如Winer告訴我的,那種作法可能也行不通,因為和許多網誌不同,新聞網站通常在每篇報導的敘述欄裡提供摘要,而不是完整的全文。更糟的是,就算也把敘述抓過來,我發現TWiki的標題外掛程式無法處理超文字標示語言(HTML)格式,而網路新聞幾乎清一色都用這種格式編寫。

這個實驗計畫就像舊時卡通裡會漏水的水壩。就在你以為所有的漏洞都堵好了的時候,另一處漏水又泉湧而出。最後我只好許願,但求聰明人發明只要點選一下就可解決問題的辦法,就像軟體開發業者向來承諾的那般。只是,就現在的進步速度來看,我懷疑那可能要再苦等數年。

但本文仍算是一篇談論RSS優點的報導 — 也附帶闡述RSS特有的彈性為什麼會讓企圖在亂中求序的人士(比方說軟體開發者)日子難過。畢竟,混亂本是網際網路的常態。

老闆,你會給我多少年終獎金?年終獎金,大家猜一猜

Smart智富月刊 Vol. 200501 January, 2005 文◎施禔盈

2004年上市公司獲利大躍進,較2003年成長六成,特別是航運、鋼鐵等傳統產業,業績更是拉出長紅,果然員工可以領到超大包的年終獎金。每到年關前一個月,員工總是開始猜一猜會拿到多少年終,其實公司今年賺不賺、自己表現好不好,都會影響老闆怎麼發。

「今年台鹽至少領12個月年終獎金、中鋼絕對會多過去年的10個月、成衣廠聚陽實業上看10個月……」,看到類似的新聞,除了羨慕之外,相信大家一定會問:那我可以領到多少年終獎金呢?

辛苦了一年,每個「吃人頭路」的員工多少都會期待領個大紅包,不過,產業景氣處在「好年冬」、還是「歹年冬」,差異可是很大的。過去,電信業年終獎金曾經出現過11個月讓人眼紅的數字,不過,這兩年都維持在2∼4個月,已經回歸平淡。

鋼鐵、航運員工,「做一年賺兩年」

倒是傳統產業開始鹹魚翻身,從2003年開始,就不斷傳出令人艷羨的數字,與過去的「死豬價」大不相同。以中鋼為例,2003年稅前盈餘創下450億元歷史紀錄之後,除了固定一個月的年終獎金外,激勵獎金、產銷獎金加起來,員工年薪可以達到22個月的水準。

去年中鋼業績再度寫下歷史新高紀錄,獲利有機會超過600億元,於是中鋼員工身價再升一級,成了「做一年賺兩年」的傳產新貴。不只鋼鐵業出現「新貴」,去年包括航運、紡織、房地產等傳統產業,因為業績拉出長紅,年終獎金也都叫人妒羨。陽明海運2003年獲利66億元,去年獎金已經夠大包了,達到10個月,去年獲利再成長20%以上,因此今年陽明的員工也是躋身為「做一年賺兩年」的俱樂部。

另外,由於去年散裝航運市場大好,裕民獲利呈倍數成長,若以2003年每股純益3.7元,公司即大手筆發放逾六個月獎金來看,2004年獲利挑戰一個資本額的裕民,旗下員工荷包肯定滿滿滿。

媒體傳播、文教出版,繼續度寒冬

相較笑呵呵的鋼鐵、航運業員工,媒體傳播、文教出版業就繼續苦哈哈了。1111人力銀行副總經理吳睿穎提到,早年無線老三台相當風光,發放10個月年終獎金沒問題,但在有線台崛起、競爭白熱化後,年終獎金卻是一年不如一年。電子媒體不好,平面媒體也同樣在度寒冬,據了解,中時集團因為不賺錢,已經有兩年沒有發放年終了。不過,去年景氣略為回升,今年中時的員工終於有紅包可領,但是紅包並不大,平均0.8個月。至於文教出版業面臨的大環境,就更嚴峻了。吳睿穎表示,現在是作者比讀者多的年代,出版業賺錢不容易,既然如此,發不出年終獎金也就不足為奇了。

獎金多不多,看公司賺不賺

年終獎金發不發、發多還是發少,與公司賺錢與否有關。以裕隆集團來說,年終獎金的計算方式為:本業營業利益×15%,而營業利益代表的是本業獲利能力(排除營業外收支)。裕隆以此為發放標準,顯然是為了激勵員工在本業好好努力,因為公司賺愈多、員工年終獎金就愈有看頭。

再看信義房屋的發放模式,是以當年獲利的三分之一做為員工獎金,但是包括業績獎金與年終獎金。去年信義房屋員工平均可拿到四個月年終獎金,公司表示今年會更好,這當然是受惠去年獲利成長之故。

電子業中的悠克,也訂有明確的獎勵模式,除了固定的兩個月年終獎金外,如果當年度出現超額盈餘,也就是業績超過預算目標,年終獎金便會跟著長大。不過,公司表示,去年業績剛好達到目標,所以今年就是兩個月。其實對於電子業來說,年終獎金向來差異不大,因為不管景氣好壞、公司賺不賺錢,多半都是固定發放1∼2個月,因為電子業普遍低底薪,重頭戲是分紅配股。至於分紅配股好不好,這又與公司賺不賺有關了。

採保障年薪制的企業還包括外商公司。一般來說,外商並沒有發放年終獎金的習慣,所以通常都把「保障年薪14個月」的其中兩個月,視為公司所發放的年終獎金。當然在保障年薪之外,企業會根據營運狀況,額外發bonus(紅利)。所以說來說去,獎金豐不豐厚,不用猜,得看景氣臉色及公司獲利狀況。


公司賺錢,年終獎金大包一點,那麼公司不賺錢呢?吳睿穎指出,台灣的企業文化重人情,雖然勞基法沒有明確規定年終獎金怎麼發,但根據過去所做的調查,尤其前幾年景氣相當低迷的時候,很多老闆還是表示,再苦也要發年終獎金。

倒是今年勞退新制登場,因為公司每月得固定提撥薪資的6%,做為員工退休金,雇主負擔增加,今年恐怕會有一些公司藉由減少發放年終獎金的模式,讓員工知難而退、自動離職。

前段班員工的獎金,至少是後段班員工的2倍

不過,如果是績效優等的員工,根本不用擔心這個問題,因為公司很少再是齊頭式平等,大家都拿一樣的獎金,主要是看員工貢獻度。工信工程董事長陳煌銘就表示,員工獎金多寡,完全是看績效,績效好的員工,公司還會發放股票做為獎勵。這兩年竄紅的東森購物,據了解,年終獎金基準為2∼3個月,但是優等員工可以拿到五個月年終,相差近一倍。再以金融業為例,雖然已聽聞今年年終獎金有機會比去年的4∼10個月來得多,不過,究竟是拿4個月還是拿10個月,也是得各憑本事。特別是在第一線衝鋒陷陣的業務員,紅包一定大過內勤作業人員。

去年景氣回溫,不少行業獲利都有長進,預期今年年終獎金會比去年來得好。當然選對行業、表現優異,能夠「做一年賺兩年」是再好不過。但轉個彎思考,就算沒有令人欣羨的獎金可領,但如果可以好好打理每一年拿到的年終獎金,讓年終獎金可以繼續生出錢兒子,會比期待老闆更慷慨來得實際,後面的「投資篇」將告訴你答案。

*********************

葉凌棋(永慶房屋總經理):最優與最差員工,獎金差距最多到10個月

年終獎金本來就是用來激勵該年表現優異的同仁,因此發放標準也會因人而異,差距很有可能從1∼10個月不等。永慶不論公司賺不賺錢,每年平均都有1∼2個月年終獎金,也是對同仁的一種承諾。

對於表現優良的業務同仁,公司會給予多元鼓勵,包括海外旅遊、每月依據業績發放的績效?金,以及年終獎金等。去年我們公司開放加盟,全省積極拓點,總體家數已成長至201家,業務同仁增加至1860位,但其中只有約1%、10∼20位的員工有機會拿到60萬元的大紅包。

針對各區域間的銷售競賽,也會提供一筆獎金,像是前年板橋成長快速、表現優異,該區域店長年終獎金就高達10個月。2004年則是以大安、板橋及雙和表現最優,區域內的店長,個個都有機會拿到10個月的豐厚獎金。

The Five Dysfunctions of a Team: A Leadership Fable

by Patrick M. Lencioni “Not finance. Not strategy. Not technology. It is teamwork that remains the ultimate competitive advantage, both because it is so powerful and so rare…"

Editorial Reviews

Amazon.com
Once again using an astutely written fictional tale to unambiguously but painlessly deliver some hard truths about critical business procedures, Patrick Lencioni targets group behavior in the final entry of his trilogy of corporate fables. And like those preceding it, The Five Dysfunctions of a Team is an entertaining, quick read filled with useful information that will prove easy to digest and implement. This time, Lencioni weaves his lessons around the story of a troubled Silicon Valley firm and its unexpected choice for a new CEO: an old-school manager who had retired from a traditional manufacturing company two years earlier at age 55. Showing exactly how existing personnel failed to function as a unit, and precisely how the new boss worked to reestablish that essential conduct, the book’s first part colorfully illustrates the ways that teamwork can elude even the most dedicated individuals–and be restored by an insightful leader. A second part offers details on Lencioni’s “five dysfunctions" (absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results), along with a questionnaire for readers to use in evaluating their own teams and specifics to help them understand and overcome these common shortcomings. Like the author’s previous books, The Five Temptations of a CEO and Obsessions of an Extraordinary Executive, this is highly recommended. –Howard Rothman

Product Description:
In The Five Dysfunctions of a Team Patrick Lencioni once again offers a leadership fable that is as enthralling and instructive as his first two best-selling books, The Five Temptations of a CEO and The Four Obsessions of an Extraordinary Executive. This time, he turns his keen intellect and storytelling power to the fascinating, complex world of teams.

Kathryn Petersen, Decision Tech’s CEO, faces the ultimate leadership crisis: Uniting a team in such disarray that it threatens to bring down the entire company. Will she succeed? Will she be fired? Will the company fail? Lencioni’s utterly gripping tale serves as a timeless reminder that leadership requires as much courage as it does insight.

Throughout the story, Lencioni reveals the five dysfunctions which go to the very heart of why teams even the best ones-often struggle. He outlines a powerful model and actionable steps that can be used to overcome these common hurdles and build a cohesive, effective team. Just as with his other books, Lencioni has written a compelling fable with a powerful yet deceptively simple message for all those who strive to be exceptional team leaders.

See all Editorial Reviews