IT项目需求分析的重点关注事项
研究發現,在需求開發階段發現的一個錯誤,平均僅需要花30分鐘修復,若在系統測試時發現則需要5到17個小時來修復。實踐證明,要改正在產品付諸應用后所發現的一個需求方面的缺陷比在需求階段改正這個錯誤要多付出大約100倍的成本。因此,我們不難發現,需求分析在IT項目中具有十分重要的作用。所謂需求分析是指通過對問題域的研究,獲得對該領域特性及存在于其中(需要解決)的問題特性的透徹理解并有文檔的說明。本文結合作者在實際項目管理工作中的經驗,就IT項目中需求分析時應注意的主要問題進行了研究分析。
1、與用戶進行充分溝通
通常,與用戶溝通前的準備時間要遠遠大于正式會面溝通的時間。一般情況下,用戶在和你連續交談兩個小時之后,就會失去熱情和耐心,這是大部分人的共同特點。所以充分的準備工作至關重要。
準備工作包括對項目整體環境熟悉的準備工作和對具體業務進行調研前的準備工作。項目整體環境的熟悉工作需要了解:項目的背景、項目的目的、項目的利益相關方等信息,以便對當前項目的鷹缽情況有一定了解。
對具體業務調研前的準備工作包括:需求調研問題的準備、需求調研模板的設計、需求調研時間安排等內容。要充分珍視用戶的時間,盡量避免由于準備工作不足而反復約見用戶,給用戶造成效率低下的印象。一旦發生這樣的錯誤,以后可能就會很難約見到用戶。
2、主動積極了解客戶業務和相關知識
在計算機技術方面我們可能非常專業,但對于具體的用戶業務可能并不十分清楚。這個項目對用戶是否有幫助、某一系統功能是否有用、某一流程處理是否合理,在不了解用戶業務的情況下,我們將很難做出判斷。
因此只有在了解業務的基礎上,我們才和用戶有共同的溝通語言和業務理解,才能真正理解系統應具有哪些功能。筆者曾在經銷商管理系統調研過程中,由于財務方面的知識有限,使得在對經銷商財務部門的調研中對部分問題不是特別的理解。
當時,筆者向用戶虛心進行請教,并在調研結束后及時對自己的財務知識進行了補充。應用領域的知識是無邊無際的,在各種項目的調研過程中,肯定會出現由于需求分析者缺乏某一領域的知識而影響需求分析工作的準確、順利進行。遇到此類問題時,需求分析者應虛心向用戶請教,同時應及時補充應用領域的知識。最好能夠在調研前做好充分的準備。
3、引導用戶,使用戶充分表達自己的想法
在與用戶交談中,如何引導用戶說出他們的需求是非常關鍵的。恰當的提問,會使用戶滔滔不絕,充分發表自己的意見和建議。而不恰當的提問,可能會導致用戶無法回答或敷衍了事地進行回答。提問可分為封閉式提問和開放式提問。
封閉式提問目的明確。如:現在你們的送貨單是手工填寫還是電腦打印?但過多使用封閉式提問,會導致談話枯燥,讓用戶感覺自己好像在接受審問。開放式提問是請對方對某一事物做進一步的解釋,可使談話達到一定的深度和廣度。
如:你認為目前的工作中存在哪些可以改進的地方?開放式提問缺點是容易使談話內容偏離主題。因此在談話過程中,應采用封閉式和開放式提問相結合的方式。以簡單問題開始、從用戶熟悉的內容開始。每次只提一個問題、集中一個重點,寧問勿猜。并盡量避免使用IT相關的一些術語,以便用戶能夠很好地理解我們的表達。
4、對用戶進行正確分類
組織中的用戶在很多方面存在差異,例如:使用系統的頻度和程度、計算機系統知識、所進行的業
務過程以及個人的素質和喜好等。根據用戶的特點,可對用戶進行一定的分類。將用戶分類并歸納各自特點,詳細描述他們的個性特點及任務狀況,將有助于需求的獲取和分析。
不同的問題需要詢問不同的人,對于操作細節的問題,要和實際負責操作的用戶進行溝通,而對于關乎全局的問題,則要和相應的管理層用戶進行溝通。如通過組織架構圖得知倉庫部門有三種角色:倉庫主管、發貨理貨員、系統操作員。
我們發現倉庫主管是對全盤業務相當熟悉的人,他負責協調本部門的全局事務;而發貨理貨員是部門的主要業務執行人;系統操作員則是倉庫管理系統的直接操作者。若我們調研的目的是搞清該部門的整體性流程,我們會很自然地選擇倉庫主管作為訪談的對象。
5、應實地了解用戶工作流程
實地觀察用戶執行業務任務的過程。了解用戶什么時候獲得什么數據,并怎樣使用這些數據,業務處理過程中需要處理哪些單據,需要和哪些角色的用戶發生關聯等。這都將有助于明確產品的功能需求。
經驗證明,與人們面談關于他們如何完成任務時會有許多限制和不準確性,而這是任務觀察可以直接解決的。特別是對于某些組織中普遍接受的規則和方法,用戶認為你也應理所當然知道,而不曾提起時。
近年來,由于人機交互的復雜性驚人地增加,人機交互的觀察和記錄已引起人們的廣泛注意。觀察是一個主觀的領域,很大程度上依賴于需求分析者的經驗。在經銷商管理系統的需求分析中,通過觀察發現:某些客戶要求送貨單中的商品價格為含稅價格,而有些客戶則要求送貨單上的商品價格為不含稅價格;有些商品的稅率為13%,而有的商品稅率為17%;
有些客戶要求送貨單上的金額小數點后保留四位,有的客戶又要求送貨單上必須提供自己公司的商品編碼等。而這些都是在調研中,用戶不曾提起的內容。
6、分析需求可行性
柳傳志曾說:“沒錢賺的事我們不干;有錢賺但投不起錢的事不干;有錢賺也投得起錢但沒有可靠的人選,這樣的事也不干?!?br /> 柳傳志為聯想集團的決策確立了上述準則,同時也為可以行性分析指明了重點。可行性分析主要是針對某一需求決定是做還是不做。一般可行性主要考慮兩個方面的因素:技術和人。技術方面主要是分析在給定的時間段內是否可實現所需的功能并滿足產品的質量要求等相關指標。
很多時候,用戶的想法在實際實施過程中是不現實的。若一味地求全和盲目遵從用戶的設想,將為項目的后續工作帶來很大的風險。因此應盡量避免在需求分析中包含技術實施上有難度的功能。如在筆者曾經負責的一個項目中,用戶要求新的管理系統應實現和用友、金蝶等管理系統的數據接口,以方便這些系統中的數據導人新的管理系統。
許諾提供與用友、金蝶等系統的數據接口,將為新系統的成功實施帶來很大的風險。因為熟悉這些系統需要時間,開發與它們的接口也需要時間,而且用友、金蝶等這些系統存在多個不同的版本。因此與外部系統接口的可行性定義為:不可行。
人的方面主要考慮目標用戶是否具有相應的素質和能力。在實際項目中,筆者曾對快速消費品行業經銷商批次管理的可行性進行了分析。首先,批次管理將涉及到所有產品的出入庫操作,并存在一個產品有多個批次的情況,因此批次管理對操作人員的能力和素質要求比較高。
其次,快速消費品行業的特點決定了產品的出入庫操作極為頻繁,因此,操作人員的工作強度比較大。再次,大部分經銷商的倉庫所在地都距離城鎮比較遠,因此工作人員的文化水平普遍不高。在
綜合考慮后,將批次管理的可行性定義為低。
對于復雜的項目,還應從經濟方面和環境方面進行考慮。經濟方面主要從投入、收益、短期、長遠利益等方面進行分析。環境方面主要考慮市場環境和政策因素。
7、確定需求的優先級別
當客戶的期望很高、開發時間很短且資源有限時,設定需求的相對優先級將有助于項目管理人員解決沖突、安排階段性交付并做出必要的取舍。建立每個需求的重要性有助于規劃軟件的構造,以最少的費用提供產品的最大功能。
特別是對漸進式的項目,優先級的設定就顯得更為重要,因為在這些開發中,項目時間安排極為緊迫并且交付日期不可改變,一些低優先級的需求就需要推遲到后續版本中進行實現或直接取消。
當眾多用戶因期望不同而就某些需求優先級的設定難以達成一致意見時,需求分析者可指出每一需求所需的費用、難度、技術風險或其他特定的與權衡需求有關的指標,來客觀評價每一需求的優先級。
8、正確理解需求分析文檔確認
需求分析是一項繁瑣枯燥的工作,需要和用戶不斷的商討、確認和反復。但大部分用戶并不只做這項工作,特別當他被很多其他的事情纏身的時候,而無心在筆者曾負責的經銷商管理系統中,經銷商認為,庫存過高將占用企業運轉資金,增加企業負擔;庫存過低則無法滿足客戶訂單,從而導致交貨周期延長,降低企業市場競爭力。由于經銷商對當前可用庫存十分關注,因此可用庫存的優先級被定義為:高優先級。仔細考慮或回答你的問題。這很容易使你錯誤地認為用戶已經真正地了解并認可了你的分析文檔。
在需求分析文檔上簽字確認,通常被認為是用戶同意需求分析內容的標志行為。而實際操作中,簽字確認工作并未得到用戶的充分重視。“他們要求我在需求文檔上簽名,于是我就簽了,否則開發人員不開始編碼?!庇脩舻倪@種態度將可能給項目帶來潛在的風險,如不斷地進行需求變更等。
對于需要用戶確認的需求分析文檔,最好在用戶確認前,就文檔內容對用戶進行一定的講解,以確保用戶完全理解并認可文檔中的內容。若用戶對文檔中的內容存在修改意見,則修改后再與用戶進行確認,直至用戶完全認可文檔中的內容為止。通常為對項目有一個整體、準確的理解,需求分析所包含的內容通常大于項目范圍所包含的內容。
因此,應讓用戶理解對于某些功能的討論并不意味著即將在系統中實現它。應使用戶明白對需求分析文檔的簽字確認是建立一個需求的基線,進一步的變更可在此基線上通過項目定義的變更過程來進行。需求確認將給初步的需求開發工作畫上了雙方都明確的句號,并有助于形成一個持續良好的用戶與需求分析人員的關系,為項目的成功奠定堅實的基礎。將知識從一個地方傳送到另一個地方并不是一件簡單的事情,而且原始的需求通常是以不完整的形式呈現的。它也許只是在某個現有系統的用戶腦中,甚至有時用戶都沒有意識到他們知道什么。同時需求分析工作者也應在日常工作中加強學習,不斷總結,使自己的需求分析能力得到不斷的提升。
總結
以上是生活随笔為你收集整理的IT项目需求分析的重点关注事项的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Python极简入门:数据类型、条件语句
- 下一篇: 项目管理中的客户需求变更时需求分析和解决