我相信做產(chǎn)品的人都知道以下兩個故事：

故事一：

某富翁想要娶老婆,有三個人選,富翁給了三個女孩各一千元，請她們把房間裝滿。

第一個女孩買了很多棉花，裝滿房間。

第二個女孩買了很多氣球，裝滿房間。

第三個女孩買了蠟燭，讓光線充滿房間。

最終，富翁選了胸部最大的那個。

故事二：

福特：你想要什么？

用戶：我想要一匹更快的馬

福特：為什么你要一匹更快的馬？

用戶：因為我想速度更快一些，好節(jié)省時間

福特：我造了個東西，叫汽車，比馬快多了

我們經(jīng)常會用這兩個故事來闡述關于抓住用戶需求的重要性。而關于需求的前世今生，關于用戶是否會用一些冠冕堂皇的理由來達到自己的目的，我想用一篇文章盡量把需求說得透徹以好檢驗自己幾年來對于需求的理解。我將以需求現(xiàn)狀與原因、來源及獲取方法、獲取之后如何分析、如何驗證的邏輯線進行梳理。

前方干貨預警，如果你是銷售人員、產(chǎn)品經(jīng)理，需求分析師，或者是你想往這幾方面發(fā)展的人建議收藏，因為文章較長，可能需要10-15分鐘。

1、關于需求實現(xiàn)的現(xiàn)狀以及原因

現(xiàn)實工作中，有各種的原因?qū)е滦枨鬅o法實踐，比如銷售人員提出了許多的需求最后都不了了之。有各種原因?qū)е翽M與程序猿開啟撕逼大戰(zhàn)，比如前幾天網(wǎng)上看到的PM與程序猿的撕逼上升到辱罵、人身攻擊的地步。

那阻礙需求的實現(xiàn)的絕大部分原因是什么？我歸結(jié)為兩方面：

一個是需求本身的問題

一個是溝通的問題

需求本身的問題

1、需求的不完整

比如PM跟UI說：這個圖標不夠顯眼，重新設計一下。 比如銷售跟PM說：有客戶反映我們的產(chǎn)品不好用，后面的產(chǎn)品你改進一下。很多這樣不完整的需求，我們不知道對方真正要表達的意思是什么，所以經(jīng)常導致需求不了了之。那么問題來了，什么樣的需求才是完整的需求？其實這個很難去界定，因為只有用戶自己才是驗證需求完整性的最合適的人。確保溝通需求時雙方對于需求的認知無歧義并在實現(xiàn)過程中無其他因素變更的需求是完整的需求。相關人員在提需求的時候盡量從各個層面來考慮，從大的框架、業(yè)務流程、實現(xiàn)目的等方面來講需求描述清楚。比如圖標的配色與整個的風格不符或者這個地方的重點是突出圖標，需要將其他地方的設計淡化，將圖標的飽和度提高。比如客戶反映在執(zhí)行某項任務時發(fā)現(xiàn)我們產(chǎn)品的這個功能隱藏太深無法找到等（舉例不一定對）。

2、不切實際的需求

我們經(jīng)常會聽到，這個產(chǎn)品要是有某某功能那就牛逼了這樣的談資。“我要天上的月亮”這樣的大部分需求都是不切實際的需求，至于如何定義不切實際的需求？不切實際的需求不僅僅是指那些不能實現(xiàn)的需求，也指那些小眾或者沒有應用場景的需求。。

3、缺乏站在用戶角度思考的需求

比如做婚紗攝影行業(yè)的O2O。當然導致這種行業(yè)失敗的原因有多種，低頻、用戶的獲取、轉(zhuǎn)化等等。但歸根結(jié)底還是自己YY出了一大堆的需求，而這種需求脫離了用戶。需求的真?zhèn)挝覀兎旁诤竺鎭碚f。

4、需求的頻繁變更

需求的頻繁變更導致在處理的過程中忘記初心，最后需求的實現(xiàn)就變成了另一個話題。

溝通的問題

1、溝通的變質(zhì)

相信大家有聽說過西點軍校的一個故事：

這個故事就反映出了在溝通中需求變質(zhì)的問題，這里我不再贅述。

2、項目經(jīng)理或執(zhí)行人員的控制

由于需求在實現(xiàn)的過程中會涉及到整個項目的時間進度、成本預算、或者優(yōu)先級等問題。項目經(jīng)理或者執(zhí)行人員會在這一過程將需求進行控制，比如擔心拖延整個進度選擇將需求的主要部分實現(xiàn)或者將需求放在下一個版本實現(xiàn)等狀況也是阻礙需求的實現(xiàn)原因之一。

3、程序猿的斷章取義

程序猿在實現(xiàn)的過程中將需求進行技術加工，將原本的需求斷章取義做成另外一種的結(jié)果。大家應該有聽過肥皂盒的故事：為了區(qū)分空的肥皂盒與裝了肥皂的肥皂盒，一群博士生在討論做一個這樣的機器需要怎么來實現(xiàn)，而實際上只需要一臺風扇即可。

以上說的涵蓋了造成需求不能實現(xiàn)的大部分原因。當然這些都是表象，據(jù)其本質(zhì)原因離不開利益沖突、工作量的增加，而這是另一個層面的問題了。

二、需求的獲取及方法

西游記中的唐僧說得較多的一句話：我從東土大唐而來，前往西天拜佛求經(jīng)。這句話涵蓋了我從哪里來，要到哪里去以及做什么。同樣需求從哪里來？

內(nèi)部來源

1、領導以及同事，或者自身挖掘

一般一個公司只從事一個行業(yè)（如果多個行業(yè)，那就將同事局限在同行業(yè)），同事基本上是行業(yè)中的精英，他們能夠?qū)Ξa(chǎn)品提出一些獨到的見解和思考，從他們那里去探尋會得到一些意想不到的反饋。

2、自身挖掘

可以關注行業(yè)的一些動態(tài)、數(shù)據(jù)等報告，常見的幾個統(tǒng)計報告網(wǎng)站：企鵝智庫、易觀智庫、艾瑞咨詢。也可以通過自己分析競品來挖掘。

外部來源：用戶或者客戶、合作伙伴。我們可以通過接觸到最終的用戶來了解他們的需求。用戶通常會用語言、動作、表情來反饋他們的真實意圖。但基本上用戶能說出來的需求只是基本的需求，更深層次的需求需要我們?nèi)ネ诰颉?/p>

了解了來源，如何獲?。?/p>

內(nèi)部來源的獲取方法：

對于領導跟同事，需要有針對性的問題提問或者頭腦風暴。這個跟用戶訪談有點類似。

對于一些行業(yè)上的數(shù)據(jù)我們可以在大方向上引用數(shù)據(jù)。對于競品分析出的需求，可以借鑒參考。

外部來源的獲取方法：

用戶訪談。用戶訪談是現(xiàn)在的一些公司比較常用的手段，因為這種方法比較有效并且靈活，能夠根據(jù)現(xiàn)場情況進行應變。但是占用的時間也相對較長，信息的存在也片面。這種方法的要點是注意人群的選定以及需要注意訪談的技巧，涉及到話術及心理方面的因素不在這里分析。

問卷調(diào)查。問卷調(diào)查的好處是調(diào)查面比較廣，可以涵蓋不同的用戶群，但是這種調(diào)查不能深入。這種方法的要點是需要注意問卷的設計。

現(xiàn)場觀察。有句話說百聞不如一見，但是這種方法太耗時間。要點是需要有洞察用戶行為舉止能力的人執(zhí)行。

以上都是關于需求得來源及獲取方法，整個需求獲取的過程，執(zhí)行人員應該都要去主動獲取，針對性的制定計劃。至于每一個方法的實施步驟及要點，比如在訪談的時候需要注意用戶有夸大事實的心理、有抗拒的心理等等這些需要在執(zhí)行的過程中不斷優(yōu)化和提升。（如果步驟與要點一一寫上，那可以成書啦!）

三、分析需求

當四面八方的需求匯集到一起時，這些需求的走向我們該如何處理？

篩選

這一步的作用是確定哪些需求是確定要實施的。

1、將不切實際的需求丟棄

不切實際的需求定義前面已經(jīng)提到：不切實際的需求不僅僅是指那些不能實現(xiàn)的需求，也包含那些小眾或者沒有應用場景的需求。我們也可以稱其中的一部分需求是偽需求，如果你不能通過應用場景來判斷其真?zhèn)涡裕瑳]關系，我們后面還會講到如何來驗證。

2、將與定位背離的需求丟棄

這里講的定位包含市場和產(chǎn)品的雙重定位。不是針對產(chǎn)品的目標消費市場的需求、不是產(chǎn)品的目標人群定位的需求都稱之為與定位背離的需求，我們應該將這些需求丟棄。之前我在做一個視頻流網(wǎng)關產(chǎn)品的時候犯的一個錯誤：有用戶反饋需要有輪播的功能，而我當時認為可以考慮，而實際上這個功能與產(chǎn)品的定位不符。

分級

這一步的作用是確定需求什么時間點做。

需求篩選出來之后，需要對需求進行分級。

劃分需求的優(yōu)先級有多種方法：四象限法、商業(yè)價值與用戶體驗法、風險-價值法等等。我這里就拿常用的四象限法進行分析，如下圖。

問題來了：如何界定緊急跟重要？

需求的緊急從大方向上應該要根據(jù)產(chǎn)品所處的階段來考慮。產(chǎn)品的起步階段的重點是核心功能的實現(xiàn)，驗證產(chǎn)品的可行性。產(chǎn)品的發(fā)展階段重點是功能的擴展和完善，需要做的是探索新的價值。產(chǎn)品的迭代階段重點是用戶體驗的提升。在不同的階段，需求的緊急度衡量的側(cè)重點是不一樣的。

大方向上考慮了之后，同一階段的需求又如何進一步細分排序？這里應該考慮需求在實現(xiàn)上面的時間緊急程度，通常以其影響程度來衡量。如A需求再不處理，會影響50%的用戶操作，影響程度惡劣，所以較為緊急。

需求的重要性從宏觀角度看應該是根據(jù)需求對于用戶的驚喜度來定。KANO模型中的三種需求：基本型需求、期望型需求、興奮型需求。我認為這三種需求的重要性為：基本型需求＞期望型需求＞興奮型需求。因為對于用戶基本的需求如果不滿足，這會引起用戶的不滿，這直接決定了用戶是否繼續(xù)探索你產(chǎn)品的其他功能。期望型的需求屬于錦上添花，而用戶興奮型的需求如果滿足了則會給產(chǎn)品增添不少好評與魅力。

再詳細一點，如果篩選除了一堆重要的需求（同一宏觀層級），又如何給重要性排序？這里我們可以根據(jù)需求的使用場景來決定：用戶在什么情況下會涉及到該需求。說白了就是這種需求涉及的使用場景的多還是少來決定。

跟蹤與管理

我相信大家都有各自一套管理方法，這里我也不拿出自己的管理與跟蹤表格說事了，因為我的也不一定是好的或者是對的。

這里僅說一下管理與跟蹤的要點:應該要包含需求源頭，是誰提出？在什么場景下提出的即需求的描述詳情？該需求的優(yōu)先級如何，排在什么時間點做？處理該需求會影響那些因素？后續(xù)的計劃是什么樣的？

四、驗證需求

如果前面的三步都做得比較好，那其實第四步就相對很容易了，只需要將處理好的需求（產(chǎn)品）再找相應的用戶確認就好。但就怕前面三步都沒有處理好而且也不做第四步進行驗證就將產(chǎn)品投入市場，那會導致很多的問題。就像一個生意在沒有確認是否可復制的時候就進行了盲目的擴張一樣的道理。

需求的驗證方法有很多，比如AB測試、比如定性定量分析等。具體用哪種方法，具體問題具體分析，下面我講述一下較為通用的方法。

《四步創(chuàng)業(yè)法》里告訴我們?nèi)绾蝸眚炞C一個產(chǎn)品，其實也可以把方法應用到需求的驗證上：將處理好的需求找特定的用戶，看是否解決他們的實際需求就好。這里我們不談論是軟件產(chǎn)品還是硬件產(chǎn)品，方法都一樣，只是周期長短不一樣罷了。但是問題來了：我們上面說的通過問卷得來的需求，這些都是基于當前的市場來做的，適合于成熟的行業(yè)，那非成熟的行業(yè)如何驗證？

用最快的方法做出原型，這個原型可以只包含核心的功能。

找到在這個行業(yè)的精英以及有創(chuàng)新意識的客戶試用。這里為什么要有兩種人群，因為行業(yè)的精英有可能也比較墨守成規(guī)。

收集通過使用之后反饋出來的意見再講原型改進，然后再找與產(chǎn)品定位的目標人群進行廣泛測試。

以上，包含了一個需求的整個生命周期，這個周期我花費了差不多兩年時間才對其形成一套完整的認知。如果你讀到了這里，請反思一下這篇文章是否對你有所幫助。如果有不對的地方，歡迎指出，不勝感激。

本文將介紹一種需求規(guī)劃、管理的可視化方法—用戶需求地圖，該方法將軟件開發(fā)項目的需求變成一張二維地圖，而不是傳統(tǒng)的簡單列表，只要這一張圖，就可以完成全部用戶需求的管理工作。

該方法有如下一些優(yōu)點：

讓你更容易看清軟件產(chǎn)品的全貌，了解產(chǎn)品功能的完整性

為用戶需求篩選和劃定優(yōu)先級提供可視化的工具，幫助你做出決策

更好的進行迭代增量式開發(fā)，同時確保有計劃、可控的發(fā)布產(chǎn)品

為傳統(tǒng)的項目計劃提供了一個更好的替代工具

有助于管理項目范圍，避免范圍的無限制蔓延

先上一個用戶需求地圖的樣例，后續(xù)介紹如何創(chuàng)建這樣的地圖

一、需求的獲取

常用的需求獲取方法包括以下幾種：

1、用戶訪談

用戶訪談是一種最基本的需求獲取手段，它是指分析人員以個別訪談或小組會議的形式與用戶進行初步的溝通。用戶訪談的形式包括結(jié)構(gòu)化和非結(jié)構(gòu)化兩種，結(jié)構(gòu)化是指分析人員按照一定準則事先準備好一系列問題，通過用戶對問題的回答來獲取有關目標軟件方面的內(nèi)容；非結(jié)構(gòu)化則是只列出一個粗糙的想法，根據(jù)訪談的具體情況來進行發(fā)揮。

2、用戶調(diào)查

在進行用戶訪談時，由于很多關鍵人員的時間有限，不易安排過多的時間或者項目涉及的客戶面較廣，不可能一一訪談。因此，就需要借助用戶調(diào)查的方法，通過精心設計要問的問題，然后下發(fā)到相關的人員手中，讓他們填寫，再從所填寫的內(nèi)容中獲取系統(tǒng)的需求信息，這樣就可以克服上述的問題。

用戶調(diào)查最大的不足就是缺乏靈活性，而且可能存在受調(diào)查人員不能很好表述自己想法的限制。

3、現(xiàn)場觀摩

俗話說，百聞不如一見，對于許多較為復雜的流程和系統(tǒng)而言，是很難用自然語言表達清楚的。因此，為了能夠?qū)ο到y(tǒng)的需求獲得全面的了解，實際觀察用戶的操作過程就是一種行之有效的方法。現(xiàn)場觀摩就是走到客戶的工作場所，一邊觀察，一邊聽客戶講解，甚至可以安排人員跟隨客戶一起工作一段時間。這樣就可以使得分析人員對客戶的需求有更加直觀的理解。但是，在現(xiàn)場觀摩過程中必須切記：建造軟件系統(tǒng)不僅僅只是為了模擬客戶的手工操作過程，還必須將最好的經(jīng)濟效益、最快的處理速度、最合理的操作流程和最友好的用戶界面等作為軟件設計的目標。

4、競品分析

可以將競品分為兩大類：用與我們相同或相似的功能滿足用戶同樣需求的產(chǎn)品、用與我們不同的功能滿足用戶同樣的需求的產(chǎn)品。所謂競品分析，就是尋找出有代表性的競爭產(chǎn)品，從多個維度對比該產(chǎn)品與我們的產(chǎn)品之間的相同之處與不同之處，從中分析出兩者的優(yōu)劣之處，得出結(jié)論，為產(chǎn)品的設計與迭代提供突破口或帶來啟發(fā)（這是指單次的競品分析）。

二、需求分析

需求分析方法有：

結(jié)構(gòu)化分析方法：包括面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法，面向數(shù)據(jù)流結(jié)構(gòu)的Jackson方法和面向數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)化數(shù)據(jù)系統(tǒng)開發(fā)方法。

面向?qū)ο蟮姆治龇椒ǎ簭男枨蠓治鼋⒌哪Ｐ偷奶匦詠矸郑枨蠓治龇椒ㄓ址譃殪o態(tài)分析方法和動態(tài)分析方法。

結(jié)構(gòu)化分析方法

結(jié)構(gòu)化分析方法的實質(zhì)是著眼于數(shù)據(jù)流，自頂向下，逐層分解，建立系統(tǒng)的處理流程，以數(shù)據(jù)流圖和數(shù)據(jù)字典為主要工具，建立系統(tǒng)的邏輯模型。

結(jié)構(gòu)化分析的步驟如下：

通過對用戶的調(diào)查，以軟件的需求為線索，獲得當前系統(tǒng)的具體模型

去掉具體模型中非本質(zhì)因素，抽象出當前系統(tǒng)的邏輯模型

根據(jù)計算機的特點分析當前系統(tǒng)與目標系統(tǒng)的差別，建立目標系統(tǒng)的邏輯模型

完善目標系統(tǒng)并補充細節(jié)，寫出目標系統(tǒng)的軟件需求規(guī)格說明

評審直到確認完全符合用戶對軟件的需求面向?qū)ο蟮男枨蠓治龇椒?/p>

面向?qū)ο蟮男枨蠓治龇椒?/b>

面向?qū)ο蟮男枨蠓治龇椒ǖ暮诵氖抢妹嫦驅(qū)ο蟮母拍詈头椒檐浖枨蠼ㄔ炷Ｐ?。它包含面向?qū)ο箫L格的圖形語言機制和用于指導需求分析的面向?qū)ο蠓椒▽W。目前已經(jīng)衍生許多種OOA方法。

每種方法都有各自的進行產(chǎn)品或系統(tǒng)分析的過程，有一組可描述過程演進的圖形標識，以及能使得軟件工程師以一致的方式建立模型的符號體系?，F(xiàn)在廣泛使用的OOA方法有統(tǒng)一的建模語言（UML）已經(jīng)在企業(yè)中廣泛使用，它把Booch、Rumbaugh和Jacobson等各自獨立的OOA和OOD方法中最優(yōu)秀的特色組合成一個統(tǒng)一的方法。UML允許軟件工程師使用由一組語法的語義的實用的規(guī)則支配的符號來表示分析模型。

在UML中用5種不同的視圖來表示一個系統(tǒng)，這些視圖從不同的側(cè)面描述系統(tǒng)。每一個視圖由一組圖形來定義。

三、創(chuàng)建需求地圖

1、需求地圖的組成

需求地圖主要由三部分組成，由上自下分別是模塊區(qū)、待排期需求區(qū)和已排期需求區(qū)，已排期需求區(qū)由多個發(fā)布計劃組成，如下圖所示：

2、模塊的分解

模塊就是將待開發(fā)的產(chǎn)品的功能進行分解，按功能從屬關系表示的樹狀層級視圖。待開發(fā)產(chǎn)品的各子系統(tǒng)、子模塊可以看作是產(chǎn)品目標下層的功能，對其中每項功能模塊還可以繼續(xù)分解為第三層、第四層……甚至更多層級的功能模塊，理論上根據(jù)待開發(fā)產(chǎn)品的規(guī)模，可以無限極的分解產(chǎn)品的功能模塊。

通過需求分析得到的模塊形成了待開發(fā)產(chǎn)品的“骨骼”，把這些模塊錄入翼發(fā)云軟件研發(fā)管理系統(tǒng)后，能夠自動在用戶需求地圖中自動生成層級的、包含關系的模塊關系圖，顯示在需求地圖第一部分“模塊區(qū)”中。

郵件管理系統(tǒng)通過需求分析得到第一層級的四個模塊：郵件組織、郵件管理、日歷管理、聯(lián)系人管理。依次再將這些模塊分解為更小、粒度更細的第二層級的模塊，郵件組織分解為郵件搜索、郵件整理兩個子模塊；郵件管理分解為發(fā)送郵件、讀取郵件、刪除郵件三個子模塊；聯(lián)系人管理分解為創(chuàng)建聯(lián)系人、編輯聯(lián)系人、刪除聯(lián)系人等。（注：橙色的模塊是最下層的模塊）

對應的樹形視圖如下所示：

3、用戶需求的生成

根據(jù)用戶需求調(diào)研和分析，把用戶需求的基本信息如名稱、需求描述、驗收標準、預估工作量、優(yōu)先級等錄入系統(tǒng)。

三、用戶需求的排期

當用戶需求錄入系統(tǒng)后，會出現(xiàn)在需求地圖的待排期區(qū)域里，待排期區(qū)域里的需求就是還沒有安排開發(fā)時間的需求，這時可以通過拖拽的方式，把需求拖到發(fā)布計劃里，從而完成需求的排期工作，排期區(qū)域里的需求就是已經(jīng)安排了開發(fā)的需求。是不是很簡單。

通過多次拖拉用戶需求后，最終完成了用戶需求地圖：

來源：pm28