需求的是是非非

前些日子有一個朋友向我要一份需求的標準文檔，因為他現在正在負責一個項目。我對他說，我的需求文檔只適合我用，并不適合你用。如果你是真的想在開發過程中引入科學的管理方法，靜下心來，認真的學習需求的方法論，仔細的思考適合你們自身的方法。如果你只是需要一份好看的模版來哄哄Boss的話，那你就隨便去找一份文檔來修改一下就行了，保證糊弄得住人。最后我的朋友毅然的找了一份漂亮的文檔走了。

    朋友走后我思考了很久，中國目前有很多的軟件公司都很有實力，可是他們在管理方法上卻很成問題。上半年在業界炒得沸沸揚揚的CMM是個什么東西呢？說穿了，就是一套適合軟件行業的管理方法。這套管理方法并不是說你花了大堆的票子去過了CMM的評估或是購買了Rational公司的什么產品，而是在于你是不是真的理解了里面的管理精髓。前些日子看一篇報道聯想實施ERP系統的文章，里面一句很不起眼的話給了我很大的感觸。它說，聯想在實施ERP之前，雖然也有大量的管理規范，但都是空談的管理，公司主要還是靠“人治”。而我們現在很多的軟件公司還是處于“人治”?！叭酥巍钡暮蠊呛車乐氐?，必將導致你的軟件企業成本居高不下，管理上不傳，下不達，企業無法快速發展。軟件行業歷來以利潤高出名，利潤是高，你想想軟件的邊際成本才多少（拷貝一份軟件需要多少錢？）?？墒侵袊能浖袠I卻做的不好?？纯次覀兊呐_灣同胞們，雖然他們在軟件平臺的研究方面并不出色，但是在軟件應用水平上是很了不起的。當然，臺灣有他的歷史原因：深受美國文化影響，屬于美國制造外包的主要地區。

    上面說了一大堆的廢話，我們還是回到我們的需求上面來。

    溝通是一切

    需求是一個過程，一個在軟件生命周期中很重要的過程。在上一篇中，我們討論了需求的層次、需求的風險、需求的特點。而在這么多需求要素之上的要素只有一個：溝通。溝通是什么，說小了是需求過程的重要技巧，說大了是軟件企業的生命線。一個項目失敗的原因有很多，而絕大多數都可以總結到溝通不暢。需求過程中充滿了溝通：需求分析員和用戶的溝通，不同的用戶之間的溝通，需求分析員和需求審核人員的溝通，項目經理和需求分析員的溝通。溝通到一個什么程度，是需求成功與否的標志。

    曾經和幾個老同學聊天的時候說起他們去用戶哪里做需求調研，用戶報來一堆資料，和他們聊了半天，他們就回去開始設計、編碼。我說你后面肯定吃苦頭了。果不其然，項目返工的時間差不多等于整個項目的時間。這太可怕了，意味著這個項目企業極可能虧本。為什么會這樣呢？項目好比一座大樓，如果設計師連大樓要蓋多少層都不清楚，那你說蓋出來的會是個什么東西。

    《軟件需求》一書中提到了一個很有意思的概念：軟件客戶需求義務和權利

    優秀的軟件產品是建立在優秀的需求基礎之上的。而高質量的需求來源于客戶與開發人員之間有效的交流與合作。通常，開發人員與客戶或客戶代理人，如市場人員間的關系反而會成為一種對立關系。雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產生摩擦，在這種情況下，不會給雙方帶來一點益處。

    只有當雙方參與者都明白要成功自己需要什么，同時也應知道要成功合作方需要什么時，才能建立起一種合作關系。由于項目壓力與日漸增，所有風險承擔者有著一個共同的目標這一點容易被遺忘。其實大家都想開發出一個既能實現商業價值，又能滿足用戶需要，還能使開發者感到滿足的優秀軟件產品。

    軟件客戶需求權利書列出了十條關于客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求。每一項權利都對應著軟件開發人員、分析人員的義務。而軟件客戶需求義務書也列出了十條關于客戶在需求過程中應承擔的義務。如果愿意，可以將其作為開發人員的權利書。

    軟件客戶需求權利書

    1. 要求分析人員使用符合客戶語言習慣的表達。

    2. 要求分析人員了解客戶系統的業務及目標。

    3. 要求分析人員組織需求獲取期間所介紹的信息，并編寫軟件需求規格說明。

    4. 要求開發人員對需求過程中所產生的工作結果進行解釋說明。

    5. 要求開發人員在整個交流過程中保持和維護一種合作的職業態度。

    6. 要求開發人員對產品的實現及需求都要提供建議，拿出主意。

    7. 描述產品使其具有易用、好用的特性。

    8. 可以調整需求，允許重用已有的軟件組件。

    9. 當需要對需求進行變更時，對成本、影響、得失（trade-off）有個真實可信的評估。

    10. 獲得滿足客戶功能和質量要求的系統，并且這些要求是開發人員同意的。

 

原文轉自：http://www.anti-gravitydesign.com