記得老仙早前在發表自家的座右銘「誠信有效溝通技巧」時，就有朋友問道：「這樣豈不很吃虧？！」對的，在現今的商業世界裡，這樣真的很容易吃虧，老仙也平白吃了十幾年的虧，不過那又如何？混到今天也總算還能問心無愧，沒有多年來吃虧的經驗，那有老仙今天的江湖地位！哈哈！
不對，這樣的回答有違老仙「有效溝通技巧」的原則，不過，如果告誡青年才俊吃虧就是你撿到的便宜，恐怕沒有幾人能聽得進去吧。既然如此，這次老仙就來個突破性的嘗試，把一個真實個案拿出來和大家分享，當「專業」碰上「無賴」時，老仙是如何去吃這個虧。本文分前後二篇，前篇主要是敘事，希望讀者能慷慨留言，告訴老仙你會如何面對這樣的問題。至於老仙的處理手法和背後原因將會在後篇中詳細道出，不管你認同與否，希望透過這個故事能讓老仙與讀者有個正面的交流機會。
專案項目背景
老仙至今還是一眾小公司的顧問(仙按：金融海嘯下，愈來愈少了…唉)，有時候會為以專案經理身份待他們處理一些專案項目，早前有這麼一個為期三個月的小型軟體開發項目：
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公司會要求把老仙換走，不能再負責她們公司日後的所有項目！
如此失敗的個案，交給你重來一次，會有什麼不一樣的做法嗎？可否給老仙一個良心的建議呢？
