在進行app開發(fā)時，需求分析在產(chǎn)品生命周期中占有重要的地位，決定著產(chǎn)品做出后被用戶接納的程度。通過對接觸過的PM進行觀察，我發(fā)現(xiàn)大部分人進行需求分析時做的事情大同小異。故總結(jié)出幾個關(guān)鍵點，形成一個可以應(yīng)對大多數(shù)需求的操作方法。

說明：由于筆者一直從事ToB產(chǎn)品的工作，故本文所述的方法只針對此類產(chǎn)品，不保證對ToC產(chǎn)品適用。

一、需求從哪里來的

需求是某些用戶在特定場景下為了得到某種服務(wù)或功能而提出的訴求或建議，它是產(chǎn)品的組成部分，也是產(chǎn)品最終要達到的目的。它可以是老板的一句話，可以是用戶使用過程中的一聲抱怨，也可以是對一堆數(shù)據(jù)分析后得出的結(jié)論。

根據(jù)筆者的觀察，需求的來源有以下幾種：

1. 老板

對于老板提出的需求，一定要重視，并非因為需求方是老板，而是因為它同時包含著機會和陷阱，而且很難拒絕。

（1）機會

• 通過老板的需求，了解老板的思路，借此一窺公司戰(zhàn)略發(fā)展方向；

• 將自己對產(chǎn)品的理解和老板的對照，找出其中的區(qū)別并思考原因；

• 和老板交流下自己的產(chǎn)品思路，發(fā)現(xiàn)自己和老板的差距；

• 把老板交代的事做好了，得到老板的賞識（這個大家都懂）。

（2）陷阱

• 并非所有的老板都了解產(chǎn)品開發(fā)流程，了解業(yè)務(wù)發(fā)展，會出現(xiàn)瞎指揮的情況；

• 某些需求會打亂團隊的產(chǎn)品規(guī)劃及開發(fā)節(jié)奏，PM處理不好將會里外不是人。

2. 用戶（內(nèi)部同事）

筆者面對的用戶是公司內(nèi)部的同事，大部分是使用系統(tǒng)的部門同事，小部分是其他的PM。

從部門同事的需求中看出，他們在意的是系統(tǒng)能否滿足他們的某項要求，通常會在提出需求的同時給出他們的解決方案。但是并不意味著就是真實需求，一個很著名的案例是想要快馬但是福特提供了汽車（不知道的朋友請自行查詢）。因此，PM在溝通中需要引導(dǎo)他們表述出自己的真實需求。

負責其他系統(tǒng)（業(yè)務(wù)線）的PM也會提出需求，來滿足一些需要跨系統(tǒng)實現(xiàn)的功能。這種情況的溝通會比較順暢，因為彼此對系統(tǒng)、開發(fā)流程、技術(shù)邊界都比較了解。

3. 自我驅(qū)動

這類需求通常會基于以下三種原因產(chǎn)生：

1. 通過數(shù)據(jù)分析得出的。

2. PM在使用系統(tǒng)時發(fā)現(xiàn)的問題（通常用戶無感知）。例如：筆者做風(fēng)控系統(tǒng)時發(fā)現(xiàn)的問題，需要對推送的進件增加控制開關(guān)。作用是在風(fēng)控模型調(diào)整或新功能上線后，控制推送進件的數(shù)量，待驗證無問題后再打開，允許大量進件。

3. 根據(jù)產(chǎn)品感提出的。產(chǎn)品感是指基于PM對產(chǎn)品的理解，對市場的分析，提出了一些對于產(chǎn)品未來發(fā)展有益的需求。

二、對需求提出方式做規(guī)定是有必要的

每個需求的提出者，通常會站在自己的角度提需求，或基于交互，或基于效率，或基于KPI等。這對PM把握需求的重要程度，了解需求內(nèi)容的準確性增加了難度。

例如：筆者曾經(jīng)對接過和我不在一個城市工作的業(yè)務(wù)部門。對接過程中，出現(xiàn)了同一個部門多人同時提需求且優(yōu)先級不明確，需求上線后使用者（非需求提出者）反饋需求實用性不高，或者需求上線后很多等待使用的人不知道等問題。

筆者通常會分三步進行操作：

1. 確定接口人并明確其職責

接口人：和需求方部門Leader溝通，讓他指定一名接口人，所有人的需求都在接口人處匯總，再提給PM。

職責：

1. 收集部門同事的需求；

2. 過濾掉不合理和不必要的需求；

3. 給出需求的優(yōu)先級；

4. 將需求提交給PM；

5. 跟進需求進度；

?2. 確定需求提出方式

郵件提出，確保周知所有相關(guān)人，并能留存記錄。

3. 部門Leader進行審批

必須由部門Leader審批，確保他了解并認可需求內(nèi)容和優(yōu)先級。

三、需求收集方式

一句話概括，就是多提問、多溝通，了解業(yè)務(wù)和實際使用場景。

1. 5W1H分析法

很多需求提出者不了解系統(tǒng)，他們只關(guān)心當前問題是否能夠解決，PM必須詳細了解需求的來龍去脈，以便能提出解決方案。在此推薦5W1H分析法，用來收集需求內(nèi)容。

（1）What（描述）

需求是什么？

（2）Why（原因）

為什么會有這樣的需求？之前的替代方案是什么？

（3）Who（使用者）

需求的使用者是誰，或者說是哪個部門？

（4）Where（場景）

需求的使用場景是什么？

（5）When（時機）

需求什么時候會被用到？被用到的頻率是怎樣的？

（6）How（檢驗）

如何確認需求已經(jīng)被滿足？

上述問題要求需求方描述清楚，可通過郵件，也可通過面談。需求的收集方法可按照自己的習(xí)慣選擇，重點在于對需求信息的收集。

2. 和需求方的溝通頻次

負責ToB產(chǎn)品的PM必須了解業(yè)務(wù)，筆者曾經(jīng)負責過財務(wù)系統(tǒng)的設(shè)計，由于不了解需求方對于結(jié)算、對賬、提現(xiàn)等操作使用場景的要求（需求方也不了解），導(dǎo)致設(shè)計出現(xiàn)問題，需要進行二次開發(fā)。

要想深入了解業(yè)務(wù)，就需要和需求方保持溝通。筆者認為，在接到需求后，至少應(yīng)該有三次溝通。

• 第一次是在接到需求后。要遵循5W1H分析法，圍繞其中的問題進行溝通，收集需求詳細信息。

• 第二次是在收集信息并對需求進行分析后。PM會結(jié)合自己對系統(tǒng)的了解，挖掘出一些細節(jié)問題，其中有一些需要和需求方確認。這期間可能會有多次溝通。

• 第三次是在PRD完成后。要將文檔內(nèi)容講給需求方聽，在評審前最后一次確認自己是否準確理解需求。至于需求背景這類問題，必須在評審會前了解清楚，以便在會上講給所有人。

  
  

  四、需求的分析與整理
  1. 需求分析的步驟

判斷需求的真?zhèn)唯C>分析需求的業(yè)務(wù)價值–>評估需求的可行性–>給出需求的優(yōu)先級。

筆者將以自己的經(jīng)歷為例，說明如何進行這四步操作：

（1）判斷需求的真?zhèn)?/strong>

在app開發(fā)設(shè)計是，該需求的5W1H分別為：

1. What：需求方是財務(wù)部門，需求內(nèi)容是在財務(wù)系統(tǒng)中新增列表，用來展示某項費用的明細，且該列表可以下載。

2. Why：之前的替代方案是從系統(tǒng)中另一個列表下載，由于并不是專門展示此類數(shù)據(jù)（數(shù)據(jù)量較大），所以需要人為進行篩選和計算。篩選計算時間不長，筆者親測約為15分鐘。

3. Who：使用者是財務(wù)部門的一名同事（只有一人），系統(tǒng)的其他使用者不會用到該列表。

4. Where：使用場景是每月與合作方對賬時，需要下載該列表，然后在excel中對某幾項金額進行計算。

5. When：每個月月初使用，統(tǒng)計上一個月各資金類型的交易量，使用頻率一個月一次。

6. How：列表中能夠按時提供準確、完整的數(shù)據(jù)，即滿足需求。

根據(jù)筆者的判斷，該需求目前有替代方法且不難操作，需求使用頻率低（一月一次），使用人數(shù)少（一人）。故該需求的業(yè)務(wù)價值不高，是偽需求。

筆者向需求方闡明了需求的不合理處，并建議在已有列表處，增加下載入口，可下載每月需要對賬的金額總和，這樣既節(jié)省了下載后再計算的工作量，同時也降低了數(shù)據(jù)量，減少下載時對資源的占用。

因為需求方堅持按照最初提的方案進行，同時不能給出合理的解釋，故最終砍掉該需求。

（2）分析需求的業(yè)務(wù)價值

這一條可以和判斷需求真?zhèn)位パa，通常業(yè)務(wù)價值很低的需求，即便做出來也很少會被用到。

依照上述事例，雖然是投入人力、耗費時間都很少的需求，但其業(yè)務(wù)價值只是為了每個月節(jié)約一個人15分鐘時間，得不償失。

另外，PM還需要對系統(tǒng)的發(fā)展方向、包含的功能、服務(wù)的人群有明確定位。對于后臺系統(tǒng)來說，在增加功能、列表時必須要有規(guī)劃和節(jié)制，否則系統(tǒng)很快就會功能冗余、查找困難、使用不便。

（3）評估需求的可行性

這一步的目的在于判斷需求的開發(fā)難度，進而給出大致的實現(xiàn)方案，需要PM和開發(fā)共同完成。

上述事例中的需求頁面功能簡單，所需數(shù)據(jù)在數(shù)據(jù)中有記錄，接口也有提供，故從可行性來說沒有問題。

PM需要對自己負責的系統(tǒng)、對接的技術(shù)人員的能力、代碼開發(fā)中的技術(shù)邊界有一定了解，才能更好的做出可行性評估。因此建議PM多學(xué)習(xí)技術(shù)，以免提出“根據(jù)手機殼顏色變換APP主題色”這類的需求。

（4）給出需求的優(yōu)先級

筆者認為，在app開發(fā)時，一般會運用四象限法則和KANO模型來判斷優(yōu)先級。這兩個方法在確定優(yōu)先級中是比較常用的，在此過多介紹，感興趣的朋友可以自行查詢（優(yōu)秀的PM需要具備查詢能力和自學(xué)能力）。

四象限法則：

• 重要性：指需求是否符合公司戰(zhàn)略發(fā)展、是否是產(chǎn)品線上的戰(zhàn)略項目、是否和公司的收益掛鉤、是否滿足產(chǎn)品的基礎(chǔ)服務(wù)等等?？傊?，在時間上不具有緊迫性，但是會對未來的發(fā)展產(chǎn)生重大影響。

• 緊急性：指需求是否必須立即解決，如不解決會持續(xù)產(chǎn)生或?qū)⒁a(chǎn)生不良影響。這類需求不一定很重要，但是在時間上有緊迫性。

如下圖所示，重要緊急的需求需要立即放下手中的事情，集中精力去解決，例如：筆者接到的風(fēng)控系統(tǒng)需求，要在合規(guī)備案檢查前上線，以滿足合規(guī)備案的需要。重要不緊急的，要在了解并分析完需求后，制定出方案，然后按部就班的執(zhí)行。緊急不重要的，能不做就不做，做的話也盡量采用省時省力的方法解決。不緊急也不重要的，這類多為偽需求，參照上述財務(wù)部門的事例，果斷拒絕掉。

KANO模型：

• 必備因素：在業(yè)務(wù)流程中必須具備的功能，用以保證流程能正常進行。功能缺失時，使用者會發(fā)現(xiàn)流程不能走通。故這類需求需要優(yōu)先考慮。例如：風(fēng)控系統(tǒng)中跑反欺詐模型時，如果調(diào)用失敗后沒有重啟流程這個功能，就會存在調(diào)用失敗的進件卡在反欺詐模型環(huán)節(jié)，造成流程中斷。

• 期望因素：這類需求通常能節(jié)省使用者的時間，提升效率。存在的目的是為了讓系統(tǒng)操作起來更流暢。優(yōu)先級一般沒有必備因素高。例如：財務(wù)系統(tǒng)每月做報表時，如果系統(tǒng)能夠?qū)⑿枰獜亩嗵幉檎也⒂嬎愕臄?shù)據(jù)，統(tǒng)一到一處并展示計算后的結(jié)果，那樣能提高使用效率。

• 魅力因素：通常是一些使用者沒有想到的功能，能大幅提升使用者效率、優(yōu)化體驗和解決使用者線下難以解決的問題的需求。這類需求在ToB產(chǎn)品中不常見，通常是必備因素和期望因素占據(jù)主導(dǎo)地位。

無差異因素和反向因素：這兩類需求我認為是偽需求，是耗費時間、精力后卻不能提升使用者體驗、效率的，遇到后應(yīng)予以拒絕。

2. 需求整理

需求的收集與整理需要用到需求池。需求池沒有固定的模板，建立的目的是為了幫助PM進行需求的評估和管理，模板內(nèi)容依照個人習(xí)慣建立即可。

需求池中的需求由PM錄入，記錄不需要像收集需求及分析時那樣細致，重點在于對需求的狀態(tài)、優(yōu)先級、排期進行記錄。