在進行app開發時(shí)，需求分(fēn)析在産品生命周期中占有重要的(de)地位，決定著(zhe)産品做(zuò)出後被用(yòng)戶接納的(de)程度。通(tōng)過對(duì)接觸過的(de)PM進行觀察，我發現大(dà)部分(fēn)人(rén)進行需求分(fēn)析時(shí)做(zuò)的(de)事情大(dà)同小異。故總結出幾個(gè)關鍵點，形成一個(gè)可(kě)以應對(duì)大(dà)多(duō)數需求的(de)操作方法。

說明(míng)：由于筆者一直從事ToB産品的(de)工作，故本文所述的(de)方法隻針對(duì)此類産品，不保證對(duì)ToC産品适用(yòng)。

一、需求從哪裏來(lái)的(de)

需求是某些用(yòng)戶在特定場(chǎng)景下(xià)爲了(le)得(de)到某種服務或功能而提出的(de)訴求或建議(yì)，它是産品的(de)組成部分(fēn)，也(yě)是産品最終要達到的(de)目的(de)。它可(kě)以是老闆的(de)一句話(huà)，可(kě)以是用(yòng)戶使用(yòng)過程中的(de)一聲抱怨，也(yě)可(kě)以是對(duì)一堆數據分(fēn)析後得(de)出的(de)結論。

根據筆者的(de)觀察，需求的(de)來(lái)源有以下(xià)幾種：

1. 老闆

對(duì)于老闆提出的(de)需求，一定要重視，并非因爲需求方是老闆，而是因爲它同時(shí)包含著(zhe)機會和(hé)陷阱，而且很難拒絕。

（1）機會

• 通(tōng)過老闆的(de)需求，了(le)解老闆的(de)思路，借此一窺公司戰略發展方向；

• 将自己對(duì)産品的(de)理(lǐ)解和(hé)老闆的(de)對(duì)照(zhào)，找出其中的(de)區(qū)别并思考原因；

• 和(hé)老闆交流下(xià)自己的(de)産品思路，發現自己和(hé)老闆的(de)差距；

• 把老闆交代的(de)事做(zuò)好了(le)，得(de)到老闆的(de)賞識（這(zhè)個(gè)大(dà)家都懂(dǒng)）。

（2）陷阱

• 并非所有的(de)老闆都了(le)解産品開發流程，了(le)解業務發展，會出現瞎指揮的(de)情況；

• 某些需求會打亂團隊的(de)産品規劃及開發節奏，PM處理(lǐ)不好将會裏外不是人(rén)。

2. 用(yòng)戶（内部同事）

筆者面對(duì)的(de)用(yòng)戶是公司内部的(de)同事，大(dà)部分(fēn)是使用(yòng)系統的(de)部門同事，小部分(fēn)是其他(tā)的(de)PM。

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

負責其他(tā)系統（業務線）的(de)PM也(yě)會提出需求，來(lái)滿足一些需要跨系統實現的(de)功能。這(zhè)種情況的(de)溝通(tōng)會比較順暢，因爲彼此對(duì)系統、開發流程、技術邊界都比較了(le)解。

3. 自我驅動

這(zhè)類需求通(tōng)常會基于以下(xià)三種原因産生：

1. 通(tōng)過數據分(fēn)析得(de)出的(de)。

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

3. 根據産品感提出的(de)。産品感是指基于PM對(duì)産品的(de)理(lǐ)解，對(duì)市場(chǎng)的(de)分(fēn)析，提出了(le)一些對(duì)于産品未來(lái)發展有益的(de)需求。

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

每個(gè)需求的(de)提出者，通(tōng)常會站在自己的(de)角度提需求，或基于交互，或基于效率，或基于KPI等。這(zhè)對(duì)PM把握需求的(de)重要程度，了(le)解需求内容的(de)準确性增加了(le)難度。

例如：筆者曾經對(duì)接過和(hé)我不在一個(gè)城(chéng)市工作的(de)業務部門。對(duì)接過程中，出現了(le)同一個(gè)部門多(duō)人(rén)同時(shí)提需求且優先級不明(míng)确，需求上線後使用(yòng)者（非需求提出者）反饋需求實用(yòng)性不高(gāo)，或者需求上線後很多(duō)等待使用(yòng)的(de)人(rén)不知道等問題。

筆者通(tōng)常會分(fēn)三步進行操作：

1. 确定接口人(rén)并明(míng)确其職責

接口人(rén)：和(hé)需求方部門Leader溝通(tōng)，讓他(tā)指定一名接口人(rén)，所有人(rén)的(de)需求都在接口人(rén)處彙總，再提給PM。

職責：

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

2. 過濾掉不合理(lǐ)和(hé)不必要的(de)需求；

3. 給出需求的(de)優先級；

4. 将需求提交給PM；

5. 跟進需求進度；

 2. 确定需求提出方式

郵件提出，确保周知所有相關人(rén)，并能留存記錄。

3. 部門Leader進行審批

必須由部門Leader審批，确保他(tā)了(le)解并認可(kě)需求内容和(hé)優先級。

三、需求收集方式

一句話(huà)概括，就是多(duō)提問、多(duō)溝通(tōng)，了(le)解業務和(hé)實際使用(yòng)場(chǎng)景。

1. 5W1H分(fēn)析法

很多(duō)需求提出者不了(le)解系統，他(tā)們隻關心當前問題是否能夠解決，PM必須詳細了(le)解需求的(de)來(lái)龍去脈，以便能提出解決方案。在此推薦5W1H分(fēn)析法，用(yòng)來(lái)收集需求内容。

（1）What（描述）

需求是什(shén)麽？

（2）Why（原因）

爲什(shén)麽會有這(zhè)樣的(de)需求？之前的(de)替代方案是什(shén)麽？

（3）Who（使用(yòng)者）

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

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

需求的(de)使用(yòng)場(chǎng)景是什(shén)麽？

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

需求什(shén)麽時(shí)候會被用(yòng)到？被用(yòng)到的(de)頻(pín)率是怎樣的(de)？

（6）How（檢驗）

如何确認需求已經被滿足？

上述問題要求需求方描述清楚，可(kě)通(tōng)過郵件，也(yě)可(kě)通(tōng)過面談。需求的(de)收集方法可(kě)按照(zhào)自己的(de)習(xí)慣選擇，重點在于對(duì)需求信息的(de)收集。

2. 和(hé)需求方的(de)溝通(tōng)頻(pín)次

負責ToB産品的(de)PM必須了(le)解業務，筆者曾經負責過财務系統的(de)設計，由于不了(le)解需求方對(duì)于結算(suàn)、對(duì)賬、提現等操作使用(yòng)場(chǎng)景的(de)要求（需求方也(yě)不了(le)解），導緻設計出現問題，需要進行二次開發。

要想深入了(le)解業務，就需要和(hé)需求方保持溝通(tōng)。筆者認爲，在接到需求後，至少應該有三次溝通(tōng)。

• 第一次是在接到需求後。要遵循5W1H分(fēn)析法，圍繞其中的(de)問題進行溝通(tōng)，收集需求詳細信息。

• 第二次是在收集信息并對(duì)需求進行分(fēn)析後。PM會結合自己對(duì)系統的(de)了(le)解，挖掘出一些細節問題，其中有一些需要和(hé)需求方确認。這(zhè)期間可(kě)能會有多(duō)次溝通(tōng)。

• 第三次是在PRD完成後。要将文檔内容講給需求方聽(tīng)，在評審前最後一次确認自己是否準确理(lǐ)解需求。至于需求背景這(zhè)類問題，必須在評審會前了(le)解清楚，以便在會上講給所有人(rén)。

  
  

  四、需求的(de)分(fēn)析與整理(lǐ)
  1. 需求分(fēn)析的(de)步驟

判斷需求的(de)真僞–>分(fēn)析需求的(de)業務價值–>評估需求的(de)可(kě)行性–>給出需求的(de)優先級。

筆者将以自己的(de)經曆爲例，說明(míng)如何進行這(zhè)四步操作：

（1）判斷需求的(de)真僞

在app開發設計是，該需求的(de)5W1H分(fēn)别爲：

1. What：需求方是财務部門，需求内容是在财務系統中新增列表，用(yòng)來(lái)展示某項費用(yòng)的(de)明(míng)細，且該列表可(kě)以下(xià)載。

2. Why：之前的(de)替代方案是從系統中另一個(gè)列表下(xià)載，由于并不是專門展示此類數據（數據量較大(dà)），所以需要人(rén)爲進行篩選和(hé)計算(suàn)。篩選計算(suàn)時(shí)間不長(cháng)，筆者親測約爲15分(fēn)鐘(zhōng)。

3. Who：使用(yòng)者是财務部門的(de)一名同事（隻有一人(rén)），系統的(de)其他(tā)使用(yòng)者不會用(yòng)到該列表。

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

5. When：每個(gè)月(yuè)月(yuè)初使用(yòng)，統計上一個(gè)月(yuè)各資金類型的(de)交易量，使用(yòng)頻(pín)率一個(gè)月(yuè)一次。

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

根據筆者的(de)判斷，該需求目前有替代方法且不難操作，需求使用(yòng)頻(pín)率低（一月(yuè)一次），使用(yòng)人(rén)數少（一人(rén)）。故該需求的(de)業務價值不高(gāo)，是僞需求。

筆者向需求方闡明(míng)了(le)需求的(de)不合理(lǐ)處，并建議(yì)在已有列表處，增加下(xià)載入口，可(kě)下(xià)載每月(yuè)需要對(duì)賬的(de)金額總和(hé)，這(zhè)樣既節省了(le)下(xià)載後再計算(suàn)的(de)工作量，同時(shí)也(yě)降低了(le)數據量，減少下(xià)載時(shí)對(duì)資源的(de)占用(yòng)。

因爲需求方堅持按照(zhào)最初提的(de)方案進行，同時(shí)不能給出合理(lǐ)的(de)解釋，故最終砍掉該需求。

（2）分(fēn)析需求的(de)業務價值

這(zhè)一條可(kě)以和(hé)判斷需求真僞互補，通(tōng)常業務價值很低的(de)需求，即便做(zuò)出來(lái)也(yě)很少會被用(yòng)到。

依照(zhào)上述事例，雖然是投入人(rén)力、耗費時(shí)間都很少的(de)需求，但其業務價值隻是爲了(le)每個(gè)月(yuè)節約一個(gè)人(rén)15分(fēn)鐘(zhōng)時(shí)間，得(de)不償失。

另外，PM還(hái)需要對(duì)系統的(de)發展方向、包含的(de)功能、服務的(de)人(rén)群有明(míng)确定位。對(duì)于後台系統來(lái)說，在增加功能、列表時(shí)必須要有規劃和(hé)節制，否則系統很快(kuài)就會功能冗餘、查找困難、使用(yòng)不便。

（3）評估需求的(de)可(kě)行性

這(zhè)一步的(de)目的(de)在于判斷需求的(de)開發難度，進而給出大(dà)緻的(de)實現方案，需要PM和(hé)開發共同完成。

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

PM需要對(duì)自己負責的(de)系統、對(duì)接的(de)技術人(rén)員(yuán)的(de)能力、代碼開發中的(de)技術邊界有一定了(le)解，才能更好的(de)做(zuò)出可(kě)行性評估。因此建議(yì)PM多(duō)學習(xí)技術，以免提出“根據手機殼顔色變換APP主題色”這(zhè)類的(de)需求。

（4）給出需求的(de)優先級

筆者認爲，在app開發時(shí)，一般會運用(yòng)四象限法則和(hé)KANO模型來(lái)判斷優先級。這(zhè)兩個(gè)方法在确定優先級中是比較常用(yòng)的(de)，在此過多(duō)介紹，感興趣的(de)朋友可(kě)以自行查詢（優秀的(de)PM需要具備查詢能力和(hé)自學能力）。

四象限法則：

• 重要性：指需求是否符合公司戰略發展、是否是産品線上的(de)戰略項目、是否和(hé)公司的(de)收益挂鈎、是否滿足産品的(de)基礎服務等等。總之，在時(shí)間上不具有緊迫性，但是會對(duì)未來(lái)的(de)發展産生重大(dà)影(yǐng)響。

• 緊急性：指需求是否必須立即解決，如不解決會持續産生或将要産生不良影(yǐng)響。這(zhè)類需求不一定很重要，但是在時(shí)間上有緊迫性。

如下(xià)圖所示，重要緊急的(de)需求需要立即放下(xià)手中的(de)事情，集中精力去解決，例如：筆者接到的(de)風控系統需求，要在合規備案檢查前上線，以滿足合規備案的(de)需要。重要不緊急的(de)，要在了(le)解并分(fēn)析完需求後，制定出方案，然後按部就班的(de)執行。緊急不重要的(de)，能不做(zuò)就不做(zuò)，做(zuò)的(de)話(huà)也(yě)盡量采用(yòng)省時(shí)省力的(de)方法解決。不緊急也(yě)不重要的(de)，這(zhè)類多(duō)爲僞需求，參照(zhào)上述财務部門的(de)事例，果斷拒絕掉。

KANO模型：

• 必備因素：在業務流程中必須具備的(de)功能，用(yòng)以保證流程能正常進行。功能缺失時(shí)，使用(yòng)者會發現流程不能走通(tōng)。故這(zhè)類需求需要優先考慮。例如：風控系統中跑反欺詐模型時(shí)，如果調用(yòng)失敗後沒有重啓流程這(zhè)個(gè)功能，就會存在調用(yòng)失敗的(de)進件卡在反欺詐模型環節，造成流程中斷。

• 期望因素：這(zhè)類需求通(tōng)常能節省使用(yòng)者的(de)時(shí)間，提升效率。存在的(de)目的(de)是爲了(le)讓系統操作起來(lái)更流暢。優先級一般沒有必備因素高(gāo)。例如：财務系統每月(yuè)做(zuò)報表時(shí)，如果系統能夠将需要從多(duō)處查找并計算(suàn)的(de)數據，統一到一處并展示計算(suàn)後的(de)結果，那樣能提高(gāo)使用(yòng)效率。

• 魅力因素：通(tōng)常是一些使用(yòng)者沒有想到的(de)功能，能大(dà)幅提升使用(yòng)者效率、優化(huà)體驗和(hé)解決使用(yòng)者線下(xià)難以解決的(de)問題的(de)需求。這(zhè)類需求在ToB産品中不常見，通(tōng)常是必備因素和(hé)期望因素占據主導地位。

無差異因素和(hé)反向因素：這(zhè)兩類需求我認爲是僞需求，是耗費時(shí)間、精力後卻不能提升使用(yòng)者體驗、效率的(de)，遇到後應予以拒絕。

2. 需求整理(lǐ)

需求的(de)收集與整理(lǐ)需要用(yòng)到需求池。需求池沒有固定的(de)模闆，建立的(de)目的(de)是爲了(le)幫助PM進行需求的(de)評估和(hé)管理(lǐ)，模闆内容依照(zhào)個(gè)人(rén)習(xí)慣建立即可(kě)。

需求池中的(de)需求由PM錄入，記錄不需要像收集需求及分(fēn)析時(shí)那樣細緻，重點在于對(duì)需求的(de)狀态、優先級、排期進行記錄。