工程變更一直是系統/軟體工程管理裡的重要課題，且是工程實務中，常見的痛苦，固然，這些痛苦的來源，部分是源於供應者發展團隊，但主要的來源其實是無視於系統/軟體工程常規的獲取者，這類的獲取者，常常在RFP中對於獲取範圍只述及概要，寄望於見到雛型時再來增質加量，但由於獲取範圍僅述及概要，專案的預算當然也是嚴重低估，但最終都希望供應者能「識大體」地吞掉。儘管，面對供應者對於需求不清及實作範圍太大，獲取者總是以一付無辜的表情對供應者說：「你們是專家，我們不懂工程！」，然而，獲取者所做的常常卻是執意讓「滿足需求」，凌駕於工程方法與專案總體要求和基準之上，供應者如果不從，有些就可能以停權，或是公告其為「不良廠商」來要脅，或者以後續維護案利誘，使供應者為了所謂「更長遠的業務機會」放棄了應有的工程方法，以便能更快速地「滿足」獲取者的需求，從而建立良好的「互動關係」。問題的處理常常是在使用者的工作環境裡，於使用者「指導」下，進行「變更」、「更正」、「新增」，使得在沒有太多時間好好思考各種衝擊與風險的情況下，不斷種下後續需透過工程變更解決之問題、錯誤、及矛盾等的惡因；而許多時候，對雛型的「變更」或「更正」，卻常常變成同專案其他系統/子系統發展的阻礙，連帶使得整個專案進度不斷落後，並使成本不斷增加，儘管供應者忍痛硬吞，但最後的結果，可能還是遭到罰款，甚至背負不良廠商的惡名。

對於專案期間不計成本的需求變更，供應者是否都要照單全收呢？若不想全盤接受，是否有其他應對作法呢？或許，下面的案例，對於獲取者與供應者雙方都能夠有所啟發。以下為本會所協助處理實際案例之一，其中所提到公部門與廠商、案情細節等的名稱與數據，基於保護相關的當事者，均做了編造處理。在本案例的研討中，除了描述案情的相關重點及本會作法外，亦將提出相關的經驗教訓，以供讀者參考。

【案例背景說明】
獲取者(AE事業公司(化名)，簡稱AE公司)為一家位於高屏地區之公家機構，基於業務發展之需要，斥資近千萬，以兩年的時間，委外發展機構的業務管理系統，該系統計有6項系統及從屬近80項子系統。並於200X年第四季，根據政府採購法公開招標，採最有利標方式決標，由設立於台北市，在本類型專案有豐富經驗的雅痞仕科技服份有限公司(化名)(Yuppies’ Tech Ltd.，簡稱YT公司)得標。該案於200Y/01/01啟動，並應於200Z/12/31完工結案，YT公司計畫以專案小組進駐AE公司的方式執行本專案，此一作法將增加專案人員食宿及南北往返之支出，而由於人員係全時投入，因此該專案組成員之薪資，亦須由本案營收全部支應。

由於本案為AE公司整體業務管理系統，利害關係者牽涉AE公司的各部門人員及AE公司的客戶，狀況錯綜複雜，缺乏此類專案經驗的AE公司的本案委外負責人，並未能於有限的時間內，完成需求蒐集的工作，代之以在RFP的委外服務工作說明書中，列出系統與子系統的名稱，並以如下的敘述帶過：

“以下提供本公司需求之子系統名稱，以為系統範圍。並提供主要作業內容，唯主要作業內容僅供參考，實際作業內容仍應以實際訪談後，產出之系統分析文件為主。”

另外，基於AE公司所選定的鯊魚齒狀軟體開發模式，在雛型製作與展示前需完成需求分析的工作。而所謂雛型分為兩階段，第一階段為平台雛型，第二階段為各系統雛型。其有關的敘述如下：

“第一次雛型展示係指廠商必須在簽約完成後，立即建置本公司之基礎平台，包含使用者權限管理、表單權限管理、應用程式選單管理…等等維持應用程式運作之基礎環境。並且需選定人才招募子系統，先期完成，做為初期驗證之用，雛型系統驗收通過後，始得進行進階設計。”

系統完成系統分析及進階設計後，實施第二次雛型展示：

“將表單、報表之設計畫面展示，確認無誤後始得進行系統發展。”

YT公司於200Y年六月完成第一次雛型展示，同時完成人才招募子系統，並向AE公司請第二期款項；至隔年三月，完成全部6項系統的系統分析文件，並持續進行部分子系統的開發階段，另準備向AE公司請第三期款項。200Z年五月向AE公司請款，並獲支付。惟被視為付款標的之系統分析報告書的審查，AE公司相關人員，並沒有全力配合，甚至於出現 “需配合系統設計增刪相關功能”(代表AE公司審查人員，並不瞭解該如何審查系統分析報告書，亦不清楚自己的需求是否都已納入)之類的審查意見，但基本上審查意見都因審查意見表的設計，被預設為 “尚稱符合”。自此而後，凡是完成雛型之系統，即不斷地修改，變更不斷產生，也因此，使得5/6以上的新子系統無法依排定的期程進行發展工作。新功能開發工作與修改工作不斷交互進行，AE公司覺得YT公司工作沒有章法，系統的作業流程顯得極為不順，常常有錯誤出現，其他系統開發的進度也有問題，於是中止後續的付款直至年底(200Z年底)，但是仍要求YT公司要繼續將系統「好好」完成。由於YT公司收不到新的款項，財務出現缺口。YT公司認為根據契約，系統分析文件劃定範圍外者，都是YT公司的額外工作，也因為這些額外工作，造成其營運成本的增加，也造成專案執行的困難。為了爭取自己的權益，並要求AE公司就新增與修改的部分(總共因此增加了3,244人時的工作量)，支付相對的工程款，遂向法院提出告訴，請求法院強制AE公司支付該筆額外的工程款項。法院方面認為，案內有關於變更與新增，及合理之工時，應提交專業之第三方機構鑑定，以作為判決之依據。遂將該案採購契約書、專案管理計畫書、系統分析報告書、需求訪談紀錄表、及YT公司要求AE公司支付額外工程款的變更項目(新增131項、變更105項，合計236項)、變更內容及兩造之答辯書內容(含佐證附件)等，交由中華民國資訊軟體品質協會(以下簡稱「本會」)鑑定。

法院來函

【鑑定概要及結果】
本會接獲此項鑑定協助請求，即在理事長的指示下，成立跨產、學、研領域的鑑定小組，並於初期完成採購契約書與專案管理計畫書的研審後，訂定下列各項為鑑定工作之原則：
1.以採購法及該案契約為依據。
2.系統基準在系統分析報告書。
3.不預設系統「基本功能」。亦即，不認為○○系統，即應有ΔΔ功能。
4.不以個人技術經驗，行使主觀推斷。
5.鑑定小組成員於鑑定工作期間，不得與兩造相關人員接觸，避免左右鑑定之結果。
6.最終鑑定結果，以合意(consensus)決做成。

同時，採取下列概念與作法進行鑑定：
1.未明述之需求列為「無從認定」。須由獲原告或被告，提供資料，以進一步評估。
2.不評論開發者系統規劃的正確與否，僅聚焦於分析報告書的內容(亦即範圍內的需求)。
3.訪談紀錄僅供參考，不視為系統分析報告書的要件。
4.鑑定技術採用符合國際標準ISO/IEC 12207與國家標準CNS 14837之審查過程，其細節則援引電機電子工程師學會(IEEE) (屬於工業標準)，所訂IEEE Std 1028軟體審查標準中之技術審查技法。技法之核心為可追溯性。
5.鑑定之步驟：
(1)了解變更需求(包含內容、目的與提出者)。
(2)確認標的系統/子系統。
(3)異同識別。
(4)結果判定。其結果由鑑定小組成員，以合意決方式，將之歸屬下列各項之一：
　? 符合原契約應承攬範圍。
　? 超出原契約應承攬範圍。
　? 無從認定。

鑑定結果中，共有118(含新增與變更)項，因無法判定原始狀態，或需求內容，列為「無從認定」，需有進一步資料，例如：變更內容、變更理由、未修改前的畫面、修改後的畫面、修改前的使用案例說明(含商業規則)、修改後的使用案例說明(含商業規則)、修改前的表單、修改後的表單、活動圖、循序圖、領域圖(類別圖)…等等，方能做完整的判定。超出原契約應承攬範圍者，則共計112項。

在本次鑑定活動中，工作範圍雖涵蓋合理工時之鑑定，然而，由於工時係由原告主觀提列於各新增與變更項目上，且無佐證資料，其專案管理計畫書中亦未提列專案變更管制程序可資查考分析；另外，法院轉交之文件中，亦無變更管制流程相關的文件(例如，變更請求書、變更建議書等)，亦缺乏能顯示YT公司專案組人員，對變更需求接收及處理的工作日誌。故無充分的資料，以執行工時鑑定。


【經驗教訓】
在本案例的鑑定中所見，有關專案執行與鑑定工作的相關經驗教訓，整理列示如下，以供讀者參考。

1.　專案的成功有賴於獲取者與供應者雙方的合作。而合作的第一步，乃是獲取者應能了解自己的需求，提出自己的需求。一般業務環境中的資訊系統，因為有實際業務過程可資類比與模擬，即使需要做業務過程改進(BPI)，亦可透過各種方式需求發掘的技法，蒐集充分需求，以完成經費的編列與發展時程的估算；而像武器系統、飛行器等複雜操作環境裝備的操控、管理軟體，才可能需要採取螺旋式(Spiral)或演化式(Evolutionary)發展生命週期模型。

2.　獲取者即使在RFP階段的委外工作說明書中，已明確且鉅細靡遺地描述了所有的需求，透過訪談，與供應者的開發人員確認(confirm)需求後，對於開發人員所提出的需求規格書(分析報告書)等，仍應仔細審查，以找出可能的遺漏、錯誤、與不一致事項，並要求發展者確實改善。其中，亦應注意其與契約(及其附屬文件)間的追溯關係是否建立。

3.　雛型法是可用的開發技法之一，但是應注意雛型的意義，應避免產生的雛型成為系統更進一步發展的絆腳石。

4.　務必為專案建立一份在獲取者與供應者間具有共識的變更處理程序，並應建立在此程序中所使用的表單，例如變更請求書、變更建議書等。為使變更處理程序能被遵循，即使專案開發團隊需進駐至獲取者方，工程師應避免與使用者過於接近，而以專案經理或發展小組長，作為與獲取者或使用者代表的對口，包括變更、修改、新增等的提出。否則，所有的變更處理將失序，尤其當系統進入試營運的階段時，使用者臨時提出的各項變更，將被照單全收，並疲於應付。最終的結果，就會像案例中的情況一樣。

5.　重視與落實工作日誌(log)的填寫。雖然在軟體發展中，所有的程式碼檔及電子式文件都會有產生、修改的日期與時間，但是這些日期與時間，是否能夠完成連貫並說明工程師一天的工作？顯然是不行的。所謂的工作日誌(log)，其所記錄的是工作人員在有新的任務或動作產生時，就要依時間把人事地物詳實記載下來。當然，這可以是一份電子檔，但是就迅速與便利性而言，紙本將更勝於電子檔案，因為紙本可以留下的不只是時間、工作事項、還有登錄者的字跡(某種程度上可避免造假，短時間以copy&paste大量製造)，可以跨系統登錄，停電之下仍可登錄。而對於像本案例中的工時計算，就有很大的助益。工作日誌(log)與工作紀錄(record)是不同的，一般紀錄通常記得極為籠統，點到為止，只要知道曾經做過那些事，或是相關的要點即可。但是工作日誌，則是在工作項目或工作流向改變時，就要按時間登錄下來。以前面有關的變更的工時計算部分為例，就鑑定的立場，希望看到的會像是：0900抵達辦公室0910電腦開機0920○○部門使用者○○○來電表示其發現○○系統中○○功能的畫面無法執行0925根據使用者所述，於○○系統之○○功能畫面中輸入XXXXXX資料畫面顯示網頁無法顯示0931使用○○服務連接至○○○開啟○○○程式檔案檢視程式邏輯0935修改YYYYYYY之邏輯判斷0950回存程式檔0955重新開啟○○系統中○○功能的畫面並輸入XXXXXX資料程式顯示查詢結果1000回報○○部門使用者○○○……。當然在專案中，工作紀錄與工作日誌兩者將併存，此時工作紀錄會是開發小組的全日工作概要，而每一位專案成員都應有自己的工作日誌，個人的工作日誌可以成為工作紀錄的附件。

6.　用例點不適合用於變更工時的估算。在專案的工時估算中，對於使用UML技術的組織，可以採用用例點(Use Case Point, UCP)方法。但是對於系統發展到一定程度後的新增、修改、更正所耗工時，則不能採用此方行之，亦不能採用功能點法(FP/FFP)。不論是新增、修改、更正，多半不似專案開始前，以Use Case顯示的是，未開發的完整功能或任務情境。因此，若以用例點來計算新增、修改、更正的工時，就必定有極大的誤差。每一個用例點，考慮的是一個完整的功能，其中會含有數種情境(以數個IF-THEN或CASE結構呈現)，而新增、修改、更正，針對的可能只是一個Use Case中某個情境的變更，甚至於是改一小行字或是按鈕的大小而已，而且每一個用例點的基數就是2.5至3.5個人日(20至28人時，視經驗因子而定)，但一個完整的案例以及Actor的組合，就不只一個用例點，由此可知UCP並不適用於新增、修改、更正之類工作的工時計算。因此，本會在對實際工時的鑑定，仍需見到登錄詳實的工作日誌或是完整的變更管制文件才能做進一步判斷。

7.　對於供應者而言，詳實的工作日誌、工程產出(含各階段的工作產品) 、專案管理資料，並不只是為了讓最終的產出更有品質，亦是為了可能的契約爭議解決做好準備。沒有文件的佐證，獲取者可以賴說供應者沒有依照契約執行。

----------------
引文: