軟件工程之需求過程（好軟件系列一）
---- 此文獻給期望成長爲軟件大團隊的項目經理
曾經在面試項目經理和需求人員的時候，我一般會問幾個問題，請問如何做一個好需求？好需求的標準是什麼？如何判斷別人做需求的水平是好還是壞？有很多回答，但是最常見的是，需求做完後，通過客戶的滿意度來判斷。我說如果是客戶滿意度來回答，豈非非得等到需求過程結束後，才能獲悉？都需求結束了，判斷出來了又有什麼用？換句話來說，是否項目經理需要跟着需求人員做需求，才能知道需求做的好還是不好？那既然項目經理都跟着做了，那還要需求人員幹什麼？是否只要一個會幫着打打字的小姑娘就可以了？
很有意思的邏輯，貌似從這個邏輯中，我們可以推出目前項目經理做需求更好。貌似市場上也有很多公司招聘項目經理要求會做需求。但是真是這樣的嗎？如果項目經理做需求，那需求人員做什麼！這是糟糕的角色定位，具體分析可以參考我寫的“漫談中國軟件” 。那反過來推理，項目經理不做需求，項目經理就不應該陪着需求人員去做需求，那麼項目經理如何才能判斷出需求人員做的需求到底是一個好的需求還是壞的需求？這就是我開篇提的面試問題了。這些問題不是說需求具體應該怎麼做，分幾步，每步怎麼弄？而是在討論做好需求的標準是什麼？或者說怎麼判斷出需求的質量。這其實屬於軟件工程範疇，因爲它本身沒有具體細化到需求細節，更多是以面來看整個需求過程的工藝如何。
平時在家有時會做飯，切菜工序是少不了的。太太打馬虎說不喜歡，就只能我來做了。每次在切菜的時候，就想着快點。但因爲菜是有各種形狀，千差萬別的，但總是快不起來。要不就是怕切到手指，要不就切的厚薄不勻，切切停停的。有一次看一個酒店師傅切菜，聽他切菜的聲音節奏感很強，就想這個師傅在切菜這個領域裏很有造詣,不是非常人。果然師傅是專業切菜工，幹了很多年切菜的活。看他切出的效果和聲音效果一致,很享受。
這就是工藝，切菜的工藝。我們判斷切菜的工藝水平，很簡單，聽，看就夠了。可以想象的是，這工藝水平的菜，比較容易在鍋裏均衡受熱，一起熟，口感各方面也會更好點。當然實際出菜的時候，客戶的吃的口感，滿意度纔是最終的定論。我們是否可以借鑑一下，理解軟件工程中需求過程的工藝水平呢？
參考CMMI中需求過程的說法，一個優秀的需求標準如下：
此處較爲學術化，我用另一個通俗維度結合我的經驗來重點分享敘述。判斷一個好的需求，可以從幾方面入手。
一，關注需求的規劃
每一個系統都是要去解決相應某領域的問題。曾見過一個MIS管理系統A，裏面把所有雜七雜八的功能都做 在一個系統裏，這些功能都很簡單。但是當某個系統B專業解決了一塊問題的時候，就把A系統的某些功能覆蓋掉了。這個時候A系統很尷尬，因爲他不僅存在推廣 浪費，功能白做的問題，還存在後續定位發展問題，系統的未來可能被替換掉。
還見過一個系統，項目一期和二期在規劃上沒有很好的銜接，出現二期做需求的時候，對一期項目的設計產生較大沖擊，甚至嚴重到將一期大部分功能推到重來。這些也是沒有規劃的原因。
所以好的需求，一定有一條主線去貫穿整個系統,一定是在某個領域無可替代，有發展動力和生命力的。這也是CMMI中提到的完整性體現。
二，關注需求用戶場景和需求變更列表分析
在CMMI中有用戶需求和系統需求，用戶需求表述的用戶用自己的語言來描述當前對系統的一些期望。其實通俗點說用戶需求最重要表達的是系統解決的用戶場景問題。用例的表述需求方式的興起也是基於場景來設計的。
曾討論需求變更的源頭分析，大多數需求變更基本是當時場景描述缺失。
比如：用戶訂餐，從功能上來說只是需要提交一個訂單而已。但是從場景分析來看，用戶訂餐，會先去找餐廳，會先找常吃的菜，會分請情侶，商務宴請，請家人，請朋友各種場景，最後纔是提交一個訂單而已。我們會發現可能做一個訂單提交功能，不一定是最重要的，可能客戶重點是想解決一個請人吃飯的問題。如果這個時候把提交訂單功能做的出神入化豈非本末倒置？
所以判斷一個需求做的好不好，其實很簡單，就是抽其中一段需求內容分析其所適用的場景和目標。如果能表述很清晰，就說明需求質量很高。這也是CMMI中正確性，可行性的的體現。
三，關注需求產出物齊全
所謂“燕過留痕，人過留跡”，優秀需求人員才能做出好的需求，而做事的方式一定會有個完整的套路，就象武功高手練的“降龍十八掌”，“六脈神劍”一樣也是有套路的。所以判斷需求做的好不好，在一些方面也能體現出來。結合經驗，總結如下：
關注目標和進度：
需求範圍SOW敲定 --- 判斷與客戶的溝通和需求範圍的控制力
需求計劃 --- 判斷需求過程推進順利的標準
需求工作量投入量估算 --- 判斷需求過程的控制力
關注深度：
需求會議紀要 --- 判斷需求過程交流達成共識產物
需求問題列表 --- 判斷需求過程中雙方交流的深度和水平
功能性和非功能性的需求覆蓋 --- 判斷需求過程中需求完整性
關注外部關聯：
需求評審(關聯設計，測試，UI)問題列表 --- 判斷需求複雜度和知識傳遞的效果（可選）
需求跟蹤矩陣--- 需求知識傳遞的保障（可選）
關注結果：
需求文檔確認和高仿真原型的確認結果 --- 最終判斷需求過程的結果
基本在需求產出物齊全這塊包括了CMMI中優秀的需求剩下的其它特性體現。
所以一個好的需求工藝，也是靠“聽”和“看”就可以了，不需要直接參與。而項目經理需要的是在這個過程中練習“聽”和“看”的本領。需要關注當需求工藝某方面出現問題的時候，知道怎麼解決它。例如：我們發現SOW範圍沒敲定下來，就開始推進需求討論了，那麼項目經理要能判斷出什麼問題,以及怎麼解決它。或者需求知識傳遞效果不太好，怎麼解決，等等之類。
總之，對於需求過程的把控是項目經理的職責，而對於需求的實施不需要項目經理。項目經理需要花更多時間在軟件工程的整體把控和客戶關係的梳理上。只有這樣，才能發揮團隊最大作用，做出一個好需求，做出一個好軟件。
