軟件工程之需求管理(1)

軟件工程之需求過程（好軟件系列一）

---- 此文獻給指望成長爲軟件大團隊的項目經理

曾經在面試項目經理和需求人員的時候，我通常會問幾個問題，請問如何作一個好需求？好需求的標準是什麼？如何判斷別人作需求的水平是好仍是壞？有不少回答，可是最多見的是，需求作完後，經過客戶的滿意度來判斷。我說若是是客戶滿意度來回答，豈非非得等到需求過程結束後，才能獲悉？都需求結束了，判斷出來了又有什麼用？換句話來講，是否項目經理須要跟着需求人員作需求，才能知道需求作的好仍是很差？那既然項目經理都跟着作了，那還要需求人員幹什麼？是否只要一個會幫着打打字的小姑娘就能夠了？

頗有意思的邏輯，貌似從這個邏輯中，咱們能夠推出目前項目經理作需求更好。貌似市場上也有不少公司招聘項目經理要求會作需求。可是真是這樣的嗎？若是項目經理作需求，那需求人員作什麼！這是糟糕的角色定位，具體分析能夠參考我寫的「漫談中國軟件」 。那反過來推理，項目經理不作需求，項目經理就不該該陪着需求人員去作需求，那麼項目經理如何才能判斷出需求人員作的需求究竟是一個好的需求仍是壞的需求？這就是我開篇提的面試問題了。這些問題不是說需求具體應該怎麼作，分幾步，每步怎麼弄？而是在討論作好需求的標準是什麼？或者說怎麼判斷出需求的質量。這其實屬於軟件工程範疇，由於它自己沒有具體細化到需求細節，更可能是以面來看整個需求過程的工藝如何。

平時在家有時會作飯，切菜工序是少不了的。太太打馬虎說不喜歡，就只能我來作了。每次在切菜的時候，就想着快點。但由於菜是有各類形狀，千差萬別的，但老是快不起來。要不就是怕切到手指，要不就切的厚薄不勻，切切停停的。有一次看一個酒店師傅切菜，聽他切菜的聲音節奏感很強，就想這個師傅在切菜這個領域裏頗有造詣,不是很是人。果真師傅是專業切菜工，幹了不少年切菜的活。看他切出的效果和聲音效果一致,很享受。

這就是工藝，切菜的工藝。咱們判斷切菜的工藝水平，很簡單，聽，看就夠了。能夠想象的是，這工藝水平的菜，比較容易在鍋裏均衡受熱，一塊兒熟，口感各方面也會更好點。固然實際出菜的時候，客戶的吃的口感，滿意度纔是最終的定論。咱們是否能夠借鑑一下，理解軟件工程中需求過程的工藝水平呢？

參考CMMI中需求過程的說法，一個優秀的需求標準以下：

 此處較爲學術化，我用另外一個通俗維度結合個人經驗來重點分享敘述。判斷一個好的需求，能夠從幾方面入手。

一，關注需求的規劃           

每個系統都是要去解決相應某領域的問題。曾見過一個MIS管理系統A，裏面把全部雜七雜八的功能都作 在一個系統裏，這些功能都很簡單。可是當某個系統B專業解決了一塊問題的時候，就把A系統的某些功能覆蓋掉了。這個時候A系統很尷尬，由於他不只存在推廣 浪費，功能白作的問題，還存在後續定位發展問題，系統的將來可能被替換掉。

還見過一個系統，項目一期和二期在規劃上沒有很好的銜接，出現二期作需求的時候，對一期項目的設計產生較大沖擊，甚至嚴重到將一期大部分功能推到重來。這些也是沒有規劃的緣由。

因此好的需求，必定有一條主線去貫穿整個系統,必定是在某個領域無可替代，有發展動力和生命力的。這也是CMMI中提到的完整性體現。

二，關注需求用戶場景和需求變動列表分析

在CMMI中有用戶需求和系統需求，用戶需求表述的用戶用本身的語言來描述當前對系統的一些指望。其實通俗點說用戶需求最重要表達的是系統解決的用戶場景問題。用例的表述需求方式的興起也是基於場景來設計的。

曾討論需求變動的源頭分析，大多數需求變動基本是當時場景描述缺失。

好比：用戶訂餐，從功能上來講只是須要提交一個訂單而已。可是從場景分析來看，用戶訂餐，會先去找餐廳，會先找常吃的菜，會分請情侶，商務宴請，請家人，請朋友各類場景，最後纔是提交一個訂單而已。咱們會發現可能作一個訂單提交功能，不必定是最重要的，可能客戶重點是想解決一個請人吃飯的問題。若是這個時候把提交訂單功能作的出神入化豈非本末倒置？

因此判斷一個需求作的好很差，其實很簡單，就是抽其中一段需求內容分析其所適用的場景和目標。若是能表述很清晰，就說明需求質量很高。這也是CMMI中正確性，可行性的的體現。

三，關注需求產出物齊全

所謂「燕過留痕，人過留跡」，優秀需求人員才能作出好的需求，而作事的方式必定會有個完整的套路，就象武功高手練的「降龍十八掌」，「六脈神劍」同樣也是有套路的。因此判斷需求作的好很差，在一些方面也能體現出來。結合經驗，總結以下：

關注目標和進度：

需求範圍SOW敲定 --- 判斷與客戶的溝通和需求範圍的控制力

需求計劃 --- 判斷需求過程推動順利的標準

需求工做量投入量估算 --- 判斷需求過程的控制力

 

關注深度：

需求會議紀要 --- 判斷需求過程交流達成共識產物

需求問題列表 --- 判斷需求過程當中雙方交流的深度和水平

功能性和非功能性的需求覆蓋 --- 判斷需求過程當中需求完整性

 

關注外部關聯：

需求評審(關聯設計，測試，UI)問題列表 --- 判斷需求複雜度和知識傳遞的效果（可選）

需求跟蹤矩陣--- 需求知識傳遞的保障（可選）

關注結果：

需求文檔確認和高仿真原型的確認結果 --- 最終判斷需求過程的結果

 

基本在需求產出物齊全這塊包括了CMMI中優秀的需求剩下的其它特性體現。

 

因此一個好的需求工藝，也是靠「聽」和「看」就能夠了，不須要直接參與。而項目經理須要的是在這個過程當中練習「聽」和「看」的本領。須要關注當需求工藝某方面出現問題的時候，知道怎麼解決它。例如：咱們發現SOW範圍沒敲定下來，就開始推動需求討論了，那麼項目經理要能判斷出什麼問題,以及怎麼解決它。或者需求知識傳遞效果不太好，怎麼解決，等等之類。

 

總之，對於需求過程的把控是項目經理的職責，而對於需求的實施不須要項目經理。項目經理須要花更多時間在軟件工程的總體把控和客戶關係的梳理上。只有這樣，才能發揮團隊最大做用，作出一個好需求，作出一個好軟件。