需求分析中应该注意的问题
在做項目時,經常會碰到這樣的事情.
客戶向我們反映在和你們的工程師談論需求時,他們總是滿口答應沒問題。可是,當他們做好以后,拿過來一看,根本就不是這么回事。而開發人員也在訴苦:用戶什么都不懂,而且他們的需求老是變動,時間又這么緊,你讓我們怎么辦?
我覺得如果開發人員在做需求分析時,如果注意以下幾點,也許可以避免被動的局面.??
1、掌握相關的行業知識
在和客戶溝通之前,最好了解一下相關的行業知識。
有一個項目管理人員說:行業知識可有可無,作為需求人員,最重要的是和客戶溝通。最好把客戶講的東西都記下來。然后,由項目組決定后,再把意見反饋給用戶。這種溝通方式,既不能有效的發現問題,也容易延誤項目時間。
案例:
小A某名牌大學畢業,公司為了鍛煉他,特意安排他和一個比較重要的客戶進行一次溝通。小A和客戶電話聯系,商定了見面的時間和地點。西裝革履的小A提前十 分鐘來到了見面的地點。一番客套之后,小A和客戶就開始進入話題。客戶開始談他的需求,從項目背景到項目目的,從業務流程到相關部門和人員。客戶興致勃勃 地說著,小A手忙腳亂的記著。客戶停下來,問小A你覺得我的觀點有什么需要補充嗎?小A老實地回答說,我對業務還不是很熟悉。客戶一下興致全無,對小A 說,等你對業務熟悉了,再來找我把。
2、重在溝通
溝通的方式可以是訪談和調研、會議、電話、電子郵件、小組討論、模擬演示等不同形式。我的意見是最好是與客戶面對面的溝通。金庸武俠小說中的高手過招,都是面帶微笑,不露聲色,比拼的是內力。面對面的溝通,就是比拼內力。所以,一定要把準備工作都做好了。
溝通其實也是在相互妥協。對用戶合理的要求,要盡量滿足。用戶的一些不合理的要求,要想辦法避免。要委婉地提醒用戶,如果這樣做,可能要增加項目時間,或者對運行環境有更高的要求。
溝通一定要有記錄,對于交流的結果還可以進行分類,便于后續的分析活動。
3、深究細節
不要等到項目做好后,才讓客戶發現問題。
客戶所能提供給你的只是他們想到的功能需求,很多問題并不在他們考慮的范圍之內,如果作為項目承擔方沒有去做分析,簡單的按照功能要求去設計、規劃,最終 出來的系統是很難完全符合客戶的業務流程的.這時,在客戶看來當然需要更改.但這種更改卻被我們看成了需求的更改。既然是需求的更改,那么就需要增加項目 成本(資源)或延長項目時間。我看過一篇文章,說要要想項目成功,就得和用戶建立親密的伙伴關系.可是,這種以需求的更改為理由讓用戶從口袋里掏錢,親兄 弟也不干阿.
所以,需求分析不僅僅是拿到客戶的需求,更重要的是還需進行分析,了解細節,并就細節跟客戶咨詢,獲取最詳細的資料。
需求是最重要的工作,也是最麻煩的。 客戶是不懂需求的,他們的腦海里面沒有這個概念, 他們只希望你做出能用的系統 ,用著順手就好
我認為做需求有幾個地方是比較關鍵的
1.人際交往能力 。這是最根本的 不用多說
2.了解需求后及時做出demo讓客戶確認,確認后要簽字。這一點非常重要,很多時候我們了解了需求就悶頭開發,等開發完畢后,卻不是客戶想要的東西,造成巨大浪費;簽字是為了讓客戶認真對待這個demo
3.能用就好,不要過多追求。程序員往往追求完美,想一下子把工作做到位;而最有效率的方法是盡快看到結果 然后再慢慢完善。在項目初期需求會經常改變,這樣的目的也是避免把過多時間耗在無用的需求上。
做過軟件的人都聽過這樣的抱怨:需求變化太快,軟件系統經常要修改,都連續加班幾個星期了……
通常面對這樣的問題,要如何解決呢?
首先,問題的根源是:需求不斷變化。
很多人都有這樣的經歷,在捕獲需求時,根據客戶的闡述,做了記錄,然后開發出了軟件,客戶卻說很多地方不符合他們的意思,又要求修改。
我們分析一下捕獲需求過程中存在的問題。
客戶很可能對軟件方面的知識知之甚少,他并不知道你需要知道什么。
比如說,一個業務流程,從業務邏輯到能轉化成軟件實現很可能會有問題。這就是所說的信息化過程中需要進行的業務改造,因為能輸入計算機,并輸出結果的一 定是能進行形式化處理的內容,這也是很多企業員工抵制信息化的原因之一,因為信息化會導致人的因素會被相對削弱,他們的工作過程也會完全被透明化。
這樣,我們就一定要讓客戶知道你要知道的是什么。如何做到呢?
對于產品類的項目,你的客戶不是一個,那么就要廣泛的去征求意見,需求調查問卷通常對全面了解客戶需求有一定的作用。
對于特定客戶,需要和他們直接溝通交流。
和客戶交流要注意方式方法,不能盲目約見,下面是一些行之有效的方法。
一、 會面前做充分的準備
通常會面前的問題列表準備時間要遠遠多于會面的時間。通常客戶在連續和你交談2個小時之后,就會失去熱情和耐心,這是大部分人的共同特點。所以充分的準備工作很重要。
如果你去客戶那捕獲需求,通常客戶會說,我需要做一個什么樣的系統,然后我可以用它來做這個,那個,還有那個……,然后就不知道該說什么了。這 時,你一定要拿出事先準備的問題列表,針對每個大的功能的每一個功能點進行提問,一個都不能放過。對非功能的需求也同樣不能放過,如客戶需要的系統至少連 續運行多少小時不出問題,系統在若干數量的訪問者訪問時的響應時間范圍等。
如果你在會面前沒有對客戶提供的資料,表格等進行全面研究,對客戶需求就不可能調查全面,你可能需要反復去約見他,這樣你會給客戶留下工作效率低的印象,他對你會逐漸的感到厭煩,對你未來的工作表現會失去信心。
二、讓客戶打開話匣子
對客戶進行提問,引導客戶說出他們的需求,是非常關鍵的,這里面的學問也是很大的。
有一些人通常會問這樣的問題:“你們的工作流程是什么樣的?”,這種問題是非常經典的無效問題。
當你向客戶提出問題的時候,你可以先進行換位思考,如果有人問你這個問題你該怎么回答呢?是不是很好回答呢?如果連你也覺得這個問題并不好回答時,就需要考慮換個問法了。
通常人們在談論自己很熟悉的東西時,都會有說不完的話,對于客戶自己每天做的工作,他為什么沒辦法對你談呢?
問恰當的問題,問能讓客戶打開話匣子的問題,你就勝利了。
這時你會面前的準備工作就顯得尤為重要了,你要針對他們要做的軟件的功能,一部分一部分的問,不能著急,要深入,并細致,對于他們如何處理這些事情的操 作習慣等都要重視,因為要改變他們的習慣,讓他們適應你的軟件的一種新的操作方法通常是會降低客戶滿意度的,甚至他們會要求你進行修改。
對于你對某些功能的猜想和假設,也一定要問客戶,是不是根本就不需要,客戶有時會礙于情面不好意思說出你的想法是沒有必要的或是錯誤的,這時你一定要足夠敏感,并勇于否定自己,這樣會減少不必要的開發工作,也會給客戶留下你很尊重事實的良好印象。
三、千萬不要浪費客戶的時間
和客戶面談時特別要注意一點,就是千萬不能浪費客戶的時間,讓他覺得非常無聊,這是捕獲需求最大的忌諱。
一旦你犯了這樣的錯誤,你再想約見他就難了,他很可能不愿意再和你會面了。尤其是企業中的領導,他們通常是日理萬機,能抽出時間和你會面,你應該感到很榮幸,因此要格外珍惜會面的時間。
這也是很多作需求的人員常常抱怨的問題,“客戶經常沒時間見我,我有什么辦法”,如果你遇到了這類問題,你一定要反省一下自己,是不是曾經犯過這樣的錯誤,下次一定不要再犯了。
四、搞清能正確回答問題的人
不同的問題需要問不同的人,需求中有很多是細小的操作級別的問題,也有很多是關乎全局的問題,這就要求一定要搞清楚什么問題去問什么人。
很多捕獲需求的人員抱怨說,“客戶答不上這些問題,他們自己都不知道要怎么做”,如果你碰到了這種事情,就要反省一下,你問對人了嗎?
客戶中有一些是大干部,有些是中層管理人員,還有操作人員。對于操作細節上的問題,一定要去問那些負責操作的人員,他們會更清楚每個步驟需要怎么去操作,如果你去問大干部這些問題,你通常會被搪塞,或者以工作太忙,還有其他得事等原因被打發掉。
對于關乎全局的問題,操作級別的人員給出的答案通常是不權威的,即便他們回答了你,你也一定要去大干部那里確認一下,再開始開發工作,否則你會后悔的。
五、發揮原型的效力
原型對于提高客戶對軟件的認知程度有很好的效果,他能使客戶對軟件有一個直觀的認識,面對原型,他們可以更好地提出他們的想法和意見,尤其對那些對軟件缺乏認識的客戶。
對原型的修改,再確認,最后得到穩定的原型,這些工作會讓需求更穩定,減少很多實施工作中的反復修改工作或者返工。
六、充分利用需求確認會議
需求確認會議通常由全體涉眾(利益相關人)參加,這可是個確認需求的難得的機會,大家能聚在一起,這樣的機會其實很難得,所以一定要珍惜。
在這種會議上,一定要先針對全局性的問題(與大家都相關的問題)進行交流,千萬不要針對部分人感興趣的問題討論個沒完沒了,那樣的話,不感興趣的人會走 開的,那樣你再想征求與他們相關問題的意見時就找不到人了。對于只跟個別部門或人員有關系的問題你可以單獨找時間根他們討論。
總結
以上是生活随笔為你收集整理的需求分析中应该注意的问题的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 软件项目管理的内在定律
- 下一篇: 软件开发定律系列之布鲁克斯定律有感