要注意兩點：
1.真正的需求可能很深，用戶沒有也無法抽象表達，需要通過迭代挖掘。
2.需求也可能會變，系統必須快速跟隨變化，這些J2EE系統就體現巨大優勢。

 Re: 失敗的經驗
 
發表人: youngS
 
我個人是這樣認為的：

首先，做項目就要有把項目做到最小規模的心理準備，而且一開始就應該努力朝這樣方向去做，不然一般的結果就是失??！

為什么要向著最小規模的方向去做，這樣的道理其實是很簡單的——這樣的系統除去了所有花哨的功能，只保留了最基本的、最需要的功能，這樣的系統相比之下是最簡單的、最穩固的、最具有擴展性的。

為什么說最小系統是最簡單、最穩固、最具可擴展性的？系統論中有個觀點，就是簡單系統才是最持久、最穩定的；復雜系統功能強大，但是相應的增加了很多不確定的因素，這導致系統內在的就有了不穩定性。在這里，我們承認這個原理，并且準備按照這個準則去進行需求的分析和項目的規劃。

那么，我們怎么使用這個準則來分析需求和規劃項目呢？概率論中有個觀點，就是樣本越多，我們依此得出的推斷越接近真實。所以，需求分析中首先要做的就是大量的占有需求資料——當然，現實中真實的情況是往往隨著項目的不斷推進，大量的需求才開始涌現出來。因此，最有效的需求分析方法我的理解是這樣的：在自己可以接觸的范圍內盡可能的收集需求，相關的或者不相關的（不相關的可以略看，不深入，但是最好能有個概念），盡可能在可以接觸的范圍內做到占有最多的需求樣本。接著，在一定階段內，對所占有的需求樣本進行歸納分析，去除不必要的功能，只保留必須的功能，這就是當前需求（記住，當前需求的前提很重要，這說明隨著時間的推移，需求可能會變，會增多）下的最小功能集。然后，把這個功能集中不易發生變化的部分和容易發生變化部分區分開來（區分的標準是，考慮在多種需求下哪些功能是相對固定的，哪些功能是容易隨著需求的不同發生變更的）。在面向對象的編程方式中，功能是由不同對象的組合提供的，因此要慎重考慮對象進行交互的邊界條件，盡可能的把耦合度降到最低；最后設計的結果可能是：某些對象提供的功能是相對不變的，某些對象提供的功能是易發生變化的；這樣一來，未來可能的變化都被盡可能的集中在了最小的范圍之內——集中在了那些功能易發生變化的對象之內，將來需求改變時，也許90％以上的改動僅僅在這些10％的易變對象中進行改動就可以達成目標了。完成這樣的任務以后，在當前需求下的分析和設計任務就算基本完成；當需求發生改變時，在當前的設計上重復使用這種分析和設計方法，可以保證整個系統隨著時間的推移，始終保持著一種最小功能集的狀態，而且結構簡潔、清晰、穩定，可以給以后的版本升級改造提供最大的靈活性和優異的升級架構，也為系統維護減輕很多的工作量。
 

我沒有研究過ISO標準，我覺得那些都是形式化的東西。當真正掌握了科學的項目工程方法和精神，自然會符合ISO；否則，只是形而上學而已。
 
客戶是上帝沒錯，可是不能一味的滿足客戶，因為客戶不了解軟件系統的開發特點。如果一味的滿足客戶，除了給軟件開發人員增加不必要的麻煩和工作量，也是一種對工作不負責任的態度，因為這樣就失去了實事求是的精神，而不實事求是的采取行動，失敗自然在前方悠閑的等著。
 
 

 Re: 失敗的經驗
 
發表人: agilejava
我們這兒有客戶簽名也不行，說改就得改，煩！
 

 Re: 失敗的經驗
 
發表人: jia2612
沒關系呀，有了客戶簽名，而后來又不按簽字的需求做事，起碼開發人員不那么被動了，這樣客戶也沒借口說三道四了
 
 

 Re: 失敗的經驗
 
發表人: iceant
TO:jia2612

我知道很多開發人員會這樣想。

但是我們的目標不太一樣，我們的目標不是做到讓客戶不投述就可以了。
我們的目標是客戶滿意，開發人員有成就感。

我們需要長期的發展與合作，不能說因為這一次項目失敗是因為客戶沒說清楚需求，或不愿意說需求，就將責任推給客戶。沒有很好的了解客戶需求，沒有幫助客戶達到他們要求的效果與功能，開發人員白忙了一段時間，我們的工作就是失敗了。同時，將責任推給客房的做法，會永遠失去客戶，這也不是我們想看到的。

我現在的想法是首先做好宣傳工作，在明年的工作中，將軟件開發過程中需求收集的重要性以及收集的方法通過各種渠道傳遞到客戶那里，希望在淺移默化中給客戶灌輸軟件工程的思想。這樣也許能更有利于以后的工作。
 
 

 Re: 失敗的經驗
 
發表人: missxkl
 
我也來扯上幾句，：）
我們的第一原則是：客戶就是上帝，客戶永遠是正確的。
做項目就是這樣，不同的用戶素質也不同。
不能指望用戶都能從開發人員的角度去做，只能讓開發人員從客戶的角度去考慮。給不同層次的用戶看他們所能看懂的東西進行確認
，就像西餐廳里并不是所有的用戶都看得懂英文菜單，給不同的用戶提供不同的菜單，最好加上點菜肴的圖片就更棒了。
需求是一個不斷變化的過程，感覺如果產品化程度不高的東西，就不要用什么軟件工程的東西來套。
做到開發前考慮盡量周全，包括系統可擴展性，打有準備的仗。
開發的時候邊做邊確認，邊確認邊修改。
這樣就會避免做完以后，跟用戶想象差距太大的情況。
當然形成書面需求，需求沒有二義性也是很重要，而且領導的感覺是最重要。在中國有時候優秀?。匠晒?，只有領導認可＝用戶認可
＝成功。
覺得iceant的想法很好，如果客戶那邊能有專門的對口人員，時間再給多一些的話，還是很有機會挽回的。
 
 

 Re: 失敗的經驗
 
發表人: lironghai
用戶就是上帝，上帝會把你累死的??！在需求分析階段這句話沒錯，但是到了需求分析完成之后，就大錯特錯了。在軟件開發過程中執行是很大的一個問題，往往客戶并不會按照原先業務分析中的東西去實現，這就是問題。其中有很多次的反復過程，最關鍵的客戶方能有一個領導階層的人可以保證你的客戶可以很好的旅行需求中所定下的一些東西。
 
 

 Re: 失敗的經驗
 
發表人: laofei
同意lironghai 的說法，如果時時刻刻把客戶當成上帝，那不但項目完了，你們公司也完了??！一個我認為比較好的變通辦法是：如果用戶需求變更比較大，那么可以把這部分工作放到二期去做，當然這需要一定的努力讓用戶理解你的工作，不過我想作為一個項目經理應該是有這個能力的，除非你的客戶太過于固執或者他們根本不想讓你做以后的工作
 
 

 Re: 失敗的經驗 
 
發表人: zybing

我說需要客戶簽名并不是代表將客戶放在對立面，把客戶當成敵人。
現在的項目經理最難當?？蛻舨粩喔男枨?，公司又要讓你快速結束項目。
雖然說為客戶考慮可以節省很多時間，但客戶的想法，客戶的需求始終處于不斷變化中，而且做下來的程序在使用中客戶也會有新的想法，或者調整使用方式，或者進行功能的擴展。如果完全都按照客戶的想法實施，或者完全替客戶考慮，一個用戶分析系統可以做成龐大的CRM系統。
讓客戶簽名的作用是在一開始需求討論的時候對需求的范圍作限制，否則以后客戶無限制的擴充需求項目無法收尾（如無白紙黑字的簽名有100%的客戶會不承認當初的定義），或者某些地方做需求的擴充作為交換省去某些不必要得需求，為項目早日結束作伏筆。
 
 

 各位的討論非常精彩，我已經作成文檔在公司里傳閱。并加上了如下的部分 
 
發表人: sprsong
我來說兩句：

1、 在一個項目里邊最重要的是需求分析。需求分析的正確與充要的決定了這個項目的成敗。系統構架的優劣、技術含量的多少只是決定了這個項目開發需要的時間和軟件的健壯性，開發的軟件客戶絕對可以使用，頂多開發的慢點，移植和擴展比較弱，但是不會影響成敗。項目的管理也共同決定了開發的周期和成本。

2、 按照軟件工程上講，一個項目的開始必須要對客戶的工作進行業務建模，相當于大學里的數學建模競賽里做的工作，對客戶的爭個業務流程進行分析，建立一套“輸入”－“公式”－“輸出”的模型。我見過的國內比較成功的一個項目，軟件開發公司聘請專業咨詢公司作業務建模和需求分析，需求完成后技術人員一次開發成功。

3、 在這個過程中，可能會發現客戶業務邏輯不甚合理的地方?；蛘呦蚩蛻籼岢龈纳茦I務流程的建議（這也是部分客戶希望通過我們系統完成的工作），或者在保證系統正確邏輯的前提下對客戶的不合理流程進行兼容設計，這樣一旦客戶發現業務的不合理，打算需求變更的情況下可以有有備無患。

4、 “Iceant”的回復說的很好：“對我們來說，目標是經手的項目能夠成功。成功的標志是雙贏！也就是用戶滿意，開發人員有成就感。所以，盡管用戶簽了字，我們也不能說‘用戶簽了字，照著做出來，如果不是用戶要的，那就用戶負責’?！?BR>不能把客戶當做我們的敵人，作項目就象打仗，出了問題互相追究責任。也不能抱著應付了事的態度，按照需求書上的內容隨便拼湊一些功能給客戶了事。最好的態度就是假設自己就是客戶，做出的系統就應該讓自己在該崗位上工作的時候最方便最順手。每做一個功能就假設自己就是該功能的用戶，看看自己怎么使用最方便，不能怕麻煩就不完善某些功能，我們手頭懶一懶，客戶就可能要多點幾萬次鼠標/每月；我們一個粗心大意，客戶就可能要加班熬夜。

5、 Banq（板橋里人）是java編程和項目實施在國內的最高成就者，他給出了項目實施的一個可行方案：……

6、 目前公司現行的項目有這樣一種情況存在：產品經理在打單和做設計的時候說的天花亂墜，單子打下來后產品經理功成身退；項目經理在項目實施的時候則很少遵守產品經理的設計文檔，按照自己對需求的片面了解實現一通。產品經理不考慮實施，項目經理不重視需求。因此如果讓產品經理對項目的設計和實施進行全全負責，項目有一個重需求的人負責，這樣打單的時候產品經理會知道有些可以答應，有些不可以答應。在項目實施的時候也可以對客戶的需求也有了足夠重視。

 Re: 各位的討論非常精彩，我已經作成文檔在公司里傳閱。并加上了如下的部分 
 
發表人: hymmyh    發表文章: 12 / 注冊時間: 2003-01 
項目成功的關鍵因素
客戶的參與度 19%
高層管理者的承諾 16%
需求的澄清 15%
聽ibm項目經理的演講中所說.
 
 

 Re: 失敗的經驗 
 
發表人: happlyin
 
首先我們要明白：
客戶需求變化是一定的。
我們要盡可能去滿足客戶的需求。

確定了上面的兩點后，我們要做的就是：
首先要求開發人員理解需求變化是不可避免的，不要反感，反對這種現象。
再就是向客戶和領導盡量爭取更多的時間來應對需求。
采取好的開發過程，例如敏捷軟件開發過程等，來包容這樣的變化。
聘請一個在需求領域有項目經驗的，而且又具有很好的設計思想的人。

我認為這樣的問題，跟前期的需求分析沒有太大的關系。因為在前期，需求本身就不完整，即使是完整的，到客戶見到成品后，也會更改需求。

 Re: 失敗的經驗
 
發表人: jiyun512

　用戶需求是在變的，然后就是用戶自己也無法對自己的業務有一個清晰的認識，開發人員然則不如用戶了，所以說需求分析部分一般情況下不可能在項目進行的初期完成，即使完成，以后還有較大的修改，這是一種對業務模型的共同模糊所造成的，當然也有用戶自己對自己業務有一個清晰認識和說明的，不過我還沒遇到，這種情況對開發人員的要求非常大，所以有種情況是可行的，就是開發人員可以以很快的開發速度來完成他對由用戶對業務模型認識的不斷清晰而帶來的重新改變己經完成的某些設計部分，如果開發人員不能完成對這種情況的快速反應，就會出現頭痛等一系列問題，如果你可以以足夠快的時間和速度來響應用戶的這種要求，那么你們的合作會是快樂的，否則則會充滿了意想不到的痛苦。
　　以上完全個人意見
 
 

 學會與客戶中爭取主動
 
發表人: pathfinder
我去年底參加了某大型高速OA系統的二級管理處需求分析，總結了一個小小的經驗，與機關打交道時，我們完成的需求分析一定要有個標準，也就是統一的標準，所有有爭議的細節，包括客戶的使用習慣，都必須適當改變，理由很多：比如這是無紙化辦公，信息時代啦，在于表達，一切以此標準為準則，前期工作量很大。
 
 

 Re: 學會與客戶中爭取主動 
 
發表人: wyse