前些日子有一個朋友向我要一份需求的標準文檔，因為他現(xiàn)在正在負責一個項目。我對他說，我的需求文檔只適合我用，并不適合你用。如果你是真的想在開發(fā)過程中引入科學的管理方法，靜下心來，認真的學習需求的方法論，仔細的思考適合你們自身的方法。如果你只是需要一份好看的模版來哄哄Boss的話，那你就隨便去找一份文檔來修改一下就行了，保證糊弄得住人。最后我的朋友毅然的找了一份漂亮的文檔走了。
朋友走后我思考了很久，中國目前有很多的軟件公司都很有實力，可是他們在管理方法上卻很成問題。上半年在業(yè)界炒得沸沸揚揚的CMM是個什么東西呢？說穿了，就是一套適合軟件行業(yè)的管理方法。這套管理方法并不是說你花了大堆的票子去過了CMM的評估或是購買了Rational公司的什么產(chǎn)品，而是在于你是不是真的理解了里面的管理精髓。前些日子看一篇報道聯(lián)想實施ERP系統(tǒng)的文章，里面一句很不起眼的話給了我很大的感觸。它說，聯(lián)想在實施ERP之前，雖然也有大量的管理規(guī)范，但都是空談的管理，公司主要還是靠“人治”。而我們現(xiàn)在很多的軟件公司還是處于“人治”?！叭酥巍钡暮蠊呛車乐氐模貙е履愕能浖髽I(yè)成本居高不下，管理上不傳，下不達，企業(yè)無法快速發(fā)展。軟件行業(yè)歷來以利潤高出名，利潤是高，你想想軟件的邊際成本才多少（拷貝一份軟件需要多少錢？）?？墒侵袊能浖袠I(yè)卻做的不好?？纯次覀兊呐_灣同胞們，雖然他們在軟件平臺的研究方面并不出色，但是在軟件應用水平上是很了不起的。當然，臺灣有他的歷史原因：深受美國文化影響，屬于美國制造外包的主要地區(qū)。
上面說了一大堆的廢話，我們還是回到我們的需求上面來。
溝通是一切
需求是一個過程，一個在軟件生命周期中很重要的過程。在上一篇中，我們討論了需求的層次、需求的風險、需求的特點。而在這么多需求要素之上的要素只有一個：溝通。溝通是什么，說小了是需求過程的重要技巧，說大了是軟件企業(yè)的生命線。一個項目失敗的原因有很多，而絕大多數(shù)都可以總結(jié)到溝通不暢。需求過程中充滿了溝通：需求分析員和用戶的溝通，不同的用戶之間的溝通，需求分析員和需求審核人員的溝通，項目經(jīng)理和需求分析員的溝通。溝通到一個什么程度，是需求成功與否的標志。
曾經(jīng)和幾個老同學聊天的時候說起他們?nèi)ビ脩裟睦镒鲂枨笳{(diào)研，用戶報來一堆資料，和他們聊了半天，他們就回去開始設計、編碼。我說你后面肯定吃苦頭了。果不其然，項目返工的時間差不多等于整個項目的時間。這太可怕了，意味著這個項目企業(yè)極可能虧本。為什么會這樣呢？項目好比一座大樓，如果設計師連大樓要蓋多少層都不清楚，那你說蓋出來的會是個什么東西。
《軟件需求》一書中提到了一個很有意思的概念：軟件客戶需求義務和權利
優(yōu)秀的軟件產(chǎn)品是建立在優(yōu)秀的需求基礎之上的。而高質(zhì)量的需求來源于客戶與開發(fā)人員之間有效的交流與合作。通常，開發(fā)人員與客戶或客戶代理人，如市場人員間的關系反而會成為一種對立關系。雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產(chǎn)生摩擦，在這種情況下，不會給雙方帶來一點益處。
只有當雙方參與者都明白要成功自己需要什么，同時也應知道要成功合作方需要什么時，才能建立起一種合作關系。由于項目壓力與日漸增，所有風險承擔者有著一個共同的目標這一點容易被遺忘。其實大家都想開發(fā)出一個既能實現(xiàn)商業(yè)價值，又能滿足用戶需要，還能使開發(fā)者感到滿足的優(yōu)秀軟件產(chǎn)品。
軟件客戶需求權利書列出了十條關于客戶在項目需求工程實施中與分析人員、開發(fā)人員交流時的合法要求。每一項權利都對應著軟件開發(fā)人員、分析人員的義務。而軟件客戶需求義務書也列出了十條關于客戶在需求過程中應承擔的義務。如果愿意，