作專案，不是數1.2.3

這幾日來，週遭的一些朋友紛紛傳來軟體開發專案陷入危機的困境，進一步閒聊中，肥蝦發現一個共通的現象－每個專案都像是在寫支大型的傳統程式一樣，按步就班的寫完程式，結果船到橋頭，卻無法自然直。現在台灣的軟體開發環境中主導專案的很多都是早期的一些Super programmer，渠等不論是寫C，寫Cobol，或者後來轉型到OO，在帶領專案之時，依然秉持著千萬人吾往矣的精神，一路斬荊披棘，勇往的往合約的字面規範前進。結果專案不是作不完，僅是不能on Scope, on Schedule, on Quality,那就更不要論on Cost了。

就肥蝦個人瞭解其專案作不完的原因，不是一路往前的苦幹實幹的精神錯了，大多也不是技術上有了絕對的瓶頸，肥蝦所聽到的大概不外乎：商業邏輯不清楚、客戶的要求刻變時翻、規格沒有確定等所謂顧客觀點的問題。

其實很多專案領導者都是非常有經驗的專業技術人員或業務人員，技術人員有著非凡的開發能力，業務人員有著靈巧的口舌之能，但總感覺少了一點東西－誰來瞭解顧客的真正需求。更有甚者，肥蝦聽說某軟體大廠，以及肥蝦以前曾合作過的國外廠商，現在竟然提出要求客戶先光就書面文件提出需求變更，不僅限定提出的期限，更限制了次數。好似這些軟體開發商在進行專案之時，以為專案經理只要在旁喊著：「1、2、3」專案就能一路平坦到目的。

記得肥蝦前陣子看了台北金融系統論壇社的一篇FIN大大回應讀者所問：「現在分行系統的問題在哪裡？」的解答－…沒有花心思在使用者的"動作與時間的合理化"分析，過度專注於新技術的嘗試，忽略了與使用者溝通能力的培養。肥蝦真是心有戚戚焉！科技始終來自人性，也只有人才會衍生出需求，不幸的是軟體專案大都是因應客戶的需求而生。因此專案如果一味的埋頭在技術觀點裡，拋棄了客戶的觀點，那真得是自絕生路了(當然某些人就是有通天的人際關係可以收案，這就不在此討論。)！

記得肥蝦前一個參與上億元的大案子，五個分組中，僅有肥蝦這一組的客戶代表、原廠顧問與我這隻肥蝦，會於中午午餐之時一起吃飯聊天，除了聊一些台灣的風俗民情外，更重要的是多了一個非正式場合的溝通方式。專案雖然由合約而生，但其中真正的含義，可說是客戶與廠商的目標、期望跟壓力的交集。因此當有些合約文字要求的功能過於嚴苛，甚至超出了使用者現今及可見未來的作業程序之時，如果兩者之間能一同面對壓力，尋求中庸之道，那必然可得一條生路。當然，身為一個專案的領導者或者是成員，既然是要收人錢財，當然是要多一分的付出，應付的職責之一就是瞭解客戶現有的作業流程，一些業界間的流程，甚至國際的趨勢。而這部份的訊息其實可得自客戶的內部作業或稽核手冊，或金融研訓院的研習，或坊間的補習業者的課程，或專業書籍，這些均或多或少有所助益。如果真得幫不了忙，那就像有次肥蝦去金融研訓院所上課問老師的問題：「要是沒有太多資料，那些交易員也無暇幫忙，那怎麼辦？」那老師的回答很妙，卻也很貼切：「那你就站在他們的後面看三個月，那就會了。」

就如史考特‧伯肯(Scot Berkun)所著的【讓事情發生】的第三章所強調的：一個專案涵蓋了商業、技術、顧客三種觀點。可是若要問專案可不可以拿到最後的CoCo，其實只有一個觀點，就是顧客的觀點。如果一個專案能順利的讓客戶與您的觀點間進行協同或者妥協，那這個專案成功是指日可待的。

記得肥蝦在一些軟體開發課程與軟體開發書籍中所看到的一些軟體開發方法論－瀑布模型、螺旋模型、快速應用軟體開發、極致程式設計、功能驅動開發－雖然各有論述、各有優缺點，但他們的目的都只有一個，就是將軟體開發on Scope, on Schedule, on Quality, on Cost的完成。就肥蝦個人淺薄的觀點：「不是那個開發方法一定 work，而是這個開發方法可否幫助你解決問題！」在PMBOK 2004的6.5發展時程之時，風險也是一個投入的因素(PMBOK 2008拿掉了，換上Enterprise Environmental Factors)，因此如何因應專案可見的風險，選擇一個迂迴漸進之路也不失為一上策，美其名可曰：快速應用軟體開發、螺旋模型等等等，但管他何名，可如期收錢才是重點。

如果顧客的觀點真得是你這個專案的最大問題與挑戰！也沒其他之路，那你準備好了預備在使用者的背後站三個月嗎？你明知山有虎，而你也僅是要回家看兄長，是否一定來個武松景陽打虎！肥蝦真得覺得，作專案，不是會喊「1、2、3」，還是需要一些其他見風駛舵的技巧的。