在信息化高速發(fā)展的今天，構(gòu)建與時(shí)俱進(jìn)的信息化系統(tǒng)已成為所有政府、企事業(yè)單位的重點(diǎn)課題之一。然而在軟件項(xiàng)目實(shí)施過程中，進(jìn)度超期、經(jīng)費(fèi)超預(yù)算、變更頻繁的現(xiàn)象層出不窮，甚至有許多項(xiàng)目根本無法達(dá)到預(yù)期的目標(biāo)，更談不上為業(yè)主創(chuàng)造真正的效益。歸根結(jié)底，軟件需求實(shí)踐這一共同的軟肋是問題根源之所在。
引言
關(guān)于軟件項(xiàng)目所存在的問題，互聯(lián)網(wǎng)上曾經(jīng)流傳著一幅漫畫，它十分生動(dòng)地展現(xiàn)了這些問題。也許很多人看完之后只是一笑置之，但如果我們認(rèn)真剖析后面的東西，還是會(huì)給我們的工作帶來許多啟發(fā)的。
溝通失真
究其原因，這幅漫畫給人大的啟示就是在需求溝通過程中產(chǎn)生了嚴(yán)重的失真，從客戶的描述到項(xiàng)目經(jīng)理的理解、分析員的設(shè)計(jì)、程序員的編碼、商業(yè)顧問的詮釋，每個(gè)角色都根據(jù)自己的特點(diǎn)和需求對信息進(jìn)行了不同的加工，從而導(dǎo)致信息的內(nèi)容有了很大的改變。因此，對于軟件需求工程而言，克服溝通失真就成了一個(gè)要點(diǎn)。
根據(jù)相關(guān)的研究顯示，在信息的傳遞過程中，如果沒有采取任何措施，那么在溝通過程中信息衰減可能的大值高達(dá)60%。而在軟件開發(fā)過程中，需求信息通常要經(jīng)歷用戶代表、需求人員、設(shè)計(jì)人員再到開發(fā)人員，因此壞的情況下，開發(fā)人員獲得的信息僅是原來的8.4%（如圖2示），這是一個(gè)十分可怕的結(jié)果。
怎樣才能夠更好地避免這種問題的出現(xiàn)呢？其實(shí)關(guān)鍵的手段有兩個(gè)：
文檔：如果信息在傳遞的過程中僅靠口口相授的話，就難免發(fā)生遺忘、加工等情況，因此必須在這個(gè)過程中有效地利用文檔，將達(dá)成共識(shí)的信息文檔化。但這種方法只是用來輔助溝通的，而不是代替溝通，這一點(diǎn)在后面還會(huì)提到。
Review：在此有意使用了英文，因?yàn)閲鴥?nèi)常將其翻譯為“評審”，但這一翻譯卻容易給人誤導(dǎo)。評審在很多人的腦海中就是得出一個(gè)通過與否的結(jié)論，這也是導(dǎo)致需求評審工作流于形式的罪魁禍?zhǔn)字?。顧名思義，Review就是再（Re）看（View）一遍的意思，其本質(zhì)含義是通過再次的審讀，盡早地暴露出錯(cuò)誤。而簡單、有效的Review就是在用戶代表闡述了需求之后，需求分析員用自己的語言再復(fù)述一遍，以確保溝通沒有失真。
隱喻：經(jīng)理叫來了小張，然后就下一階段的工作做出了一些重要的指示和安排：“$%#^@(*)#@……”。
小張正要扭頭走的時(shí)候，經(jīng)理叫住了他，說到：“你簡單地說說看，我剛才給你交待的任務(wù)有哪些”（看來管理人員早已掌握了這一招）。
提示：如果有一個(gè)測試人員對你說：“我前天仔細(xì)測試了一下你寫的程序，發(fā)現(xiàn)一個(gè)問題也沒有，恭喜你！”。你會(huì)怎么想呢？
a. 覺得自己的程序?qū)懙煤芎茫?BR> b. 覺得測試人員方法不得當(dāng)或測試不細(xì)致。
我想大多數(shù)人都會(huì)做出“b”的選擇！可是到了需求評審時(shí)為什么卻轉(zhuǎn)了180度的彎呢？為什么期望需求評審時(shí)一點(diǎn)問題也沒有呢？
“溝通失真”高度概括了其中所蘊(yùn)藏的問題，但如果我們細(xì)細(xì)地思考第1、2、3、4、10幅圖（這五幅圖中的景象與需求活動(dòng)有很大的相關(guān)性），并將其兩兩比較就會(huì)得到一些有益的啟發(fā)。下面我們就一起來看看。
客戶：放大需求
當(dāng)我們比較圖1中的1幅和第10幅圖時(shí)，就會(huì)發(fā)現(xiàn)用戶在描述自己的需求時(shí)做了許多“添磚加瓦”的事?！坝脩粢床粫?huì)說，要么就會(huì)添油加醋”的現(xiàn)象，在我的實(shí)踐中是屢見不鮮的。而在這種現(xiàn)象的背后有什么潛在的原因呢？我認(rèn)為至少有兩方面關(guān)鍵因素：
（1）客戶希望支付的成本盡可能少，獲得的效益盡可能多
這種思維對于任何一個(gè)客戶、任何一個(gè)人而言都是本能反應(yīng)。而當(dāng)用戶對開發(fā)成本越不了解時(shí)，這種心態(tài)就會(huì)越強(qiáng)烈，更加擔(dān)心自己“虧損”了；因此在需求協(xié)商時(shí)就會(huì)采取盡可能增加功能的方法來降低“虧損”的風(fēng)險(xiǎn)。
要有效地克服這個(gè)因素的困擾，核心的要點(diǎn)在于建立客戶對開發(fā)團(tuán)隊(duì)的信任度，而建立信任度的要點(diǎn)有兩個(gè)方面：一是需求人員必須提升自己的專業(yè)主義（關(guān)于這一點(diǎn)我將在后續(xù)的文章中說明）；二是需求人員要多站在用戶的角度想問題，讓用戶感覺需求人員的目標(biāo)是幫助自己解決問題，而非一味謀取利益。
（2）解決方案的選擇權(quán)交給了不熟悉技術(shù)的客戶
也就是用戶經(jīng)常會(huì)談解決方案，甚至許多需求團(tuán)隊(duì)在進(jìn)行需求捕獲活動(dòng)時(shí)，經(jīng)常預(yù)期用戶能夠直接告訴他們要做什么（What），而不太關(guān)心用戶提出需求的真正動(dòng)機(jī)（Why）。但是這樣就將解決方案的選擇權(quán)交給了并不熟悉技術(shù)的客戶代表，而客戶代表選擇的解決方案不是合適的話，就必將引發(fā)后續(xù)的需求變更。
案例&場景：
在CRM軟件開發(fā)的過程中……
負(fù)責(zé)輸入客戶信息的用戶向開發(fā)人員提出：“你看這個(gè)界面，光電話就有快10個(gè)輸入框，太麻煩了，每次按tab鍵都按酸了。我希望把他們合并成兩個(gè)，一個(gè)為常用電話，一個(gè)為其他電話”。
“那有多個(gè)電話怎么辦？”，開發(fā)人員回應(yīng)道。
“其他電話的輸入框可以設(shè)置為多行的、較寬的，這樣我可以輸入多個(gè)，中間用逗號(hào)分開它！”。
“好的，沒問題” 。
……
當(dāng)經(jīng)理看到了這些客戶信息之后，向開發(fā)人員提出：“我需要一個(gè)功能，輸入任何電話號(hào)碼，自動(dòng)找出相應(yīng)的客戶?！?BR> “啊……”
如果我們細(xì)究這個(gè)場景，分析一下負(fù)責(zé)輸入客戶信息的用戶所提出的變更就會(huì)發(fā)現(xiàn)：“將10個(gè)電話輸入框合并成兩個(gè)”顯然是解決方案，而真正的需求是“輸入太麻煩了，每次按tab鍵都按酸了”。你或許就會(huì)想到如下所示的解決方案：
也就是說，默認(rèn)情況上只顯示左邊的部分，當(dāng)需要時(shí)點(diǎn)擊“其它>>”按鈕就可以將右邊的不常用輸入項(xiàng)顯示出來。
總而言之，因?yàn)閷τ谝粋€(gè)特定的問題可能的解決方案會(huì)有很多，因此用戶可能在使用軟件的過程中不斷發(fā)現(xiàn)其他可選的、更合適的替代方案，從而導(dǎo)致了不必要的需求變更。而要緩解這一現(xiàn)象的關(guān)鍵就在于在需求捕獲的過程中多問“為什么”。
項(xiàng)目經(jīng)理：控制需求
當(dāng)我們比較圖1中第1幅和第2幅圖時(shí)，就會(huì)發(fā)現(xiàn)項(xiàng)目經(jīng)理在溝通的過程中會(huì)導(dǎo)致需求產(chǎn)生偏差。由于國內(nèi)許多軟件項(xiàng)目經(jīng)理們通常是一身兼多職，項(xiàng)目管理、需求分析、架構(gòu)設(shè)計(jì)一肩挑，因此在需求捕獲的過程中，總會(huì)“及時(shí)”地在腦海里勾勒出技術(shù)框架和路線，然后盡可能地控制需求的范圍。
就像這里，客戶需要的可能是一個(gè)“秋千”或者是“上樹工具”，但不管真正的需求是什么，第2幅圖中的解決方案卻都無法有效地滿足。如果要做“秋千”，不應(yīng)該被樹干擋住；如果要做“上樹工具”，木板的數(shù)量顯然太少了。
究其原因不難發(fā)現(xiàn)，需求人員首先從項(xiàng)目經(jīng)理的視角按工作量對需求進(jìn)行了控制：將“三層”板的工作量減成“一層”板，如果不小心控制掉的是對業(yè)務(wù)很重要的東西，那么終一定會(huì)以變更的形式“回報(bào)”給開發(fā)團(tuán)隊(duì)的。然后需求人員又從架構(gòu)師的角度進(jìn)行了“改良”：不穩(wěn)定的“全掛在一個(gè)樹枝上”改成“掛在兩個(gè)樹枝上”，結(jié)果根本無法使用。
因此具有多個(gè)角色的需求人員，必須在需求的過程中“戴正自己的帽子”，真正從理解業(yè)務(wù)的角度來捕獲需求。
分析人員：技術(shù)加工
案例&場景：
分析員小張：“嘿，伙伴們！我有個(gè)提議，我們研究Hibernate已經(jīng)有一段時(shí)間了，一直沒時(shí)間真正動(dòng)手用一用。我看這個(gè)項(xiàng)目就不錯(cuò)，不算太大，就用它試試吧！”。
“好主意！”，大家紛紛表示贊同。
……
“約定時(shí)間已經(jīng)過去1個(gè)月，現(xiàn)在項(xiàng)目進(jìn)展到底如何了？什么時(shí)候可以交付？”，客戶方CIO質(zhì)問到。
分析員小張：“現(xiàn)在主要困擾我們的是一些需求細(xì)節(jié)一直存在變化，開發(fā)團(tuán)隊(duì)又有了一些人離職，所以……”（真正的情況是：由于團(tuán)隊(duì)第使用Hibernate，有些數(shù)據(jù)訪問層的問題一直沒有有效解決，導(dǎo)致進(jìn)展不斷失控。）
現(xiàn)在許多名稱中包含“需求分析”、“系統(tǒng)分析”之類的職位，大多是由技術(shù)骨干擔(dān)任的，因此在工作中很少從業(yè)務(wù)角度進(jìn)行分析，更多還是追求技術(shù)框架、新技術(shù)。對于這種現(xiàn)象，究其根源，關(guān)鍵還在于“技術(shù)能力”對他們的未來發(fā)展更為重要，而“業(yè)務(wù)能力”卻不是那么重要。但為了使需求工作有更好的提高，我會(huì)強(qiáng)烈呼吁那些Title上有“分析”之類名稱的人們，加強(qiáng)業(yè)務(wù)分析吧！
編程人員：斷章取義
對于第4幅圖，可以用一句生動(dòng)的話來概括：“你要繩子，我給你了；你要木板，我也給你了；你為什么說這不是你想要的呢？”。我想程序員也有類似的問題想問自己的客戶，“你要文本框，我提供了；你要一個(gè)表單，我也有了；你為什么說這個(gè)程序不是你想要的呢？”。這讓我想起了這樣一幕：
案例&場景：
叮鈴鈴……，程序員小趙的電話急促地響起。小趙剛接起電話就聽到了對面迫不急待地抱怨聲“倉庫管理員反應(yīng)，入庫模塊沒法使用！你馬上查一下，盡快解決一下！”。
小趙放下電話就開始Check out、Builder、Run、Debug……等一系列操作。經(jīng)過一番測試之后，小趙沒好氣地提起電話回復(fù)說：“這些客戶真是笨！這哪有問題，肯定是操作上出了問題！我怎么用都是好的，你們客戶服務(wù)的人也應(yīng)該加強(qiáng)對用戶的培訓(xùn)，別什么事都扔給我們！”。
……
可是，問題仍然沒有解決！開發(fā)人員到了現(xiàn)場一看，終于發(fā)現(xiàn)了問題的所在：這是一套基于B/S的倉庫管理系統(tǒng)，在入庫時(shí)，倉庫管理員首先需要錄入入庫單，然后填入“驗(yàn)收情況”，后點(diǎn)擊“入庫”按鈕。但當(dāng)倉庫管理員錄入完入庫單，逐一驗(yàn)過入庫貨物之后再回到電腦前時(shí)，等待他的卻是一個(gè)令其不知所措的問題，Session超期！
一肚子氣的小趙一個(gè)電話就打到需求分析員小錢那里：“你們的需求是怎么寫的！這么重要的東西也不寫明白，我們怎么知道填完入庫單后要驗(yàn)貨那么長時(shí)間，才填寫驗(yàn)收情況呀！”。
“哦，這也算是需求嗎？如果這也算的話，那我們豈不成了業(yè)務(wù)人員了！”，小錢很強(qiáng)勢地回答到。
這是需求嗎？也許很多讀者會(huì)有不同的看法！但如果缺乏對業(yè)務(wù)場景的了解，又如何能夠真正理解需求呢？斷了“業(yè)務(wù)場景”之章，必將導(dǎo)致取出的“需求”之義有所偏差呀！
作者簡介：中國系統(tǒng)分析員顧問團(tuán)軟件工程首席顧問，中國軟件技術(shù)大會(huì)杰出貢獻(xiàn)專家，資深咨詢顧問。主要研究領(lǐng)域?yàn)樾枨蠊こ?、系統(tǒng)分析與設(shè)計(jì)、軟件估算，致力于推動(dòng)軟件工程方法論的落地應(yīng)用。本文節(jié)選（并改編）于筆者新著《軟件需求佳實(shí)踐：SERU過程框架原理與應(yīng)用》（電子工業(yè)出版社博文視點(diǎn)）
引言
關(guān)于軟件項(xiàng)目所存在的問題，互聯(lián)網(wǎng)上曾經(jīng)流傳著一幅漫畫，它十分生動(dòng)地展現(xiàn)了這些問題。也許很多人看完之后只是一笑置之，但如果我們認(rèn)真剖析后面的東西，還是會(huì)給我們的工作帶來許多啟發(fā)的。
溝通失真
究其原因，這幅漫畫給人大的啟示就是在需求溝通過程中產(chǎn)生了嚴(yán)重的失真，從客戶的描述到項(xiàng)目經(jīng)理的理解、分析員的設(shè)計(jì)、程序員的編碼、商業(yè)顧問的詮釋，每個(gè)角色都根據(jù)自己的特點(diǎn)和需求對信息進(jìn)行了不同的加工，從而導(dǎo)致信息的內(nèi)容有了很大的改變。因此，對于軟件需求工程而言，克服溝通失真就成了一個(gè)要點(diǎn)。
根據(jù)相關(guān)的研究顯示，在信息的傳遞過程中，如果沒有采取任何措施，那么在溝通過程中信息衰減可能的大值高達(dá)60%。而在軟件開發(fā)過程中，需求信息通常要經(jīng)歷用戶代表、需求人員、設(shè)計(jì)人員再到開發(fā)人員，因此壞的情況下，開發(fā)人員獲得的信息僅是原來的8.4%（如圖2示），這是一個(gè)十分可怕的結(jié)果。
怎樣才能夠更好地避免這種問題的出現(xiàn)呢？其實(shí)關(guān)鍵的手段有兩個(gè)：
文檔：如果信息在傳遞的過程中僅靠口口相授的話，就難免發(fā)生遺忘、加工等情況，因此必須在這個(gè)過程中有效地利用文檔，將達(dá)成共識(shí)的信息文檔化。但這種方法只是用來輔助溝通的，而不是代替溝通，這一點(diǎn)在后面還會(huì)提到。
Review：在此有意使用了英文，因?yàn)閲鴥?nèi)常將其翻譯為“評審”，但這一翻譯卻容易給人誤導(dǎo)。評審在很多人的腦海中就是得出一個(gè)通過與否的結(jié)論，這也是導(dǎo)致需求評審工作流于形式的罪魁禍?zhǔn)字?。顧名思義，Review就是再（Re）看（View）一遍的意思，其本質(zhì)含義是通過再次的審讀，盡早地暴露出錯(cuò)誤。而簡單、有效的Review就是在用戶代表闡述了需求之后，需求分析員用自己的語言再復(fù)述一遍，以確保溝通沒有失真。
隱喻：經(jīng)理叫來了小張，然后就下一階段的工作做出了一些重要的指示和安排：“$%#^@(*)#@……”。
小張正要扭頭走的時(shí)候，經(jīng)理叫住了他，說到：“你簡單地說說看，我剛才給你交待的任務(wù)有哪些”（看來管理人員早已掌握了這一招）。
提示：如果有一個(gè)測試人員對你說：“我前天仔細(xì)測試了一下你寫的程序，發(fā)現(xiàn)一個(gè)問題也沒有，恭喜你！”。你會(huì)怎么想呢？
a. 覺得自己的程序?qū)懙煤芎茫?BR> b. 覺得測試人員方法不得當(dāng)或測試不細(xì)致。
我想大多數(shù)人都會(huì)做出“b”的選擇！可是到了需求評審時(shí)為什么卻轉(zhuǎn)了180度的彎呢？為什么期望需求評審時(shí)一點(diǎn)問題也沒有呢？
“溝通失真”高度概括了其中所蘊(yùn)藏的問題，但如果我們細(xì)細(xì)地思考第1、2、3、4、10幅圖（這五幅圖中的景象與需求活動(dòng)有很大的相關(guān)性），并將其兩兩比較就會(huì)得到一些有益的啟發(fā)。下面我們就一起來看看。
客戶：放大需求
當(dāng)我們比較圖1中的1幅和第10幅圖時(shí)，就會(huì)發(fā)現(xiàn)用戶在描述自己的需求時(shí)做了許多“添磚加瓦”的事?！坝脩粢床粫?huì)說，要么就會(huì)添油加醋”的現(xiàn)象，在我的實(shí)踐中是屢見不鮮的。而在這種現(xiàn)象的背后有什么潛在的原因呢？我認(rèn)為至少有兩方面關(guān)鍵因素：
（1）客戶希望支付的成本盡可能少，獲得的效益盡可能多
這種思維對于任何一個(gè)客戶、任何一個(gè)人而言都是本能反應(yīng)。而當(dāng)用戶對開發(fā)成本越不了解時(shí)，這種心態(tài)就會(huì)越強(qiáng)烈，更加擔(dān)心自己“虧損”了；因此在需求協(xié)商時(shí)就會(huì)采取盡可能增加功能的方法來降低“虧損”的風(fēng)險(xiǎn)。
要有效地克服這個(gè)因素的困擾，核心的要點(diǎn)在于建立客戶對開發(fā)團(tuán)隊(duì)的信任度，而建立信任度的要點(diǎn)有兩個(gè)方面：一是需求人員必須提升自己的專業(yè)主義（關(guān)于這一點(diǎn)我將在后續(xù)的文章中說明）；二是需求人員要多站在用戶的角度想問題，讓用戶感覺需求人員的目標(biāo)是幫助自己解決問題，而非一味謀取利益。
（2）解決方案的選擇權(quán)交給了不熟悉技術(shù)的客戶
也就是用戶經(jīng)常會(huì)談解決方案，甚至許多需求團(tuán)隊(duì)在進(jìn)行需求捕獲活動(dòng)時(shí)，經(jīng)常預(yù)期用戶能夠直接告訴他們要做什么（What），而不太關(guān)心用戶提出需求的真正動(dòng)機(jī)（Why）。但是這樣就將解決方案的選擇權(quán)交給了并不熟悉技術(shù)的客戶代表，而客戶代表選擇的解決方案不是合適的話，就必將引發(fā)后續(xù)的需求變更。
案例&場景：
在CRM軟件開發(fā)的過程中……
負(fù)責(zé)輸入客戶信息的用戶向開發(fā)人員提出：“你看這個(gè)界面，光電話就有快10個(gè)輸入框，太麻煩了，每次按tab鍵都按酸了。我希望把他們合并成兩個(gè)，一個(gè)為常用電話，一個(gè)為其他電話”。
“那有多個(gè)電話怎么辦？”，開發(fā)人員回應(yīng)道。
“其他電話的輸入框可以設(shè)置為多行的、較寬的，這樣我可以輸入多個(gè)，中間用逗號(hào)分開它！”。
“好的，沒問題” 。
……
當(dāng)經(jīng)理看到了這些客戶信息之后，向開發(fā)人員提出：“我需要一個(gè)功能，輸入任何電話號(hào)碼，自動(dòng)找出相應(yīng)的客戶?！?BR> “啊……”
如果我們細(xì)究這個(gè)場景，分析一下負(fù)責(zé)輸入客戶信息的用戶所提出的變更就會(huì)發(fā)現(xiàn)：“將10個(gè)電話輸入框合并成兩個(gè)”顯然是解決方案，而真正的需求是“輸入太麻煩了，每次按tab鍵都按酸了”。你或許就會(huì)想到如下所示的解決方案：
也就是說，默認(rèn)情況上只顯示左邊的部分，當(dāng)需要時(shí)點(diǎn)擊“其它>>”按鈕就可以將右邊的不常用輸入項(xiàng)顯示出來。
總而言之，因?yàn)閷τ谝粋€(gè)特定的問題可能的解決方案會(huì)有很多，因此用戶可能在使用軟件的過程中不斷發(fā)現(xiàn)其他可選的、更合適的替代方案，從而導(dǎo)致了不必要的需求變更。而要緩解這一現(xiàn)象的關(guān)鍵就在于在需求捕獲的過程中多問“為什么”。
項(xiàng)目經(jīng)理：控制需求
當(dāng)我們比較圖1中第1幅和第2幅圖時(shí)，就會(huì)發(fā)現(xiàn)項(xiàng)目經(jīng)理在溝通的過程中會(huì)導(dǎo)致需求產(chǎn)生偏差。由于國內(nèi)許多軟件項(xiàng)目經(jīng)理們通常是一身兼多職，項(xiàng)目管理、需求分析、架構(gòu)設(shè)計(jì)一肩挑，因此在需求捕獲的過程中，總會(huì)“及時(shí)”地在腦海里勾勒出技術(shù)框架和路線，然后盡可能地控制需求的范圍。
就像這里，客戶需要的可能是一個(gè)“秋千”或者是“上樹工具”，但不管真正的需求是什么，第2幅圖中的解決方案卻都無法有效地滿足。如果要做“秋千”，不應(yīng)該被樹干擋住；如果要做“上樹工具”，木板的數(shù)量顯然太少了。
究其原因不難發(fā)現(xiàn)，需求人員首先從項(xiàng)目經(jīng)理的視角按工作量對需求進(jìn)行了控制：將“三層”板的工作量減成“一層”板，如果不小心控制掉的是對業(yè)務(wù)很重要的東西，那么終一定會(huì)以變更的形式“回報(bào)”給開發(fā)團(tuán)隊(duì)的。然后需求人員又從架構(gòu)師的角度進(jìn)行了“改良”：不穩(wěn)定的“全掛在一個(gè)樹枝上”改成“掛在兩個(gè)樹枝上”，結(jié)果根本無法使用。
因此具有多個(gè)角色的需求人員，必須在需求的過程中“戴正自己的帽子”，真正從理解業(yè)務(wù)的角度來捕獲需求。
分析人員：技術(shù)加工
案例&場景：
分析員小張：“嘿，伙伴們！我有個(gè)提議，我們研究Hibernate已經(jīng)有一段時(shí)間了，一直沒時(shí)間真正動(dòng)手用一用。我看這個(gè)項(xiàng)目就不錯(cuò)，不算太大，就用它試試吧！”。
“好主意！”，大家紛紛表示贊同。
……
“約定時(shí)間已經(jīng)過去1個(gè)月，現(xiàn)在項(xiàng)目進(jìn)展到底如何了？什么時(shí)候可以交付？”，客戶方CIO質(zhì)問到。
分析員小張：“現(xiàn)在主要困擾我們的是一些需求細(xì)節(jié)一直存在變化，開發(fā)團(tuán)隊(duì)又有了一些人離職，所以……”（真正的情況是：由于團(tuán)隊(duì)第使用Hibernate，有些數(shù)據(jù)訪問層的問題一直沒有有效解決，導(dǎo)致進(jìn)展不斷失控。）
現(xiàn)在許多名稱中包含“需求分析”、“系統(tǒng)分析”之類的職位，大多是由技術(shù)骨干擔(dān)任的，因此在工作中很少從業(yè)務(wù)角度進(jìn)行分析，更多還是追求技術(shù)框架、新技術(shù)。對于這種現(xiàn)象，究其根源，關(guān)鍵還在于“技術(shù)能力”對他們的未來發(fā)展更為重要，而“業(yè)務(wù)能力”卻不是那么重要。但為了使需求工作有更好的提高，我會(huì)強(qiáng)烈呼吁那些Title上有“分析”之類名稱的人們，加強(qiáng)業(yè)務(wù)分析吧！
編程人員：斷章取義
對于第4幅圖，可以用一句生動(dòng)的話來概括：“你要繩子，我給你了；你要木板，我也給你了；你為什么說這不是你想要的呢？”。我想程序員也有類似的問題想問自己的客戶，“你要文本框，我提供了；你要一個(gè)表單，我也有了；你為什么說這個(gè)程序不是你想要的呢？”。這讓我想起了這樣一幕：
案例&場景：
叮鈴鈴……，程序員小趙的電話急促地響起。小趙剛接起電話就聽到了對面迫不急待地抱怨聲“倉庫管理員反應(yīng)，入庫模塊沒法使用！你馬上查一下，盡快解決一下！”。
小趙放下電話就開始Check out、Builder、Run、Debug……等一系列操作。經(jīng)過一番測試之后，小趙沒好氣地提起電話回復(fù)說：“這些客戶真是笨！這哪有問題，肯定是操作上出了問題！我怎么用都是好的，你們客戶服務(wù)的人也應(yīng)該加強(qiáng)對用戶的培訓(xùn)，別什么事都扔給我們！”。
……
可是，問題仍然沒有解決！開發(fā)人員到了現(xiàn)場一看，終于發(fā)現(xiàn)了問題的所在：這是一套基于B/S的倉庫管理系統(tǒng)，在入庫時(shí)，倉庫管理員首先需要錄入入庫單，然后填入“驗(yàn)收情況”，后點(diǎn)擊“入庫”按鈕。但當(dāng)倉庫管理員錄入完入庫單，逐一驗(yàn)過入庫貨物之后再回到電腦前時(shí)，等待他的卻是一個(gè)令其不知所措的問題，Session超期！
一肚子氣的小趙一個(gè)電話就打到需求分析員小錢那里：“你們的需求是怎么寫的！這么重要的東西也不寫明白，我們怎么知道填完入庫單后要驗(yàn)貨那么長時(shí)間，才填寫驗(yàn)收情況呀！”。
“哦，這也算是需求嗎？如果這也算的話，那我們豈不成了業(yè)務(wù)人員了！”，小錢很強(qiáng)勢地回答到。
這是需求嗎？也許很多讀者會(huì)有不同的看法！但如果缺乏對業(yè)務(wù)場景的了解，又如何能夠真正理解需求呢？斷了“業(yè)務(wù)場景”之章，必將導(dǎo)致取出的“需求”之義有所偏差呀！
作者簡介：中國系統(tǒng)分析員顧問團(tuán)軟件工程首席顧問，中國軟件技術(shù)大會(huì)杰出貢獻(xiàn)專家，資深咨詢顧問。主要研究領(lǐng)域?yàn)樾枨蠊こ?、系統(tǒng)分析與設(shè)計(jì)、軟件估算，致力于推動(dòng)軟件工程方法論的落地應(yīng)用。本文節(jié)選（并改編）于筆者新著《軟件需求佳實(shí)踐：SERU過程框架原理與應(yīng)用》（電子工業(yè)出版社博文視點(diǎn)）