在信息化高速發(fā)展的今天，構建與時俱進的信息化系統已成為所有政府、企事業(yè)單位的重點課題之一。然而在軟件項目實施過程中，進度超期、經費超預算、變更頻繁的現象層出不窮，甚至有許多項目根本無法達到預期的目標，更談不上為業(yè)主創(chuàng)造真正的效益。歸根結底，軟件需求實踐這一共同的軟肋是問題根源之所在。
引言
關于軟件項目所存在的問題，互聯網上曾經流傳著一幅漫畫，它十分生動地展現了這些問題。也許很多人看完之后只是一笑置之，但如果我們認真剖析后面的東西，還是會給我們的工作帶來許多啟發(fā)的。
溝通失真
究其原因，這幅漫畫給人最大的啟示就是在需求溝通過程中產生了嚴重的失真，從客戶的描述到項目經理的理解、分析員的設計、程序員的編碼、商業(yè)顧問的詮釋，每個角色都根據自己的特點和需求對信息進行了不同的加工，從而導致信息的內容有了很大的改變。因此，對于軟件需求工程而言，克服溝通失真就成了一個要點。
根據相關的研究顯示，在信息的傳遞過程中，如果沒有采取任何措施，那么在溝通過程中信息衰減可能的最大值高達60%。而在軟件開發(fā)過程中，需求信息通常要經歷用戶代表、需求人員、設計人員再到開發(fā)人員，因此最壞的情況下，開發(fā)人員獲得的信息僅是原來的8.4%（如圖2示），這是一個十分可怕的結果。
怎樣才能夠更好地避免這種問題的出現呢？其實關鍵的手段有兩個：
文檔：如果信息在傳遞的過程中僅靠口口相授的話，就難免發(fā)生遺忘、加工等情況，因此必須在這個過程中有效地利用文檔，將達成共識的信息文檔化。但這種方法只是用來輔助溝通的，而不是代替溝通，這一點在后面還會提到。
Review：在此有意使用了英文，因為國內常將其翻譯為“評審”，但這一翻譯卻容易給人誤導。評審在很多人的腦海中就是得出一個通過與否的結論，這也是導致需求評審工作流于形式的罪魁禍首之一。顧名思義，Review就是再（Re）看（View）一遍的意思，其本質含義是通過再次的審讀，盡早地暴露出錯誤。而最簡單、有效的Review就是在用戶代表闡述了需求之后，需求分析員用自己的語言再復述一遍，以確保溝通沒有失真。
隱喻：經理叫來了小張，然后就下一階段的工作做出了一些重要的指示和安排：“$%#^@(*)#@……”。
小張正要扭頭走的時候，經理叫住了他，說到：“你簡單地說說看，我剛才給你交待的任務有哪些”（看來管理人員早已掌握了這一招）。
提示：如果有一個測試人員對你說：“我前天仔細測試了一下你寫的程序，發(fā)現一個問題也沒有，恭喜你！”。你會怎么想呢？
a. 覺得自己的程序寫得很好！
b. 覺得測試人員方法不得當或測試不細致。
我想大多數人都會做出“b”的選擇！可是到了需求評審時為什么卻轉了180度的彎呢？為什么期望需求評審時一點問題也沒有呢？
“溝通失真”高度概括了其中所蘊藏的問題，但如果我們細細地思考第1、2、3、4、10幅圖（這五幅圖中的景象與需求活動有很大的相關性），并將其兩兩比較就會得到一些有益的啟發(fā)。下面我們就一起來看看。
客戶：放大需求
當我們比較圖1中的1幅和第10幅圖時，就會發(fā)現用戶在描述自己的需求時做了許多“添磚加瓦”的事?！坝脩粢床粫f，要么就會添油加醋”的現象，在我的實踐中是屢見不鮮的。而在這種現象的背后有什么潛在的原因呢？我認為至少有兩方面關鍵因素：
?。?）客戶希望支付的成本盡可能少，獲得的效益盡可能多
這種思維對于任何一個客戶、任何一個人而言都是本能反應。而當用戶對開發(fā)成本越不
項目經理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html
