錨點Q1： 如何了解和分析客戶需求？
1，首先要圈定明確的客戶群
只有明確的客戶群
才能讓我們很好去研究
2，學會用客戶的語言來描繪產品
3，學會理解客戶的多重身份
4，了解客戶的價值觀
5，理解客戶需求背后的深層次心理需求
6，像客戶一樣體驗，像客戶一樣感知他們的生活世界
1）像客戶一樣看
2）像客戶一樣用
3）像客戶一樣想
去體驗客戶的生活世界，而不是客觀世界。只有這樣，才能像有經驗的銷售那樣，能見到什么人說什么話。二，銷售員如何了解客戶的需求(如何了解客戶需求并做好分析)利用提問來了解客戶需求通過傾聽來了解客戶需求通過觀察來了解客戶需求客戶的需求是千差萬別的，不了解客戶的需求，就無法提供有效的服務，更不可能贏得客戶忠誠。在實踐中，通常可以通過以下方法來了解客戶的需求。1．利用提問來了解客戶的需求 要了解客戶的需求，提問題是最直接、最簡便有效的方式。通過提問可以準確而有效地了解到客戶的真正需求，為客戶提供他們所需要的服務，在實際運用中有以下幾種提問方式可以供我們靈活選擇運用： (1)提問式問題。單刀直入、觀點明確的提問能使客戶詳述你所不知道的情況。例如，你可以問：“*，您打開電腦時，發生了什么情況？”這常常是為客戶服務時最先問的問題，提這個問題可以獲得更多的細節。 (2)封閉式問題。封閉式的問題即讓客戶回答“是”或“否”，目的是確認某種事實、客戶的觀點、希望或反映的情況。問這種問題可以更快地發現問題，找出問題的癥結所在。例如“*，當電腦出現問題時，您是讓它開著還是關著？”這個問題是讓客戶回答是“開”還是“關”。如果沒有得到回答，還應該繼續問一些其他的問題，從而確認問題的所在。 (3)了解對方身份的問題。在與客戶剛開始談話時，可以問一些了解客戶身份的問題，例如對方姓名、賬號、電話號碼等。目的是獲得解決問題所需要的信息。(4)描述性問題。讓客戶描述情況，談談他的觀點，這有利于了解客戶的興趣和問題所在。(5)澄清性問題。在適當的時候詢問、澄清客戶所說的問題，也可以了解到客戶的需求。(6)有針對性的問題。例如要問客戶對所提供的服務是否滿意，這有助于提醒客戶再次惠顧。 (7)詢問其他要求的問題。與客戶交流的最后，你還可以問他還需要哪些服務。例如“先生，還有沒有其他我們能為您做的？”通過主動詢問客戶的其他要求，客戶會更容易記住你和你的公司。2、通過傾聽客戶談話來了解客戶的需求 在與客戶進行溝通時，必須集中精力，認真傾聽客戶的回答，站在對方的角度盡力去理解對方所說的內容，了解對方在想些什么，對方的需要是什么，要盡可能多地了解對方的情況，以便為客戶提供滿意的服務。3．通過觀察來了解客戶的需求 要想說服客戶，就必須了解他當前的需要，然后著重從這一層次的需要出發，動之以情，曉之以理。在與客戶溝通的過程中，你可以通過觀察客戶的非語言行為了解他的需要、欲望、觀點和想法。總而言之，通過適當地問問題，認真傾聽，以及觀察他們的非語言行為，可以了解客戶的需求和想法，更好地為他們服務。 三，企業應該如何了解客戶需求？(如何了解客戶需求并做好分析) 客戶總是有兩組需求，能明確說出的是一組，可以稱之為“有聲的需求”；另一組是沒有說出來的，可以稱之為“沉默的需求”。通常，有聲的需求是在任何一個行業中大多數商家試圖滿足的需求，了解這種需求并不困難。較為困難的是識別客戶沉默的需求。很多時候，企業能夠領先一步之處就在于了解到了客戶的更多需求。 把定期調研變為隨時隨地 為什么產品功能與客戶的需求總是不一致？是不是要對客戶的每一個需求都說“是”？如何把握客戶需求的層次來更好地實現客戶需求？ 每當出現這些問題，就會有人說：需求的前期調研不足。其實，客戶需求不是僅僅通過調研能夠了解的。單憑幾百個樣本并不能夠完全抽取出客戶的核心需求。了解客戶需求不能單依靠市場調研這一種方式，而是需要隨時隨地的關注客戶需求，行業變化會產生客戶需求，日常的銷售反饋就是客戶需求，客戶的抱怨也是需求，售后服務人員的電話記錄單中也有客戶需求，研發人員的創新也是客戶需求。其實，無論是在市場之內還是市場之外，客戶都在不斷地表達著他們的需求。因此，只有企業整體時刻保持對客戶的關注，才能真正做到了解客戶需求。 不提產品只問問題 有一個經典的商業案例：一個中等規模的公司從通用電氣購買了價值50萬美元的個人電腦。通用電氣并不制造電腦。這家公司為什么不直接從制造商那里購買電腦呢？答案是：制造商只賣電腦，而這種產品很多廠家都能生產。相反，通用電氣不僅向這家公司出售電腦，還提供自選配置、附件、服務和融資。這家公司與客戶的聯系是電子化的，公司需要電腦來支持對客戶的服務，而融資提供了資金的來源，使企業能夠更好地匹配收入和支出，進行一項為期三年的技術改造。通用電氣看到了這一系列需求，滿足了他們的需要，為他們提供了一個解決方案。 可能很多人說，通用電氣有實力做到這些。但請注意，這里重要的是他了解到了客戶需求，才可能去實現。通常情況下，客戶并不十分清楚或不能清晰地表述自己的問題或需求，因此，在沒有完整、清楚地把握客戶的需求之前，即使將全球最好的產品和服務推薦給客戶也無濟于事。誰能幫助客戶真正解決問題，向客戶提供的是獲利的行動，誰才能贏得客戶。與客戶“換位思考” 站在客戶的立場去了解需求，要能夠分配更多的時間去關注客戶，更要能與客戶做“換位思考”。回想一下在上個月中花了多少時間與你的5位最重要的客戶在一起？與他們的交談僅僅是禮貌的寒暄，還是關于客戶最重要需求的實質性討論？ 假設你是你的5個最重要客戶中某一家的首席執行官，試著問自己幾個問題： ――你的總體目標是什么？ ――什么是你最關心的事情？ ――為了幫助你達到自己的目標，供應商應該怎么做？ ――目前的供應商是否符合你的希望？ ――他們為何未能符合你的希望？ 作為企業來說，早就應該結束想當然制造客戶需求的階段了，只有企業整體重視起來，從實際出發，以客戶為本，才能真正達到對客戶需求的了解。任印泉
錨點Q2： 如何系統的進行用戶需求分析
1.概念
需求的定義包括從用戶角度(系統的外部行為),以及從開發者角度(一些內部特性)來闡述需求.
關鍵的問題是一定要編寫需求文檔.我曾經目睹過一個項目中途更換了所有的開發者,客戶被迫與新的需求分析者坐到一起.系統的分析人員說:"我們想與你談談你的需求."客戶的第一反應便是:"我已經將我的要求都告訴你們前任了,現在我要的就是給我編一個系統".
百事通
而實際上,UGGs,需求并未編寫成文檔,因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話,你就確信你已明白用戶的需求,那完全是自欺欺人.
需求的另外一種定義認為需求是"用戶所需要的并能觸發一個程序或系統開發工作的說明".有些需求分析專家拓展了這個概念:"從系統外部能發現系統所具有的滿足于用戶的特點、功能及屬性等".這些定義強調的是產品是什么樣的,而并非產品是怎樣設計、構造的.而下面的定義則從用戶需要進一步轉移到了系統特性:
需求是指明必須實現什么的規格說明.它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束.
從上面這些不同形式的定義不難發現:并沒有一個清晰、毫無二義性的"需求"術語存在,真正的"需求"實際上在人們的腦海中,這個人們主要是指客戶,但一般情況下,用戶并不能描述自己的需要,只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對.系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識.
任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型,一種描述.
2.需求分析的任務
開發軟件系統最為困難的部分就是準確說明開發什么.最為困難的概念性工作便是編寫出詳細技術需求,這包括所有面向用戶、面向機器和其它軟件系統的接口.同時這也是一旦做錯,將最終會給系統帶來極大損害的部分,并且以后再對它進行修改也極為困難.
目前,國內產品的龐雜,一家企業可能有幾個系統并立運行,它們之間接口是系統開發人員最頭痛的問題.
對于商業最終用戶應用程序,企業信息系統和軟件作為一個大系統的一部分的產品是顯而易見的.但是對于我們開發人員來說,并沒有編寫出客戶認可的需求文檔,我們如何知道項目于何時結束?而如果我們不知道什么對客戶來說是重要的,那我們又如何能使客戶感到滿意呢?
然而,即便并非出于商業目的的軟件需求也是必須的.例如庫、組件和工具這些供開發小組內部使用的軟件.當然你可能偶爾勿需文檔說明就能與其他人意見較為一致,但更常見的是出現重復返工這種不可避免的后果,而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價,這些血的教訓正在國內的軟件開發者身上發生.
近來,我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟件.不幸的是,當他們開發完這個工具后,發現這個工具不能打印出源代碼文件,使用者當然希望有這個功能.結果這個小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤并構思準確,如果我們沒有編寫文檔,軟件達不到期望目標也只能是咎由自取了.
相反的情況,我曾見一個要集成到"錯誤跟蹤系統"中的簡單界面寫了一頁需求說明.而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用.他們依據需求對系統進行測試時,此系統不僅非常清晰地實現了所有必需功能,而且未發現任何錯誤.
事實上,需求文檔在開發過程中一直起指導作用.
3.需求分析過程
可把整個軟件需求工程研究領域劃分為需求開發和需求管理兩部分更合適,如圖4-1所示:
圖4-1 需求工程域的層次分解示意圖
需求開發可進一步分為:問題獲取、分析、編寫規格說明和驗證四個階段.這些子項包括軟件類產品中需求收集、評價、編寫文檔等所有活動.需求開發活動包括以下幾個方面:
確定產品所期望的用戶類別.
獲取每個用戶類的需求.
了解實際用戶任務和目標以及這些任務所支持的業務需求.
分析源于用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息.
將系統級的需求分為幾個子系統,并將需求中的一部份分配給軟件組件.
了解相關質量屬性的重要性.
商討實施優先級的劃分.
將所收集的用戶需求編寫成文檔和模型.
評審需求規格說明,確保對用戶需求達到共同的理解與認識,并在整個開發小組接受說明之前將問題都弄清楚.
需求管理需要"建立并維護在軟件工程中同客戶達成的合同" .這種合同都包含在編寫的需求文檔與模型中.客戶的接受僅是需求成功的一半,開發人員也必須能夠接受他們,并真正把需求應用到產品中.通常的需求管理活動包括:
定義需求基線(迅速制定需求文檔的主體).
評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它.
以一種可控制的方式將需求變更融入到項目中.
使當前的項目計劃與需求一致.
估計變更需求所產生影響并在此基礎上協商新的承諾,這種承諾具體體現在項目解決方案上.
讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤.
在整個項目過程中跟蹤需求狀態及其變更情況.
以上幾點說明是我總結了成功實施項目后系統分析人員的經驗,同時也根據國內外的其他系統實施的相關成功經驗,進行了總結.
4.需求的類型
下面這些定義是需求工程領域中常見術語的定義.
軟件需求包括三個不同的層次:業務需求、用戶需求和功能需求(也包括非功能需求).
1.業務需求(business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求,它們在項目視圖與范圍文檔中予以說明.
2.用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務,這在使用實例(use case)文檔或方案腳本說明中予以說明.
3.功能需求(functional requirement)定義了開發人員必須實現的軟件功能,使得用戶能完成他們的任務,從而滿足了業務需求.
在軟件需求規格說明書 (SRS)中說明的功能需求充分描述了軟件系統所應具有的外部行為.軟件需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用.對一個大型系統來說,軟件功能需求也許只是系統需求的一個子集,因為另外一些可能屬于子系統(或軟件部件).
作為功能需求的補充,軟件需求規格說明還應包括非功能需求,它描述了系統展現給用戶的行為和執行的操作等.它包括產品必須遵從的標準、規范和合約;外部界面的具體細節;性能要求;設計或實現的約束條件及質量屬性.所謂約束是指對開發人員在軟件產品設計和構造上的限制.質量屬性是通過多種角度對產品的特點進行描述,從而反映產品功能.多角度描述產品對用戶和開發人員都極為重要.
下面以一個字處理程序為例來說明需求的不同種類.業務需求可能是:"用戶能有效地糾正文檔中的拼寫錯誤",該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器.而對應的用戶需求可能是"找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞".同時,該拼寫檢查器還有許多功能需求,如找到并高亮度提示錯詞的操作;顯示提供替換詞的對話框以及實現整個文檔范圍的替換.
從以上定義可以發現,需求并未包括設計細節、實現細節、項目計劃信息或測試信息.需求與這些沒有關系,它關注的是充分說明你究竟想開發什么.項目也有其它方面的需求,如開發環境需求或發布產品及移植到支撐環境的需求.盡管這些需求對項目成功也至關重要,但它們并非本書所要討論的.
5.需求分析的原則
不重視需求過程的項目隊伍將自食其果.需求工程中的缺陷將給項目成功帶來極大風險,這里的"成功"是指推出的產品能以合理的價格、及時地在功能、質量上完全滿足用戶的期望.下面將討論一些需求風險.
不適當的需求過程所引起的一些風險:
1. 無足夠用戶參與
客戶經常不明白為什么收集需求和確保需求質量需花費那么多功夫,開發人員可能也不重視用戶的參與.究其原因:一是因為開發人員感覺與用戶合作不如編寫代碼有意思;二是因為開發人員覺得已經明白用戶的需求了.在某些情況下,與實際使用產品的用戶直接接觸很困難,而客戶也不太明白自己的真正需求.但還是應讓具有代表性的用戶在項目早期直接參與到開發隊伍中,并一同經歷整個開發過程.
系統人員在實踐過程中,也有些感覺,在實施一家公司的項目時,若無足夠的用戶參與,系統人員獲得的需求是片面的,不完整的,這樣系統在需求之初就埋下風險.
2. 用戶需求的不斷增加
在開發中若不斷地補充需求,項目就越變越龐大以致超過其計劃及預算范圍.計劃并不總是與項目需求規模與復雜性、風險、開發生產率及需求變更實際情況相一致,這使得問題更難解決.實際上,問題根源在于用戶需求的改變和開發者對新需求所作的修改.
要想把需求變更范圍控制到最小,必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明,并將此說明作為評價需求變更和新特性的參照框架.說明中包括了對每種變更進行變更影響因素分析的變更控制過程,有助于所有風險承擔者明白業務決策的合理性,即為何進行某些變更,相應消耗的時間、資源或特性上的折中.
產品開發中不斷延續的變更會使其整體結構日漸紊亂,補丁代碼也使得整個程序難以理解和維護.插入補丁代碼使模塊違背強內聚、松耦合的設計原則,特別是如果項目配置管理工作不完善的話,收回變更和刪除特性會帶來問題.如果你盡早地區別這些可能帶來變更的特性,你就能開發一個更為健壯的結構,并能更好地適應它.這樣設計階段需求變更不會直接導致補丁代碼,同時也有利于減少因變更導致質量的下降.
3. 模棱兩可的需求
模棱兩可是需求規格說明中最為可怕的問題.它的一層含義是指諸多讀者對需求說明產生了不同的理解;另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明.
模棱兩可的需求會使不同的風險承擔者產生不同的期望,它會使開發人員為錯誤問題而浪費時間,并且使測試者與開發者所期望的不一致.一位系統測試人員曾告訴我,她所在的測試組經常對需求理解有誤,以致不得不重寫許多測試用例并重做許多測試.
處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍.僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的.如果不同的評審者從不同的角度對需求說明給予解釋,但每個評審人員都真正了解需求文檔,這樣二義性就不會直到項目后期才被發現,那時再發現的話會使得更正代價很大.
4. 不必要的特性
"畫蛇添足"是指開發人員力圖增加一些"用戶欣賞"但需求規格說明中并未涉及的新功能.經常發生的情況是用戶并不認為這些功能性很有用,以致在其上耗費的努力"白搭"了.開發人員應當為客戶構思方案并為他們提供一些具有創新意識的思路,具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡,開發人員應努力使功能簡單易用,而不要未經客戶同意,擅自脫離客戶要求,自作主張.
同樣,客戶有時也可能要求一些看上去很"酷",但缺乏實用價值的功能,而實現這些功能只能徒耗時間和成本.為了將"畫蛇添足"的危害盡量減小,應確信:你明白為什么要包括這些功能,以及這些功能的"來龍去脈",這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能.
5. 過于精簡的規格說明
有時,客戶并不明白需求分析有如此重要,于是只作一份簡略之至的規格說明,僅涉及了產品概念上的內容,然后讓開發人員在項目進展中去完善,結果很可能出現的是開發人員先建立產品的結構之后再完成需求說明.這種方法可能適合于尖端研究性的產品或需求本身就十分靈活的情況.但在大多數情況下,這會給開發人員帶來挫折(使他們在不正確的假設前提和極其有限的指導下工作),也會給客戶帶來煩惱(他們無法得到他們所設想的產品).
6. 忽略了用戶分類
大多數產品是由不同的人使用其不同的特性,使用頻繁程度也有所差異,使用者受教育程度和經驗水平也不盡相同.如果你不能在項目早期就針對所有這些主要用戶進行分類的話,必然導致有的用戶對產品感到失望.例如,菜單驅動操作對高級用戶太低效了,但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難.
7. 不準確的計劃
據統計,導致需求過程中軟件成本估計極不準確的原因主要有以下五點:頻繁的需求變更、遺漏的需求、與用戶交流不夠、質量低下的需求規格說明和不完善的需求分析.
對不準確的要求所提問題的正確響應是"等我真正明白你的需求時,我就會來告訴你".基于不充分信息和未經深思的對需求不成熟的估計很容易為一些因素左右.要作出估計時,最好還是給出一個范圍.未經準備的估計通常是作為一種猜測給出的,聽者卻認為是一種承諾.因此我們要盡力給出可達到的目標并堅持完成它.
6.需求分析人員和用戶的合作關系
優秀的軟件產品是建立在優秀的需求基礎之上的.而高質量的需求來源于客戶與開發人員之間有效的交流與合作.通常,開發人員與客戶或客戶代理人,如市場人員間的關系反而會成為一種對立關系.雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產生摩擦,在這種情況下,不會給雙方帶來一點益處.
只有當雙方參與者都明白要成功自己需要什么,同時也應知道要成功合作方需要什么時,才能建立起一種合作關系.由于項目壓力與日漸增,所有風險承擔者有著一個共同的目標這一點容易被遺忘.其實大家都想開發出一個既能實現商業價值,又能滿足用戶需要,還能使開發者感到滿足的優秀軟件產品.
軟件客戶需求權利書列出了十條關于客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求.每一項權利都對應著軟件開發人員、分析人員的義務.而軟件客戶需求義務書也列出了十條關于客戶在需求過程中應承擔的義務.如果愿意,可以將其作為開發人員的權利書.
客戶有如下權利:
1:要求分析人員使用符合客戶語言習慣的表達
需求討論應集中于業務需要和任務,故要使用業務術語,你應將其教給分析人員,而你 不一定要懂得計算機的行業術語.
2:要求分析人員了解客戶的業務及目標
通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業務任務和怎樣才能使產品更好地滿足你的需要.這將有助于開發人員設計出真正滿足你的需要并達到你期望的優秀軟件.為幫助開發人員和分析人員,可以考慮邀請他們觀察你或你的同事是怎樣工作的.如果新開發系統是用來替代已有的系統,那么開發人員應使用一下目前的系統,這將有利于他們明白目前系統是怎樣工作的,其工作流程的情況,以及可供改進之處.
3:要求分析人員編寫軟件需求規格說明
分析人員要把從你和其他客戶那里獲得的所有信息進行整理,以區分開業務需求及規范、功能需求、質量目標、解決方法和其它信息.通過這些分析就能得到一份軟件需求規格說明.而這份軟件需求規格說明便在開發人員和客戶之間針對要開發的產品內容達成了協議.軟件需求規格說明書可以用一種你認為易于翻閱和理解的方式組織編寫.要評審編寫出的規格說明以確保它們準確而完整地表達了你的需求.一份高質量的軟件需求規格說明能有助于開發人員開發出真正需要的產品.
4:要求得到需求工作結果的解釋說明
分析人員可能采用了多種圖表作為文字性軟件需求規格說明的補充.因為如工作流程圖那樣的圖表能很清楚地描述出系統行為的某些方面.所以需求說明中的各種圖表有著極高的價值.雖然它們不太難于理解,但是你很可能對此并不熟悉.因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發工作結果和符號的意義,及怎樣檢查圖表有無錯誤及不一致等.
5:要求開發人員尊重你的意見
如果用戶與開發人員之間不能相互理解,那關于需求的討論將會有障礙,共同合作能使大家"兼聽則明".參與需求開發過程的客戶有權要求開發人員尊重他們并珍惜他們為項目成功所付出的時間.同樣,客戶也應對開發人員為項目成功這一共同目標所作出的努力表示尊重與感激.
6:要求開發人員對需求及產品實施提供建議,拿出主意
通常,客戶所說的"需求"已是一種實際可能的實施解決方案,分析人員將盡力從這些解決方法中了解真正的業務及其需求,同時還應找出已有系統不適合當前業務之處,以確保產品不會無效或低效.在徹底弄清業務領域內的事情后,分析人員有時就能提出相當好的改進方法.有經驗且富有創造力的分析人員還能提出增加一些用戶并未發現的很有價值的系統特性.
7:描述產品易使用的特性
你可以要求分析人員在實現功能需求的同時還要注重軟件的易用性.因為這些易用特性或質量屬性能使你更準確、高效地完成任務.例如,客戶有時要求產品要"用戶友好"或"健壯"或"高效率",但這對于開發人員來說,太主觀了并無實用價值.正確的應是:分析人員通過詢問和調查了解客戶所要的友好、健壯、高效所包含的具體特性.
8:調整需求,允許重用已有的軟件組件
需求通常要有一定的靈活性.分析人員可能發現已有的某個軟件組件與你描述的需求很相符.在這種情況下,分析人員應提供一些修改需求的選擇以便開發人員能夠在新系統開發中重用一些已有的軟件.如果有可重用的機會出現,同時你又能調整你的需求說明,那就能降低成本和節省時間,而不必嚴格按原有的需求說明開發.所以說,如果想在產品中使用一些已有的商業常用組件,而它們并不完全適合你所需的特性,這時一定程度上的需求靈活性就顯得極為重要了.
9:獲得滿足客戶功能和質量要求的系統
每個人都希望項目獲得成功.但這不僅要求你要清晰地告知開發人員關于系統"做什么"所需的所有信息,而且還要求開發人員能通過交流了解清楚取舍與限制.一定要明確說明你的假設和潛在的期望.否則,開發人員開發出的產品很可能無法讓你滿意.
客戶有下列義務:
1:給分析人員講解你的業務
分析人員要依靠你給他們講解的業務概念及術語.但你不能指望分析人員會成為該領域的專家,而只能讓他們真正明白你的問題和目標.不要期望分析人員能把握你們業務的細微與潛在之處,他們很可能并不知道那些對于你和你的同事來說理所當然的"常識".
2:抽出時間清楚地說明并完善需求
客戶很忙,經常在最忙的時候還得參與需求開發.但無論如何,你有義務抽出時間參與"頭腦風暴"會議的討論,接受采訪或其它獲取需求的活動.有時分析人員可能先以為明白了你的觀點,而過后發現還需要你的講解.這時,請耐心一些對待需求和需求的精化工作過程中的反復,因為它是人們交流中的很自然的現象,何況這對軟件產品的成功極為重要.
3:準確而詳細地說明需求
編寫一份清晰、準確的需求文檔是很困難的.由于處理細節問題不但煩人而且又耗時,故很容易留下模糊不清的需求.但是,在開發過程中,必須得解決這種模糊性和不準確性.而你恰是為解決這些問題作出決定的*人選.不然的話,你就只好靠開發人員去正確猜測了.在需求規格說明中暫時加上待定(to be determined, TBD也可采用漢語拼音略寫"DQD:待確定")的標志是個不錯的辦法.用該標志可指明了哪些需要進一步探討、分析或增加信息的地方.不過,有時也可能因為某個特殊需求難以解決或沒有人愿意處理它而注上TBD標志.盡量將每項需求的內容都闡述清楚,以便分析人員能準確的將其寫進軟件需求規格說明中.如果你一時不能準確表述,那就得允許獲取必要的準確信息這樣一個過程.通常使用所謂的原型技術.通過開發的原型,你可以同開發人員一起反復修改,不斷完善需求定義.
4:及時地作出決定
正如一位建筑師為你修建房屋,分析人員將要求你做出一些選擇和決定.這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息準確度中選擇折衷方案等.有權做出決定的客戶必須積極地對待這一切,盡快做處理、做決定.因為開發人員通常只有等你做出了決定才能行動,而這種等待會延誤項目的進展.
5:尊重開發人員的需求可行性及成本評估
所有的軟件功能都有其成本價格,開發人員最適合預算這些成本(盡管許多開發人員并不擅長評估預測).你所希望的某些產品特性可能在技術上行不通,或者實現它要付出極為高昂的代價.而某些需求試圖在操作環境中要求不可能達到的性能或試圖得到一些根本得不到的數據,開發人員會對此作出負面的評價意見,你應該尊重他們的意見.有時,你可以重新給出一個在技術上可行、實現上便宜的需求,例如,要求某個行為在"瞬間"發生是不可行的,但換種更具體的時間需求說法("在50ms以內",但若沒有準確的技術分析不能輕易下結論),這就可以實現了.
6: 劃分需求優先級別
大多數項目沒有足夠的時間或資源來實現功能性的每個細節.決定哪些特性是必要的,哪些是重要的,哪些是好的,是需求開發的主要部分.只能由你來負責設定需求優先級,因為開發者并不可能按你的觀點決定需求優先級.開發者將為你確定優先級提供有關每個需求的花費和風險的信息.當你設定優先級時,你幫助開發者確保在適當的時間內用最小的開支取得最好的效果.在時間和資源限制下,關于所需特性能否完成或完成多少應該尊重開發人員的意見.盡管沒有人愿意看到自己所希望的需求在項目中未被實現,但畢竟是要面對這種現實的.業務決策有時不得不依據優先級來縮小項目范圍或延長工期,或增加資源,或在質量上尋找折衷.
7:評審需求文檔和原型
正如我們將在第1 4章討論的,無論是正式的還是非正式的方式,對需求文檔進行評審都會對軟件質量提高有所幫助.讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性.評審也給客戶代表提供一個機會,給需求分析人員帶來反饋信息以改進他們的工作.如果你認為編寫的需求文檔不夠準確,就有義務盡早告訴分析人員并為改進提供建議.通過閱讀需求規格說明,很難想象實際的軟件是什么樣子的.更好的方法是先為產品開發一個原型.這樣你就能提供更有價值的反饋信息給開發人員,幫助他們更好地理解你的需求.必須認識到:原型并非是一個實際產品,但開發人員能將其轉變、擴充成功能齊全的系統.
8:需求出現變更要馬上聯系
不斷的需求變更會給在預定計劃內完成高質量產品帶來嚴重的負面影響.變更是不可避免的,但在開發周期中變更越在晚期出現,其影響越大.變更不僅會導致代價極高的返工,而且工期也會被迫延誤,特別是在大體結構已完成后又需要增加新特性時.所以一旦你發現需要變更需求時,請一定立即通知分析人員.
9:應遵照開發組織處理需求變更的過程
為了將變更帶來的負面影響減少到*限度,所有的參與者必須遵照項目的變更控制過程.這要求不放棄所有提出的變更,對每項要求的變更進行分析、綜合考慮,最后作出合適的決策以確定將某些變更引入項目中.
10:尊重開發人員采用的需求工程過程
軟件開發中*挑戰性的莫過于收集需求并確定其正確性.分析人員采用的方法有其合理性.也許你認為需求過程不太劃算,但請相信花在需求開發上的時間是"很有價值"的.如果你理解并支持分析人員為收集、編寫需求文檔和確保其質量所采用的技術,那么整個過程將會更為順利.盡管去詢問分析人員為什么他們要收集某些信息,或參與與需求有關的活動.
系統分析人員在開發過程中可能會遇到以下問題,一些很忙的客戶可能不愿意積極參與需求過程,而缺少客戶參與將很可能導致不理想的產品.故一定要確保需求開發中的主要參與者都了解并接受他們的義務.如果遇到分歧,通過協商以達成對各自義務的相互理解,這樣能減少今后的摩擦.
7.需求文檔
需求開發的最終成果是:客戶和開發小組對將要開發的產品達成一致協議.協議綜合了業務需求、用戶需求和軟件功能需求.就像我們早先所看到的,項目視圖和范圍文檔包含了業務需求,而使用實例文檔則包含了用戶需求.你必須編寫從使用實例派生出的功能需求文檔,還要編寫產品的非功能需求文檔,包括質量屬性和外部接口需求.只有以結構化和可讀性方式編寫這些文檔,并由項目的風險承擔者評審通過后,各方面人員才能確信他們所贊同的需求是可靠的.
你可以使用以下三種方法編寫軟件需求規格說明:
用好的結構化和自然語言編寫文本型文檔.
建立圖形化模型,這些模型可以描繪轉換過程、系統狀態和它們之間的變化、數據關系、邏輯流或對象類和它們的關系.
編寫形式化規格說明,這可以通過使用數學上*的形式化邏輯語言來定義需求.
由于形式化規格說明具有很強的嚴密性和*度,因此,所使用的形式化語言只有極少數軟件開發人員才熟悉,更不用說客戶了.雖然結構化的自然語言具有許多缺點,但在大多數軟件工程中,它仍是編寫需求文檔最現實的方法.包含了功能和非功能需求的基于文本的軟件需求規格說明已經為大多數項目所接受.圖形化分析模型通過提供另一種需求視圖,增強了軟件需求規格說明.
如果解決了您的問題請采納！
如果未解決請繼續追問：
錨點Q3： 如何抓住人性，如何分析客戶需求
一、顧客貪利的心理：
人性的弱點每個人都有只是略有差異而已，古往今來的人概莫能免每個人都有貪利的想法。例如打折可以吸引更多顧客，讓利會讓老顧客更動心，贈品豐富會增加新顧客的數量，原價多少錢現價多少錢絕大多數的顧客都感興趣，一折起三者起的海報絕大多數人都要去看看，這就是人愛貪利的消費心理。
二、顧客好奇的心理：
其實顧客的好奇心理與從眾心理很相似，在馬路上看到圍著一堆人就忍不住過去看看，好奇是人之本性。對自己不了解的事物總是想了解但是又怕冒風險，這就是人的本能想法。因為人天生具備好奇心理才應運而生“商不厭奇”說法，所以商家的促銷活動也設計的離棄古怪越來越新奇，激發人們的好奇心理增加客源數量，促銷活動形式花樣百出曾出不窮。
三、顧客的恐懼(擔心)心理：
一個裝修非常豪華富麗堂皇的店鋪，即使店鋪的商品價格并不昂貴，工薪階層的顧客還是有顧慮不敢去光顧，這就是恐懼心理。恐懼心理來自信息的不對稱，因為商家是信息優勢一方顧客是弱勢的一方，顧客害怕被宰害怕傷自尊沒面子，顧客的恐懼心理擔心價格昂貴買不起，商品價格太貴自己財力不能承受，擔心產品質量有問題售后服務問題等等，擔心被營業員纏住不放被強行推薦購物，擔心服務質量擔心有問題解決不了等等。
四、顧客的逆反心理：
強買強賣的生意是沒有辦法成功的，很多店鋪的營業員抓住顧客就喋喋不休的推薦，不考慮顧客的感受根本不在意顧客的感覺，只有一個想法把產品推出去讓顧客把錢掏出來，這樣的方式顧客不喜歡推薦也不會成功。
對于顧客要不失熱情又不讓顧客感覺到壓力，留有一定的空間又不能讓顧客感覺到受冷落，顧客是非常奇怪的你不理她顧客很不高興，你離顧客太近產生壓力她也不高興說你老盯著她的錢包。對于顧客的逆反心理要把握非常好的尺度，既不冷也不熱不遠也不近的方式真誠服務，讓顧客覺得你就在她身邊真誠服務就可以了。
五、顧客的從眾心理：
賣東西有個奇怪的現象，如果沒有人買就誰也不買生意無人問津，如果看到一個購買大家都跟著效仿這就是從眾心理。
當我們面對客戶的挑剔，首先不是防衛、排斥和拒絕，而是虛心傾聽，冷靜客觀地研究分析客戶挑剔的觀點。研究分析時，還要站在客戶的立場，就客觀的事實和主觀的感覺和情緒，去了解客戶為何挑剔。在面對最挑剔客戶時，尤須如此。
WwwJIZhUba.coM
錨點Q4： 如何做需求分析
隨著技術的不斷發展和用戶對網站功能性的需求不斷提高，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟件工程，也越來越復雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規范的、有效的、健壯的開發機制，才能適應用戶不斷變化的需要，達到預期的計劃目標。
網站項目管理（WPM）的含義為Web-based Project Management，即以Web 應用程序為主要表現方式的架構來進行的項目設計及管理，這樣的架構中包含了瀏覽器、網絡和Web
服務器等關鍵主體，主要體現在網站設計、以瀏覽器為客戶端的Web應用程序開發（例如信息類網站、網上商店、虛擬郵局、客戶關系管理。）等項目管理中。
按照筆者的經驗，網站項目管理可以分為以下l六個階段進行控制：
1. 需求分析及變更管理
2. 項目模型及業務流程分析
3. 系統分析及軟件建模
4. 界面設計、交互設計及程序開發
5. 系統測試和文檔編寫
6. 客戶培訓、技術支持和售后服務
需要說明的是，這些階段雖然具有一定的延續性，但是并非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。
（一）如何做好需求分析及變更管理？
業務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。
一：讓客戶暢所欲言，羅列出所有的需求
讓用戶將所有的想法盡可能的闡述清楚，并把所有的要求羅列出來，不要遺漏。這時候不應該害怕“勾引”起客戶的潛在需求而增加設計開發的工作量，從而被今后客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求準確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時可能會產生意想之外的變更，甚至這個變更會破壞已經做的模型及結構，那么這個項目從開始就注定了會失敗；比如站點所有的功能都實現了，本地測試起來也沒有什么問題了，但是你卻不知道客戶的系統是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經驗的開發人員都會明白這樣的設計是個災難，無論是應用服務器、數據庫還是程序全部要重新開發！
二：透過現象分析潛在的需求
很多情況下客戶并非專業人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術難關，這需要我們去為客戶進行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現難度和強度很高的地方特別值得注意。
客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統而且尺度難以控制的，這就要求業務人員在傾聽了客戶的詳細說明以后，幫助客戶進行整理和分析，同時預測客戶在開發過程中變更及今后應用中可能進行修改升級的潛在需求。
比如在為客戶設計辦公自動化系統的時候，也許就要為客戶預留將來與他們的業務單位進行交互的通道；在設計郵件系統的時候要考慮可能會需要廣告管理服務器；設計網絡電子商店時今后增加庫存產品進銷存統計分析等等；限于時間財力的考慮，客戶通常能夠接受分階段實施的開發過程，在需求分析時，提早為客戶設想到今后的需求變更除了使項目開發更加順利以外，也為今后業務的進一步深入打下了更好的基礎。
筆者曾負責一(yi)個(ge)大型新聞(wen)網(wang)站(zhan)的(de)(de)設計，當客戶(hu)拿著(zhu)將近(jin)五十頁(ye)厚(hou)的(de)(de)一(yi)本設計要求報告時，我(wo)發(fa)現有四十頁(ye)的(de)(de)內(nei)容對程序開(kai)發(fa)來說(shuo)都是(shi)(shi)重復的(de)(de)，而(er)在其中(zhong)一(yi)頁(ye)的(de)(de)角落(luo)卻畫(hua)了個(ge)“搜索(suo)(suo)其他(ta)網(wang)站(zhan)相關(guan)新聞(wen)”的(de)(de)按鈕，并(bing)且沒有做(zuo)任何(he)說(shuo)明，僅(jin)僅(jin)這10個(ge)字所完成的(de)(de)工作量完全頂(ding)的(de)(de)上(shang)其他(ta)整(zheng)整(zheng)四十頁(ye)重復贅述所做(zuo)的(de)(de)工作，客戶(hu)完全不知(zhi)道這個(ge)要求引(yin)(yin)發(fa)的(de)(de)問題(ti)實(shi)際就是(shi)(shi)一(yi)個(ge)搜索(suo)(suo)引(yin)(yin)擎的(de)(de)開(kai)發(fa)，通(tong)過協商，客人同意了修改成站(zhan)內(nei)搜索(suo)(suo)的(de)(de)引(yin)(yin)擎。
轉載：//citymember.cn/zixun_detail/109112.html
