【交流園地】資深PM談軟體開發專案
經常聽到軟體委託方（甲方）專案管理人員抱怨：「不了解軟體開發，但被長官指派為專案負責人，不得不為。但實在不知道過程看不到摸不到的軟體開案要如何管理?」 「專案管理」本身就是一門「軟」學科，它有許多相同的管理理念，但還需要更多「管理」軟技巧，才能讓專案進行得更順利與成功。本文試著以簡單的方式依專案發展時程讓甲方了解如何進行軟體專案管理。
第一招 選最適合的廠商
用「男怕入錯行，女怕嫁郎」來形容甲方的選商也不為過。甲方想要找一個合適的廠商來協助其開發軟體專案，而乙方何嘗也不是如此，希望找一個優良的客戶，彼此可以配合，乙方希望所提供的方案可以協助甲方解決問題，而也可以從中獲取合理的利潤。
甲方在選商的過程可依自身組織的採購方式進行，但正因軟體專案看不到、摸不著，非常依靠廠商的專案能力與人力，故在選商過程最忌諱採用「選最低價的廠商」的方式進行，而應該採「選最適合的廠商」的方式進行。
在遴選的初期需要準備預計委託專案的業務範圍、使用人員範圍、預計時程、安裝地點、限制條件⋯等，讓有趣興的軟體廠商對於欲委託的專案有一清楚的認識，以免雙方因「誤解而結合」，走向專案失敗的第一步。在選商的過程中應有選商評分表，並組成評選小組，建立選商評估方式讓選商得以較客觀的進行，淢少因某人的意見而抹煞眾人的意見。進行選商時可請廠商進行簡報、展示等。評選小組也可對於廠商進行信譽評估、實際拜訪廠商等，讓選商的過程可以更全面更透明。
第二招 各取所需 沒賺錢的生意沒人要
在甲乙雙方的軟體委託案中，雙方分別代表了自己所屬的組織進行本案，在專案金額已固定的限制下，雙方基於「各為其主」的心態，希望在合約的進行中獲取最大的利益，因此在先天上彼此就有「對抗」的成份在，但軟體專案卻又是非常依賴雙方的人力及能力知識，當雙方議定專案範圍、時程及委託價金時，即應將此「對抗」心態降到最低，而以「合作」取代。甲方專案管理人員需要了解讓所負責的專案順利的如期如質完成並順利上線使用，才是專案的最大利益，而不是在專案過程中從乙方爭取了多少合約外利益給自己的組織。甲方專案管理人員需要清楚的知道，乙方公司一定是一個將本求利的公司，若是專案不論長短期都沒有利潤，彼此的關係也不會維持的太久。
第三招 專注成本、時間及範圍
談到「專案管理」，就必需要先了解專案有三個限制：成本（包含人力、設備、金錢等）、時間及範圍。而這三個限制構成專案產出物的品質。而這三個限制的變動會影響產出物的品質，換言之，若這三個限制有任一個變動又想維持原來的品質，那就需要改變其他兩項。
或許有些甲方的專案管理人員會說：「在我的經驗中，即使要求了廠商一些合約外的項目，廠商仍然也如期的交付所約定的產出物。」其實在要求了合約外的項目（範圍的增加），乙方的專案施作團隊為了維持產出物的品質，可能採取了投入更多的成本（投入更多的人力）或是投入更多的時間（專案成員加班）。也有可能採取降低品質，以滿足原來成本及時間的限制。
因此，甲方對於專案同樣會面臨有三個限制，只是沒有乙方那麼明顯與直接，這也表示甲方同要需要採取各種專案管理的方法以完成專案。
第四招 定期的專案會議是必要的
甲方對於乙方專案經理所提出的專案計畫，不要抱有廠商一定會作好的想法而不去理會其「專案計畫」，應要仔細核對其工作項目及產出對比於合約的工作範圍是否有遺漏？ 逐一檢視乙方所安排的時程計畫及所配合專案組織的人力及工作量，審視乙方專案經理在工作項目的人力分派計畫是否合理可行。另在工作計畫上常會遺漏甲方所需配合工作項目的工期需求，在專案進度計劃時也需一併思考。
在專案進度計畫中，最細的工作項目時作時程最好不要太長，大約是一到二週，甲方不一定每一最細的工作項目都需要檢查乙方是否有達到，可以用抽查的方式，如此較可避免乙方時程有延遲時無法查覺，導致嚴重延遲無法挽回。
定期的專案會議是必要的。在會議中除可了解專案的進度，也可彼此協調雙方應處理的事項，及追㾈雙方上次會議待辦事項，若專案執行有所偏差及問題時，也可在會議中進行討尋求解決方案。
第五招 需求確認與管理是最最重要
執行一個軟體專案，無非是要解決甲方某一特定或是某些現在已存在或是未來會遇到的問題，而這些問題即是需求的根源，問題/需求應由該業務之負責單明白敘述，甲方應有固定的人選能敘述所想解決的問題及需求，若是有跨單位的業務流程問題，甲方更應有可整合的人選來統合不同單位之間的差異與矛盾。切記不要把不確定/不明確的需求丟給乙方專案，千萬不要認為：「乙方是專業的，他們可以解決的」。乙方是資訊的專業，但解決不了甲方部門間的需求矛盾或是需求的不確定性。
乙方資訊公司在軟體開發時，都會要求需求確認、系統分析確認⋯等確認的工作項目，「確認」的工作是有必要的，用以溝通甲乙雙方就需求的了解是否有偏差。甲方的管理人員應正面看待此要求，文件看不懂，可請乙方人員說明，在確認中一定要檢查文件是否滿足原來的需求。需求確認的確認需與需求提出為相同的人員。
甲方所面對外在的環境會改變或是人員的想法會改變，相對應要電腦化的資訊系統也會需要跟著改變，會改變是正常的，但不因會改變而認為：「反正會變，為何要確認？」。經確實確認的需求、設計等項目是處在彼此了解，結構穩固的狀態，對於未來的發展是可期待的。而在「確認」後的改變就必需進行管理，每一改變都需評估對專案在成本、範圍、時程、技術等的影響等，並取得到雙方的同意，讓原預計要發展的結構內容維持在一穩固的狀態。
第六招 測試腳本、測試小組也要量身訂做
一般而言較負責的廠商會提供給甲方測試報告，甲方專案管理人員在開始進行測試前，可就兩個面向先行檢視，檢視所設計開發的系統是否滿足原先彼此所確認的規格，是否有所遺漏及不符處？檢視乙方所提出的測試報告是否含蓋了所要開發的功能？測試的順序是否展現了甲方的業務流程順序。
甲方在進行測試時，應組成測試小組，小組人員最好由原提出需求及確認需求的人員所組成，在測試之前應先準備測試腳本，若是廠商有提供腳本，可拿來參考，但切勿只用廠商所提供的腳本作為測試的腳本，以免測試的案例不足及偏頗。
在測試過程應詳細記錄通過與不通的功能，特別是不通過的功能應留下錯誤的佐證資料，以便廠商就錯誤問題進行修改。測試與錯誤修正一般而言不會重疊進行，而是以不重疊的方式交替進行，主要是為版本管理，讓測試時是在一個穩定且明確的版本上進行。
若是乙方所提供的軟體系統經多次測試與修改，在問題收斂到某一數量，雙方覺得留下的問題已不嚴重，可以上線使用時，為確認原已測試過關的功能不因修改其他的問題有所影響，需要重新再測試一次。若是所開發系統會有比較多人同時上線使用，或是有系統反應速度的嚴格限制時，就有必需作壓力測試，這類的壓力測試，需要使用工具，工具及測試一般而言都由廠商提供，而測試的範圍可選擇作業比較頻繁或是較重要的作業來進行，若是預算、時程允許也可以業務流程為範圍，在流程會用到的功能均予以測試。除有特別原因，一般軟體系統在正式上線使用前會進行平行作業，讓新系統與現有系統或是人工系統平行作業一段時間並同時進行比對，以確保新系統上線時的正確性及穩定性。
一般而言軟體系統很難作到找不到問題（Bug），因此大概無法作到「沒有問題，才驗收的條件」，一般驗收的最低門檻大概是：「需求規格範圍內屬業務流程內之作業都可正常運作無誤」，當然一般衡量標是：「該軟體系統可上線使用了嗎？」。另驗收條件也要以合約規範來進行，若是合約規範不清，也可參考甲方組織內類似案件來進行。
第七招 善用同業經驗或是資訊單位協助
甲方專案管理人員在進行專案管理時，除可請教同事外，若是組織內有資訊單位，亦可請其協助提供支援，特別是在技術上。若是經費許可，專案有其必要性，也可尋求其他的資訊相關之管理顧問從第三者的角度協助進行專案管理。
結語
資訊軟體本質上在未見到成果前較難以文字及圖型說明，在執行過程中也較難清楚看到全貌，而工作與工作之間先後順序的強制性又不如其他工程類專案強烈，施作過程全靠工程師人工所生產，因先天上的不同，軟體專案管理也相對的複雜且難管理。要讓資訊軟體專案成功，甲乙雙方的專案管理人員，不能只有「各為其主」更要互助合作才有可能成功。