煮萎日誌-2009/12/27

「一個不敢表達自我的人，如何獲得別人的敬重？一個只想到自已的人，如何獲得別人的善意？」

為何人不敢當面表達自己的意見跟看法，而只敢在背後吱吱喳喳！
這是肥蝦擔任社區主委的第一感受，如同先前的匿名信一般，好似大家還活在威權體制的時代！
怕！怕別人記恨。怕！怕別人報復。怕！…。
但是不敢忠實勇敢的說出自己的感受與看法，別人要如何得知自己的立場與處境？
溝通第一步：「勇敢的說出來！」

別人不應該晚上洗衣服，別人不應該讓小孩喧鬧，別人不應該…。
凡事只想到自己，要求別人改變！「自我為中心」是社區百分之九十五的問題核心。
在工商煩忙的社會，生活作息不再是一成不變的「日出而作，日落而息。」也不是「瓜棚豆架，雞犬之聲相聞。」
社區住戶之間如果不能互相尊重，關懷彼此，而一味地責怪別人，問題是永遠不能解決。

不具名鄰居的指教回覆-我還沒上任耶

不具名鄰居(以下簡稱為您)惠鑒：
首先必須向其他各位先進抱歉，因為弟尚未上任(本月26日方進行交接)已接獲了某些住戶的指教。其中因有一封信直接投入弟的住戶信箱(交接後即設住戶意見反應箱，還請多加利用)，因為不知對方的貴姓與大名，更不知伊居所所在，就伊所建議事項，進行初步瞭解後，書寫投遞至所有住戶的信箱，尚請 海涵！爾後，弟衷心冀望各位先進如有任何意見，均能惠賜貴姓與住所，以便弟能向各位先進當面請益。
承蒙您的指教，弟自感慶幸，也深感惶恐！弟也僅是本社區的小小住戶，也是從士林移居至此，但弟日後在管委會的作為必定在遵守法令、符合程序，以及社區住戶多數共識的基礎之上。
針對您來函所陳述的兩項建議，如有任何未明而誤解之處，還請 見諒，並請進一步告知。至於後續的任何作為，因管理委員會乃是採取委員制，非弟能一人專擅！加以管委會之上尚有區權大會，因此後續的可能作法，弟還得與各位委員一同討論，以及廣聽社區住戶的多數意見。個人將至目前僅有的瞭解、認知，呈述於下。
(1)建議一：警衛室不能放電視。
(A)目前的瞭解：
就弟向前任的主委與委員請教，此決議應是第一屆管理委員會(或區權會)之時的決議事項。該電視為以前住戶搬離之時贈予管理委員會；有線頻道為廠商無償贈與。
(B)個人的認知：
弟能感受您對警衛桌前放置電視可能引發的安全問題有所擔憂，但弟以為當時管理委員會的諸位賢達作此決定，必有當時背景與住戶反應的考量。如今也許時空環境遷移，因此需要作些變更，但弟以為還得遵照一定的程序，如果住戶多數反應不應設置電視，弟將敦請總幹事自警衛桌前撤除電視。
此外，入口大廳並不專為警衛而用，弟一心想將其轉換為社區住戶的聯誼中心。如果爾後，社區的長者或住戶們能多於該處進行活動，弟思考將電視轉換為供住戶休憩使用，不但可促進社區的良性互動，減省各住戶之私電費、增進環境保護，更可多加利用朱總幹事的護理專長。
(C)未來的作法：
(i)弟於26日上任後會調閱三年來之管委會與區權會會議記錄，明確界定該事是否記載於相關文件之中。
(ii)如果下任管委會認為應進行檢討，或者具名反對之住戶達9戶(含)以上(住戶1/10)，弟將發放問卷進行調查。如果反對者達住戶中之一定比例(弟以為管委會決議事項，應有1/3以上反對；區權會則應有1/2以上反對)，則敦請總幹事協助將電視自警衛桌前撤除。

(2)要求警衛針對住戶與住戶間的樓層間，以及其間電燈關閉的定點巡邏。
(A)目前的瞭解：
就弟之目前瞭解，先前胡主委曾要求警衛進行此等作為，但因住戶們對於自己樓層間的電燈開關有不同的見解，因此無法確實地實行。
(B)個人的認知：
弟以為整體社區的安全防護與住戶緊急求助事件的處理，為社區警衛的首要職責。況且我們社區僅有單哨警衛，日間因尚有總幹事在入口大廳上班，因此日間警衛可適時進行巡邏活動，巡視各樓層的共用電燈；但夜間警衛除必要活動外，其警衛重點應以入口大門、停車場大門、社區監視器螢幕、及社區話機機台為重點，伊巡邏與活動空間應以聽得見話機音響，與能及時反應為原則。
此外，樓層間的電燈僅為對門兩戶共用，兩造之間應視雙方共識，於平時即發揮彼此公德，注意隨手關燈，節約能源。尤其夜間之時，警衛進行您所要求之活動，估計需花費20-30分鐘，屆時如有任何住戶有緊急事故，這幾近半小時的時間恐成為重要的關鍵。
(C)未來的作法：
(i)弟將與新任委員們討論我們社區的日、夜間警衛作業準則。針對社區的需求與現況，依優先順序，擬定適當的作業程序與活動要求。
(ii)針對我們社區管理委員會與相關聘用單位間的作業組織架構與權責，弟也將一併與新任委員們共同依據相關法令與社區規約，擬定管理委員會的組織細則。

以上均為弟目前的瞭解與認知，如有不明或不妥之處，尚請進一步予以指正。因弟僅是社區無給職之委員，生活上也須為五斗米折腰，加以夜間尚於世新進修第二個碩士學位，並偶至補習班兼任專案管理的顧問講師，因此能為社區貢獻之時間實屬有限。弟也自認個人的為人品格與民主素養有一定的層次，不會四處造謠、惡意破壞社區和諧，因此懇切盼望社區先進們日後對小弟有任何指教，請加具大名或住所，或者於個人於入口大廳輪值之時不吝親臨賜教，以免使弟誤解本意或一時無所就教。
此外，就弟這幾日與些許住戶溝通。在住戶們的要求下，上任之後，關於此次區權會議通過之停車場管理辦法，弟必得全力執行。上任後，爾後如有停放於共用區域，住戶專用車位在原所有權人授權委託下，對於任意停放的車輛、放置物則請保全公司進行強制保管；專有車位內置放不當物品，則進行宣導與進行必要安全處理，若因此而有得罪之處，還請 海涵！

敬祝
闔家平安

距主任委員交接尚有二日的小小住戶
IT肥蝦 敬上
2009/12/24

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

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

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

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

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

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

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


【賣辣椒的女人】

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

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

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

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

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

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

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

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

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

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

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

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

說；「用不著！」又一個買主來了，問：「辣椒辣嗎？」

賣辣椒的婦女看了一眼自己的辣椒，信口答到：「長的辣，短的不辣！」

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

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

我沒有再說話，心想：這回看你還有什麼說法？

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

賣辣椒的婦女信心十足地回答：「硬皮的辣，軟皮的不辣！」

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

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



我忽然有所頓悟：

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

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

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

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

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

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

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

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

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

推薦一個專案管理小茅屋

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

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

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

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)!但肥蝦以為針對這些在你的邏輯架構屬於例外的部份就特別記一下就好了!(一本書由多人所作,因此有些前後稍微衝突的地方在所難免!)

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

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

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

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

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

“誠信”忙喊道：“快樂快樂，我是誠信，你拉我回岸可以嗎 ？ “

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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