打從8月10日就想把一些感受寫出來，無奈題材的確敏感，一不小心，可能累了編輯背上黑鍋，網站還可能遭人圍剿。不過，如果老仙不寫，恐怕我們的「業界菁英」為了顧念「日後利益」，大概也不會胡亂的說三道四，指斥當權者的不是。有見及此，老仙最終還是想借「馬團隊救災專案」來說說專案管理失當之弊。老仙有言在先：
1. 救災專案無疑屬危機管理之一種，不過本文對此涉獵不深，僅從風險管理角度談及一二而已，
2. 本仙所認定之流弊，不論紅橙藍綠，一概與政治無關，閱者不必認同，但請不要用過度敏感的政治神經來給老仙扣帽子。
記得老仙自8月8日起，心情是由關心、擔心、震撼、震驚、傷心、到悲憤失望，對事態的發展，真的是百感交集。就專案管理的理念來說，老仙大膽地說，整個團隊錯漏百出，完全是個不及格專案項目，就算換上老仙般的「行政架構外行人」來當專案經理，也定會比劉經理處理得好！
Kickoff meeting啟動會議
原則上防災應變小組成立與啟動是及時的，專案贊助人(project sponsor)也親臨現場，充分體現對專案的高度重視。遺憾的是，這麼大型的、危急且史無前例的專案(program)，總專案經理除了必須清晰任命、全面授權外，會議還必須釐清所有專案項目最難處理的知識範疇(knowledge area)---溝通管理！
如老仙前文所述，溝通是專案管理者最主要的工作，如果連這個都不懂，想把專案搞好，根本是緣木求魚！如此嚴峻的項目，啟動會議不應再是打個照面，然後回家吃飯看戲，爾後再從長計議。人選與各子項目專案經理定位後，首要任務必須清楚明訂溝通計劃(communication plan)，這個東西在很多專案項目都會流於形式，甚至被人忽略。但是在一個人多口雜，加上溝通渠道(communication channel)多不勝數的情況下，資料將如何收集、何時收集、怎樣處理、由誰分析歸納、如何辨真、誰來統籌發放、誰與誰該收到怎麼樣的訊息、….凡此種種都必須第一時間敲定，否則當資訊混亂、茅盾、失真、錯判時，整個團隊根本無法正確下一步該如何走下去！說真的，88節陪老爸吃個飯，回家陪陪親人，沒有不當之處。我想當時北部地區也有不少人在過著歌舞昇平的日子，問題是如果你是被委以重任的專案成員，你很自然地需要善用你的權力去履行的義務！24時隨傳候命(on call)是理所當然，如果上述的溝通計劃清晰明確，每位重要成員都可以全天候掌握到所需資訊而作出決策，老仙才賴得管你是在飯店還是在家中的大床上下達命令。
風險(危機)意識
專案管理第二個難題就在風險管理！一般專案成員都善於面對已發生的的事，對那些將發未發的事項，總是會感到無所適從。最常見的狀況就是把這樣的風險看待成「有機會發生而已」，繼而就把它當作「不會發生吧」來應對。面對如此突如其來的項目，從總專案經理到子項目經理，多半都抱持著上述的僥倖心態，明顯地對風險意識不足、對預留應變措施缺如。基於資訊繁雜、計劃不周，一般情況下總專案經理必須緊急應對，以時間而論，最簡便而實際的做法應在8月9日當天就指派高層成員南下統籌，作為總指揮部的橋樑。就以老仙這位局外人為例，8月9當天起，我已經開始聯絡在台友人(北中南部)，10日得知各人安好後已安排友人將本仙仍留在台的所有家當捐出。但回顧本專案的總負責人，他依舊「處變不驚」，理髮如宜，儘管日常作息與專案無關，但教利害關係人(stakeholders, 受災人)心裡如何承受。
政治手腕低劣
是的，老仙不談政治，這裡說的處事的政治手腕(political issue)。很多專案經理是天真得可以的，他/她會相信團隊內不存在任何政治問題。問題是中國式的專案項目裡，只要成員超過兩位，政治問題便是無可避免的了。以上述乘千上萬成員的大型專案項目，就算不談政治意識形態，除了當前利益、自身價值、以至災後重建權益，在在都會左右一個人的決定。作為總經理人，以為下屬勢必一個指令一個動作地去完成你指派的任務，那根本是不切實際的！如此艱巨的任務，如事前不擬訂好跟進催(促)(驗)收的動作，任由救急措施或款項發放了便以為大功告成，那是無知的。如果是老仙面對同類問題，除了指派尊人定時跟催各項進度外，為了將意識形態的影響力降至最低，老仙勢必會好好利用傳媒的力量。既然輿論的焦點必然聚焦我的一言一行，當然可藉此借助傳媒的監察力量，適度地發放篩選好的訊息，爾後根本就不必畫蛇添足了，傳媒定會自發地助你盯上需被監督行事的人，一舉兩得，何樂而不為！
管理任用、進退失據
如老仙前文，要求所有專案經理都是本科出身根本不切實際，像這樣的救災應變專案，誰會專家？！但是專案基本原則(ground rule)必須清楚，如果下屬沒有充足的準備便逼得上戰場殺敵，下屬本身的素質將直接影響任務成效！專案之初，什麼是終極目標？救命！這是不容致疑的。但是就連人居海外的老仙都知道事態何嚴重時，總經理人或子項目經理人在72小時竟然還不動員緊急應變人員(軍人)加入救援，這明顯是決策遲緩(姑勿論理據若何)。當高薪厚祿的總專案經理，閑時看似無所事事，但重要關頭，就算開罪仝人上司的決策，也必須當機立斷。到了最初的項目目標已經無法完成時，我們就必須更改目標(change scope)，救命已沒有希望之時，康復重建比挖屍到底熟輕熟重，又再一次令世人驚心。俯身聞屍者英勇，授權任命者無能！由爾後運抵的儀器足証老仙此言。
說真的，或許有人會說老仙事後孔明，不過誠如老仙前文所言，專案經理的第一原則是去情緒化(no emotion)。諸公或許就可以從本案例中看到各大才高八斗的專案項目經理是何等的不濟。面對專案成效如此差劣，專案成員出現在事發現場將會面對利害關係人如何招呼，再笨的人也該會想到。所以，即使明知將會成為眾矢之的、明知出現也於事無補、明知派派便當別人不會領情、明知表達同情會評為裝模作樣、明知最終成效就是讓人出出氣，子項目經理人也不可作出情緒反擊，甚至明說出現是來給你出出氣的晦氣說話。有如此這般的子項目負責人，除了個人因素外，多半是上級教導無方，物以類聚之故。
遲來的正思
88災變專案事以至此，期初目標是全盤失敗，超過700人不幸殉難。總專案經理人如果可以妄顧如斯錯漏，毅然續聘，試圖完成餘下的任務，那將會是又一次的錯判。設身處地，為所有利害關係人想一想，你今後將要如何去面對他們呢？你的團隊，因種種錯失而飽受批評，士氣蕩然，你還可以重建他們的信心嗎？他們還會受命於你嗎？設若後續專案需要各方專才加入管理團隊，你一日不去，有誰敢冒此大不諱投身賊營？儘管有人認為風頭已過，奇怪為何在此百廢待舉的時刻總經理人才要退位讓賢。老仙卻認為，早在期初無法完成專案目標之時，總經理人便應該對外宣佈辭呈，待第一階段應變處理完成後便馬上生效，這樣才是一位較有擔當的專案經理所為。
2009年8月26日星期三
當「豬頭老闆」給你這樣的差事，你會怎麼辦？( 下篇)
沒想到中篇的提問會帶出讀者忖測老仙方案的背後用意，反而未能吸引讀者踴躍發表個人見解，真有點失望。
在未講述老仙那5個小時做了些甚麼前，先說一則小故事：
打從大學階段起，老仙就已經開始不務正業，唸的是「黑手」，最常讀的卻是電腦天文、散文小說、宗教哲學、政治經濟、甚至是禪學…現在嘛，老婆也老在唸老仙八卦，心理血型、掌相星座、就連女性和兒童讀物也不錯過，真的是無藥可救。可是，老仙在時裝雜誌、花生秀上除了看到漂亮美眉外，還可以觀察到明年將會熱爆的色系，有誰知那一天在界面設計、產品包裝甚或展會佈置上，老仙不會比設計師們還要「潮」呢？(註：「潮」即跑在潮流尖端。)
回說老仙的提案：
1. 踏出老闆辦公室的一刻，老仙便召集僅有的三名資深工程師/系統分析師來開會(無他，5時下班，不馬上開會，恐怕會害得他們又要加班了)，咨詢一下他們對這樣一個ERP系統的看法。[communication management]
2. 席間工程師們當然提出了很多資源、功能、以至需求不清的問題，但是老仙開的不是「聲討老闆無能」大會，自當用「藍帽子」(註：六頂思考帽的藍色監控功能)讓大家趕快步入正題，查詢每位工程師對ERP的理解有多少、經驗如何、曾經做過甚麼類似的案子、要打做一個他所理解的功能模組大概需時多少…[facilitating workshop, collect requirement]
3. 待所有人充分交換意見後，大體上我方的實力有多少，能做些甚麼，老仙心中有數。如果按此照實回報，價位確實不菲，單是完成工程師們所能理解的功能就得花上超過50萬的預算，以至需時年多。
4. 會議準時5點前結束，交待了老仙大概構想，保證不會讓他們陷入萬劫不復之地後，各人便安心下班了。[team building, team buy in]
5. 會後按所得如常報價並無不可，不過老仙回看兩大頁A4文件，實在不忍就此打住。作為一名專案經理，是不是單從技術出發而不顧市場現況呢？老仙的看法或許和各位不太一樣。
6. 從短短兩頁的文件可以看出這廠家在內地實際上屬於「小山寨」規模，所營運的產品規模也十分小，要她花50萬甚或過百萬投資在一套無形的軟體系統上，根本不可能。再說，就算好願意投資軟體系統，要她等上兩年，也是不切實際的要求。既然老仙的「普通常識」告訴我如此的報價根本行不通，那當然得另謀解決之道。[manage stakeholders expectation, decision making]
7. 這時除了可以找一些老朋友來出謀獻策外，就得翻一翻老仙的「八卦資源回收筒」，喚醒一些久違了的記憶。大陸媒體雜誌上可輕易找到打從三千到三萬不等(更貴的當然也有)又號稱是ERP系統的「東西」，再透過新世代真正專家---互聯網，在網上找出三千元的東東是長得怎麼樣，具備甚麼功能。把可引用的功能和先前討論的成果合併、裁剪、以至刪減，將篩選後的資料整理成老仙版的報價。[collect requirement, procurement, statement of work]
8. 以十萬元的預算來打造一套“三千元多一點點的ERP系統”，確實預留了不少空間。即使真的做不出來，找原供應商修修補補，換個界面商標，也大有可能順利結案。但這也不是萬全之策，所以老仙在報價中最後加上“若客戶需要增加任何本報價單內沒有明列項目，我方會因應要求之複雜程度而追加預算，代客戶確認追加報價後方可落實執行。”(仙按：功能是新增與否，有經驗的項目經理當然心中有數，其中實有很大的商榷餘地。)[contracting]
9. 晚上八時將整理好的報價內容電郵給老闆過目，並預留明早有足夠的修改和討論空間。[negotiation]
至於整個決策過程，老仙考慮的不是客戶或老闆的大腿好不好抱，而是釋出的東西能否達到三贏的局面。然而，客戶最終還是沒有接受我方的報價，但是至少下屬沒有吃黑鍋、老闆沒有不高興、而客戶也沒有不滿意，這已算是老仙能力所及的極限了。
仙按：[]括號內的不都是PMP課程內必授的課題嗎？不少人經常問PMP到底實不實用？依老仙看來，該問的是「自己能活用多少？」
在未講述老仙那5個小時做了些甚麼前，先說一則小故事：
打從大學階段起，老仙就已經開始不務正業，唸的是「黑手」，最常讀的卻是電腦天文、散文小說、宗教哲學、政治經濟、甚至是禪學…現在嘛，老婆也老在唸老仙八卦，心理血型、掌相星座、就連女性和兒童讀物也不錯過，真的是無藥可救。可是，老仙在時裝雜誌、花生秀上除了看到漂亮美眉外，還可以觀察到明年將會熱爆的色系，有誰知那一天在界面設計、產品包裝甚或展會佈置上，老仙不會比設計師們還要「潮」呢？(註：「潮」即跑在潮流尖端。)
回說老仙的提案：
1. 踏出老闆辦公室的一刻，老仙便召集僅有的三名資深工程師/系統分析師來開會(無他，5時下班，不馬上開會，恐怕會害得他們又要加班了)，咨詢一下他們對這樣一個ERP系統的看法。[communication management]
2. 席間工程師們當然提出了很多資源、功能、以至需求不清的問題，但是老仙開的不是「聲討老闆無能」大會，自當用「藍帽子」(註：六頂思考帽的藍色監控功能)讓大家趕快步入正題，查詢每位工程師對ERP的理解有多少、經驗如何、曾經做過甚麼類似的案子、要打做一個他所理解的功能模組大概需時多少…[facilitating workshop, collect requirement]
3. 待所有人充分交換意見後，大體上我方的實力有多少，能做些甚麼，老仙心中有數。如果按此照實回報，價位確實不菲，單是完成工程師們所能理解的功能就得花上超過50萬的預算，以至需時年多。
4. 會議準時5點前結束，交待了老仙大概構想，保證不會讓他們陷入萬劫不復之地後，各人便安心下班了。[team building, team buy in]
5. 會後按所得如常報價並無不可，不過老仙回看兩大頁A4文件，實在不忍就此打住。作為一名專案經理，是不是單從技術出發而不顧市場現況呢？老仙的看法或許和各位不太一樣。
6. 從短短兩頁的文件可以看出這廠家在內地實際上屬於「小山寨」規模，所營運的產品規模也十分小，要她花50萬甚或過百萬投資在一套無形的軟體系統上，根本不可能。再說，就算好願意投資軟體系統，要她等上兩年，也是不切實際的要求。既然老仙的「普通常識」告訴我如此的報價根本行不通，那當然得另謀解決之道。[manage stakeholders expectation, decision making]
7. 這時除了可以找一些老朋友來出謀獻策外，就得翻一翻老仙的「八卦資源回收筒」，喚醒一些久違了的記憶。大陸媒體雜誌上可輕易找到打從三千到三萬不等(更貴的當然也有)又號稱是ERP系統的「東西」，再透過新世代真正專家---互聯網，在網上找出三千元的東東是長得怎麼樣，具備甚麼功能。把可引用的功能和先前討論的成果合併、裁剪、以至刪減，將篩選後的資料整理成老仙版的報價。[collect requirement, procurement, statement of work]
8. 以十萬元的預算來打造一套“三千元多一點點的ERP系統”，確實預留了不少空間。即使真的做不出來，找原供應商修修補補，換個界面商標，也大有可能順利結案。但這也不是萬全之策，所以老仙在報價中最後加上“若客戶需要增加任何本報價單內沒有明列項目，我方會因應要求之複雜程度而追加預算，代客戶確認追加報價後方可落實執行。”(仙按：功能是新增與否，有經驗的項目經理當然心中有數，其中實有很大的商榷餘地。)[contracting]
9. 晚上八時將整理好的報價內容電郵給老闆過目，並預留明早有足夠的修改和討論空間。[negotiation]
至於整個決策過程，老仙考慮的不是客戶或老闆的大腿好不好抱，而是釋出的東西能否達到三贏的局面。然而，客戶最終還是沒有接受我方的報價，但是至少下屬沒有吃黑鍋、老闆沒有不高興、而客戶也沒有不滿意，這已算是老仙能力所及的極限了。
仙按：[]括號內的不都是PMP課程內必授的課題嗎？不少人經常問PMP到底實不實用？依老仙看來，該問的是「自己能活用多少？」
2009年7月9日星期四
當「豬頭老闆」給你這樣的差事，你會怎麼辦？( 中篇)
如此簡單的問題竟然也要分成三篇來寫，老仙「吹水」(註：廣東話，即灌水)能力真的漸進化境了，哈哈！
先說明兩點：
1) 題中的老闆其實一點也不豬頭，未涉足IT行業前，他曾經是香港顯赫一時的地產界名人。命題為豬頭目的是吸引大家的注意而已，諸公不難發現，當一眾員工聚在一起時，最能夠引起共鳴的話題大多離不開埋怨某某主管的無能、或是評斷某某決策的無知，發掘別人長處的技能恐怕已變得落伍了，大義凜然地指斥豬頭老闆的壯舉諸公或多或少也曾參與其中吧？
2) 因為種種原因，老仙不便說明不能和客戶直接溝通的理由；不過，即使可以如此，老仙也不打算這樣做。
不知道讀者是否認同與華人交往和與洋人打交道是有點不一樣的，面對前文的題目，老仙深信老闆已經花了不少時間和對方交談，要一位內地小企業的老闆願意花時間寫下(不管他是否有秘書代勞)一份兩頁紙的文檔，其實不是件容易的事，由文件內容也可以看出對方不大清楚ERP為何物，當然同時也理解到老闆沒有(能力)清楚地指導對方如何提供合適資料，也沒有盡到教育客戶的責任，所以提出與客戶直接溝通，詳細理清頭緒後方行報價的方法不是不可為，只是老仙不為而已。因為
1) 在專案未成事前，我方理應盡量控制成本，不斷增加我方的成本(長途電話、外訪…)去追逐一個可能是「虧本的機會」，老仙向來是不熱切的。如果能在談判過程中盡量在成本轉嫁到對方的身上，無疑對日後的談判是更有利的。
2) 老闆要的是報價，而不是要求你出面把事情搞定，時間上真的不容許老仙如此為之。(註：老仙下午三時多接令，到晚上八時已經將草擬好的文檔發給老闆，準備明天早上和他商討修改後便可以由他跟進。)及
3) 最重要的原因---面子問題。以上兩點其實影響不大，不過當華人的面子尤關的問題時，你會發現他們很多時候會做一些十分不合常理的事，為了爭爭面子，非做不可，虧多少並不重要！老外可能一輩子也搞不懂這是什麼樣的營商之道。要和客戶直接溝通，無論你如何小心翼翼，也免不了直接或間接地「彰顯」老闆當初的缺失或無知，顯示了公司內容溝通的不足(按：老闆探討系統需求前應先行溝通)，大大犯了「不給面子」的重罪，恐怕最終會死無全屍！這點老仙不可不防！
雖則老祖宗門當戶對的念頭已被認為不合時宜，就連(曾經)流行曲「現象七十二變」不也曾告訴你「將會發現一些奇蹟，只要你拋開一點面子問題」？(仙按：大古老了嗎？諸公或許已經不記得羅大佑曾經有過這麼一首「古董流行曲」吧！)然而，長官們的心態有多開明往往不是我輩小民所能猜測的，單是第三點，老仙已認定了可行的方案，不過可能因為涉及金額問題，讀者們的意見都很「理性」。當然，大家所提出的理據都很清晰，但了為了方便比較，老仙現把過往歸納得來的建議提出，供大家參考看看：
方案一：報價五十至一百萬美金，為期約兩年。(提出這級別報價的朋友多半在跨國大機構幹活)
方案二：報價五十至二百萬港元(約乖5可得台幣估價)，為期一至兩年。(提出這級別報價的朋友多半在本地中、大機構幹活)
方案三：報價五十萬港元以下，為期9個月至一年。(提出這級別報價的朋友多半在本地小軟體公司幹活)
而老仙呢：在晚上8時完成的報價，老仙提出的是10萬港元為期6-9個月可以完成的ERP系統！
看到如斯這般的報價差異，你會支持那個方案呢？支持和不支持的原因何在？可否和大家分享一下你的見解呢？
先說明兩點：
1) 題中的老闆其實一點也不豬頭，未涉足IT行業前，他曾經是香港顯赫一時的地產界名人。命題為豬頭目的是吸引大家的注意而已，諸公不難發現，當一眾員工聚在一起時，最能夠引起共鳴的話題大多離不開埋怨某某主管的無能、或是評斷某某決策的無知，發掘別人長處的技能恐怕已變得落伍了，大義凜然地指斥豬頭老闆的壯舉諸公或多或少也曾參與其中吧？
2) 因為種種原因，老仙不便說明不能和客戶直接溝通的理由；不過，即使可以如此，老仙也不打算這樣做。
不知道讀者是否認同與華人交往和與洋人打交道是有點不一樣的，面對前文的題目，老仙深信老闆已經花了不少時間和對方交談，要一位內地小企業的老闆願意花時間寫下(不管他是否有秘書代勞)一份兩頁紙的文檔，其實不是件容易的事，由文件內容也可以看出對方不大清楚ERP為何物，當然同時也理解到老闆沒有(能力)清楚地指導對方如何提供合適資料，也沒有盡到教育客戶的責任，所以提出與客戶直接溝通，詳細理清頭緒後方行報價的方法不是不可為，只是老仙不為而已。因為
1) 在專案未成事前，我方理應盡量控制成本，不斷增加我方的成本(長途電話、外訪…)去追逐一個可能是「虧本的機會」，老仙向來是不熱切的。如果能在談判過程中盡量在成本轉嫁到對方的身上，無疑對日後的談判是更有利的。
2) 老闆要的是報價，而不是要求你出面把事情搞定，時間上真的不容許老仙如此為之。(註：老仙下午三時多接令，到晚上八時已經將草擬好的文檔發給老闆，準備明天早上和他商討修改後便可以由他跟進。)及
3) 最重要的原因---面子問題。以上兩點其實影響不大，不過當華人的面子尤關的問題時，你會發現他們很多時候會做一些十分不合常理的事，為了爭爭面子，非做不可，虧多少並不重要！老外可能一輩子也搞不懂這是什麼樣的營商之道。要和客戶直接溝通，無論你如何小心翼翼，也免不了直接或間接地「彰顯」老闆當初的缺失或無知，顯示了公司內容溝通的不足(按：老闆探討系統需求前應先行溝通)，大大犯了「不給面子」的重罪，恐怕最終會死無全屍！這點老仙不可不防！
雖則老祖宗門當戶對的念頭已被認為不合時宜，就連(曾經)流行曲「現象七十二變」不也曾告訴你「將會發現一些奇蹟，只要你拋開一點面子問題」？(仙按：大古老了嗎？諸公或許已經不記得羅大佑曾經有過這麼一首「古董流行曲」吧！)然而，長官們的心態有多開明往往不是我輩小民所能猜測的，單是第三點，老仙已認定了可行的方案，不過可能因為涉及金額問題，讀者們的意見都很「理性」。當然，大家所提出的理據都很清晰，但了為了方便比較，老仙現把過往歸納得來的建議提出，供大家參考看看：
方案一：報價五十至一百萬美金，為期約兩年。(提出這級別報價的朋友多半在跨國大機構幹活)
方案二：報價五十至二百萬港元(約乖5可得台幣估價)，為期一至兩年。(提出這級別報價的朋友多半在本地中、大機構幹活)
方案三：報價五十萬港元以下，為期9個月至一年。(提出這級別報價的朋友多半在本地小軟體公司幹活)
而老仙呢：在晚上8時完成的報價，老仙提出的是10萬港元為期6-9個月可以完成的ERP系統！
看到如斯這般的報價差異，你會支持那個方案呢？支持和不支持的原因何在？可否和大家分享一下你的見解呢？
2009年6月22日星期一
投訴處理趣談
致美女供應鏈公司：
去年我把「女友0.99版」軟件升級到「老婆1.0版」之後，發現系統變得一塌糊塗，「貌美」影像處理器變得模糊了，而「音量」控制器也失效了，分貝不斷提高，尤其是經多番調節後的自定義功能「守時」也失靈了。此外，「老婆1.0版」也把原來好用的軟體如「溫柔88」及「妝扮33」也殺掉了，而新加入了些沒有效益的軟件(如「LV3.0」、「麻將2.0」和「三八俱樂部」等)卻無法刪除。至於「烹飪2.0」也經常無故呼叫出「外賣3.5」程序。還有，每當我要執行「打掃2」或是「進修5」程式時，整個系統便會由原先的多工操作更換成單工作業，即使我IGNORE它繼續執行，「嘮叨6.6」也會忽然跑出來，令系統當掉，請問你們的系統為什麼會那麼爛！
氣憤的先生 上
===================================================================================
敬覆「氣憤的先生」：
首先要提醒您的是「開源」-「多工」-「女友0.99」的娛樂軟件，而「老婆1.0」則是「單工」「私有」的作業系統，本質上它們已經有很大的分別。在系統更新前，你應該有看到「悔恨」的警告條款吧？而您也透過「宣誓」和「婚宴」兩套交易平台來再次確認了您的選擇。很抱歉告訴您，這是個單向作業流程，「老婆1.0」是無法downgrade的。
如今，您可以嘗試以下的方法來修補系統的瑕疵，上網下載「香水1.2」、「唇印2.2」及「長髮3.0」到「出差」資料夾，更新檔案後，「溫柔88」及「妝扮33」有可能會回復正常，不過一旦操作不當，「烹夫」病毒可能摧毀整個系統，請格外小心。如果您認為風險太大，我們建議執行較溫和的「送珠寶2.0」程序，它可能可短暫改善「貌美」影像處理器及其他子程式的表現。不過，要特別提醒您的是，每次使用這個程序後您必須到我們的「增值交易平台」將此軟件升級，否則下次使用時非但得不到預期的效果，還會自動執行「嘮叨1.0」的24小時長駐程式。
如果您仍然對上述處理程序不滿的話，你可以嘗試以逆向思維模式來解決您目前的難題---將「老婆1.0」升級為「老媽1.0」作業系統，當系統升級為「老媽1.0」時，附帶的「子女2」和「傭工1.0」子系統會將噪音分流，同理即使「嘮叨1.0」自動執行，它的殺傷力也會降至最少。當然啦，這個程序是要閣下到「基金」交易平台儲備足夠積分後方可生效，而它只是一個防守性的軟件，將不會提升原系統的效能。
最後一提，坊間盛傳可以透過下載加裝一個名為「二奶」的程式便可以使用戶重新戶享用「女友XX」娛樂軟件，不過我們發覺「二奶」程式其實內置蠕蟲病毒，會耗盡系統資源，即使你透過「離婚」清洗器將病毒清除，它也會在不久的將來轉化成「老婆2.0」病毒，請用戶當心。
技術支援中心 敬上 2009-06-23
註：美女供應鏈公司只負責「女友」軟件的技術支援，有關「老婆」系列，請聯絡「苦主聯盟」網站！
(仙按：讀"科技太太的求救信"後有感而發)
去年我把「女友0.99版」軟件升級到「老婆1.0版」之後，發現系統變得一塌糊塗，「貌美」影像處理器變得模糊了，而「音量」控制器也失效了，分貝不斷提高，尤其是經多番調節後的自定義功能「守時」也失靈了。此外，「老婆1.0版」也把原來好用的軟體如「溫柔88」及「妝扮33」也殺掉了，而新加入了些沒有效益的軟件(如「LV3.0」、「麻將2.0」和「三八俱樂部」等)卻無法刪除。至於「烹飪2.0」也經常無故呼叫出「外賣3.5」程序。還有，每當我要執行「打掃2」或是「進修5」程式時，整個系統便會由原先的多工操作更換成單工作業，即使我IGNORE它繼續執行，「嘮叨6.6」也會忽然跑出來，令系統當掉，請問你們的系統為什麼會那麼爛！
氣憤的先生 上
===================================================================================
敬覆「氣憤的先生」：
首先要提醒您的是「開源」-「多工」-「女友0.99」的娛樂軟件，而「老婆1.0」則是「單工」「私有」的作業系統，本質上它們已經有很大的分別。在系統更新前，你應該有看到「悔恨」的警告條款吧？而您也透過「宣誓」和「婚宴」兩套交易平台來再次確認了您的選擇。很抱歉告訴您，這是個單向作業流程，「老婆1.0」是無法downgrade的。
如今，您可以嘗試以下的方法來修補系統的瑕疵，上網下載「香水1.2」、「唇印2.2」及「長髮3.0」到「出差」資料夾，更新檔案後，「溫柔88」及「妝扮33」有可能會回復正常，不過一旦操作不當，「烹夫」病毒可能摧毀整個系統，請格外小心。如果您認為風險太大，我們建議執行較溫和的「送珠寶2.0」程序，它可能可短暫改善「貌美」影像處理器及其他子程式的表現。不過，要特別提醒您的是，每次使用這個程序後您必須到我們的「增值交易平台」將此軟件升級，否則下次使用時非但得不到預期的效果，還會自動執行「嘮叨1.0」的24小時長駐程式。
如果您仍然對上述處理程序不滿的話，你可以嘗試以逆向思維模式來解決您目前的難題---將「老婆1.0」升級為「老媽1.0」作業系統，當系統升級為「老媽1.0」時，附帶的「子女2」和「傭工1.0」子系統會將噪音分流，同理即使「嘮叨1.0」自動執行，它的殺傷力也會降至最少。當然啦，這個程序是要閣下到「基金」交易平台儲備足夠積分後方可生效，而它只是一個防守性的軟件，將不會提升原系統的效能。
最後一提，坊間盛傳可以透過下載加裝一個名為「二奶」的程式便可以使用戶重新戶享用「女友XX」娛樂軟件，不過我們發覺「二奶」程式其實內置蠕蟲病毒，會耗盡系統資源，即使你透過「離婚」清洗器將病毒清除，它也會在不久的將來轉化成「老婆2.0」病毒，請用戶當心。
技術支援中心 敬上 2009-06-23
註：美女供應鏈公司只負責「女友」軟件的技術支援，有關「老婆」系列，請聯絡「苦主聯盟」網站！
(仙按：讀"科技太太的求救信"後有感而發)
當「豬頭老闆」給你這樣的差事，你會怎麼辦？(前篇)
近期老仙閒來無事，看多了些書和網誌，發覺愈來愈多朋友談專案，什麼「九陽神功」、什麼招數絕活層出不窮，連隱世專家也愈來愈多浮上水面來湊湊熱鬧！然而老仙一向對位高權重的「尊家」們有點感冒，大概是因為老仙不學無術，對專家們慣用一大堆的專業名詞無所適從，對那些高深莫測的理論招數也感到格格不入。加上老仙一向敢於以小人之心去測度君子之腹，總是會懷疑為什麼xx高層總愛在新產品上市前頻頻曝光，他/她高調唱好的技術或產品是否真的如斯神奇？好比那些愛丟出一堆經濟學詞彙的分析員一樣，他/她的結論就會因此比別人高桿嗎？尤其是當老仙看到那些仍搞不清邏輯推理關係的專家來唱談軟體智慧財產權時，老仙就更認同大前研一先生所說的「這個年代已經沒有專家」的看法。(仙按：大前先生這句話的背後論述請參閱其著作。)
尚幸老仙向來不以專家自居，也不以為自家的經驗會別人的優勝，所以才會催生了前文，希望和讀者分享一個真實案例，讓大家一同探討改進的空間。像匿名讀者提及「奇怪發包商可影響承包商的用人一問」，老仙是從來沒有想過這樣的問題(仙按：這本來就是現實狀況)，如果談合約內文，發包商真的多半是無從過問，然而現實是發包商若對合作對手有異議時，他實在有太多的渠道和方法去「幹掉」這位「眼中釘」，作為專案經理的人是不可不防的。(按：除非你是活在那些跨國大企業或CMM的庇蔭下，否則你的老闆勢必以商業利益作優先考量。)
綜觀讀者留言，美中不足的是jonsonleou君指出了老仙的處理手法只是中規中矩卻不大方地告訴大家他/她的上策為何。這回老仙又想到了一個約5年前老闆給老仙的考題，我曾經多次在演講和專案管理課程上拿來和聽眾討論，結果都讓老仙感到有點意外，不知道CNET的讀者們，可否就這樣一個題目給老仙一個良心的建議：-
經濟低迷，不要說轉換跑道，就連保住飯碗也有一定難度，設想你的老闆在一天的下午，找了你這位專案經理進他的辦公室，給了你兩頁A4大小的文檔，內容是：
老闆有位朋友，在廣州開設了一家小型的化妝品生產廠房，全廠合共兩條生產線，生產的化妝品種類約十來種，現在他希望我方能幫忙為他設計一套ERP系統。請我方明天給他一個報價和預估進度時程，若可行則可馬上動工！
別問了，就這麼多了，老闆所收集到的客戶需求(Collect Requirement)就這麼多了，再問下去，可能對方連ERP是什麼也不清楚，只是道聽塗說而已。
至於老闆嘛，已經是王恩浩蕩，給了你半個下午和一個晚上啦，要做個報價而已，時間已經很「綽綽有餘」。
如果你要問老闆公司的背景嘛，從來沒有做過ERP系統，一向都有做軟體設計，不過主力是網頁設計。
你大概會說報不出來？！先想想你一家大小都等著你微薄的薪水來過活，「不如歸去」恐怕不易說得出口吧？
2009年6月2日星期二
當「專業」碰上「無賴」，你會怎麼辦？(後篇)
就前篇所得回應觀察，留言大致分為：
1) 情緒性表達，對此老仙沒有補充。
2) 表示喝酒溝通的實用要。不
3) Airborne、Brazy、Blue君等建議，不無參考價值，在此先行謝過！
至於
<一>「人肉路由器」和 <二>「專職無賴」
對於那些因能力不足而無法順利掌控全局的專案經理，只要透過適度的訓練和累積一定經驗，日後定可成為出色的管理人員，故此他們並不屬上列人仕。
如果你經常和一些大機構或政府單位接觸，你會很容易會碰上第一類型「無賴」，轉寄電郵是他們的獨門絕技，他們最善長是將客戶的意見、投訴「完完整整的傳達」到下游供應商，將上級的壓力「輕輕鬆鬆的轉移」給下屬或合作伙伴。他完全能夠掌握進度和投訴的資訊，不過對策就一應欠奉，當然責任不也沾身。大概是碰多了之故，老仙對於這類型經理並不感冒，因為他們也不難應付。首先，他們處理專案的終極目標只是「不要出亂子」而已，因為亂子一出，會十分影響他的仕途。所以只要把握住這個重點，和他們談個折衷方案，甚至請他們向客戶說些好話，交上級的檢討報告「酌情」回報等等，他們都會「適當」幫忙。畢竟這類經理多半是長袖善舞之輩，和客戶把酒言歡通常是他們的強項，而久經沙場的他十分理解把你搞倒對他也沒有半點好處，非在必要的卸責保命情況下，他在這方面是有高度的彈性的。
但是面對第二類「無賴」你就必須額外小心，因為他們處理專案的目的只有一個，就是「所有問題都與我無關，錯不在我！」這類型經理不太在意專案是否成功，出了亂子沒關係，只要與他無關就成了。他非但不會善用專案經理的權力來權衡利害應變，他會第一時間將所有人的「罪狀」匯報給高層主管知道。這類型人不做實事還好，一旦他是位認真落力的員工，大小事務都參與其中的話，那專案項目就註定了不得善終！而前篇所述的D君正正是老仙所說的這類「專職無賴」，導致老仙折翼而歸也是意料中事。
難道就如此這般的吃記悶虧就了事嗎？老仙說過，誠信是必須堅持的，不過溝通卻可以有技巧變化。即使碰到「專職無賴」你也不必和他比「奸」，但是也絕不能白白送死。所以老仙在處理上述案子時，在不同階段有不一樣的部署：
1) 合作前期，顧及各方人士面子，不能推倒重來之下，老仙作了一堆陳述。內容既滿足了雙方當初的需求，又預留了延伸的彈性。當然，只要你有十足的經驗，要把個案延誤推給對方是一點也不難的，但是本著互惠互利的合作原則下，老仙當然希望軟體能按計劃順利進行。至於A公司的內部不利因素，別人沒有問，老仙當然也不會說啦！[按：期間往來記錄當然必須備案。]
2) 期初，老仙自收到那封各方高層都看到的第一封電郵後，就已經心知不妙。[仙按：文件副本是給予與案相關且有必要跟蹤項目的人士而已，在國外，電郵副本「贈」予高層，多半是有目的而為的，辦公室政治愈烈的公司，員工對cc這個東西會加倍小心，因為一不小心將會引發軒然大波。]真的，你有誠信不代表別人也一定和你來這一套，除了按進度完成計劃好的工作外，當然需要檢討對方的投訴是否屬實。老仙不在A公司是常有之事，但老仙的手提電話卻從來沒有收到對方的留言，由此觀之，老仙已經證實了對方的「身份」。此時，防範「敵方」來襲已經變成必要措施了，前文所說的部署大致如下：
· 將始末先向A老闆交待，分析箇中形勢，並預告A老闆對方根本就不希望有人來「管」，所以L公司高層是不會讓老仙去辯解的。
· 當然，站在專案管理立場，老仙還是有責任告A老闆要繼續「管」的話，會有得失L公司的風險，甚至會影響A公司未來的收入，他必須審慎考慮清楚。
· 至於後備方案並給予彼此一個下台階，現在就可以多派一位聯絡人，由他出面與D君接觸，按原來的「極力遷就」的模式運作，老仙只在幕後操盤。
· 當然也順應老闆意願，承諾只要對方願意，老仙去挨罵一點不難。
· 最後，當然也要自保，先行預告如果今後還是由老仙處理此案，最終的結果是對方會要求更換專案經理。
3) 原先A老闆對老仙之言半信半疑，待對方不讓老仙與會，他需要親自出面接受L公司老闆的質詢後，A老闆對老仙的預測也心中有數了。期中，因為老仙的電郵內容，L老闆或多或少會注意到D君的狀況，也不會反對由老仙繼續處理這個案子。不過，站在企業主的立場，當投訴事項對己方有利時，撐自己的員工是在所難免的了，不過這樣就註定了老仙的命運。往後該發生的問題也真的發生了，姑勿論老仙如何應變，結局均是對方甚為不滿。
4) 唯獨在過
5) 期末當然是D君興高采烈地將所有錯誤轉移給老仙而將之摌除了，而A老闆也樂得來個順水推舟，在三贏(A、L公司繼續合作，老仙也沒有被炒)的狀況下將個案落幕。
2009年5月1日星期五
當「專業」碰上「無賴」，你會怎麼辦？(前篇)
記得老仙早前在發表自家的座右銘「誠信有效溝通技巧」時，就有朋友問道：「這樣豈不很吃虧？！」對的，在現今的商業世界裡，這樣真的很容易吃虧，老仙也平白吃了十幾年的虧，不過那又如何？混到今天也總算還能問心無愧，沒有多年來吃虧的經驗，那有老仙今天的江湖地位！哈哈！
不對，這樣的回答有違老仙「有效溝通技巧」的原則，不過，如果告誡青年才俊吃虧就是你撿到的便宜，恐怕沒有幾人能聽得進去吧。既然如此，這次老仙就來個突破性的嘗試，把一個真實個案拿出來和大家分享，當「專業」碰上「無賴」時，老仙是如何去吃這個虧。本文分前後二篇，前篇主要是敘事，希望讀者能慷慨留言，告訴老仙你會如何面對這樣的問題。至於老仙的處理手法和背後原因將會在後篇中詳細道出，不管你認同與否，希望透過這個故事能讓老仙與讀者有個正面的交流機會。
專案項目背景
老仙至今還是一眾小公司的顧問(仙按：金融海嘯下，愈來愈少了…唉)，有時候會為以專案經理身份待他們處理一些專案項目，早前有這麼一個為期三個月的小型軟體開發項目：
L公司是一家生產商，面對的客戶多半是世界知名的誇國企業，為了滿足客戶的需求和鞏固自身的地位，她們會提供一些增值服務給這些客戶，而服務內容主要是專屬的管理軟體，而A便是承包這些軟體的供應商。A公司多年來是任由L公司說什麼，便改什麼，只要能「趕得出來」，假日加班也會盡力配合完成，成本從來無法估算。除了不懂得如何去管理一個項目外，也因為L公司是她的大客戶，所以A公司是很少提出異議。
A老闆為了不想讓專案項目持續失控，請老仙待為處理這個小案子。第一步，當然是老仙深信不疑的專案啟動會議，問題是軟體修改事項早在老仙到位之前已經談過(未完全落實)，三個月的期限也大致訂了出來(若無法如期完成，案子可能會告吹)，而A公司內部又適逢引入新進員工，案子部分項目要交由新鮮人處理，作培訓之用。在眾多不利因素下，老仙大致在會上作出了以下的陳述：
1) 如果我們能充分配合各個子項目進度，三個月完成初版，應該沒有問題，
2) 軟體修改事項中有以下幾個大問題(此略過)，我方會於當天列出所有問題，如果(對方的專案經理)D君能夠在一周內確認俱體事項，進度將不會有問題，
3) 我方約需要兩周時間完成系統規格書，待D君正式同意規格書內容後，大致需要一個月的開發時間，期間我會於每周提供一份簡短進度摘要(會面與否視實際需要另議)，
4) Beta發放後，希望對方能在一周內完成他們的測試並提供修改報告或建議給我們，
5) 餘下以一周作最終修改，隨後交付UAT驗收。
6) 專案期間如果還有什麼遺漏的事項，彼此當酌情處理。
聰明的讀者看到以上的內容，想必明白老仙在此已經預留了不少調動空間。至於類似這樣的小型項目，諸君就不必問我為何不做個關鍵路徑圖(CPM)、訂個後備方案(Contingency Plan)、甚或是計算一下掙值(Earn Value)啦！{按一：歡迎讀者提供你的見解。}
好了，有了初步計劃，如期交出問題後，當然就是等待D君回覆啦。D君在一周後回電說十分忙碌，未能解答我方疑問，期間，為了顧及對方的處境和我方安全，老仙只以電郵單獨向D君查詢進度如何。及後，約兩周過後對方總算回答了我方的所有問題，不過電郵除了給老仙外，副本還交到A、L公司的所有高層電郵帳號。
到了這裡，老仙已經感到事態不妙了，我可能又碰上了「專案無賴」(註解見後篇)！
但猜度也於事無補，項目繼續進行，不過兩周期限將至，各方高層真的收到了D君所發出的一封投訴電郵，內文大致是「兩周內遍尋不獲老仙，項目延誤了很多，到底發生了什麼問題！」
生氣嗎？不，這有違老仙另一NO Emotion 原則。在處理了一些小節後(後篇將會詳述)，老仙第一時間將規格書交出，並致電商討內容細節。不幸的是D君並沒有正面回覆老仙的查詢，數日後D君卻背後告訴各方老闆這份規格完全不妥，只是將他們交出的文檔抄了過來，完全不能接受，而L公司高層也因此而要求招見A公司老闆！{按二：事已至此，不知諸位看倌又有何高見呢？}
老仙見慣風浪，這點事兒嚇不了老仙，不過A老闆便急忙希望老仙出面擺平此事(他以為到L公司挨罵一下就好了)，不過老仙深信L公司是不會讓老仙參與這次聲討大會的，如果對方願意我在場，我去挨罵又何妨呢！結果也正如老仙所料，對方要求單獨與A老闆會面，為今之計，老仙只好以電郵將事情始末、時間明細一一道出(內容當然是讓對方百口莫辯)，為了顧全D君顏面，除了對事不對人外，還鄭重告訴對方可能是出於一些小誤會而已，D君和我們已經盡力配合…相信日後合作一定會更為順暢。…如此這般的文件已經是老仙最後可做的事了…{按三：讀者們，你又會如何處理呢？}
回說規格文檔，因系統屬功能提升項目，原規格書重複之處老仙是刻意刪除，只做了一份較為簡潔的文檔。至於如何不成，老仙間接地透過友人去詢問D君修改意見，答案是「不知道」。有見及此，老仙私下又重弄了一份包括原系統在內的一份較「厚重」的文檔出來(新內容部分沒有修改過)，最後透過友人以其名義交付D君查收，最終這份文檔幾乎在完全沒有修改過的情況下通過了。
既然老仙說得出百口莫辯四字，聲討大會之上對方當然是無法辯解(這也是不能讓老仙在場的原因之一)，不過L老闆最終還是對A老闆說「如果老仙有那麼多時間去寫這樣一封電郵，為什麼不花多一點時間把事情做好！」…{按四：如果是你，你又有何感想？}
事到如今，系統當然還是要繼續開發下去，期間應了「梅菲定律」(Murphys Law)所說的「如果你認為會出錯的地方，它一定會出錯！」(仙按：我的課有教哦！)，問題一錯發生，延誤了約兩個月才結案了事。期間我方的問題當然包括了新進人員的經驗不足和粗心大意，而對方於系統交付前當天還不斷提出修改也是禍因。細節不談，以下數點應能提供足夠線索給讀者研判：
1) 聲討大會之後，我方已經回復一貫作風，「盡力」協助對方一切修改事項，
2) 老仙提供了額外的聯絡人員和D君溝通，
3) 正常情況之下，D君沒有再找老仙了，
4) 在一次例外的狀況下，D君在專案之初就沒有列清楚的邏輯發生錯誤，在交付客人前夕發現錯誤而急忙要求我方配合修改，在我方人員無法同意的情況下，D君致電老仙商量對策{按五：這個邏輯謬誤若不修改，L公司的客戶是不可能接受的，改或不改請讀者提供你的見解。}，
5) 一份報表先後提出了五次修改，但是每一次所提出的錯誤或遺漏並不是什麼新發現，在第一次交付驗收時報表樣式本就如此，…
凡此種種，即使系統順利結案，大家也能想像在最終的檢討會議上，L公司會要求把老仙換走，不能再負責她們公司日後的所有項目！
如此失敗的個案，交給你重來一次，會有什麼不一樣的做法嗎？可否給老仙一個良心的建議呢？
不對，這樣的回答有違老仙「有效溝通技巧」的原則，不過，如果告誡青年才俊吃虧就是你撿到的便宜，恐怕沒有幾人能聽得進去吧。既然如此，這次老仙就來個突破性的嘗試，把一個真實個案拿出來和大家分享，當「專業」碰上「無賴」時，老仙是如何去吃這個虧。本文分前後二篇，前篇主要是敘事，希望讀者能慷慨留言，告訴老仙你會如何面對這樣的問題。至於老仙的處理手法和背後原因將會在後篇中詳細道出，不管你認同與否，希望透過這個故事能讓老仙與讀者有個正面的交流機會。
專案項目背景
老仙至今還是一眾小公司的顧問(仙按：金融海嘯下，愈來愈少了…唉)，有時候會為以專案經理身份待他們處理一些專案項目，早前有這麼一個為期三個月的小型軟體開發項目：
L公司是一家生產商，面對的客戶多半是世界知名的誇國企業，為了滿足客戶的需求和鞏固自身的地位，她們會提供一些增值服務給這些客戶，而服務內容主要是專屬的管理軟體，而A便是承包這些軟體的供應商。A公司多年來是任由L公司說什麼，便改什麼，只要能「趕得出來」，假日加班也會盡力配合完成，成本從來無法估算。除了不懂得如何去管理一個項目外，也因為L公司是她的大客戶，所以A公司是很少提出異議。
A老闆為了不想讓專案項目持續失控，請老仙待為處理這個小案子。第一步，當然是老仙深信不疑的專案啟動會議，問題是軟體修改事項早在老仙到位之前已經談過(未完全落實)，三個月的期限也大致訂了出來(若無法如期完成，案子可能會告吹)，而A公司內部又適逢引入新進員工，案子部分項目要交由新鮮人處理，作培訓之用。在眾多不利因素下，老仙大致在會上作出了以下的陳述：
1) 如果我們能充分配合各個子項目進度，三個月完成初版，應該沒有問題，
2) 軟體修改事項中有以下幾個大問題(此略過)，我方會於當天列出所有問題，如果(對方的專案經理)D君能夠在一周內確認俱體事項，進度將不會有問題，
3) 我方約需要兩周時間完成系統規格書，待D君正式同意規格書內容後，大致需要一個月的開發時間，期間我會於每周提供一份簡短進度摘要(會面與否視實際需要另議)，
4) Beta發放後，希望對方能在一周內完成他們的測試並提供修改報告或建議給我們，
5) 餘下以一周作最終修改，隨後交付UAT驗收。
6) 專案期間如果還有什麼遺漏的事項，彼此當酌情處理。
聰明的讀者看到以上的內容，想必明白老仙在此已經預留了不少調動空間。至於類似這樣的小型項目，諸君就不必問我為何不做個關鍵路徑圖(CPM)、訂個後備方案(Contingency Plan)、甚或是計算一下掙值(Earn Value)啦！{按一：歡迎讀者提供你的見解。}
好了，有了初步計劃，如期交出問題後，當然就是等待D君回覆啦。D君在一周後回電說十分忙碌，未能解答我方疑問，期間，為了顧及對方的處境和我方安全，老仙只以電郵單獨向D君查詢進度如何。及後，約兩周過後對方總算回答了我方的所有問題，不過電郵除了給老仙外，副本還交到A、L公司的所有高層電郵帳號。
到了這裡，老仙已經感到事態不妙了，我可能又碰上了「專案無賴」(註解見後篇)！
但猜度也於事無補，項目繼續進行，不過兩周期限將至，各方高層真的收到了D君所發出的一封投訴電郵，內文大致是「兩周內遍尋不獲老仙，項目延誤了很多，到底發生了什麼問題！」
生氣嗎？不，這有違老仙另一NO Emotion 原則。在處理了一些小節後(後篇將會詳述)，老仙第一時間將規格書交出，並致電商討內容細節。不幸的是D君並沒有正面回覆老仙的查詢，數日後D君卻背後告訴各方老闆這份規格完全不妥，只是將他們交出的文檔抄了過來，完全不能接受，而L公司高層也因此而要求招見A公司老闆！{按二：事已至此，不知諸位看倌又有何高見呢？}
老仙見慣風浪，這點事兒嚇不了老仙，不過A老闆便急忙希望老仙出面擺平此事(他以為到L公司挨罵一下就好了)，不過老仙深信L公司是不會讓老仙參與這次聲討大會的，如果對方願意我在場，我去挨罵又何妨呢！結果也正如老仙所料，對方要求單獨與A老闆會面，為今之計，老仙只好以電郵將事情始末、時間明細一一道出(內容當然是讓對方百口莫辯)，為了顧全D君顏面，除了對事不對人外，還鄭重告訴對方可能是出於一些小誤會而已，D君和我們已經盡力配合…相信日後合作一定會更為順暢。…如此這般的文件已經是老仙最後可做的事了…{按三：讀者們，你又會如何處理呢？}
回說規格文檔，因系統屬功能提升項目，原規格書重複之處老仙是刻意刪除，只做了一份較為簡潔的文檔。至於如何不成，老仙間接地透過友人去詢問D君修改意見，答案是「不知道」。有見及此，老仙私下又重弄了一份包括原系統在內的一份較「厚重」的文檔出來(新內容部分沒有修改過)，最後透過友人以其名義交付D君查收，最終這份文檔幾乎在完全沒有修改過的情況下通過了。
既然老仙說得出百口莫辯四字，聲討大會之上對方當然是無法辯解(這也是不能讓老仙在場的原因之一)，不過L老闆最終還是對A老闆說「如果老仙有那麼多時間去寫這樣一封電郵，為什麼不花多一點時間把事情做好！」…{按四：如果是你，你又有何感想？}
事到如今，系統當然還是要繼續開發下去，期間應了「梅菲定律」(Murphys Law)所說的「如果你認為會出錯的地方，它一定會出錯！」(仙按：我的課有教哦！)，問題一錯發生，延誤了約兩個月才結案了事。期間我方的問題當然包括了新進人員的經驗不足和粗心大意，而對方於系統交付前當天還不斷提出修改也是禍因。細節不談，以下數點應能提供足夠線索給讀者研判：
1) 聲討大會之後，我方已經回復一貫作風，「盡力」協助對方一切修改事項，
2) 老仙提供了額外的聯絡人員和D君溝通，
3) 正常情況之下，D君沒有再找老仙了，
4) 在一次例外的狀況下，D君在專案之初就沒有列清楚的邏輯發生錯誤，在交付客人前夕發現錯誤而急忙要求我方配合修改，在我方人員無法同意的情況下，D君致電老仙商量對策{按五：這個邏輯謬誤若不修改，L公司的客戶是不可能接受的，改或不改請讀者提供你的見解。}，
5) 一份報表先後提出了五次修改，但是每一次所提出的錯誤或遺漏並不是什麼新發現，在第一次交付驗收時報表樣式本就如此，…
凡此種種，即使系統順利結案，大家也能想像在最終的檢討會議上，L公司會要求把老仙換走，不能再負責她們公司日後的所有項目！
如此失敗的個案，交給你重來一次，會有什麼不一樣的做法嗎？可否給老仙一個良心的建議呢？
訂閱：
文章 (Atom)