2009年11月30日 星期一

PMBOK的應用-【賣辣椒的女人】


自從肥蝦通過PMP考試後,在工作職場中總有不少長官或朋友常會問的問題就是:「如何把PMBOK的流程應用到專案中?」

大哉問!說真格得,PMBOK的流程從2000年的39個,到2004年的44個,至目前的42個,若加上每個流程的輸入與產出,如何應用到實際的工作中,這已是一個非常的難題,那就更遑論那眾多的工具了。

如何把專案管理知識體系應用到實際的專案,甚至生活中呢?是不是通過所謂的PMP考試,就是一個稱職的專案經理?是不是在特定行業或特定的個案中,是一個良好的專案經理,就代表他永遠都是一個稱職的專案經理呢?

肥蝦我個人的答案是否定的!書就只是書,工具就只是工具,Lessons Learned就只是Lessons Learned,這都是死的,就算PMBOK會四年調整一次,那又代表它能把所有攸關專案管理的常識、知識與特質,清楚描述嗎?

重點還是在專案經理自身的修為、信心與態度,書是死的、考試是死的、而人是活的!因此如何活用、適用、量用、衍用這些死知識,才是專案經理應強加鍛鍊的功課!

肥蝦在網路上看到此篇【賣辣椒的女人】,足以說明肥蝦心中對PMP證照與PMBOK的心態-「生活中的智慧可以被寫成書,但你不能簡單地照著書上寫的智慧去生活,因為生活只能是鮮活而靈動的!不要在智慧中夾雜著傲慢,不要使謙虛缺乏智慧。」


【賣辣椒的女人】

賣辣椒的人,恐怕經常會碰到這樣一個眾所周知的問題,

那就是不斷會有買主問「你這辣椒辣嗎?」
不好回答。答「辣」吧,也許買辣椒的人是個怕辣的,

立刻走人;答「不辣」吧,也許買辣椒的人是個喜吃辣的,生意還是做不成。

當然解決的辦法也眾所周知的經典,那就是把辣椒分成兩堆,

吃辣與不吃辣的各選所需,這是書上說的。
我一天沒事,就站在一個賣辣椒婦女的三輪車旁,

看她是怎樣解決這個二律背反難題的。

趁著眼前沒有買主,我自作聰明地對她說:
「你把辣椒分成兩堆吧,有人要辣的你就跟他說這堆是,

要不辣的你就給他說那堆是。」
沒想到賣辣椒的婦女卻只笑了笑,輕聲說:「用不著!」
說著就來了一個買主,問的果然是那句老話「辣椒辣嗎?」

賣辣椒的婦女很肯定地告訴他:「顏色深的辣,顏色淺的不辣!」
買主信以為真,挑好辣椒付過錢,滿意地走了。

也不知今天是怎麼回事,大部分人都是買不辣的,

不一會兒,顏色淺的辣椒所剩無幾了。
我於是又說:「把剩下的辣椒分成兩堆吧!不然就不好賣了!」

然而,賣辣椒的婦女仍是笑著搖搖頭,

說;「用不著!」又一個買主來了,問:「辣椒辣嗎?」

賣辣椒的婦女看了一眼自己的辣椒,信口答到:「長的辣,短的不辣!」

果然,買主就按照她的分類標準開始挑起來。

這一輪的結果是,長辣椒很快告罄。看著剩下的都是深顏色的短辣椒,

我沒有再說話,心想:這回看你還有什麼說法?

沒想到,當又一個買主問「辣椒辣嗎」的時候,

賣辣椒的婦女信心十足地回答:「硬皮的辣,軟皮的不辣!」

我暗暗佩服,可不是嘛,被太陽曬了半天,確實有很多辣椒因失水變得軟綿綿了。
賣辣椒的婦女賣完辣椒,臨走時對我說:

「你說的那個辦法賣辣椒的人都知道,而我的辦法只有我自己知道!」



我忽然有所頓悟:

生活中的智慧可以被寫成書,

但你不能簡單地照著書上寫的智慧去生活,因為生活只能是鮮活而靈動的!

不要在智慧中夾雜著傲慢,不要使謙虛缺乏智慧。

2009年11月19日 星期四

什麼是知識?-研究方法課堂隨記


肥蝦正在修讀世新的資管在職碩班,這學期修了一門「研究方法」,授課老師為吳統雄老師(http://tx.shu.edu.tw/)。
在第一堂課,老師以新接龍為引子,意圖灌輸我們一個正確的學習觀念,以及追求知識的正確的觀念。課堂後要求學生們針對「什麼是知識」作一個簡要的回答。
肥蝦野人獻曝,把自己對「什麼是知識」想法的簡易初淺說明在此呈現,期盼藉由能發揮拋磚引玉的效果,並誠盼經由 各位的指教,肥蝦能獲得更多正面有益的認知!

(一)什麼是知識?
簡述:
在探討什麼是知識前,個人覺得必須對真理(truth)與知識(knowledge)間作一個明確的界分與定義。
在目前文獻中對於真理或知識的解釋非常地多,也存在相當大的爭議。
就個人自我的觀感,個人將兩者作了以下的定義:
(1)真理(truth):符合客觀事物實際情況及其發展變化規律的道理。
(2)知識(Knowledge):人類將所認知到的經歷,經由適當方式加以整理及陳述的結果。
因此人類現有的知識與真理之間,個人以為不能劃上絕對的等號。個人以為知識只是人類在試圖追求真理的過程中,所不斷累積下來的成果。
在關於知識的描述中有兩點是比較容易發生問題的:(1)人類認知。(2)適當陳述。
人類的認知,其出發點為以人為主軸,認知的過程則必須以自我感官或內心的知覺進行探索。因此在先驗上,對於認知的主客觀上即很難超脫"人"的立場。
此外,陳述的公正、不偏頗、準確與精確,更有著相當的距離。單就溝通理論上就溝通的流程中即可能出現很多失誤的節點。
就以個人對於此題目的認知為例來說,此題目對於知識的定義已先假設:「知識為對真理的描述」,或者一般傳統上的:知識是"證成為真的信念"(justified true belief)。因此就如老師於課堂上所言:「知識是可被實證與可被預測的。」但是單就" 可被實證與可被預測的"的單純字面意義,目前就個人對於量子力學中的「測不準原理」的初淺瞭解,已經對此有某些的衝突。但是本質上,個人以為經由人類知覺的探索,發現所謂的「測不準原理」,也是一種追求"真理"下的"知識"!

(二)什麼是實證知識?
簡述:
就個人所接觸有限的文章中對實證的對應英文多為Positive或Empirical兩個單字。
Positive多被解讀為被事實所證明或者確鑿的證據;而Empirical則含有實驗或經驗的含意。
個人認為可稱為所謂的實證知識乃是:針對特定的人為認知陳述的結果,可被經由人為特定設計或規畫的程序,進行重複的過程,或者該結果存在共有認可的輔助現象,
基本上,個人以為實證的核心本質,存在著人為設計或邏輯推論的脆弱基本點。人為現有的實證方式不外乎實驗室實驗、統計實驗兩大類型。在實驗室實驗的重點,為對控制變項(自變數)的釐清與精密掌控;而統計實驗,除了需要設法釐清控制變項(自變數)外,並需進一步對於母體假設的認定,以及驗證追求適當的合理性。
目前知識架構的建立,大分為純理論建構與實證驗證。兩者之間相輔相成的目標:即在於期望追求對於真理正確陳述的知識。因此個人以為對於實證知識的吸收,應特別注意於其人為設計程序的邏輯合理性思考,以及相關控制變數的釐清與假設。

(三)什麼是機率型知識?
簡述:
人們經由實證的過程,可發現陳述的現象為一個特定結果-如:在其他環境不變下,水受熱為蒸汽。-或為一種規律性的呈現狀態-如:在其他環境不變下,投擲骰子的點數分配。-人類以為所認知到的經歷結果,為呈現一個有規律的分佈狀態,對此規律行為的描述可稱為機率型知識。
另外,就機率可再區分為先驗型機率與後驗型機率兩者。先驗即認為是不證自明的,如太陽必從東方升起。而後驗型的就是經由人為不斷的模擬與實證,而歸納出的規律型態。
針對母體甚小的現象,進行大量實證,當然可以推論出合理的機率分佈,但對於母體廣袤的現象,要得出完整的機率描述,就目前的人為方法/科技可說是非常困難。就如現今眾多的研究報告,在卷首均為假設該現象符合常態分配(normal distribution),再進一步進行實證。這個盲點就在於:該現象是否真的符合人為所設定的機率型式呢?這個問題個人以為今年的金融風暴,就可以明顯的曝露出人類追求機率型知識的侷限性。

(四)為什麼有數字,就可能有知識?
簡述:
數字是一種人為創造的較為嚴謹的語言,藉以試圖描述所認知的現象。因此首先的要點,即是必須先要瞭解該數字,在描述現象之時的代表意義-絕對性、相對性。
一個實體蘋果,加上另一個實體蘋果,可得出兩個實體蘋果,這可稱為絕對性數字的陳述;一個蘋果的甜度,加上另一個蘋果的甜度,是否可得出一個蘋果的兩倍甜度,則非必然(這甜度這代表數字是一種相對性的數字)。
數字背後存在知識,也許可以更適當的敘述為:以較為嚴謹的語言,所描述人為認知的現象,就是知識。符合了個人在問題一:什麼是知識?中對知識的解釋。
數學語言,可說是人類目前發展至今最為精確的語言,加以數論中對於數字的探索,更加推演出進一步的邏輯性演繹。但是個人以為數字的基本問題,還在於對描述事物的根本性問題-即被呈述的事物所代表的數字是一種絕對,還是相對性?

2009年11月18日 星期三

推薦一個專案管理小茅屋



昨日肥蝦上網找相關衝突管理相關的文章,無意間發現了一座專案管理小茅屋(Project Management Hut) http://www.pmhut.com/

在這個網站中有一些不錯的小文章,對於文章等相關資源的分類非常清楚,更可貴的是它還有ITIL跟Project Management的共通性與相輔性的文章討論!因此肥蝦推薦這個網址與大家一同分享。

ITIL:IT Infrastructure Library(資訊技術基礎架構庫)是由英國電腦和電信局(The Central Computer and Telecommunications Agency)所開發出用於規範IT服務管理的架構。藉由流程的利用將資源最佳化,以提昇 IT 服務水準,試圖結合技術面向與商業目的,證明IT組織的價值。

2009年10月28日 星期三

5.1.3.1的Requirements Documentation是否流入4.2Develop Project Management Plan?


近來有一位朋友問了很多有關4.2 inputs的問題,肥蝦我個人建議他看一下PMBOK page 49的Figure 4.5!但4.2.1.2的說明跟Figure 4.5有一個衝突點:即是Requirements Documentation是否流入4.2Develop Project Management Plan.

基本上,4.2.1.2的Outputs from Planning Processes基本上主要是三個baselines跟十二個子計畫(可從PMBOK 4.2.1.2的說明可知),但如參考Figure 4.5可以發現5.1除了 Requirement management plan流入4.2外又多一個requirements documentation也流入4.2.1.2! 這requirements documentation是有點爭議性的!

以肥蝦個人的理解,就從整個PMBOK的角度,可以把4.2看成是做完各個領域的規劃後進行彙總的過程:
(1)所以首要的是先確認專案的存在與業務(Business)的要求(=>project charter).
(2)再來是彙總所有規劃程序主要產出的子計劃跟baseline,追求其間的一致性,總不能子計劃之間彼此打架吧!(=>Outputs from Planning Processes).
(3)另外因為是我們的組織要在現有的環境下去執行它,所以現有週遭環境法令的限制,公司的組織與資源,以及以往公司或外界相關的經驗,都可以拿來作參考或調整的依據.(=>Enterprise Environmental Factors;Organizational Process Assets)

由於此處的工作主要是進行彙整,最重要是需要專家的能力進行處理(Expert Judgment),而產出當然就是在專案執行,監控,結案所要依據的規範了(Project Management Plan)!

因此你可以想成如果其他規劃流程的產出是為了完成相關的子計劃或baseline,基本上就不會再流入4.2了.因為4.2要的是所有領域規劃的最終可納入專案後續作業依據的產出!

只有requirements documentation要特別留意一下!就規劃的流程,你可發現:5.1的output:Requirements Documentation會留入5.2產生Project scope statement(還有project document updates=>當然就是指Requirements Documentation);以及5.3配合Project Scope Statement一起產生WBS,WBS Dictionary(還有project document updates=>當然就是指Requirements Documentation).以及12.1去判斷那些需要外購,進而有Procurement Management Plan與Procurement Documents!

因此基本上5.3的產出Scope Baseline,在規劃的產出而言,已能大體上包含了Requirements Documentation的要求!因此就PMBOK的文字說明僅寫了Outputs from Planning Processes是代表baseline and subsidiary plans. 可是在Figure 4.5又特別把requirements documentation列為4.2的input!當然也是可以把他想成requirements documentation是客戶/USER的原始要求,因此需要在彙整Project Management Plan時需要再特別的考量(在Project Scope Statement中有所謂Project exclusions)!但肥蝦以為針對這些在你的邏輯架構屬於例外的部份就特別記一下就好了!(一本書由多人所作,因此有些前後稍微衝突的地方在所難免!)

以上是肥蝦個人的淺見跟說明,還請 參考!

2009年10月6日 星期二

誠信才是永遠的!-"誠信"漂流記讀後感

今日收到一位好友寄來一封聽說是對岸那邊聯考的作文─"誠信”漂流記

內容如下:
----------------------------------------------------------------------------
話說誠信被那個“聰明”的年輕人投棄到水裡以後,他拼命地游著,最後來到了一個小島上。“誠信”就躺在沙灘上休息,心裡計劃著等待哪位路過的朋友允許他搭船,救他一命。

突然,“誠信”聽到遠處傳來一陣陣歡樂輕鬆的音樂。他於是馬上站起來,向著音樂傳來的方向望去:他看見一隻小船正向這邊駛來。船上有面小旗,上面寫著“快樂”二字,原來是快樂的小船。

“誠信”忙喊道:“快樂快樂,我是誠信,你拉我回岸可以嗎 ? “

“快樂”一聽,笑著對“誠信”說:“不行不行,我一有了誠信就不快樂了,你看這社會上有多少人因為說實話而不快樂,對不起,我無能為力。”說罷,“快樂”走了。

過了一會兒,“地位”又來了,誠信忙喊到:“地位地位,我是誠信,我想搭你的船回家可以嗎?”

“地位”忙把船劃遠了,回頭對“誠信”說:“不行不行,誠信可不能搭我的船,我的地位來之不易啊!有了你這個誠信我豈不倒霉,並且連地位也難以保住啊!”

誠信很失望地看著“地位”的背影,眼裡充滿了不解和疑惑,他又接著等。

隨著一片有節奏的卻不和諧的聲音傳來,“競爭”們乘著小船來了,“誠信”喊道:“競爭,競爭,我能不能搭你的小船一程?”競爭們問道:“你是誰,你能給我們多少好處? ”

“誠信 ”不想 說,怕說了又沒人理,但“誠信”畢竟是誠信,他說:“我是誠信……”
“你是誠信啊,你這不存心給我們添麻煩嗎?如今競爭這麼激烈,我們‘不正當競爭’怎麼敢要你誠信?”言罷,揚長而去。

正當誠信感到 近乎絕望的時候,一個慈祥的聲音從遠處傳來:“孩子,上船吧!”,一個白髮蒼蒼的老者在船上掌著舵道:“我是時間老人。”“那您為什麼要救我呢?”誠信問道。 老人微笑著說:“只有時間才知道誠信有多麼重要!”

在回去的路上,時間老人指著因翻船而落水的“快樂”、“地位”、“競爭”,意味深長地說道:“沒有『誠信』,快樂不長久,地位是虛假的,競爭也是失敗的。”
-----------------------------------------------------------------------------

這篇文章肥蝦以為可以作為一個專案經理在做利害關係人溝通管理之時的註腳!

一個專案當然專案經理要設法建立公司,專案團隊在利害關係人心中的credit!唯有credit才能使得利害關係人對專案有信心,對你-專案經理有信心!

任何手法都是一時的!最重要的是一旦您的或專案團隊的credit失去,你將一無所有!

就順序上來說,肥蝦個人的作法如下:

利用公司的credit接下案子->建立PM的credit->建立專案團隊的credit->建立公司在這個專案的credit!

如果利害關係人已經認為公司是騙人的,你一定要設法保住您專案經理的credit!否則此專案必敗無疑!

因讀到此篇文章心也所感,肥蝦特與各位一同分享!

2009年9月28日 星期一

推薦一個另類但有趣的網站--http://tx.shu.edu.tw/



肥蝦現正進修世新的資管在職碩班,向第二個碩士學位挑戰!

本學期修讀了一門【研究方法】授課老師是吳統雄老師。他的思考可說非常地非主流,但伊的思維肥蝦覺得非常有趣!

吳老師個人有一個學習網站:
http://tx.shu.edu.tw/

伊強調的主旨:「多元學習,獨立人格!」肥蝦覺得非常符合一個專案經理應有的態度。

吳老師可說以自身的學習與經驗,提出了自有的看法與見解。當然各位先進也許初看之時,會覺得伊過於自大與自誇,但深究其理,相信可有不少收穫!

加以專案管理可說是一門社會學科與整合管理的藝術,因此吳老師的一些看法與見解,肥蝦以為可提供給專案經理進一步修練的參考。

上週讀書會的一個成員,希望肥蝦提供一些forms或tools以供伊使用。肥蝦這方面的資源尚稱豐富,私下分享亦無問題!但肥蝦非常強調一個重點:「任何forms或tools均是他人在某些環境下的產物。而身為一個專案經理的你,有否堅實的理論基礎與豐富的經驗,加以消化,並且因地、因時、因人加以修正,符合自己本身的風格與特質!」

前一陣子,辦公室的另一部門的同仁也在問:所謂的系統分析文件是否一定要以UML的diagrams去呈現給客戶?

肥蝦特別的提醒她:應注意專案的本質與文件的對象。對從未接觸過與學習過UML的客戶來說,使用UML的diagrams可否達到專案所要求的溝通目標?是否加速雙方的溝通進度與深度?是否針對溝通對象的特質與背景,使用雙方可接受或客戶願意採納的方式去撰寫系統分析文件?就如「讓事情發生」第七章所言:「和所有工具都要保持柏拉圖式的關係,工具和圖表可以成為重要的東西,只要保持客觀。」

就肥蝦個人的想法:身為一個專案經理切不可受限於工具與過程,任何的作為應以順利交付專案的產出、服務或結果為目標!

2009年8月18日 星期二

「自傘自度還是上帝之手」讀後心得


-兼論科學人雜誌第90期「市場與計劃,缺一不可」-

「自傘自度還是上帝之手」是我閱讀陳沖先生專著的第二本,記得第一本「法國狼與貓頭鷹」是前年於客戶端進行一個專案之時,與我合作的user推鑒我閱讀的。在那個案子我所學甚多,與我合作的users更是讓我受益良多。

陳沖先生,記得在我擔任立委助理之時與他有數面之緣。當時即感覺他的金融實務與財金法律知識非常紮實;但卻隱約感覺此人有點恃才傲物。在觀看這「自傘自度還是上帝之手」之時,感覺上也許是幾次宦途浮沈,展閱他的文章之後,發現他的意見寬容了許多。正巧前日也翻閱了科學人雜誌第90期薩克斯(Jeffrey D. Sachs)先生的專欄-「市場與計劃,缺一不可」發覺兩者在理念之間,有些異曲同工之妙,因此特寫此篇心得以記錄個人的感想。

我於就讀經濟學碩士之時,指導教授的專長在於【發展經濟學】,因此攻讀碩士之時,也修了一年政治研究所所開設的【政治經濟學】課程。這兩個學門均主要在探討經濟環境中,市場與制度這兩個支柱,但彼此間的觀點與立場卻有一定的差異。

就我個人初淺的認知,發展經濟學基本上是尊重市場經濟(看不見的手/上帝的手)的功效,但為弭補市場機能的不足或缺限,則須加以良善規劃的制度(政府管制/那把傘);而政研所的政治經濟學,感覺上比較偏向政府政策與制度的重要性,經濟就是人為的活動,因此需要加以適當的管制,市場的機能很多時候,只會讓現況脫離了發展的目標與途徑。也許有些讀者感覺:「這只不過是孰重孰輕的問題罷了!」,就我個人的思維與架構來說,卻是非比尋常!

以往個人認為,市場如同流水一般-水往低處流,市場逐利而行;那政策與制度,就如那堤堰一般,藉由增加成本或設定成本,讓水往人們設想的路徑流去,但一旦過於強迫,常會導致堤毀人亡的慘劇發生。近來隨著肥蝦自我工作與社會經驗的成長,深覺任一現象的背後大多有著糾葛難分的事因。各種原因間影響的比重或有深淺,其間的互動關係可能曖昧未明。因此為達成目標、解決問題,就如陳沖先生所言:「政策既定,如何執行?又如何避免副作用?就必須有所配套!」(金管會的好棋,page 109-110),也如那薩克斯(Jeffrey D. Sachs)先生所言:「不論公私部門,任何大規模的行動要成功,市場與計劃兩者缺一不可。」

在現今之中,市場與計劃兩者之間兩者實無法切割,各位可查看「六法全書」的厚度,就可知道政府的制度何其繁多與重要;參看每日的股市交易,就可知多少人忙於追逐利潤。因此任一現象或問題的背後,影響因素可能是已存在的法令,也可能是市場趨利的誘因,也可能是人性的一時不易變更的固有偏好。而要解決問題就如同pareto法則(80/20法則),我們僅能就最重要的成因去設法改進。

就如同在【誰是火箭專家】乙文中所說,美國次貸風暴的源頭是:Rocket scientists、Rating agencies、Regulators;而在【原來是國王之手】所認為解決金融風暴的好方法,首推英國的是針對流動性問題,並連結至市場利率的SLS(特別流動性規劃)。陳沖先生的此言深得我心,也給了吾等警語,就同專案經理在設法解決問題達成專案目標一樣,在面對繁多頭痛的病徵之時,如何針砭主要病因,規劃與執行解決之道。

此外在【樓梯間的欄杆】乙文中,作者也以票據法為例,說明經濟方法才是解決經濟問題的有效方式。法制就如同那樓梯間的欄杆,不見得用得到,修法僅是在欄杆上精雕細刻;但如要人不跌倒,重要的還是那樓梯必須拾階平穩。這讓肥蝦想起「愛上經濟」(中譯本經濟新潮社出版)這本書中男主角山姆所言:「伊小時,政府強迫要他家在樓上露台裝設鐵欄杆,政府意圖扮演父母一般的角色,確忘了民眾們應自我培養自己應有的風險與效益間取捨的態度。」這次金融風暴,不管是民眾購買連動債的損害,或者銀行的損失,其主要癥結,不就在於民眾或銀行缺乏自我負責的風險意識,以及應有的管理風險的態度。

台灣金融主管單位積極要求金融業者應該要KYC(Know your customer),在購買衍生性新商品前,購買者須填寫或回答一定格式的問卷。因此,肥蝦以為政府已設定相關的法規與制度,因此執法重點應在誰逾越了欄杆,而不是如在【誰是火箭專家】陳先生所說:「不懂的商品,別再碰了!」而是設法將商品的資訊公開化與透明化,並建立每人應有的風險意識。

如果有人願意當風險愛好者,又何必去禁止他呢?金融市場之所以發展,不正是這世界上存在了風險中立、愛好與趨避的各色人等嗎?真正重要的是:不如藉由制度與市場的結合。政府可藉由制度,要求具有更多資源的一方,強迫其發佈相關的資訊,再經由市場去解讀與評價,達到一定的目的;並設法把人民當個成人看待,應讓伊培養自我承擔風險的態度。政府主要將功能與角色,應放在那些沒傘可自度之人。對於有傘自度者,推廣風險自負的正當心態,嚴懲翻牆越梯之徒,如此,個人以為才有可能將台灣推向一個區域的金融中心。

利潤與風險實為一體的兩面,追求利益當得承受風險,因此追求多大的利得就得看自我能承受多大的風險。這就如同專案管理一般,專案經理與團隊的要責之一,不就在風險的辨識、衡量、專人專責、監控、報告,以及設法找出風險背後的主因,設法防範於事前,並密切與連貫的連結至公司的風險承受度。