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

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

一、需求從哪里來的

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

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

1. 老板

對(duì)于老板提出的需求，一定要重視，并非因?yàn)樾枨蠓绞抢习?，而是因?yàn)樗瑫r(shí)包含著機(jī)會(huì)和陷阱，而且很難拒絕。

（1）機(jī)會(huì)

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

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

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

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

（2）陷阱

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

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

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

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

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

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

3. 自我驅(qū)動(dòng)

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

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

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

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

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

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

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

筆者通常會(huì)分三步進(jìn)行操作：

1. 確定接口人并明確其職責(zé)

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

職責(zé)：

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

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

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

4. 將需求提交給PM；

5. 跟進(jìn)需求進(jìn)度；

?2. 確定需求提出方式

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

3. 部門Leader進(jìn)行審批

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

三、需求收集方式

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

1. 5W1H分析法

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

（1）What（描述）

需求是什么？

（2）Why（原因）

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

（3）Who（使用者）

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

（4）Where（場(chǎng)景）

需求的使用場(chǎng)景是什么？

（5）When（時(shí)機(jī)）

需求什么時(shí)候會(huì)被用到？被用到的頻率是怎樣的？

（6）How（檢驗(yàn)）

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

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

2. 和需求方的溝通頻次

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

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

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

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

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

  
  

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

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

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

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

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

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

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

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

4. Where：使用場(chǎng)景是每月與合作方對(duì)賬時(shí)，需要下載該列表，然后在excel中對(duì)某幾項(xiàng)金額進(jìn)行計(jì)算。

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

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

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

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

因?yàn)樾枨蠓綀?jiān)持按照最初提的方案進(jìn)行，同時(shí)不能給出合理的解釋，故最終砍掉該需求。

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

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

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

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

（3）評(píng)估需求的可行性

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

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

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

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

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

四象限法則：

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

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

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

KANO模型：

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

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

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

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

2. 需求整理

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

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