某日，老師在課堂上想考考學生們的智商，就問一個男孩:“樹上有十只鳥，開槍打死一只，還剩幾只？”

男孩反問:“是無聲槍么？”

“不是。”

“槍聲有多大？”

“80~100分貝。”

“那就是說會震得耳朵疼？”

“是。”

“在這個城市里打鳥犯不犯法？”

“不犯。”

“您確定那只鳥真的被打死啦？”

“確定。”老師已經不耐煩了，“拜托，你告訴我還剩幾只就行了，OK？”

“OK。鳥里有沒有聾子？”

“沒有。”

“有沒有關在籠子里的？”

“沒有。”

“邊上還有沒有其他的樹，樹上還有沒有其他鳥？”

“沒有。”

“方圓十里呢？”

“就這么一棵樹。”

“有沒有殘疾或餓得飛不動的鳥？”

“沒有，都身體倍棒。”

“算不算懷孕肚子里的小鳥？”

“都是公的。”

“都不可能懷孕？”

“……，決不可能。”

“打鳥人的眼有沒有花？保證是十只？”

“沒有花，就十只。”

老師腦門上的汗已經流下來了，下課鈴響起，但男孩仍繼續問:“有沒有傻的不怕死的？”

“都怕死。”

“有沒有因為情侶被打中，自己留下來的？”

“笨蛋，之前不是說都是公的嘛！”

“同志可不可以啊！”

“……，性取向都很正常!”

“會不會一槍打死兩只？”

“不會。”

“一槍打死三只呢？”

“不會。”

“四只呢？”

“更不會!”

“五只呢？”

“絕對不會！！！”

“那六只總有可能吧？”

“不可能！”

“好吧，那么所有的鳥都可以自由活動么？”

“完全可以。”

“它們受到驚嚇起飛時會不會驚慌失措而互相撞上？”

“不會，每只鳥都裝有衛星導航系統，而且可以自動飛行。”

“恩，如果您的回答沒有騙人，”學生滿懷信心地回答，“打死的鳥要是掛在樹上沒掉下來，那么就剩一只，如果掉下來，就一只不剩。”

老師當即倒地。

當然這只是一個笑話，笑過之后可能不少人會認為這個小朋友是做需求調研的最佳人選。回顧軟件開發上的許多案例，軟件開發失敗率一直居高不下，特別在外包開發領域中，這個值可能會更高一籌。在分析項目失敗的原因時，需求的因素可能是失敗的關鍵原因，需求不明確，客戶對需求的變更頻頻等等。

一、需求的調研

需求調研是為需求說明書做前期工作，可以說需求說明書是從需求調研表中得到或抽取出來的。需求調研是要了解客戶希望所要開發的系統能夠解決他們的問題，以及了解他們對系統的期望等等。需求調研是整個開發的基礎，經過需求調研的結果整理出需求說明書作為后續開發使用。

如果所做項目是一個陌生的行業（專業），往往需要專家或者顧問等角色的協助。但是作為調研人員最少要想辦法了解這個行業，或許你需要成為這個行業的專家，但最少要了解一定的專業知識（最少專業詞匯你要知道）。這樣客戶的溝通才能達到順暢，不會出現牛頭不對馬嘴的現象。

在某些難度不是很大的行業或者項目，做需求調研的時候可以通過自學的方式了解行業的特點，這些項目往往因為規模比較小，也不需要專家指導。但是作為調研的時候我們最需要了解的一些問題如，

1、客戶目前的問題與困難；

2、客戶現在的工作模式；

3、客戶對系統的期望；

4、客戶哪些要求是自己能做到的，哪些是依靠系統來做；

5、客戶對系統開發方式以及時間的要求等等。

其實做需求調研的時候最重要的目的在于資料收集，或許小孩的那種打破砂鍋的方式會引起客戶的反感，但是實際項目中往往需要的就是這些比較周全的調研方式，能夠考慮到的問題點都需要和客戶確認，盡量避免想當然的做法，只是采用的方式可能需要優化一下，采用良好的方式，盡量得到客戶的最大配合。

二、需求的描述和確認

對于需求的調研內容需要進行整理和分類，分清有用功能、可選用功能、無用功能及不可實現功能。對于這些功能和客戶再次確認之后才能最終形成開發的需求文檔。

對于需求的描述有很多方法和工具，但是無論采用哪種方法和工具都是相對抽象的方式，如何讓客戶能夠理解需求的實際內容，需要客戶有良好的理解能力，畢竟系統還只是紙面上的內容，客戶還是很難完全了解到真實的系統。

如何對需求進行描述在項目開發中是一個很難定奪的題目，有些公司采用Demo的方式，有些采用傳統的功能樹方式，有些采用界面的描述方式，有些采用UML建模的方式，形式多種多樣，各種方式都有其好壞。但是對于方式的選擇需要注意一些問題：

1、了解客戶是否能夠理解所描述的問題；

2、避免先入為主；

3、避免形式主義。

有些公司采用UML描述需求，但是客戶的能力達不到能夠理解UML所描述的問題，甚至公司內部的開發人員也無法很好的理解UML，可能只有需求人員懂UML，這種需求結果就值得思考，客戶是否知道你在說什么？如果你先入為主使用這種方式來描述問題，難道期望客戶去學習這些知識嗎？

三、需求的控制

客戶往往很難知道他們需要什么樣的系統，有時候系統做到一半的時候客戶會提出一些新的想法，甚至等系統上線的時候客戶才發現系統和他們腦子里想的東西完全不是一回事。

對于這些可能會說當初需求定義的時候不是簽過字，確定做成這樣，怎么不是你想要的呢？問題可能會歸根于與客戶溝通的方式和手法上。但是對于需求的控制來說，對如何避免需求的反復，客戶腦門一熱就有新點子出來，還有許多不切實的要求等等，都在需求控制范圍內。

有人會說我們和客戶說好了，協議也簽訂說：除了紙上描述的東西之外，其余的都是變更追加。但是這個觀點固然好，也是完全歸于一方有利來考慮，而且有很多時候我們簽署在合同內的需求文檔也比較含糊。

另外，雙方在問題的理解上可能會有歧義，一旦真正要將合同拿出來對峙的時候，彼此都很難說服對方。就像樹上有十只鳥一樣，沒有說好環境，狀態等等的假設，一切的結果應該說都可能是合理的。

如何控制需求，除了軟件工程上提出的那些理論之外，也很難有新的觀點，但是在實際的操作過程中，我們可能一方面要維護和客戶的關系，另一方面也要考慮系統的開發時間和整體工數等等，做一個權衡。

筆者更趨向使用問題具體化的方式來控制，盡量將能夠想出的問題通通羅列出來和客戶確認，同時采用換位思考的方式，盡量能夠讓客戶理解我們所描述的系統狀況。如果在調研和需求的確認階段能夠把工作做得很好，在后期的開發過程中變更的內容就會比較少，變更的內容也就容易控制。

和客戶進行良好的溝通，多為客戶做一個考慮，避免將自己以一個高調姿態介入和客戶的溝通中，說一些客戶很難懂的專業術語，將客戶噴的云里霧里，自以為自己的專業領域多么了不起，這種和客戶的溝通方式最容易造成需求空洞，后期翻盤的概率很高。

如果客戶不懂你口中所說的內容，可能問題出于客戶，另外更大的程度出于你，我們需要考慮采用的溝通方式以及內容是否通俗易懂，能將復雜的問題講的簡單就證明你不簡單。

河南億恩科技股份有限公司(www.artduck.net)始創于2000年，專注服務器托管租用，是國家工信部認定的綜合電信服務運營商。億恩為近五十萬的用戶提供服務器托管、服務器租用、機柜租用、云服務器、網站建設、網站托管等網絡基礎服務，另有網總管、名片俠網絡推廣服務，使得客戶不斷的獲得更大的收益。
服務器/云主機 24小時售后服務電話：0371-60135900
虛擬主機/智能建站 24小時售后服務電話：0371-55621053
網絡版權侵權舉報電話：0371-60135995
服務熱線：0371-60135900