需求的是是非非

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

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

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

溝通是一切

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

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

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

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

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

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

軟件客戶需求權利書

1. 要求分析人員使用符合客戶語言習慣的表達。
2. 要求分析人員了解客戶系統的業務及目標。
3. 要求分析人員組織需求獲取期間所介紹的信息，并編寫軟件需求規格說明。
4. 要求開發人員對需求過程中所產生的工作結果進行解釋說明。
5. 要求開發人員在整個交流過程中保持和維護一種合作的職業態度。
6. 要求開發人員對產品的實現及需求都要提供建議，拿出主意。
7. 描述產品使其具有易用、好用的特性。
8. 可以調整需求，允許重用已有的軟件組件。
9. 當需要對需求進行變更時，對成本、影響、得失（trade-off）有個真實可信的評估。
10. 獲得滿足客戶功能和質量要求的系統，并且這些要求是開發人員同意的。

軟件客戶需求義務書

1. 給分析人員講解業務及說明業務方面的術語等專業問題。
2. 抽出時間清楚地說明需求并不斷完善。
3. 當說明系統需求時，力求準確詳細。
4. 需要時要及時對需求做出決策。
5. 要尊重開發人員的成本估算和對需求的可行性分析。
6. 對單項需求、系統特性或使用實例劃分優先級。
7. 評審需求文檔和原型。
8. 一旦知道要對項目需求進行變更，要馬上與開發人員聯系。
9. 在要求需求變更時，應遵照開發組織確定的工作過程來處理。
10. 尊重需求工程中開發人員采用的流程（過程）。

需求權利和義務規定了客戶和開發者雙方應該做些什么，雙方共同出力，確保需求過程的有序進行。不過，大多數的軟件公司一般都把“客戶是上帝”這句話貫徹的很好，客戶有什么樣的要求，軟件公司就做什么樣的修改，最終損害的是客戶和自己雙方的利益。一次，我和一個小軟件企業的技術總監聊起這方面的事情，請教他的做法。他在經歷了幾次銷售人員隨意答應客戶要求的痛苦之后，決定親自出動，在和客戶接觸的過程中掌握主動權，判斷客戶是不是一個“好”客戶，再決定做不做這個軟件。實施了一段時間后，發現效果非常的好，成本大幅度下降，客戶也很滿意。軟件開發過程中軟件企業和客戶是一對合作者，一榮俱榮，一損俱損。要達到雙方共贏的局面，只能靠充分的溝通。

需求分析和需求管理

需求的過程包括了兩個過程，需求管理和需求分析。如同一個公司開展業務離不開管理一樣，脫離了需求管理的需求過程很難做到順利的完成需求過程。當然，并不是所有的軟件公司都沒有需求管理，例如安排需求的時間也是需求管理的一方面，大多數的軟件公司都沒有一個科學的、

任何活動都離不開管理，需求過程也不例外。需求過程的活動分為需求管理和需求分析兩種。大多數人說不清楚需求管理和需求分析的差別，但是他們在進行需求過程的時候已經不知不覺的在開展需求管理和需求分析兩種活動了。這種行為就有點像一些小企業主，缺乏科學的、系統的管理知識，但你卻不能說他不懂管理，因為他有大量的實踐經驗。同樣的，一些不夠成熟的軟件企業在進行需求分析的時候，主要還是靠經驗，并沒有一個經過驗證的方法。

需求分析活動包括對一個軟件項目需求的獲取、分析、規格說明及驗證。典型需求分析的結果是軟件需求規格說明（System Requirements Specifications）及相關分析模型。經評審批準，這些文檔就定義了開發工作的需求基線（baseline）。這個基線在客戶和開發人員之間就構筑了計劃產品功能需求和非功能需求的一個約定（agreement）。工程項目可能會有其它的約定，例如可交付性、約束條件、進度安排、預算及合同約定等。但這些并不是需求過程主要考慮的因素。

需求約定是需求開發和需求管理之間的橋梁，需求管理包括在工程進展過程中維持需求約定集成性和精確性的所有活動，如圖所示。需求管理強調：

1、控制對需求基線的變動。
2、保持項目計劃與需求一致。
3、控制單個需求和需求文檔的版本情況。
4、管理需求和聯系鏈之間的聯系或管理單個需求和其它項目可交付品之間的依賴關系。
5、跟蹤基線中需求的狀態。

和任何的管理活動一樣，需求管理的目的也是為了確保需求分析活動按照既定方針執行。

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