我們的客戶在軟體開發過程中不斷提出新的需求或變更需求,專案經理鑑於往後持續專案的獲得又不敢說什麼,造成我們開發團隊的困擾.尤其每當訪談需求完,客戶堅持不簽認...

不知是否有人對此能提供其實務經驗與做法..

謝謝!!

我們比較單純的作法是把你的變更跟規格需求納入合約規範中才有依據.

一開始的報價範圍的確定就要有個規範,後面的需求訪談才不會被無限延伸,不過這個又跟客戶有點關係,某些業務或專案經理為了後面的案子答應修改或變更,但是雙方沒留下任何文件,造成需求無限延伸.

客戶不簽確認,基本上我們的合約尚有定義是不會製作的.

這樣也許不是最好的作法,但是是適合自己公司的方式.

在專案中“需求會不斷增加”，基本上就是不會做需求管理使然。

需求管理的第一步是要“定義與分析問題”。客戶所以要採購或開發某一系統，必然是要解決真實世界中的某一個問題或為了把握某個機會。如果，所有專案中的利害關係人對這一點没有共識，在專案的過程中一定會發生許許多多的問題。

對系統要解決的問題有了共識後，需求管理的下一步是要“了解需要”。不論是定使用者需求或系統需求的人，都要對使用者的需要做徹底的了解。但是定需求的人(系統分析師)多半不是使用者，所以，在這個時候使用者一定要積極參與。如果，使用者參與的不夠，將來也一定是問題層出不窮。

再來，系統分析師透過與使用者的接觸後，對使用者的需要有了徹底了解之後，還要能把它們轉換成系統需要具有的“特性(feature)”。當找到系統特性後，就要針對這些特性加以列表管理。其中最重要的就是依其重要性將它們排序，而這個重要性是以使用者的觀點來定的。如果，沒有這麼一張依重要性排序的系統特性清單，一樣在專案後期會產生許多問題。

以上這些都是需求管理的基本功，致於深入的細節，就要自行去研究與學習了。希望您能儘早找到解決這個問題的方向，祝福您 !

軟體品質協會資深管理師 周茂松

個人認為這個問題牽扯可以很廣，以個人想法，如果需求的部分不能在 pre sales 階段就達到一定的共識，在專案進行中，需求的變更通常是沒法避免的。如何說服客戶相信專案團隊的作法 (專案團隊導入專案與開發系統的方式)，會是一個需求是不是可以容易掌握並避免無限制的變化或是成長的重要因素。

個人認為或許比較好的方式會是 (當然這其中還要看團隊的 readiness)：

1. 如果業務有辦法讓客戶認知，本案的需求在成案以前 (就是 pre sales 階段) 是很難界定到一個夠清楚的情形 (看 readiness)，建議可以切割專案成為規劃案與導入案兩案。目前蠻多的實例在市場上。當然這除了要說服客戶，專案團隊也有一定的風險。

2. 一樣前述的情形，建議設法與客戶將合約簽成需求確認的部分是以賣人力的方式計價。一定的時間內如果不能談定，是不是就該延長時間與費用，或是就目前所談定的確認系統的範圍，進而做開發。

以上兩點的癥結在於在 pre sales 階段專案團隊 (很多時候主要是業務) 是不是就可以說服客戶，採用專案團隊建議的方式來簽約，確保專案最後的成功。

如果在 pre sales 階段其實談的不是很順利，但是因為某些原因專案又一定要接，那在專案的執行過程當中，原先 pre sales 階段的努力必須繼續，在專案過程中，專案管理與需求管理的功夫就更是要花大功夫，避免最後的損失。

Thanks.

----------------
Thanks

把困難又不知道如何解決的問題推給別人去處理，不失為一種解決問題的方式。不過它不徹底，而且，經常使用此一方法，會喪失許多難得的成長機會。

從專案成功的標準－如質、如期、如預算－的角度來看，專案的籌獲方與供應(或建置)方其實是在同一條船上的。也就是不會發生：只有己方贏而對方輸的情況。如果，能夠接受這樣的觀點，那麼，一個專案不論在實務上，將它切成多少個合約(次專案)，終究要有一個小組出來扛起“需求管理”的責任。否則，專案的範疇是不會得到控制的。

扛起這個責任的小組，也必定要帶著整個團隊(包括籌獲方和供應方)一起從這三項基本功夫開始，一步一脚印的往前走，中間不能落掉任何一步。否則，專案中其它的努力，都可能被此一妖魔鬼怪所吞噬啦！當然，只有這些基本功還是不夠的，一定要搭配其它的措施，才能把“需求管理”做得徹底。