【技術e專欄】從軟體專案「需求」問題談專案軟技巧（上）
如果各位時常接觸委外軟體開發專案（不論站在合約甲方或乙方），不知大家認為「需求」問題在專案面臨的所有困難中，「挫折」程度排在第幾位？依可信的統計數據與筆者經驗，如果答案不在前3 名內，可能的原因只有兩個：不是能力強；不然就是真的太強運。
「需求」問題仍然是痛
十幾年前，根據美國統計：8000 個軟體專案中大約有2/3 無法結案或如期上線，這些失敗案例中，約4 成肇因於需求發展或管理問題（12.8％ 為使用 者提供的需求資訊不足，12.3％ 為廠商的需求及規格分析不完整，11.8％ 起因於需求與規格的變更。Standish Group）；事隔不到十年，國內主計處也 對台灣二百多家政府機關作了幾次類似的調查（詳附 下圖），最近一次的數據是，六成多的受訪單位曾 發生專案無法如期驗收的情況，其中，「需求變更」 與「需求不明確以致雙方認知不同」是起因的第1、 2 名，各占四成之多！（97 年的比例較94 年微幅下降，但排名仍穩佔前二）。
知道「做什麼」，只是「做不好」
大家都會同意：在「需求發展」階段多花一個小時排除需求誤解，就有機會多避免專案後期數十、甚至數百小時的變更重工。因為我們已經清楚，需求規格不明確或弄錯重點，即便當初白紙黑字契約明確，但「債」很少不回頭找上門的，結果對業主及廠商都是損失，例如爭論歸責的談判投入，軟體開發重工費用，上線時程延宕造成的機會成本等，更糟的代價甚至不是花錢或花時間就能彌補的！
需求管理「必勝」指南？
為了精簡具體，大部分組織的標準程序只會描述「What To Do」，對於較複雜的流程實務細節，會視必要性另外規範專屬的「工作指導書」或「工作指南」文件，來引導或分享「把事情做好」的方法。例如軟體公司的程式撰寫流程，可能都附有一份對應的「Coding Guidelines」；建構管理程序也常會以「Naming Rules」文件作補充。因此，PM（專案經理）手上還真的缺了一份需求管理「必勝指南」，能夠提供各類專案特徵與問題狀況的索引，讓甲乙雙方權責人員依分類就能立即找到潛在的需求爭議風險，查閱解決相關問題的「絕殺」技巧。
有人說，需求問題的根源在於軟體功能本質上不具形的「模糊」特性，所以期待「風平浪靜」是不切實際的。我們認為，這個觀點雖然說的通，但還是把問題看簡單了，因為除了「模糊」之外，專案本身 就是一個問題大熔爐，隨著案子進展，還會有技術風險、溝通障礙、管控失衡、利益衝突、政治糾葛…等 「複雜」問題，它們都是可以惡化需求問題的催媒。「模糊」與「複雜」相互之間不定期的「作用」，就足以製造一連串的問題情境，讓專案負責人看到「目瞪口呆」，窮於應付。所以我們要說：解決專案需求 問題的知識，其實就是專案管理能力的知識；專案管理能力的知識範圍，除了眾所週知的軟工程序或管理理論，還有工作者在工作過程中所有派的上用場的軟技巧（Soft Skill，如：溝通談判、判斷力、執行力、 人際觸覺…）。
實際上，程序或理論架構大部分不難懂，所以執行的經驗與軟技巧顯然更具勝負關鍵性。更直接的說，因為軟技巧的存在，工作本身才有其真正的靈魂，才能展現它自己的價值（包含個人價值）。常見許多執行者（甚至組織的程序制定者）失了焦，認為只要照著程序步驟進行，自然就會有好的產出與 結果；在苦嘗失敗時，則只會針對標準程序作質疑。其實，很多人都忘了回顧自己施加在執行過程中的每一個細環節與小決策，檢討它們與最終失敗的關連。
千錯萬錯，原來很多不是別人的錯－乙方篇
也許身處乙方的您並不全然同意這種看法，認為很多是客戶不懂軟體的製程與價值，是專案需求問題的主因之一。例如曾聽過乙方PM 強調：「客戶根本沒有『需求凍結』的概念，需求『確認』只是形式，跟他們談『變更管理』也無濟於事。」類似的抱怨固然有其個別的情境因素與困難，但我們在此仍要務實誠懇地提醒乙方：委外合約通常不會載明變 更管理的具體流程，「需求凍結」的字眼更是少見，何況是甲方應該具備哪些「知識」或「體認」的描述。所以，這個例子的問題都還在專案風險應該界定的範圍，廠商在接案前就必須著手評估，而非以「客戶配合，理所當然」視之。
上述提醒，有經驗的PM 應早有體認，我們要強調的是，這個認知不是摘自什麼軟工流程，而是來自專案管理的經驗或PM 的判斷力。就拿同一例子進一步說，雖然客戶「根本沒有需求凍結的概念」，但我們沒有理由否定：甲方在一個案子的進行過程，對軟工製程特性的理解有多少進步，對特定變更管理方法的接納與堅持落實程度有多少改善，還是取決於專案經理本身的「道行」（可擴大解釋為廠商能力）。這種道行不是發揮在特定情境或場合，而是透過一連 串有章法的行事過程逐漸顯露出來的。
就這個例子，我們可以繼續假想，道行較高的 PM 可能會做哪些事來因應需求問題（如右表）。
觀察成功者；勤推敲，重檢討
當然，這個情境只是所有乙方PM 相互砥勵共勉的目標，看來順理成章的過程，實則暗潮洶湧。在如此「軟性」領域，到底是「知易行難」還是「知難行易」根本說不準，筆者的親身體驗是，「好」的 PM 總能帶給周遭夥伴（含甲方）一種「安定感」，也就是我們常說的好PM 自然就有好「運氣」。
怎麼衡量自己作的好不好呢？建議可以挑選幾個您覺得「道行」較高的「偶像」，從其行事特質 或態度，來「假想」他們在與自己相同的處境下會怎麼做。例如：若是由公司裡某個高階主管來處理，他會有什麼舉動？會聚焦哪些細節？哪些過程可能會採用什麼不同的方法或手段…？如果是總經理來當PM 呢？會帶來什麼新的的元素？又如果是任何一個您遵敬且稍微瞭解的企業家呢？張忠謀？ Steve Jobs？這些標桿對象的身價各有不同，如果各位能夠慢慢展現出類似的「火候」，當然您的價值也能水漲船高。探討至此，要先下的一個結論是：PM 的經驗與軟技巧愈強，化解問題的機會愈高，專案的成功率當然更篤定。
同舟共濟同理心 守護專案「乖乖」－甲方篇
如果您是甲方成員，當然希望承包商的各方面能力「愈強愈好」，但前文也提到過，軟體專案的特性即「模糊」又「複雜」，特別是仰賴密集溝通的需求認知，幾乎不可能在初期確保想法一致；系統規模愈大，問題或風險也愈多。兩個不曾接觸的組織在時限內要相互瞭解、配合，並完成合約（RFP）文字指定 的某種「目標」，期待不出狀況是不切實際的。最怕的是雙方誤以為「依據」標準程序或流程要求，在專案初期（如專案啟動會議，需求發展階段等）「有開 會」就是作好了溝通，殊不知「形式上」的共識與確認，只是把「未爆彈」搬回「庫房」，後果可想而知。
但我們不是才剛過完，PM 的能力就是成功的關鍵嗎？您一定也常常在想：「廠商如果找個『好一點』 的PM，就不會有那麼多狀況。」的確，如果「好一點」的PM 代表的只是「多一點」的薪水；且可以定義「必須」好一點的能力項目是什麼；又可以判斷哪個PM 在這些項目有好一點的表現，那麼廠商何樂不為？大家都願意拿「已知」有限的額外付出，去交換重工與延宕的「未知」磨難。然而實務上的情況是：「『好一點』的PM 難以客觀衡量；『好很多』的PM 可能不符乙方成本」。各位要知道，目前（民國100 年12 月）「中華民國資訊軟體協會」所建議 的最新「資訊委外服務人員計價參考要點」，其計算基礎仍是參考行政院主計處「98 年度電腦應用概況報告」對資訊人員平均月薪的調查結果，其中「監督管理人員」（含PM）的平均月薪為66,000 元。
我們認同愈大的案子，需要能力愈強的PM，但大家還是得面臨「多大叫大，多小是小」的窘境，何況須再配對更難以具體化的PM 能力分等，因此許多甲方乾脆透過合約直接指定「可能」需要的PM 年資或實績（「理論上」等於有較好的能力）。但我們要順勢提醒的是，當初甲方所做的預算規劃，有多少比例是打算配置在「好一點」的專案管理上？ 這個配置比例與客戶自己期望乙方提供的管理品質又是否對等呢？相信這些問題都還有爭議，而類似的矛盾與窘境就是目前專案的特性，也是個案設法自尋 出路的過程。看清了這層事實，就應該能理解：為了「如期如質如成本」的目標，與其一昧期盼廠商面面俱到，不如務實的提供「關鍵協助」；以貴賓之姿，消極、旁觀，不如取袍友之度，積極、挹注 。
所謂的「關鍵協助」，當然是以甲方本分上能夠配合的事項為中心，基本上能夠將雙方議定的，甲方應配合工作的目標正確認識與釐清，並能自行掌控相關任務的狀況與成效，對專案來說已經非常有幫助。如果客戶能夠進一步展現「同舟共濟」的心態，特別是甲方的專案承辦窗口或專案負責人，能自發性地對乙方可能面臨的問題或風險，主動提供能力範圍的協助（如在客戶內部的橫向溝通），則破除專案溝通問題的效率必可大幅提昇。
甲乙雙方不可能天生完美契合
我們可以作個比喻：甲乙雙方的距離就像是兩條口徑不一的軟管，兩管必須銜接，雙方「溝通之泉」才能開始暢流，專案工作也才能逐步啟動。雙方接口湊合的愈緊密，水流的功效愈佳；反之則可能造成程度不一的漏水，嚴重的甚至導致接口斷裂。如果現在只能使用膠帶捆合兩管，則乙方PM 就是那段維一的膠帶，孤身肩負著專案成敗的重任；它的長度與粘性一經決定就很難改變，發生嚴重問題時，可選擇「換一條」再重新捆過（小心拆換），只是您無法肯定新的膠帶能否把狀況控制的更好。以上就是甲乙雙方溝通與共識環境的基本寫照，倘若甲方能 理解實務情況的艱困，甚至能積極主動的提供協助，這股挹注將好比一段段自動馳援的「補充膠帶」，不但能適時強化接合度與補漏，必要時甚至能緊急挽救即將斷裂的接口，對於專案執行結果當然影響甚鉅。
進一步說，每一個膠帶長度與粘性的不同，就好比各PM 經驗與能力的差異，同理，大家對於甲方奧援的膠帶（如專案負責人、各窗口代表等）也會有品質的期待。其實客戶能展現「同舟共濟」的態度，已經足以讓廠商滿懷感謝，對專案運作也會增加助力；若甲方「附帶」著優秀的「相關能力」，那麼這股「助力」就有機會昇格為「保證」，而那條「水道」應該會就此「安靜」的工作下去，不再製造新問題。以下我們就順勢羅列一分「好一點」的甲方成員，扮演專案協助角色的行事特徵，供大家參考與同勉：
客戶有三力，萬事都順利
- 熱心且富洞察力：憑藉著對使用者端的瞭解，能識別專案運作的潛在風險，並能主動及時提醒乙方；之於系統需求，能察覺與提醒容易被忽略或誤解的「需求特徵」；之於議題溝通，能掌握特定單位、個人的溝通模式或文化習性。
- 同理心與判斷力：為避免時程延誤，能優先審核確認乙方階段產出，並適時回應乙方之提議，必要時明定內部權責窗口及處理流程（如處理時限 或確認層級）；對於專案的任何疑問或顧慮，必主動查證與釐清；有關決策之權衡應充分聚焦專案目標，以維護合約雙方立約之用意。
- 責任感與執行力：對於同意配合的專案事項，能激勵內部執行者落實執行；為求成效，願意適當採用及選擇有效的監控方法，並能探索爭議或困難的主因，據以持續改善作法。
客戶希望「評選」出好的廠商，其實廠商也同樣期望「遇到」好的客戶，若使用者無心檢討造成軟體系統需求爭議的部分責任，不能客觀體察所要求的 軟體功能在業界的市場價值（即價金合理性）以及對客戶自己的價值（即功能效益或迫切性），一昧要求 「改到滿意」才能驗收，而無視「Give and Take」 的協商模式，那麼如何期望未來能遇到素質愈來愈好的乙方呢？本段最後也有一個結論：業主愈能「同 舟共濟」，加上廠商合乎期待的「能力」，化解問題 的機會就愈高，專案的前景必然一片看好。
多看書是練功第一步
結束了關於甲乙雙方能力的「激辯」，我們已經看得更清楚：流程規範是表演者的舞台（ISO, CMMI-DEV, CMMI-ACQ 等皆同），沒有舞台，就沒有人瞭解主角到底在作什麼；而執行者在工作過 程發揮的「軟實力」，才是舞台上真正的主角。
其實大家都講的出一套類似的學習方法：「我們要先作『動作』的規劃，實作的過程要勤作紀錄（遇到的問題，作過的決策等），工作結束後要分析它們如何影響結果，並要回頭調整原先的『動作』，必要時檢討對『原則』的解讀（簡直就是專案管理的微型版）」，差別在於我們有多「渴望」打造屬於自己「通頭撤尾」的Know-How。這也是為什麼只有少數專案成功（如期如質如成本)，或者某些人負責的案子總是成功的原因。
很明顯，培養能力的第一步還是得從「多看書」出發，手中可參考的「原則」愈多，表示我們愈有機會去正確解讀及轉化別人已經親身驗證的知識果實，然而軟技巧的知識領域相當龐廣，沒有既定的學習規則或順序，端看個人「最欠什麼，先補什麼」。一般而言，將通用軟技巧（如分析、溝通能力等）與領域工作標準（如需求訪談、管理等）整合的「專屬」知識最容易拿來作「速成」學習。例如，「功能需求爭議處理原則」一定比「談判實務」更貼近我們的工作特徵；「誘導正確需求的好方法」總比「溝通高手」更為務實可行。這種「特效藥」（視其品質）對組織 或個人在業務進行上會有最快速直接的改變。而通用軟技巧（溝通能力、問題分析力...）的學習是以深度取勝，故需較長的時間潛移默化，與前述「專屬」知識有不同的考量目標。
建立PM Club 分享成長俱樂部
進一步看，由於每個組織的文化、特性或習慣的不同，對於相關知識的應用必然也存在部分差異。為了就近解決軟技巧上的各種問題，許多公司（特別在乙方）會在制度上設立類似 PM Club 的功能性組織或團體（或相關討論區），專門為分享、蒐集與探討實務上已經充分聚焦的事件，並儘可能將其轉化為有結構的知識。同時，組織也常指定專屬的單位（如 PMO，Project Management Office），適時對相關知識「原則」作「制度化」的評估，期以標準化來提高組織整體的工作效益與經驗傳承能力。
所以不論廠商與客戶，大家當然依然正視著這個問題，持續專注專案管理的進步，我們也不會停止相關努力。本文（上篇）主要是基於對軟體專案需求問題逐漸改善的期盼，從問題本質的角度先提出薄見。次回（下篇）我們將蒐集常見的需求問題，並逐一探討甲乙雙方的因應原則或技巧。各位下期見！