起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識從一則笑話到需求分析
小編導讀：回顧軟件開發(fā)上的許多案例，軟件開發(fā)失敗率一直居高不下，特別在外包開發(fā)領域中，這個值可能會更高一籌。在分析項目失敗的原因時，需求的因素可能是失敗的關鍵原因，需求不明確，客戶對需求的變更頻頻等等。
某日，老師在課堂上想考考學生們的智商，就問一個男孩:“樹上有十只鳥，開槍打死一只，還剩幾只？”
男孩反問:“是無聲槍么？”
“不是。”
“槍聲有多大？”
“80~100分貝。”
“那就是說會震得耳朵疼？”
“是?！?/p>
“在這個城市里打鳥犯不犯法？”
“不犯?！?/p>
“您確定那只鳥真的被打死啦？”
“確定。”老師已經(jīng)不耐煩了，“拜托，你告訴我還剩幾只就行了，OK？”
“OK。鳥里有沒有聾子？”
“沒有?！?/p>
“有沒有關在籠子里的？”
“沒有?！?/p>
“邊上還有沒有其他的樹，樹上還有沒有其他鳥？”
“沒有?！?/p>
“方圓十里呢？”
“就這么一棵樹?！?/p>
“有沒有殘疾或餓得飛不動的鳥？”
“沒有，都身體倍棒。”
“算不算懷孕肚子里的小鳥？”
“都是公的?！?/p>
“都不可能懷孕？”
“……，決不可能?！?/p>
“打鳥人的眼有沒有花？保證是十只？”
“沒有花，就十只。”
老師腦門上的汗已經(jīng)流下來了，下課鈴響起，但男孩仍繼續(xù)問:“有沒有傻的不怕死的？”
“都怕死。”
“有沒有因為情侶被打中，自己留下來的？”
“笨蛋，之前不是說都是公的嘛！”
“同志可不可以??！”
“……，性取向都很正常!”
“會不會一槍打死兩只？”
“不會。”
“一槍打死三只呢？”
“不會?！?/p>
“四只呢？”
“更不會!”
“五只呢？”
“絕對不會！??！”
“那六只總有可能吧？”
“不可能！”
“好吧，那么所有的鳥都可以自由活動么？”
“完全可以?！?/p>
“它們受到驚嚇起飛時會不會驚慌失措而互相撞上？”
“不會，每只鳥都裝有衛(wèi)星導航系統(tǒng)，而且可以自動飛行?！?/p>
“恩，如果您的回答沒有騙人，”學生滿懷信心地回答，“打死的鳥要是掛在樹上沒掉下來，那么就剩一只，如果掉下來，就一只不剩?！?/p>
老師當即倒地。
當然這只是一個笑話，笑過之后可能不少人會認為這個小朋友是做需求調研的最佳人選?；仡欆浖_發(fā)上的許多案例，軟件開發(fā)失敗率一直居高不下，特別在外包開發(fā)領域中，這個值可能會更高一籌。在分析項目失敗的原因時，需求的因素可能是失敗的關鍵原因，需求不明確，客戶對需求的變更頻頻等等。
一、需求的調研
需求調研是為需求說明書做前期工作，可以說需求說明書是從需求調研表中得到或抽取出來的。需求調研是要了解客戶希望所要開發(fā)的系統(tǒng)能夠解決他們的問題，以及了解他們對系統(tǒng)的期望等等。需求調研是整個開發(fā)的基礎，經(jīng)過需求調研的結果整理出需求說明書作為后續(xù)開發(fā)使用。
如果所做項目是一個陌生的行業(yè)（專業(yè)），往往需要專家或者顧問等角色的協(xié)助。但是作為調研人員最少要想辦法了解這個行業(yè)，或許你需要成為這個行業(yè)的專家，但最少要了解一定的專業(yè)知識（最少專業(yè)詞匯你要知道）。這樣客戶的溝通才能達到順暢，不會出現(xiàn)牛頭不對馬嘴的現(xiàn)象。
在某些難度不是很大的行業(yè)或者項目，做需求調研的時候可以通過自學的方式了解行業(yè)的特點，這些項目往往因為規(guī)模比較小，也不需要專家指導。但是作為調研的時候我們最需要了解的一些問題如，
1、客戶目前的問題與困難；
2、客戶現(xiàn)在的工作模式；
3、客戶對系統(tǒng)的期望；
4、客戶哪些要求是自己能做到的，哪些是依靠系統(tǒng)來做；
5、客戶對系統(tǒng)開發(fā)方式以及時間的要求等等。
其實做需求調研的時候最重要的目的在于資料收集，或許小孩的那種打破砂鍋的方式會引起客戶的反感，但是實際項目中往往需要的就是這些比較周全的調研方式，能夠考慮到的問題點都需要和客戶確認，盡量避免想當然的做法，只是采用的方式可能需要優(yōu)化一下，采用良好的方式，盡量得到客戶的最大配合。
二、需求的描述和確認
對于需求的調研內容需要進行整理和分類，分清有用功能、可選用功能、無用功能及不可實現(xiàn)功能。對于這些功能和客戶再次確認之后才能最終形成開發(fā)的需求文檔。對于需求的描述有很多方法和工具，但是無論采用哪種方法和工具都是相對抽象的方式，如何讓客戶能夠理解需求的實際內容，需要客戶有良好的理解能力，畢竟系統(tǒng)還只是紙面上的內容，客戶還是很難完全了解到真實的系統(tǒng)。
如何對需求進行描述在項目開發(fā)中是一個很難定奪的題目，有些公司采用Demo的方式，有些采用傳統(tǒng)的功能樹方式，有些采用界面的描述方式，有些采用UML建模的方式，形式多種多樣，各種方式都有其好壞。但是對于方式的選擇需要注意一些問題，
1、了解客戶是否能夠理解所描述的問題；
2、避免先入為主；
3、避免形式主義。
有些公司采用UML描述需求，但是客戶的能力達不到能夠理解UML所描述的問題，甚至公司內部的開發(fā)人員也無法很好的理解UML，可能只有需求人員懂UML，這種需求結果就值得思考，客戶是否知道你在說什么？如果你先入為主使用這種方式來描述問題，難道期望客戶去學習這些知識嗎？
三、需求的控制
客戶往往很難知道他們需要什么樣的系統(tǒng)，有時候系統(tǒng)做到一半的時候客戶會提出一些新的想法，甚至等系統(tǒng)上線的時候客戶才發(fā)現(xiàn)系統(tǒng)和他們腦子里想的東西完全不是一回事。對于這些可能會說當初需求定義的時候不是簽過字，確定做成這樣，怎么不是你想要的呢？問題可能會歸根于與客戶溝通的方式和手法上。但是對于需求的控制來說，對如何避免需求的反復，客戶腦門一熱就有新點子出來，還有許多不切實的要求等等，都在需求控制范圍內。
有人會說我們和客戶說好了，協(xié)議也簽訂說：除了紙上描述的東西之外，其余的都是變更追加。但是這個觀點固然好，也是完全歸于一方有利來考慮，而且有很多時候我們簽署在合同內的需求文檔也比較含糊。另外，雙方在問題的理解上可能會有歧義，一旦真正要將合同拿出來對峙的時候，彼此都很難說服對方。就像樹上有十只鳥一樣，沒有說好環(huán)境，狀態(tài)等等的假設，一切的結果應該說都可能是合理的。
如何控制需求，除了軟件工程上提出的那些理論之外，也很難有新的觀點，但是在實際的操作過程中，我們可能一方面要維護和客戶的關系，另一方面也要考慮系統(tǒng)的開發(fā)時間和整體工數(shù)等等，做一個權衡。筆者更趨向使用問題具體化的方式來控制，盡量將能夠想出的問題通通羅列出來和客戶確認，同時采用換位思考的方式，盡量能夠讓客戶理解我們所描述的系統(tǒng)狀況。如果在調研和需求的確認階段能夠把工作做得很好，在后期的開發(fā)過程中變更的內容就會比較少，變更的內容也就容易控制。
和客戶進行良好的溝通，多為客戶做一個考慮，避免將自己以一個高調姿態(tài)介入和客戶的溝通中，說一些客戶很難懂的專業(yè)術語，將客戶噴的云里霧里，自以為自己的專業(yè)領域多么了不起，這種和客戶的溝通方式最容易造成需求空洞，后期翻盤的概率很高。如果客戶不懂你口中所說的內容，可能問題出于客戶，另外更大的程度出于你，我們需要考慮采用的溝通方式以及內容是否通俗易懂，能將復雜的問題講的簡單就證明你不簡單
本文作者：@ houzeal? ? ? ? ? ? ? 來自：CSDN
- 目前還沒評論，等你發(fā)揮！
