需求的定義：

?

1，需求： 需求就是 "要什么" .。需求分析本質上就是問題分析，問題分析的方法論可運用到需求分析。

一般情況下，需求直觀表達為誰在什么情況下想干什么。這里就涉及帶了"目標用戶" "使用場景" "用戶目標"。

eg：

一個人餓了，想吃東西。--------------->這就是用戶需求。

你給了他一包方便面。--------------------->這就是滿足用戶需求。

你給了他一塊面包，然后告訴他，面包比方便面好吃，但是容易噎到，于是搭著賣了一瓶紅茶。------->這是創造用戶需求。

?

2，需求的的場景

是需要根據具體場景特點來分析如何滿足需求。比如分析觀看視屏用戶在移動場景下的特點就是移動頻繁、注意力不易集中、

流量有限等 ！ 那對應的視屏類產品設計原則就會考慮讓交易單手操作、視屏簡單而兩點集中（如：萬萬沒想到? 等短視頻的搞笑視屏）。

基于什么環境： 地鐵/辦公室/室內/公共場合/走路/夜晚/戶外..........

基于什么用戶： 具體什么特征，比如身份、收入、區域........

基于什么行為： 行為或操作流程，比如購物流程、操作習慣、行為認知..........

場景分析也就是需要考慮具體什么環境（時間、地點、情境）什么類型用戶的什么動機，想達到什么目標，以及人與人的關系。如實地記錄下來，如果偏差或缺乏信息，之后的分析就會有所偏差。

?

需求的分類

?

1、需求層次：
1）. 業務需求：業務需求是方案范圍，經營范圍，或者項目范圍
2）. 用戶需求：用戶需求在互聯網中的表現大多是在各種場景下，用戶想做某件事情所遇到的問題，或所想滿足的欲望。
3）. 功能需求：主要說明了系統實際應做到什么。這是用戶最直觀也是最主要的需求。功能需求是為了滿足業務跟用戶而制定的。
4）. 系統需求：響應系統層面需求，例如：系統沒有內存了，頁面卡了

2、常規三個層次的顧客需求：基本型需求、期望型需求和興奮型需求。
1）.基本型需求：用戶認為產品“必須有”的屬性或功能。當其特性不充足(不滿足用戶需求)時，用戶很不滿意;當其特性充足(滿足用戶需求)時，無所謂滿意不滿意，用戶充其量是滿意。
如果此類需求沒有得到滿足或表現欠佳，客戶的不滿情緒會急劇增加，并且此類需求得到滿足后，可以消除客戶的不滿，但并不能帶來客戶滿意度的增加。產品的基本需求往往屬于此類。對于這類需求，企業的做法應該是注重不要在這方面失分。
我們一般停留在這個階段
2）.期望型需求：耍求提供的產品或服務比較優秀，但并不是“必須”的產品屬性或服務行為有些期望型需求連用戶都不太清楚，但是是他們希望得到的;在市場調查中，用戶談論的通常是期望型需求，期望型需求在產品中實現的越多，用戶就越滿意;當沒有滿意這些需求時，用戶就不滿意。
此類需求得到滿足或表現良好的話，客戶滿意度會顯著增加，當此類需求得不到滿足或表現不好的話，客戶的不滿也會顯著增加。這是處于成長期的需求，客戶、競爭對手和企業自身都關注的需求，也是體現競爭能力的需求。對于這類需求，企業的做法應該是注重提高這方面的質量，要力爭超過競爭對手。
3）.興奮型需求：要求提供給用戶一些完全出乎意料的產品屬性或服務行為，使用戶產生驚喜。當其特性不充足時，并且是無關緊要的特性，則用戶無所謂，當產品提供了這類需求中的服務時，用戶就會對產品非常滿意，從而提高用戶的忠誠度。
此類需求一經滿足，即使表現并不完善，也能到來客戶滿意度的急劇提高，同時此類需求如果得不到滿足，往往不會帶來客戶的不滿。這類需求往往是代表顧客的潛在需求，企業的做法就是去尋找發掘這樣的需求，領先對手。

?

如何與客戶高效的溝通需求

?

很多外包服務商都會有這樣抱怨：客戶的需求又改了，之前做的工程又返工了......。出現這種情況，很大部分原因在于：與客戶溝通時，客戶說出來的需求，與談需求的乙方接受的“需求”，與最后工程師接受到的、真正實施的需求很不一致導致的。這就像多人傳話的游戲一樣，第一個人說出的話，與最后一個人所聽到的，是截然不同的意義。
---------------------?

同時除了信息溝通不到位之外，還有一個原因是：
一般面對客戶談需要的乙方角色都是銷售或產品經理，而這類角色的人會有公司業績壓力的影響，在與客戶談需求時，內心的活動是：先把這個事籠下來，把我的業績完成，至于是否能開發那是工程師的事；
而工程師他的主要服務對象是給他提出需求的人（產品經理等角色），他的工作任務是基本把需求開發完成；
由此以來，一個項目承接下來后，能對客戶承擔責任的人就少了，到工程結尾的時候，就不可避免的會發生各種改需求或返工的情況。
?

真正能有效、能開發出客戶滿意的系統，就應該在與客戶溝通需求時，一定要有一個這樣角色的人：即能作為產品經理，能比較迅速的梳理出客戶的需求，同時也能作為工程師，能評估出項目的難易度和開發周期，同時也能作為銷售，能與客戶談出一個雙方比較合理的價格。

?

?

大體的流程是這樣的：

1.先和客戶溝通想要實現什么功能？

2.整理一份粗粒度的需求文檔，并設計原型。

3.找客戶確認原型，并在需求文檔上簽字畫押。

4.循環上述步驟

? ?

該如何和客戶進行交流？

? ? 1.用戶需要什么功能？用戶提供了哪些數據？這些數據是否能夠實現用戶所需要的功能？

? ? 2.注意聆聽客戶的要求，并用自己的語言重復給客戶聽。建議：錄音保存后整理。

? ? 3.軟件的使用頻率、使用周期、數據量是多少（比如：每月最多上傳多少條記錄），以便于后期優化。以及誰使用本系統？涉及到權限的管理。

? ? 4.專業領域的術語一定要明確。類型、是否唯一。如："代碼證號"=="組織機構代碼證號"
?

項目如何開始：怎樣和客戶談需求

三種客戶類型：

1 的確很專業。能提供基本可用的文檔，能給出要求規范，能向你提出有價值疑問和擔心。能快速回答你的問題。

2 以為自己很專業。 給的文檔基本沒法用。沒法提供規范和標準，喜歡指指點點和挑毛病。只會向你提傻逼問題。基本回答不了你的問題。

3 啥都不懂。 不給文檔。能給你幾個參考范例（打開數個網站，告訴你我要做成和它們一樣的。）只能等著你來問100個問題。。。

四種合作方式：

1 創始人直接和你接洽：

交流結果的協商余地很大，需求不易反復，細節不會被過分追究。更容易統一想法，執行力高，你能對項目和產品產生更大的影響。但往往甲方會過于急進。

2 項目代表和你接洽：

這是非常理想的狀況了。甲方有一個產品經理或IT經理能作為代表，負責匯總甲方的所有需求和標準和你溝通，他有過與外包方合作的經驗，知道危險的環節所在，能承擔翻譯和橋梁的角色，幫助你阻擋和說服不恰當的需求。能集中地承擔責任，也會積極地和你一起規避項目失敗的風險。非常lucky！

3 專業部門和你接洽：

IT部門或技術部門的某個高級別工程師負責和你溝通，你們會比較有共同語言，甚至惺惺相惜。技術方面的合作會很順利，但是涉及到產品和需求，他們無法幫你擋住來自市場或內容部門的麻煩。合作開始后，很有可能在技術思路上產生分歧；如果在程序部分耽誤了太多時間，而產品端被忽視，你有可能受到其它部門及上層的質疑。

4 市場部門（內容部門）和你接洽：

最好你先去燒燒香，準備好最壞打算。專業和思考模式的差異會導致你們關心的問題完全不一樣。你首要滿足了他們關心的地方后，切記留出不少時間來解決那些他們看不見但實際上非常重要的問題。另外你需要做更多的事，寫更多的文檔，主動和專業部門聯系，力爭和決策層有溝通。

如果你面臨了第3和第4種狀況，

請先熟悉一下甲方的組織機構。例如一般 內容型、媒體、渠道、宣傳類項目的開發：

需求 和 市場部門 溝通

功能 和 內容部門 溝通

軟硬廣告位或專題 等 和 銷售部門 溝通（如果是改版類，廣告位合同可能提前半年簽訂，一定要和銷售協調好）

技術、系統、安全、統計問題等 和IT、網管、數據統計部門 溝通

某些問題 需要和 總裁助理、行政 等官僚部門溝通。

部分特別的內容 需要和 創意、美工、文案部門 溝通

當以后確定需求的時候，如果發現這些部門的人沒有參與，請提前與之溝通。

第1和第2種狀況可跳過上述步驟。

八步流程:

第一步：聽聽客戶想要什么。

以及預計工期和預算（這兩件事上一點都不要靦腆，這是關系項目成本最重要的元素）。

第二步：提問。

1 項目的目的是什么。（品牌、渠道、流量、廣告費、用戶數、VC、其它商業模式）

2 甲方的優勢和資源是什么。(錢，內容資源，人力大戰，傳統行業優勢)

3 盡量提供可視的參照及借鑒對象 。（應用上有沒有可解決的。界面上比較喜歡哪個站點的設計。交互上有沒有可參考的對象）

4 其它工程的細節問題。

比如（工期上的上下限是什么？

是否會需要與現有系統整合、是否需要數據遷移？是否會需要甲方的工程師合作？

是否有開發平臺的限制？

是否有代碼規范及標準？最終需要哪些開發文檔和源碼 ）

第三步：取得共識。

與甲方取得共識非常重要，保證你所理解的那他們所理解是同一個東西。這一步需要你根據掌握的情況列出提綱，畫出草圖或框架圖。有參考對象的，標注上，哪個部分會比較像某某。

然后請甲方確認， 這個框架是他們想要的。

第四步：給出工程時間軸。

到了這一環節，就需要你的項目經理組織所有團隊成員坐下來討論，先劃分功能模塊，然后討論每個功能模塊的可行性、難度、花費時間、bug發生率、測試耗時。再討論一頭一尾 系統搭建和系統整合的所需時間。

項目經理對工程耗時和可行性完全心里有數后，畫出工程的時間軸。包括并行狀況，里程碑節點、測試期、緩沖期等（如何畫工程時間軸，甘特圖，我以后會專門寫一篇）。時間軸要實事求是，并且預留好充分的緩沖期（工程師估時*2*110%）。

第五步：需求做減法。

大部分情況下，時間軸表現的狀況都會超出客戶的預期。如果客戶對工期沒有要求，也要提醒客戶考慮 項目可行性風險、市場等候成本、市場或戰略變化導致的浪費。

韓磊有一篇《大褂還是內褲》的blog很形象地描述過這個問題。

所以要和甲方一起盡量對需求做減法。把整體需求拆成2~3期，落實只開發最基礎和最必要的一期需求。

這時簽訂正式開發協議。

不要忘了計算 需求文檔和產品方案 的費用。

第六步：撰寫詳細的需求文檔。

《框架圖》下載西喬的模版。可視化表現產品的框架、布局、細節、部分交互。

《流程圖》》下載西喬的模版。理出產品的邏輯關系。

《功能需求文檔》》下載西喬的模版。 羅列 功能、應用、交互上細節，分離基礎件，作為開發分工和系統及數據構造的 基礎文檔。

第七步：商討需求文檔

盡量召集甲方所有相關部門的負責人 一起召開這次會議，商討需求文檔。

在閱讀到你的需求文檔之前，可能甲方的大部分人都對產品沒有可視和具象的理解。也從未關注到細節和邏輯關系。所以需要產品經理從全局角度和邏輯線索講解文檔。

更可能發生的狀況是，沒有人堅持看完或仔細看過你寫的文檔。

所以這次會議是一場耐心和體力的考研。

文檔作者需要 分別向各個部門指出他們需要關注和拍板的地方，聽取他們的建議，將任何變動要求都分類記錄。

安撫情緒。解答困惑。控制需求變動。

第八步：定稿需求文檔

分職能（部門）類建立表格文檔。將會議協商中所有 分歧性意見和變動意見 都逐條寫下。抄送所有相關負責人。并要求他們糾正分歧和確認變動。

所有會議中可能被提出但是未出現在此郵件文檔中的 意見，不會列入需求文檔中。當然允許可以書面反饋補充。

根據確認過的反饋回復，修改需求文檔。直到需求文檔定稿。

協商討論和文檔修改可能經過2~3輪。所以需要項目經理提前提醒客戶注意，搜集需求和文檔定稿的 時間線里程碑。如果這個階段耗時過久，會嚴重延誤整個項目進度。要求客戶盡量集中地謹慎地提出建議和修改。

三種武器：

需求問卷：無論是面對專業還是不專業的客戶，交流中都有很多沒考慮到的遺漏點，這些他們看不到的點往往是最關鍵的點，也有可能是被客戶故意規避掉的點。

此時撰寫一份需求問卷非常有效。

問卷里提出重要的全局性的問題，需要客戶逐條書面回答。

某些問題可以提供多個選項答案，及補充區域。

某些問題 需要確鑿的態度，Yes或NO。

不要提出需要客戶寫一大段表述性文字的問題。

需求問卷精簡扼要，有針對性，重要，不要浪費客戶的時間，不要把寫字的工作量丟給客戶。

書面確認：

書面確認 一方面包括 ：所有討論結果、建議 和變更 都要有書面文字備查。電話和開會上說說的這些口頭表達都沒有效應。這一點一開始你就要聲明，甚至有必要寫在合同里。

另一方面包括：你要盡量提供書面的可視化的東西 來讓甲方確認。

甲方很難完備或是提供適合工程使用的文檔。所以千萬不要在項目初期的需求文檔上省懶。

郵件抄送：

郵件抄送一種明確職責的方法。對方可能不看你的郵件，但代表你告之過。

盡可能地抄送重要郵件給戰略層，可以能避免一些重大問題的出現。

結語：

到此看起來，搜集和確定需求真是一件耗時耗力的工程。

其實在理想的工程項目時間分配中，1/3的時間用于確定所有需求和開發文檔。 1/2的時間用于測試，解決bug，安全測試、壓力測試等。真正用于開發的只應該占1/6。

當然web項目的開發肯定達不到這個理想狀況。但是也由此可見需求階段的重要性和工作量。這一階段省一分力或有一分遺漏，到了項目后期可能需要十分力來彌補。

?

一個全新的需求項目

思維導圖：

第一步，需求確認

首先肯定是要去確認需求，要知道做什么，做成什么樣。
第二步，分析資源

分析資源主要是兩個注意的地方：
1、人力資源
有多少人能用，每個人的能力如何？
2、時間節點
這個需求要求如何？什么時候交付？
第三步，功能分析

這一步跟第一步需求確認息息相關，首先要確認功能有哪些。然后要對這個工程所處的使用環境和要求進行判斷，有多少訪問量，性能要求，對工程的易用性，侵入性，持久化等如何要求？
第四步，技術選型

技術選型需要我們有足夠的經驗和知識面來支撐，平時就要獲取很多的知識，這樣在遇到具體需求的時候可以去尋找出合適的技術來應對。有些時候可能市面上現有的技術沒有辦法滿足我們本次項目的需求，那這時候可能就需要自己去造輪子。
第五步，設計實現

如果以上四步做的很好，那么最后一步就是水到渠成。根據之前的需求分析，功能分析，技術選型，然后來具體的量化我們的功能。完成這些，就可以開始coding了。
?

================================================================================================================================================================================================

?

?

?

?

?

?

?

?

?

?

?

?

?

?

總結

以上是生活随笔為你收集整理的互联网项目开始时需要去谈的产品需求分析：的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。