[專案管理] 解救您的專案 - 如何面對不斷變更的需求

作者: Fred Wang 原作日期: 2011/10/2

       如何面對不斷變更的需求，要了解為何客戶會不斷變更他的需求，有沒有可能是派來談需求的代表，對業務的需求不夠了解，專業能力不夠，提出的需求代表性不足，提出的不是最終用戶的需要，也許是對系統化過程經驗不足，也可能是尚未成熟的需求(只有想法)，或許是新業務或變動大的業務，尚無法訂定明確的需求。這些問題要先了解，才能真正找到問題的根源。(先確認到底專案所有相關影響人有哪些，他們的期望與需求各是什麼，客戶的代表是否有足夠的授權）

       解決不斷變更的需求，需要建立一些管理程序，而這些管理程序也要看雙方合作的經驗與信任的關係，如果合作經驗少，信任度尚未建立，需求分析與變更管理的過程都需要更嚴謹(成本較高)的方式來進行。

1.    需求蒐集與分析

a.專業的了解 : 系統分析師不僅僅只是蒐集客戶的需求了解客戶業務流程，還須對客戶的產業與專業領域有更多的了解，最好也懂得以一些大型系統作為最佳案例，例如SAP ERP各模組功能，在需求討論的過程可以提供客戶一個比較好與正確的引導，以期能讓客戶對需求考慮完整周詳，減少未來的需求變更。當然要求SA具備專業顧問級的能力，可能不太容易，但是這個能力的大小將直接影響專案的進行。一些大型專案(在中大型公司)會引進專業顧問，將業務流程標準化與合理化再進行系統化。

b.需求溝通會議 : 需求的提出與需求變更，透過正式的需求溝通會議進行，任何決議都有紀錄，紀錄都有簽字，且須通知主管，而不是一通電話或eMail私底下就決定，如此會讓客戶(需求提出者)，更審慎地制定需求與嚴格地面對變更。

c.雛型化需求確認 : 由於使用者的需求變化大，也許是業務面變化大，也許是新的業務需求，可以採用雛形化的需求確認方法，透過多次需求訪談，快速雛型建立與確認，將需求談定。如果系統龐大，則應該區分功能模組，逐一確認模組。d.

d.使用高生產力的工具 : 由於雛型開發法可能的成本高於瀑布法，因此，使用可以快速開發雛形且未來容易轉換成實際系統的工具才有較好的生產力。

e.累積經驗 : 最好每次專案可以累積一些雛形，樣板或模組化的功能，不同應用領域累積不同的專業經驗與設計雛形，可以讓這個過程能夠更為快速。當然對於需求不明確的專案，專案經理必須估較長的需求確認時程，與雙方談定需求確認的方法，以避免爭議。(需求合理性是另外一個議題)

2.     系統設計

需求變更是專案過程中常見的現象，因為需求變更造成整個架構變更，全部或多數程式要重寫，都是系統設計開發人員要設法避免的。因此有經驗的設計開發人員會採取彈性的設計與開發手法，預先考慮可能的變更，提供系統較好的彈性，重點列出如下 :

a.彈性的架構 : 將系統設計得更為彈性，讓變更時的影響最小，設計的彈性包括系統架構每一層次都獨立化(如使用者介面與商業邏輯，資料處理區隔, Web設計上Javascript, CSS, HTML區隔，使用MVC架構等)

b.程式模組化 : 系統的開發最理想的是像堆積木般，將既成的模塊加以組合就可以完成整個系統，也就是採用庫存程式庫，再加以組裝。或是先用標準的庫存程式建立半成品(標準次系統)，在上面加以客製化的程式來完成整個成品。

c.參數化設計 : 系統中可能變動的部分予以參數化，可以透過一個設定檔或介面進行變更，這些參數可能是系統參數或由使用者自行變更的業務參數。

這些能力與開發團隊累積的開發與系統架構的經驗與累積的程式庫有關。

3.    變更管理

a.將變更管理列入合約 : 專案一開始就跟客戶談好變更的方式與流程，而且要在合約中註明。另外，上線後提供多久或多少次的變更支援，在合約訂定保固的條文。

b.保留彈性的時間 : 專案時程最好也留下一些彈性的時間可以面對一些小型的變更，而會影響時程的大型變更就須雙方談定否則不能貿然進行。

c.變更過程要有變更記錄 : 專案會議需有會議記錄外，變更也需有變更紀錄以記錄需求變更的原因，變更的單位與負責人，主管，進行變更的影響分析，造成的成本增加，對專案時程的影響等，且必須雙方負責主管同意才能進行變更。

特別是對專案越後期的變更，造成影響越大，如果沒有做好變更管理，釐清責任，將大幅提高專案的風險。

       如同軟體品質管理，要做到多嚴謹，訂定怎樣的品質標準與要投入的成本多少有關，需求與變更管理也是一樣，都應該有成本觀念。多數專案的失敗，往往發生不斷延長的時程與不斷增加的成本。

推薦相關閱讀 :

1.    怎樣控制需求變更 , ITEye, 2008/11/5

2.    企業如何應對客戶不斷變化的需求，2011/6/10

3.    需求總是變化，程序總在修改，2011/5/19