2011年10月28日

商業周刊::你的誠信值多少?[何飛鵬]

(摘自商業周刊第1146期2009.11.9-11.15)

我確定誠信是有環境限制的。人在順境中、在正常的情境下,人可以守住誠信。但如果社會秩序失控、外部的制約失效,人還能守住誠信嗎?又如果一個深陷困境,在造次顛沛之際,人還能守住誠信嗎?

我也確定,誠信是有規則限制的,對小錢的誘惑,我們可能無動於衷,但是如果誘惑的金額變動:十萬、一百萬、一千萬、一億、十億...,如果拿不拿都沒有人知道,也不會有法律的制約,只剩下我一個仁自己對誠信的堅持,那我們會在哪一個金額失守呢?這個金額就是每一個人誠信的規格。

不要太相信自己的道德,不要太自認自己的誠信,誘惑會包裹著各種人性弱點的糖衣,在每一個人最脆弱的時刻,趁虛而入。在每一個人還沒面對考驗時,仔細分析一下,自己的誠信值多少吧!

商業周刊::最大企業落難,芬蘭竟敢不救

(摘自商業周刊第1233期2011.7.11-7.17)

事實上,我們不能,也不會決定,誰該在未來佔有一席之地,而且,誰知道好主意會從哪裡來?

種子撒多了,總有大樹長出。

責任不再是選定一棵大樹費心栽培,保護它不受風吹雨打,而是,不斷撒下創新的種子,讓它在森林長大自然成長,並由市場決定,誰可以繼續存活。

2011年10月27日

商業周刊::6大常勝法則害慘諾基亞

(摘自商業周刊第1233期2011.7.11-7.17)

諾基亞沒落,不只是手機產業的競爭浮沉,更深的意義是,當典範轉移加速來到,過去的成功思維,需要常常重新檢討,不只企業,甚至個人也是如此。

以前,我們學到的是要貼近市場,要專注,不斷提高競爭門檻,加強核心競爭力,就能基業長青。真的是如此嗎?

「台灣還停在,把事做好,不斷改善的思維,」...諾基亞就是這樣失去戰場的;未來比的是「誰能用想像力,重新制定遊戲規則。」這是一場更難的戰爭。

1.聆聽消費者,就能找出大賣的新產品?

諾基亞緊守聆聽消費者的老方法,但是蘋果的方法,卻是「你看,世界照我的方式走。」

「如果你太照顧你現在的顧客,就很難拋開核心僵固,」...核心僵固的意思是,當一家公司堅守自己原有的核心能力太久,沒有培養新的能力,核心能力可能變成毀滅公司的要素。

過去太成功或孤芳自賞,都可能陷入核心僵固的困境,錯過重要改變的時機。

看到趨勢不難,難的是改變核心能力,重寫遊戲規則。這類創新,既然過去不存在,「問消費者是問不出來的。」

2.打敗第二名,就能穩坐第一名寶座?

這種比名次的邏輯要重新思考了。...光看排名是「只有在靜態,變化沒那麼大的情況下才適用。」如果碰到跨界對手,光看市占率,會變成競爭時的盲點。

像以前,統一只要贏味全,就能在台灣做得很好,沒想到康師傅在大陸做起來,反攻台灣。「對統一來說,這個對手是憑空冒出來的。」...「除了深化,拉大和競爭者的差距,還是要想未來的敵人,」...很多成功者的問題是,對未來投資太少,沒有花精力與資源研究還不在排行榜上的新對手。

3.打仗,當然要找一直贏的戰將主導才對?

典範轉移時代,連傑出的定義都改變,過去有效率,能省成本才算傑出,可是只專注在成本和效率上,習慣沿著既有的成功模式發展,遇到破壞式創新時,同樣手足無措。「你建立的核心能力越強,築起的牆越高,要跳出來越困難。」

...未來領導人的必要條件,是要有新世代產品開發、破壞式創新的經驗,「年輕時去嘗試、去壯遊,會更有想像力,即使失敗都無妨,」少了自己摸索這塊,當遊戲規則一改變,隨即沒頂。

4.身為老大就不能放棄當老大?

一旦遊戲規則改變,最好的方式不是跟隨別人,而是重新定義出下一個破壞式創新。

「忘記力(unlearn)很重要,」...成功,通常都是天時、地利,「但是這些要素,很可能不會再來,」面對新挑戰,須忘記自己過去的成功,擁抱新的條件、環境,重新思考,才可能重返舞台。

5.身為領導者,跟我合作的,也要是一百分?

諾基亞面對的是「分母的困境」,公司越來越賺錢後,再也沒有不賺錢這個選項,習慣了一支手機賺兩百元,反而不知如何面對一支手機只賺五元的低價手機。

低價手機讓市場慢慢產生質變,山寨機從另一頭侵蝕諾基亞的客製化能力,「這個模式是集體客製化(Mass Customization),」...山寨機讓千千萬萬人來幫你做研發,更貼近用戶,「八個喇叭,讓某個地區農夫耕田也聽得到鈴聲的農民機,因為量有限,諾基亞願意做嗎?」...

現在,領導品牌不再只要思考「怎樣推出更好、更貴的產品,」而是一百分的產品能賺錢,二十分、三十分的產品照樣能賺錢。

6.營收獲利創新高就代表公司沒問題?

...美國《彭博商業週刊》(Bloomberg BusinessWeek)用的四個排名指標,「營收成長率、獲利成長率,還有股東權益報酬率、每股盈餘」放在一起看,才能看出公司價值,...市值比營收,更能反映一家公司的真實價值。

「公司不是不朽的,樹長不上天,公司也要面臨人性、組織上的挑戰。」...現在企業老大面對的難題是,一個沒有地圖、指標的新世界就此展開,上路之後,連對手是誰,都要你自己定義。

商業周刊::手機巨人諾基亞為何倒下?

(摘自商業周刊第1233期2011.7.11-7.17)

高效率的成本控制思維,殺死了諾基亞該有的創新。

今日,若我們不再僅能依循自己的強項而行,那麼,又該如何適從?又怎麼能知道,自己的強項已經不適用於今日?這真是兩難的問題。

沒有人能自誇當我們面臨諾基亞的處境,會比他們更能解決問題。我們只能更謙虛來學習諾基亞的教訓。

當戰場不斷在改變,原有的優勢不一定總能適用在新的戰場裡,甚至反而會成為束縛,「忘記力(unlearn)變得很重要。」

在《創新的紀律》(The discipline of innovation)一書就說,把過去最擅長、最核心的忘掉,才能很快學到新東西。

過去的管理學教導我們,在戰場上,要專注核心,以把握機會消滅對手。但現在的動態競爭理論卻是在談:我們要會把握機會放棄自己的優勢,以創造新優勢!

諾基亞犯的錯,就是把自己的優點極大化後,沒留餘地讓自己冒險,最後,成為一百分的輸家。

擺脫成功的慣性當然難,畢竟,若非它讓你成功過,你也不會養成習慣。

商業周刊::微笑球后高雅妮,3招搞定壓力

(摘自商業周刊第1233期2011.7.11-7.17)

如能一步一腳印、化整為零的做好每一個步驟,排山倒海的壓力就會紓解不少。

只要參加比賽,運動員就會有勝負成敗的壓力,這是「宿命」。克服壓力的唯一方法是:習慣它!

選擇和壓力做朋友,而非視若無睹或逃避。

在思考與回答的同時,等於「自我提醒」。

商業周刊::大膽想,大膽做,錯中學[何飛鵬]

(摘自商業周刊第1233期2011.7.11-7.17)

大膽是企及顛峰的要件,大膽也會隱藏危機與錯誤,但在犯錯中學習,則是成長快速的要件。

商業周刊::那幅倒過來的地圖[孫秀惠]

(摘自商業周刊第1233期2011.7.11-7.17)

改變一個人的想法,跟改變他的品味一樣難。即便很小的改變都不容易。

諾基亞今日的處境,不在於它不努力把事情做好,而在於,它少了「忘記」:忘記自己的成功模式,忘記過去看世界的方法...。

沒有人能自誇當我們面臨諾基亞的處境,會更有辦法。我們只能:更謙虛。

2011年10月26日

1.4.9-組合關係

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.9-組合關係

組合關係(Composition)是一種特殊的聚合關係,所以它繼承了結合關係,以及聚合關係的「整體-部分」(Whole-Part)的特質,還獨有全然擁有Part物件的特質。系統分析師可以透過檢核下列四項要件,判斷是否採用組合關係:

1.在企業領域的專業概念裡,兩種物件之間有一種固定不變且需要保存的靜態關係。(繼承自結合關係的要件)

2.在資訊化時,系統會用到這些靜態關係,而且必須將它們存到資料庫。(繼承自結合關係的要件)

3.在企業領域的專業概念裡,兩種物件之間有Whole-Part的靜態關係。(繼承自聚合關係的要件)

4.Part物件只能連結一個Whole物件,且Whole物件被註銷(Destroy)時,Part物件必須一塊被註銷。(組合關係獨有的要件)

在基金模擬個案中,定期定額申購是很重要的概念。客戶約定了定期定額申購之後,銀行每月就會依照約定自動成立一筆小額的申購交易,而且每期申購的基金單位數都會被累加在一起。特別的是,自動成立的單期交易沒有自己的憑証號碼,而是共有原先定期定額申購約定時的憑証號碼。

請看圖1-11,針對定期定額申購與單期交易之間的組合關係,系統分析師做了如下的思考:

1.定期定額申購與單期交易之間的關係,固定不變且需要被永久保存下來。(符合上述要件1)

2.由於,定期定額申購與單期交易之間的關係需要被保存下來,所以會被存到資料庫裡。(符合上述要件2)

3.客戶約定了定期定額申購之後,每月就會依照約定自動生成一筆小額的申購交易,所有的單期交易都歸屬於同一個定期定額申購交易底下。兩者之間有著Whole-Part的特質,定期定額申購是Whole,單期交易是Part。(符合上述要件3)

4.每一個單期交易物件只能連結一個定期定額申購物件,且定期定額申購物件被註銷時,單期交易物件必須一塊被註銷。(符合上述要件4)

5.每一個定期定額申購底下,可以有零到多個的單期交易。所以,在單期交易端標示(*),代表一個定期定額申購物件可以連結零到多個單期交易物件。

6.每一筆單期交易,只能隸屬於某一個定期定額申購底下。所以,在定期定額申購端標示(1),代表一個單期交易物件只能連結1個定期定額申購物件。


圖1-11: 組合關係

2011年10月24日

1.4.8-聚合關係

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.8-聚合關係

聚合關係(Aggregation)是一種特殊的結合關係,所以它繼承了結合關係的特質,而且還獨有「整體-部分」(Whole-Part)的特質。簡言之,聚合關係兩端的物件,需具有Whole-Part的關係。系統分析師可以透過檢核下列三項要件,判斷是否採用聚合關係:

1.在企業領域的專業概念裡,兩種物件之間有一種固定不變且需要保存的靜態關係。(繼承自結合關係的要件)

2.在資訊化時,系統會用到這些靜態關係,而且必須將它們存到資料庫。(繼承自結合關係的要件)

3.在企業領域的專業概念裡,兩種物件之間有Whole-Part的靜態關係。(聚合關係獨有的要件)

在我們的基金模擬個案中,有「基金看台」的概念。每一個基金看台可以設定多檔自選基金,如此一來,客戶就可以同時觀看並比較多檔基金的報酬率。請看圖1-9,假設我在彰化銀行、新光銀行、永豐銀行都有申購基金,所以我設定了三個基金看台,這樣就可以同時間觀看這三個基金帳戶裡頭的基金資料。由於,三個基金帳戶裡頭都有申購過安本亞太基金,所以這檔基金會同時出現在三個基金看台中。


圖1-9: 一個Part物件可以連結多個Whole物件

請看圖1-10,針對基金看台與自選基金之間的聚合關係,系統分析師做了如下的思考:

1.基金看台與自選基金之間的關係,固定不變,且在該基金看台被整個刪除,或者某自選基金從該基金看台除名之前,兩者之間的關係需要被永久保存下來。(符合上述要件1)

2.由於,基金看台與自選基金之間的關係需要被保存下來,所以會被存到資料庫裡。(符合上述要件2)

3.基金看台聚集了多檔自選基金。自選基金是基金看台裡很重要的一項元素,而且可以說,如果沒有自選基金,基金看台幾乎也就失去了存在價值。所以,兩者之間有著Whole-Part的特質,基金看台是Whole,自選基金是Part。(符合上述要件3)

4.每一個基金看台底下,可以有零到多檔的自選基金。所以,在自選基金端標示(*),代表一個基金看台物件可以連結零到多個自選基金物件。

5.每一檔自選基金,可以設定在多個基金看台底下。所以,在基金看台端標示(*),代表一個自選基金物件可以連結零到多個基金看台物件。


圖1-10: 聚合關係

商業周刊::隨心所欲自由畫

(摘自商業周刊第1226期2011.5.23-5.29)

放鬆並不一定代表完全放空,看電影、唱歌、跑趴是一種方式,但都是透過外界的聲光刺激,瘋狂過後,有種空虛的感覺。

創作,卻是由內而外自發的,每一筆都在下決定,跟自己對話。

很多人畫完後,反而漲紅了臉,感覺很累,但內心卻很充實。

2011年10月21日

1.4.7-結合關係

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.7-結合關係

類別之間最常見的關係,不是上述的一般化關係,而是此處的結合關係(Association)。系統分析師可以透過檢核下列兩項要件,判斷是否採用結合關係:

1.在企業領域的專業概念裡,兩種物件之間有一種固定不變且需要保存的靜態關係。
2.在資訊化時,系統會用到這些靜態關係,而且必須將它們存到資料庫。


圖1-8: 結合關係

請看圖1-8,針對基金帳戶與申購交易之間的結合關係,系統分析師做了如下的思考:

1.發生任何一筆申購交易,都必須確實記錄在某一基金帳戶底下。申購交易與基金帳戶之間的關係,固定不變,且在該基金帳戶被結清之前,兩者之間的關係需要被永久保存下來。(符合上述要件1)

2.由於,申購交易與基金帳戶之間的關係需要被保存下來,所以會被存到資料庫裡。(符合上述要件2)

3.每一個基金帳戶底下,可以有零到多筆的申購交易。所以,在申購交易端標示(*),代表一個基金帳戶物件可以連結(Link)零到多個申購交易物件。

4.每一筆申購交易,只能登記在某一個基金帳戶底下。所以,在基金帳戶端標示(1),代表一個申購交易物件只能連結1個基金帳戶物件。

2011年10月20日

1.4.6-一般化關係

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.6-一般化關係

系統分析師透過類別定義屬性和操作,所以日後針對同類別的一群物件,就可以使用相同的方式對待它們。不過有時候,這些物件並不是全然相同,可能大部分的屬性和操作相同,但是少部分的屬性和操作卻不同。在這種情況下,類別之間的一般化關係(Generalization)就派上用場了。

現在我們先來看一段模擬情境,體會系統分析師在訪談期間可能遇到的情況,隨後我們才說明如何使用一般化關係。當系統分析師訪談到申購基金的主題時,立即理解到「申購交易」是一項很重要的概念。所以,系統分析師檢核了成為候選物件的兩項要件,我們在前面曾提及:

1.在企業運作過程中,企業人員會使用到的專業事物或概念。
2.而且,在資訊化時,系統也會用到,或者需要保管。

客戶申購基金時,企業人員確實會使用到申購交易的概念,符合前述要件1。而且,在資訊化時,系統也需要保管每一筆的申購交易,符合前述要件2。「申購交易」同時符合上述兩項要件,所以系統分析師將它列為候選物件,並且讓所有的申購交易物件歸屬於同一類別,如圖1-4所示。


圖1-4: 申購交易類別

企業人員說:申購交易有兩種,一種是單筆申購,另一種是定期定額申購。

系統分析師問:這兩種有什麼不同呢?

企業人員答:單筆申購比較簡單,就跟我們平常買東西,一次買斷的情況相同。客戶單筆申購某檔基金100,000元,買斷,我們給客戶申購交易的憑証號碼,交易就結束。定期定額申購,比較像是一種約定,客戶可以跟我們約定每月的15號,自動從指定扣款帳戶支出5,000元申購某檔基金。每月15日定期,每次5,000元定額,指定某檔基金,指定某個扣款帳戶,經過這樣的約定之後,每個月就會定期定額自動支出一筆資金來申購基金。

系統分析師問:那客戶可以更改定期定額的約定嗎?

企業人員答:隨時可以改啊!

系統分析師問:可以更改哪些項目?

企業人員答:可以改扣款日期、投資金額、扣款帳號,還有扣款情況。


圖1-5: 三個申購類別

系統分析師定義出三個申購類別,相較起來,申購交易屬於一般類別(Generalized Class),單筆申購與定期定額申購屬於特殊類別(Specialized Class),如圖1-5所示。

因為,系統分析師把單筆申購與定期定額申購裡,通用的屬性與操作記錄到申購交易類別,所以申購交易類別定義了通用且一般性的屬性與操作。至於,單筆申購與定期定額申購兩者獨有且特殊的屬性與操作,當然還是記錄在兩者自己的類別裡。所以,相較於申購交易的一般性,我們將申購交易歸屬於一般類別,而將單筆申購與定期定額申購歸屬於特殊類別。

系統分析師可以透過檢核下列兩項要件,判斷是否採用一般化關係:

1.在企業領域的專業概念裡,特殊物件必須「是一種」(a kind of)一般物件。
2.多種特殊物件裡,有部分通用的屬性與操作,也有部分獨有的屬性與操作。

上述的「是一種」要件,必須遵守企業概念。舉例來說,我們可以接受「休旅車是一種汽車」,但是很難接受「遙控車是一種汽車」。因為遙控車是玩具,不是汽車,或許說「遙控車是一種玩具汽車」,會比較符合企業領域裡的專業概念。

請看圖1-6,系統分析師經過下列思考決定使用一般化關係:

1.單筆申購是一種申購交易,定期定額申購也是一種申購交易。或者說,申購交易可以分為兩種,一種是單筆申購,另一種是定期定額申購。(符合上述要件1)

2.單筆申購與定期定額申購裡,都需要記錄申購日期、信託金額、扣款帳號、憑証號碼這四項屬性,以及必須執行計算手續費這項操作,這些屬性與操作屬於通用部分。看起來單筆申購確實比較單純,沒有特殊的屬性和操作。不過,定期定額申購就不是這麼單純了,它多了扣款日期、投資金額、扣款情況這三項屬性,以及多了一個約定異動的操作。(符合上述要件2)


圖1-6: 類別之間的一般化關係

在一般化的過程中,我們將特殊類別裡頭通用的屬性和操作記錄到一般類別裡,因此透過一般化關係,特殊類別可以繼承(Inheritance)一般類別裡的通用屬性與操作。由於特殊類別透過繼承,可以直接重用(Reuse)一般類別裡的屬性、操作和方法,節省開發成本。變動發生需要改版時,也只需要改版一般類別,節省維護成本。

請看圖1-7裡的特殊類別,我特別將繼承來的屬性與操作一併列出,而且使用網底區分。


圖1-7: 從申購交易類別繼承而來的屬性與操作

2011年10月19日

經理人月刊::做你最擅長的,其他都交給別人!

(摘自經理人月刊第82期2011.9)

杜拉克認為工作者「不要花時間提升自己表現平平的領域能力,應該集中加強自己的長處,」因為「要把弱點加強到一般水準,比把一流的能力加強到超越一流更耗精力。」

杜拉克:「了解長處只有一種方法,就是反饋分析。」

根據蓋洛普調查,只有20%的工作者覺得自己每天都有機會發揮所長。因為「大多數的組織(或員工)猶如在暗室裡拼湊起來的拼圖,每塊拼圖都是邊緣被磨掉、勉強拼湊上去的。但是,讓一點兒光線進入室內之後才發現,十之八、九的圖塊都擺錯了地方,」《發現你的天才》形容。

那麼,如何發覺自己的天賦和長處呢?《發現你的天才》指出,「天賦會體現在自己喜歡的事情上」;《讓工作自由》形容,發揮長處時,「會覺得彷彿處在時間靜止的『順境』中,毫不費力就表現出自己最好的一面」。這種感受,和苦練卻無法進步的挫折感截然不同。

該書分析,「能力」是「長處」(該書稱為「天賦」)、「知識」和「技巧」的總和。...前者可以透過學習、練習獲得,但後者則是一種天生獨特的能力。換句話說,透過辛勤的練習和學習,只能把一件事做到80分;唯有家上天賦與長處,才可能接近完美。

因此,建立真正能力的關鍵,應該是「順著天賦做事」——找出最主要的天賦,再用知識、經驗與練習把它磨亮。「任何天賦都要回到『紀律』的堅持上,」嚴長壽在《教育應該不一樣》中,附和了這個觀點。

成功,有很多途徑。逆著長處硬拚,是work hard;順著天賦選擇有利位置,才算是word smart。唯有了解自己的長處,才知道自己適合甚麼樣的組織和工作,才知道自己能在甚麼情況下做出貢獻,也才懂得選擇走來最輕鬆、優雅的那一條路,並且周而復始地、自信發光。

2011年10月18日

經理人月刊::溝通是主管或部屬的責任?

(摘自經理人月刊第82期2011.9)

「大部分完美的溝通也許純粹是『分享共同的經驗』,不包含任何邏輯性。」蘇格拉底曾指出,「一個人應該根據他人擁有的經驗,與他人談話。」也就是說,與計程車司機說話,就該使用司機使用的語言,以此類推。

「對人們解釋術語沒甚麼用處,如果這些術語並不存在於他們的經驗中,他們就無法接收這些術語,因為超出他們的認知範圍。」與其對主管大談每件事的細節,不如先思索它對主管有什麼意義。

經理人月刊::不要重新發明輪子!

(摘自經理人月刊第82期2011.9)

這種人家推薦、再去找來看的行為,不但是本能反應,也是很重要的挑書方法,因為書真的多到看不完,但如果有人已經碰過你在工作上遭遇的問題,也構思過解決之道,與其耗費心力得出一個相同的結論,何不翻翻書呢?然後再借力使力,讓這些人幫你過濾出還有哪些更好的書。日本作家本田直之有句話說得有意思,「不是沒時間讀書,而是不讀書,所以沒時間!」因為當你讀愈多書,你愈會發現,你碰過的問題,別人早就都幫你解答過了,就能不必費心去重新發明輪子了!

1.4.5-類別

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.5-類別

「物以類聚」點出了物件(Object)與類別(Class)之間的關聯。針對一群相似的物件,我們本能地將它們視為一類(同一類別)。訪談時,系統分析師聽著企業人員談論某一事物,甚至請他舉出兩三個具體且容易理解的實例,試圖藉由理解且分析這兩三個同類型的實例,定義出適用於這些實例的類別。

簡言之,系統分析師透過分析真實世界中同類型的實例,以便定義出適用於軟體世界的類別。經過設計之後,程式設計師會為這些類別編碼。隨後在軟體系統執行期間,系統內部將遵照各類別獨自的定義,誕生各類不同功用的物件。最後,這些不同類別的物件將呼叫彼此的操作,合力完成各項系統功能。


圖1-3: 基金帳戶類別與物件

所以,一個簡化後的開發程序,以及系統運作情況,大致如上所述。歸結,類別與其物件之間細微的關聯,條列如下:

1.(類別)定義屬性與操作,且所屬(物件)共有這些屬性與操作。

2.雖然同類(物件)共有屬性,可是每一個(物件)卻獨有屬性值。每個基金帳戶物件共有「總成本」這項屬性,可是每個基金帳戶物件的總成本值都不同。請看圖1-3,A基金帳戶的總成本值是100,000元,B基金帳戶的總成本值是200,000元,C基金帳戶的總成本值是300,000元,每個基金帳戶物件獨有自己的總成本值。

3.因為同類(物件)共有操作和方法,所以它們可以做相同的事情,而且有相同的作法。

4.稍後我們還會提到,(類別)也定義關係(Relationship),且所屬(物件)共有這些關係。不過,如同屬性與屬性值的情況,雖然同類(物件)共有關係,可是每一個(物件)卻獨有關係值。

2011年10月17日

商業周刊::成功者沒告訴你的好習慣

(摘自商業周刊第1243期2011.9.19-9.25)

而習慣的巧妙之處就在於,它能使人在一個「無心」(mindless)、自動的情況下行動。美國心理學之父威廉.詹姆士(William James)便曾表示:「我們應該盡可能地將有用的行動自動化、習慣化,而且越早越好、越多越好。」而他如此推論的理由是,當我們越多的行為成為習慣,那麼我們就將更多的認知資源(cognitive resource),分配給更複雜的、有意識的訊息處理。

換句話說,當一個好行為持續夠久成為習慣,自動化的結果便能在無意識下,花最少的心力(mental effort)表現出來,我們也就擁有更多的認知資源,去從事無法自動化的行為,把精力花在刀口上。

根據英國倫敦大學學院(UGL)健康行為研究中心的研究指出,建立一個新習慣,依難易程度不同,需要十八到二百五十四天不等的時間,但平均而言,只要六十六天就可以培養一個新習慣。

商業周刊::蔣友柏連八年下午兩點下班

(摘自商業周刊第1243期2011.9.19-9.25)

一直自稱是「生意人」而非「創意人」的蔣友柏認為,要有規律作息,才能做出適合的創意,「比較規律就不會胡思亂想,」他說,只要把腦袋訓練到可以隨時靜下心來處理問題,這樣自然就有創意。

商業周刊::名律師挑最棘手的先做

(摘自商業周刊第1243期2011.9.19-9.25)

最棘手、最麻煩的事情最先做。

而且,困難或麻煩之事若放著不處理,即使先處理別的事,心還是懸在那裡,影響了做其他事的心情和狀態。黃日燦終於體悟到:「遲早要做,與其遲,不如早。」

幾次嘗試後發現,先做完最棘手的是會有種「輕舟已過萬重山」的感覺,接下來就很順手,因為感覺上再沒有更難的事了。「當你知道這麼做是有利的,並實際享受它帶來的好處,你就可以持續下去。」

只要早半秒鐘到位,就從容很多;晚半秒鐘,註定永遠疲於奔命。

商業周刊::企管大師40年不間斷發問

(摘自商業周刊第1243期2011.9.19-9.25)

能夠四十年如一日的到處向人請教問題,逐漸累積出知識與常識的廣度,憑藉的,就是這種不看清任何一個人,覺得能以任何人為師的心態。

想法都有價值,可能不完整,但都有它的好處。

因為他不僅會問問題,也聽得懂問題,然後透過「摘要回饋」,再回過頭幫學生解決問題。

「對方的答案未必有系統,因為他不是來講課的,」但司徒達賢認為別人願意分享知識,他也應該要整理出簡潔扼要的摘要,「還給人家」。

商業周刊::時尚教母想法一律畫下來

(摘自商業周刊第1243期2011.9.19-9.25)

一個人若沒有沉澱,根本不可能在生活中提煉出更好的想法。

----------
Uniqlo藝術總監佐藤可士和說:溝通品味的方式,就是丟掉自我本位主義,他習慣聽很多人從不同觀點敘述同一件事,等到每個人都說完才發言。

商業周刊::心臟名醫記錄開刀心得38年

(摘自商業周刊第1243期2011.9.19-9.25)

醫學的領域這麼大,人外有人天外有天,並不是今天的人怎麼做,就代表那是對的。過去老師的權威可以被推翻,今天自己的成就也同樣可以被改進,記錄手術心得就是讓自己更好。

商業周刊::PayEasy總座每週練空手道

(摘自商業周刊第1243期2011.9.19-9.25)

人為什麼會改變,自己覺得有好處才會改變,(但)那個機會很少,往往是被逼著改變。

如果你習慣養成的意志不夠堅定,靠旁人支持來推自己一把,也會是改變的第一步。

一個好習慣的養成,可以自覺,也可以靠旁人支持完成,這種幸福的習慣,非但不會讓人有壓迫感;人生,反而更圓滿。

商業周刊::投信老總打太極拳十六年

(摘自商業周刊第1243期2011.9.19-9.25)

一個東西要能持續,一定要它簡單、有效、限制少。

商業周刊::九層塔與羅勒醬

(摘自商業周刊第1243期2011.9.19-9.25)

身邊的事,點點滴滴,本來都有豐富的常識,甚至是知識,只是,沒有留心,就從身邊溜走了。

很多事我們都知道,或者很容易知道,甚至動手去做,但是我們都沒有這麼做,為什麼?

人的心裡之所以不願意去改變,不願意養成一些明明知道對自己有好處的習慣,最主要是人們都喜歡停留在舒適圈。

1.4.4-封裝

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.4-封裝

面對真實世界中的多數物品,我們是「不知」亦能用,多數事件,我們也是「不知」亦能行。當然,我們對多數的事物也不是全然無知,只不過通常是有限度的知。因之,在物品或事件所蘊含的細節都被封裝(Encapsulation)起來的情況下,我們還是可以使用物品、參與事件,毫無困難。

所以,當我們打造軟體物件來模擬真實世界裡的事物時,也模擬了這種封裝特性。由於軟體物件的封裝性,物件之間僅透露足以進行互動的低限資訊。對於物件的封裝性,系統分析師要掌握下列要點:

1.已知操作。物件通常僅對其他物件透露自身的操作,彼此之間透過呼叫(Call)已知的操作來互動。
2.封裝屬性。每個物件封裝著屬性值,不透露給其他物件。
3.封裝方法。每個物件封裝著方法,僅對其他物件透露操作,但不透露其方法。

因此,系統分析師要特別注意,在分析規劃物件的方法時,如果需要與其他物件互動,甚至是使用到物件本身的屬性或操作時,切記要嚴守下列三項要件:

1.不得直接提及物件的屬性。
2.也不得假設物件的執行方法。
3.僅能夠使用到物件的操作。

從上述可以發現,我們為了悍衛物件的封裝特性,犧牲掉許多便利性。好比喝冰飲時不能打開杯蓋,直接暢飲,非得戳一個小洞,透過吸管,小口小口吸取,十分不便。使用吸管有一個好處,不小心打翻時,不會濺得四處都是,然後還得花錢再買一罐。

嚴守物件的封裝性,有一個好處,當需求發生變動而需要改寫程式碼時,變動會被侷限在物件的屬性和方法中,不會起漣漪效應,也不會發生牽一髮動全身的連鎖反應。由於軟體內部的組成物件易於汰舊換新,所以軟體的使用壽命延長,後續的維護成本也偏低,企業因此得到高投資報酬率,不過眼前首先要付出的代價是較高的開發成本。

2011年10月14日

1.4.3-操作與方法

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.3-操作與方法

針對物件的操作,系統分析師還必須進一步探問how,了解操作的實行方法(Method)。簡言之,操作是物件的what,而方法則是物件的how。然而,在我們用程式實作出物件之前,物件是死的,它哪會有什麼方法來執行操作。所以,我們其實是想獲知企業人員慣用的操作方法,然後將人為的操作方法轉移給物件,成為物件的操作方法。

系統分析師訪談企業人員時,主要得獲知方法的執行步驟(Procedure)、所需或者產出的資料、計算公式,以及企業的特殊限制。也許,系統分析師可以參考下列問題,向企業人員提問:

1.您(企業人員)通常都怎麼執行某操作的呢?可以告訴我,主要的執行步驟嗎?(探問執行步驟)
2.請告訴我這些執行步驟會需要使用到什麼資料?以及會產出什麼資料?(探問資料的輸入及輸出)
3.請告訴我這些執行步驟會需要使用到計算公式嗎?(探問計算公式)
4.在執行某操作時,有沒有什麼重要的限制需要注意或遵守的?(探問特殊限制)

假設針對基金帳戶物件的「申購基金」這項操作的執行步驟,系統分析師向企業人員訪談的過程中,可能出現如下述的模擬對話:

系統分析師問:您通常都怎麼執行「申購基金」這件事呢?可以告訴我,主要的執行步驟嗎?(探問執行步驟)
企業人員答:是這樣的,申購基金分為兩種:一種是單筆申購,另一種是定期定額申購。
系統分析師問:誰在什麼時候會決定是哪一種?還是可以同時包含兩種?(判斷是否要拆成兩項操作)
企業人員答:客戶一開始在申購基金時,就得二選一,決定是要單筆申購某檔基金,還是定期定額申購。

(對於客戶而言,單筆申購基金或者定期定額申購基金是兩項不同的目的,所以系統分析師決定將原先的圖1-1裡的申購基金操作一分為二,改成圖1-2的模樣。)


圖1-2: 申購基金操作一分為二

系統分析師問:請您挑比較簡單好懂的一種,告訴我您主要的執行步驟?(探問執行步驟)
企業人員答:都很好懂啦,我就先說單筆申購的情況,好了。客戶告訴我們單筆申購的基金名稱、信託金額以及扣款帳號,那我們這邊只要確認這檔基金有販售,然後客戶指定的扣款帳號裡頭有足夠的餘額可以付信託金額和申購手續費,這樣就可以申購了。確認申購之後,我們會從客戶指定的扣款帳號中,支出信託金額和申購手續費。最後,我們會給客戶一個申購交易的憑証號碼,就完成單筆申購了。

系統分析師記錄「單筆申購基金」的主要執行步驟如下:

1.客戶告知(基金名稱)、(信託金額)以及(扣款帳號)。
2.企業人員確認(該檔基金販售中)。
3.企業人員確認客戶指定的(扣款帳號)裡頭有足夠的(餘額),可以用來支付(信託金額)和(申購手續費)。
4.確認申購之後,我們會從客戶指定的(扣款帳號)中,支出(信託金額)和(申購手續費)。
5.最後,我們會給客戶一個(申購交易的憑証號碼),就完成單筆申購了。

隨後,系統分析師可以請企業人員協助確認這份記錄,同時給予補充。但是,對於單筆申購基金的操作方法還沒訪談完,系統分析師還得獲知並確認輸出入資料、計算公式以及特殊限制。

2011年10月13日

1.4.2-屬性與操作

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.2-屬性與操作

試圖去了解真實世界中任一事物時,有多元的角度可以去探尋,就像佛法有四萬八千法門一般。不過,系統分析師並不需要這麼樣深入了解物件,對於任何一種物件本身,系統分析師只需要針對下列兩項問題去探尋:

1.物件需要記錄哪些屬性(Attributes)?
2.物件可以提供哪些操作(Operations)?

上述的問題可以說的更白話些,或許系統分析師可以向企業人員作如下的提問:

1.某物會記錄什麼資料呢?(探問屬性)
2.某物可以提供我們哪些資料呢?(探問屬性)
3.透過某物,可以讓我們查到哪些資料嗎?(探問屬性)
4.某物可以做什麼用呢?(探問操作)
5.有了某物之後,我們可以拿它來做什麼事呢?(探問操作)

假設我們要開發基金交易平台,來向企業人員進行訪談,期間提到了「基金帳戶」。想像一下,系統分析師跟企業人員之間的模擬對話,大概會像這樣子:

系統分析師問:基金帳戶會記錄什麼資料呢?(探問屬性)
企業人員答:基金帳戶裡頭主要會記錄總成本、總現值、總損益、總報酬率。
系統分析師問:有了基金帳戶之後,我們可以拿它來做什麼?(探問操作)
企業人員答:有了基金帳戶之後,只要裡頭存有足夠的錢,你就可以用它來申購基金,或者贖回基金。


圖1-1: 基金帳戶的屬性與操作

針對物件的各項屬性,系統分析師還需要進一步了解它在企業裡的定義、資料型態(Data Type)、可能的範圍值、或者初始值,更別忘了了解這項屬性是怎麼跑出來的?或許,系統分析師可以向企業人員作如下的提問:

1.可以請您(企業人員)用簡單的一、兩句話,解釋某屬性是什麼嗎?(探問屬性定義)
2.可以請您舉個例子嗎?(判斷屬性的資料型態)
3.請問某屬性有範圍值嗎?(判斷屬性的資料型態以及欄位大小)
3.1可被接受的數字,最大最小為何?(數字型態)
3.2.可被接受的字串,最長最短為何?(字串型態)
3.3.預設的項目,有哪幾個?項目異動的頻率?(列舉型態)
4.請問某屬性有初始值嗎?(探問屬性的初始值)
5.怎樣做才能夠得到某屬性值(Attribute Value)?(探問屬性值的獲得方法)
5.1.請問誰會提供這項屬性值?(鍵入值)
5.2.請問可以向哪裡查詢這項屬性值?(查詢值)
5.3.請問計算公式為何?(計算值)
5.4.請問可有獨特的編碼方式?(流水碼或特定編碼)

2011年10月12日

1.4.1-物件

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.1-物件

真實世界由琳瑯滿目的事物所構成,但並非所有的事物都適合對應成軟體物件(Object)。對於系統分析師而言,候選物件應該同時符合下列兩項條件:

1.在企業運作過程中,企業人員會使用到的專業事物或概念。
2.而且,在資訊化時,系統也會用到,或者需要保管。

系統分析師在訪談企業人員時,可以提出類似下述的問句,以便獲知重要的物件。像是:

1.在執行這項工作時,你們會用到哪些專業概念?(探問物件)
2.你們在執行這項工作時,會需要用到哪些資料?(探問物件)

諸如此類的問句,有助於找到重要的物件。軟體公司可以多向資深的系統分析師蒐集此類的智慧問句,甚至編寫成系統分析師通用的工作手冊。

2011年10月11日

1.4-重要的OO及UML概念

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML

1.4-重要的OO及UML概念

OO是一種較為直覺的設計思維,在設計軟體時,讓軟體世界裡的程式物件對應真實世界裡的具體事物,以此來模擬真實世界的運作情況。觀察真實世界可以發現,真實世界由各式各樣的事物所組成,每種事物都有它特有的結構和行為,而且在聯繫起不同事物之後,還能夠展現出豐富多元的能力。所以,OO軟體也由各式各樣的軟體物件所組成,並且合力提供多樣化的服務,以此參與企業運作過程。

OO概念是UML的基礎,也就是說,系統分析師在學習使用UML的同時,其實就是在應用OO概念。換個角度來看,UML與OO兩者互為表裡,系統分析師腦子裡運用的是OO概念,但是表達出來的需求文件內容,卻是使用UML圖。

UML最大的特色,在於它是個圖形語言,因此享有圖形思考與表達的優勢。所以在本書裡,我們除了要求系統分析師在編寫需求文件時,須以UML圖為主,文字為輔外,還要求系統分析師在訪談及討論會議期間,皆須以UML圖引導整個會議進行,並且以產出UML圖為其會議結果。

1.訪談即是繪製UML圖。
2.討論即是修改UML圖。

想像一下,系統分析師帶著安裝了UML工具的筆記型電腦,到使用者或領域專家的辦公處所進行訪談,訪談的產出就是UML圖。系統分析師啟動UML工具的同時,就是訪談的開始。系統分析師開始動手繪製第一張UML圖,也同步開始請教使用者各項問題,一邊繪圖一邊跟使用者澄清認知,以便完成UML圖。依循這樣的過程,產出一張又一張的UML圖。當這些UML圖都繪製並且經過確認之後,系統分析師列印UML圖交給使用者,並且將UML檔案傳回給公司,完成此次訪談會議。

在訪談記錄正式成為需求文件期間,使用者有任何補充,或者系統分析師有任何疑問,都切記以手上的UML圖為討論依據。同樣地,系統分析師提交文件給設計師之後,如果設計師有任何疑問,需要開討論會議的話,也必須以UML圖為討論依據,沒有準備好UML圖,不浪費時間開無謂的討論會議,與會人員沒有修正UML圖,討論會議不算結束。

在了解OO與UML的相關性之後,接下來我們會介紹幾項重要的OO概念,當然它們同時也是UML裡的重要概念。

2011年10月7日

1.3-UML圖

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML

1.3-UML圖

在本書中,系統分析師將學到兩大類的UML圖:行為類的圖(Behavior Diagrams)與結構類的圖(Structure Diagrams)。

行為圖將引導系統分析師分析且釐清「系統該做些什麼?」系統分析師在繪製行為圖時,可以聚焦在系統多方面的動作,像是系統與使用者之間的互動,或者是某種物件(Object)因為事件的刺激以至於發生某些反應動作,以及一群物件互動完成某項服務等等。系統分析師在訪談期間或結束之後,可以透過這些不同功能的行為圖,獲知系統多方面的行為。

系統分析師主要會學到下列的UML圖,它們都歸屬於行為類:

1.使用案例圖(Use Case Diagram)
2.活動圖(Activity Diagram)
3.狀態圖(State Machine Diagram)
4.循序圖(Sequence Diagram)

結構圖將引導系統分析師獲知「系統的重要組成元素是什麼?」通常,透過結構圖將引導系統分析師釐清企業裡(Business)的專有名詞,以及專有名詞之間的關係,以此做為系統的核心結構。其餘,技術面的結構設計就留待設計師去傷腦筋了,這部分並不是系統分析師的工作職責。

系統分析師主要會學到下列的UML圖,它們都歸屬於結構類:

1.類別圖(Class Diagram)

2011年10月6日

1.2-UML並非萬能

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML

1.2-UML並非萬能

有些系統分析師對UML懷有高度期望,希望採用UML來蒐集及編寫需求之後,可以不再誤解或遺漏需求,或者可以降低需求變動。不難想見,系統分析師經常得面對這些的問題,當然期望學了UML之後,可以一勞永逸地解決掉這些問題。可是UML並非萬能,無法根除這些本質性的問題,不過也不必悲觀,總是有對策可以來處置需求誤解、遺漏或變動的情況。

人跟人的溝通,本來就會產生誤解,更何況使用者與系統分析師的專業背景不同,當然在訪談的過程中,充滿大大小小的誤解,既是在所難免,也就無法避免。再者,人腦並非電腦,談著談著,總是有多多少少的遺漏,無法在區區幾次匆忙的訪談中,明確又清晰地條理分明,這無疑是強人所難。

既然,訪談之中,會有誤解與遺漏,那日後反反覆覆多次地透過電話、電郵、會面來變動需求,或者是經過展示之後,才發現錯誤而變動需求的煩人事件,也就不可抗拒地自然而然地發生了。

雖然,UML無法根除這些本質性的問題,但我們還是有對策可以來面對這樣的現象,試圖減輕系統分析師的工作壓力。對策如下:

1.使用UML圖(Diagram)引導訪談,降低遺漏需求的情況。UML提供10多款不同功能的圖,可以讓系統分析師在訪談過程中,透過多款不同的圖來釐清需求各種不同角度的面貌,降低遺漏。而且,每款圖都有它獨特的組成圖示,在繪製每一個圖示時,都將引導系統分析師提出適時且重要的問題,以便蒐集與釐清需求。
2.快速產出可執行的程式片段,透過展示來突顯誤解。
3.封裝變動,讓需求發生變動時,可以追蹤到變動之處,迅速改版,並且不讓變動起漣漪效應,向外擴散。

所以,在本書裡,我們將要求系統分析師學習多款UML圖,並且在編寫需求時,不僅得產出讓使用者簽字的文件,還得同時產出讓設計師能接續設計的UML圖件。這樣的要求對於系統分析師確實相當為難,但是想要跟使用者確認需求、簽字同意,除了提交使用者能夠看懂的文字(Text)之外,別無選擇。然而,想要滿腦子OO概念的設計師和程式設計師,可以高效率且零誤解地看懂系統分析師產出的需求文件,除了透過具OO概念的UML圖外,目前看來似乎別無它法。

2011年10月5日

1.1-Why系統分析師需要學習UML

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML

1.1-Why系統分析師需要學習UML

系統分析師(System Analyst)的處境相當辛苦,他們往往站在使用者與開發人員的中間,做為兩者之間的溝通橋樑。系統分析師一方面需要向使用者蒐集並釐清需求(Requirements),另一頭又得急忙向開發人員提出清晰且明確的需求。

在專案進行期間,系統分析師除了得請神明保佑自己最好別誤解或遺漏需求外,還得面對使用者變更需求的反覆性格,以及開發人員不願因需求變動而做白工的強硬態度。這一切現象讓系統分析師心力交瘁,焦頭爛額。

在OO(Object-Oriented)與UML(Unified Modeling Language)成了擋不住的浪潮之後,程式設計師(Programmer)大量使用C++、Java等等的OO程式語言,同時也進一步帶動設計師(System Designer)使用UML來表達關於OO設計。所以,系分文件傳到設計師手中之後的第一件事情,便是將非OO文件轉成OO的UML圖,隨後才能進行複雜的設計,並且產出各式的UML圖,交由程式設計師(Programmer)按圖編碼。

然而,非OO的需求文件轉成OO的UML圖,不僅缺乏效率又錯誤百出。許多公司開始意識到這樣的問題,紛紛要求系統分析師學習OO概念,並且採用UML編寫系分文件。如此一來,OO概念從分析開始,經由設計,一路貫穿到實作,溝通零誤差。

UML是一套用來表達OO分析設計的國際標準語言,從1997年發展至今,吸引了相當多的愛用者,也發展出各式付費或免費的UML工具。挑選一套UML工具,做為系統分析師、設計師和程式設計師的工作平台,有助於提高工作效率。系統分析師產出的UML檔案,可以交由設計師添加設計細節,最後再交由程式設計師按圖編碼。