接下來，我們要開始講產品經理工作中最重要的環節——需求分析與管理。

這里我對需求分析的定義要廣一些，包括：需求的獲取、需求的評估、需求的評審、需求的管理等。因此，本文是對產品全生命周期需求分析的描述，不僅僅是產品前期的需求分析。

本文結構如下：

No.005 如何做好需求分析.png

我們先來看看需求的分類。

一、需求分類

1、從商業角度分為用戶需求和商業需求

用戶需求：2C產品我們通常叫做用戶，2B產品我們可能還會叫他客戶。這些人的訴求稱之為用戶需求。
商業需求：和企業利益密切相關的需求。

作為產品經理，我們一定不能只考慮用戶需求，還要考慮其與商業需求的權衡。你做一個所有人都喜愛的產品，但是卻沒有任何盈利點，又有什么用呢？

用戶的需求包括但不限于一下這些：

• 娛樂休閑
• 歸屬感
• 溝通
• 意見領袖：意見領袖的一言一行是追隨者愿意模仿，意見領袖存在是具有其自身價值的。
• 利益：物質利益、精神利益
• 獲取知識和資訊
• 自我情感表達
  • 對人情感的分類：懷念，痛惜，懷恨，輕蔑，佩服，失望，嫉妒，慶幸，誠信，通信，嫉妒，快慰，信任，顧慮，顧忌，嘲笑。
  • 對己情感分類：自豪，慚愧，得意，自責，開心難堪，自卑，自信
  • 在現在生活中，人對自己情感的閱讀很差的，很少有人愿意去讀自己的內心。所以產品經理要學會洞察并把握用戶情感。
• 愛和被愛
• 社交
• 分享
• 安全
• 尊重

當然，這里有一個經典的理論模型——馬斯洛需求層次理論模型。用戶所有的需求都可以對應到這個模型上。我們要的不是說要了解該模型中每一層都對應哪些需求，而是要能夠知道該需求可以對應到那一層，這是一個思維問題。

馬斯洛需求層次理論.jpg

2、從產品開發角度分為功能性需求、非功能性需求

功能性需求：即產品設計上的功能

非功能性需求：包括產品性能、安全、兼容性、運營、UI、數據統計等需求。

很多產品經理都會忽視非功能性需求，最終導致產品出現各種bug、宕機、頻繁修改等問題。
這里提醒大家一點，我們永遠不能假設開發同志們在開發時，能夠考慮到性能、兼容性等問題?？紤]這些問題，是產品經理的工作。

3、按需求重要性分

3.1 必備型需求

必備型需求是用戶認為產品“必須有”的屬性或功能。

當其特性不充足（不滿足用戶需求）時，用戶很不滿意；當其特性充足（滿足用戶需求）時，無所謂滿意不滿意，用戶充其量是滿意，如婚嫁網站中搜索異性的功能等等。

用戶認為是理所當然應該存在的比方說：汽車里面的空調、車輪子

3.2 期望型需求

期望型需求（又叫績效性需求）需求提供的產品或服務比較優秀。

注意期望型并不是“必須”的產品屬性或服務行為（有些期望型需求連用戶都不太清楚）但是是他們希望得到的。

在市場調查中，用戶談論的通常是期望型需求，期望型需求在產品中實現的越多，用戶就越滿意;當沒有滿足這些需求時，用戶就不滿意。

例如婚嫁網站中除了搜索功能外，還可以為用戶在瀏覽異性的時候，根據瀏覽的異性匹配和推薦一些異性出來（根據喜好推薦）。

3.3 魅力型需求

魅力型需求要求提供給用戶一些完全出乎意料的產品屬性或服務行為（興奮型需求）。

魅力型需求使用戶產生驚喜。當其特性不充足時，并且是無關緊要的特性，則用戶無所謂，當產品提供了這類需求中的服務時，用戶就會對產品非常滿意，從而提高用戶的忠誠度。

比如：進入婚嫁網站就直接給你推送喜歡的異性，都是你中意的或超出預期的。

3.4 無差異型需求

無論提供或不提供此需求，用戶滿意度都不會有改變，用戶根本不在意。

比如：婚嫁網站上面提供PM2.5值、預告婚嫁網站上面提供物流快遞查詢等。

3.5 反向型需求

用戶根本都沒有此需求，提供后用戶滿意度反而會下降。

比如：婚戀網站上面提供在線離婚咨詢

4、學會探究問題的本質

社會進程的推動，其實就是滿足需求的過程。我們來看“國家的需求是穩定”這樣一個需求，我們該如何去探究：

• 國家需要穩定
  • 合理的社會福利
    • 醫療
    • 社保
    • 公積金
  • 法律與執法機器
    • 嚴格的法律
    • 警察，武警
  • 安全需求
    • 軍隊
    • 武器

互聯網產品也是基于這樣的需求大環境下被推動。
所以，思考問題是有方法的，當我們把一些根本的東西本質看透以后就能比較清晰的分析和思考問題了。

二、需求獲取

需求獲取的流程：明確目標 - > 選擇采集方法 - > 制定采集計劃 - > 執行采集 - > 資料整理。

這個流程沒什么好說的。需求獲取（采集）的方法有很多中，有些我們已經在《市場調研與分析》中講過了，除了那些，還有可用性測試、從運營等業務部門獲取等方法。

這里從需求獲取工作中單提出來3點：用戶調研、可用性測試和單項需求卡片。

1、用戶調研

1.1 用戶群細分

市場細分麥肯錫方法.png

1.2 明確目標用戶群及特征

用用戶群細分方法簡單描述我們的目標用戶群及其特征。

1.3 用戶場景及建模

用戶角色模型：新手用戶；熟練用戶；價值用戶。

其實就是對用戶進行畫像，類比與很多刑偵劇心理咨詢師對罪犯的心理測寫（這個類比好像不太合適哈），我們會對用戶的基本人口特征、需求等進行描述。下面是一個示例：

核心用戶畫像.png

我們通常會在目標用戶群中提煉出幾個典型的用戶，進行畫像。最后產出的用戶畫像將是后續的各種討論和決策的基本依據。

基于各種原因，我們的用戶畫像可能是會變化，這時我們就需要及時更新這些畫像。

1.4 用戶核心需求把控/目標用戶需求痛處

用戶口中所說的需求未必就是真實的需求，我們要學會把用戶需求轉化為產品需求。

用戶需求：用戶自以為的需求，并且經常表達為用戶的解決方案。

產品需求：經過我們的分析，找到的真實需求，并且表達為產品的解決方案。

所以我們所說的需求分析其實就是，從用戶提出的需求出發，找到用戶內心真正的渴望，再轉化為產品需

求的過程。

2、可用性測試

可用性測試是指通過讓實際用戶使用產品或原型方法來發現界面設計中的可用性問題，通常只能做少數幾個用戶的測試，看他們怎么做，屬于典型的定性研究。

可用性測試需要注意的問題：

第一，如果可用性測試做得太晚（往往在產品將要上線的時候），這時發現問題也于事無補了。

其實，可用性測試在產品的各個階段都可以做。在尚無任何成型的產品時，可以拿競爭對手的產品給用戶做；在產品只有紙面原型的時候，可以拿著手繪的產品，加上紙筆給用戶做；在產品只有頁面 Demo 的時候，可以拿 Demo 給用戶做；更多的時候，在產品已經可以運行以后，可以拿真實的產品給用戶做。不同階段不同做法，從中都能發現相應的問題。

第二，總覺得可用性測試很專業，所以干脆不做。

可用性測試，聽著很專業，但收益又無法量化，所以對很多老板來說，不太愿意在這個上面投入資源，經常因為項目時間過緊被略過。我們知道，可用性測試通常來說做 5 個左右的用戶才可以發現大部分的共性問題，前前后后的準備也耗時不少，但只做一個用戶，并且簡化步驟，也比不做要好。

第三，明確是測試產品，而不是測試用戶。

可用性測試要邀請用戶來做測試人員，我們在開始之前，應當明確地告訴用戶，這個測試的目的是發現軟件產品中的問題，而不是要測試用戶是否有能力來很好地使用軟件。所以，不要讓用戶聽到“可用性測試”的術語，而是說“來試用一下我們的 新產品，提點意見”。 清楚地說明這一點將有助于減輕用戶的壓力，使得他們能像在真實環境一樣來使用軟件。

第四，測試過程中，組織者該做的和不該做的。

剛開始的時候，可以告知用戶大概持續的時間，要做哪些事情，讓用戶心中有數，輕松愉快地完成任務。

可用性測試中，我們可以要求用戶在使用產品的過程中采用一種名為“發聲思維”的方法，即在使用產品的同時說出自己的思考過程，比如為了完成某個任務，用戶想先做什么，后做什么，為什么要做某個動作，等等。

做測試的過程中千萬不要有任何的引導與暗示，而只是觀察和記錄，因為任何引導都可能使得原本可以發現的問題無法暴露。用戶行為和預想的不一樣時，可以提問，實在進行不下去的時候，給予提示。記住，一切的錯都是產品和我們的錯，用戶絕對沒有錯。如果真覺得用戶錯了，那也是你找錯人了，不是這個人錯了。

結束之后，如有可能應該送個小禮品，當然在邀請的時候就要告訴用戶會有一些對他付出時間的補償。盡快總結，并且發給用戶，一方面讓用戶感到他做了一件有意義的事，另一方面也是表示感謝，建立長期和諧的“用戶參與產品設計”的氛圍。

3、單項需求卡片

單項需求卡片的理念就是： 產品的需求工作不只是需求分析人員的事，而是涉及產品的每個干系人的義務，至少得參與“采集”的過程，理想的狀態是產品的所有干系人都參加過“需求采集” 的培訓，然后在日常工作中養成主動提交需求給產品人員的習慣，但實際很難做到，所以作為專業的需求分析人員，就應該盡量降低同事們，比如銷售、服務、技術人員提交需求的成本，也是節省我們自己的時間。

一張單項需求卡片描述了一個用戶需求到底包含哪些內容，重點是描述用戶場景，誰在什么時間、地點產生了何種需求。

需求卡片還有一個好處是可以存檔，可以避免后面的扯皮。為什么說這點呢，因為我曾經吃過虧啊！o(╥﹏╥)o

這里提供一個非常簡單的模板：

需求采集表.png

三、需求評估

需求評估有2個目的：

• 評估需求合理性：不合理的一般不會進入需求列表中
• 評估需求優先級：若需求合理，則評估其優先級

1、需求優先級的評估

我們把需求匯總好之后，會進行需求分析，這里會對所有的需求進行合理性的評估，結合產品戰略與市場狀況，決定哪些需求做哪些不做，匯總進產品需求池中。

需求優先級的評估需要綜合考慮產品戰略、市場狀況、開發量、性價比等。其中產品戰略和市場狀況決定商業優先級，商業優先級和開發量決定性價比（即需求優先級）。

需求優先級計算公式.png

我們通常會把商業優先級在1-5級中，1最高，5最低。開發量一般以所需開發時長來定，以N小時/人作為計量單位。

這里面有個問題，商業優先級固定在[1,5]，但開發量的數值缺失不確定的。

舉個例子：

上面兩個需求那個優先級高呢？

這里有幾個答案：

• 答案1：需求1和需求2優先級一樣高；
• 答案2：如果需求1的確很重要的話，那么需求1的優先級更高；
• 答案3：如果需求1不是非常重要的話，那么需求2的優先級更高。

那個答案更合理呢？

在我看來，我認為答案1和答案2是合理的，答案3是一個偽命題。

對于答案3，如果需求1不是非常重要的話，我們就不應該給它的商業優先級定為5，定為5本身就是不合理的。

對于答案2，看起來比答案3合理多了。這里的邏輯是如果量化性價比出現問題的話，可以由主觀意愿介入來做決定。

其實面對這種情況，我們還有一種辦法。

前面的解決辦法其實是建立在商業優先級和開發量的權重一樣的情況下，一旦權重不一樣，就會出現答案2 所說需求1的確很重要的情況。

這個時候，我們可以引入歸一化的概念，對商業優先級和開發量進行歸一化處理，然后加上其權重。此時就變成了如下公式：

需求優先級計算公式-加權重.png

注：w1，w2為權重，商業優先級和開發量均經過歸一化處理

另：我們很少會使用這種方法，了解即可。

1.1 商業價值評估

即便是已經篩選評估出來的需求，很多時候量也是非常大的，而哪些該做，哪些不該做，很多時候我們會遇到：

• 老板拍腦袋要這么做
• 自己拍腦袋要這么做
• 顧此失彼，左顧右盼

其實，在產品不同階段，對需求的排序，也是有一些方法可以參考的，其實需求變通一下，和我們日常工作的評估方式是差不多的，可以分為四類：

• 重要且緊急
• 重要不緊急
• 緊急不重要
• 不緊急不重要

其實，無論需求到底是什么，產品終歸是商業性產品，所以打造產品的商業價值才是最重要的，所以在衡量需求的時候，最重要的衡量指標就是這個需求是否具有商業價值，商業價值越大，那么它就越重要越緊急。

商業價值也只是產品某一個階段的目標（有可能是一個長期的目標），基于這個目標我們會對其進行分解，當前的需求排序，應該最為符合當前的目標。

商業價值的評估是個哲學性問題，需要產品經理對行業和產品足夠理解。

1.2 開發量評估

開發量評估，其實是需要產品經理根據自己公司開發人員的具體情況來定的。

但還是有些定量和定性方法可以遵循。

（1）標簽估計法

選定一個大家已知的功能，例如：上傳照片（上傳，編輯，保存等，已知該功能需要3天時間）

• 將此功能工作量設定為50

• 請研發工作人員參照這個50的系數（上傳照片工作量）對目前手中需要完成的功能工作量進行評估，并寫出他們估計的系數。

• 假定估算系數為：55（工作量和上傳照片差不多）,80（工作量稍高）,200（工作量特別大），出現明顯的數據差距，則說明研發人員對此功能并不理解，沒有達成一致，這個時候則需要：

  • PM邀請成員進一步明確需求，理清功能

• 如果估算系數表現為：80,100,90，則說明大家意見比較統一（也有可能集體對需求理解錯誤，所以需要在明確一次需求），如果無誤，則可以估算出該功能耗時時間大概是在5-6天，具體時間可商議確定。

（2）實際討論法

實際討論法其實就是與研發人員通過“溝通”大家達成一種默契，即可以保質保量的完成工作，也不至于大家熬更守夜（要注意：熬夜不是光榮的，更不是值得長期去干的事情）。

當大家達成意見一致以后，產品經理再根據討論的結果來和領導以及其他部門協調各種時間。

其實在于職場，很多時候都是一種默契，即你讓別人好過，自己也會相對好過。

（3）強制手段法

強制手段法顧名思義就是狹天子以令諸侯了，強制在某個時間點前完成。

產品經理要善于去爭取各種資源，尤其是公司領導和老板，一些時候比較困難的事情可能因為老板點個頭或者一封郵件，就會變得比較好辦。

• 第一，不要總是拿老板壓人，很多時候需要先和同事溝通在自己的底線范圍內，都爭取溝通解決。

• 如果確實對方無法在底線范圍解決，而且你對當前任務確實相對看中，則需要想各種辦法來推動整個事情的進程，可以通過郵件，電話，當面匯報等，向老板提請需求并說明實際情況，為什么需要由他來推動，重要在哪里，需要怎么推動等等。

• 這種情況一定注意一個原則，就是對事不對人。

（4）放棄法

規范的做法是標簽估計法，最常用的方法是實際討論法，經常需要用到的是強制手段法。這些方法都可以解決開發量評估的問題。

這里說一個，在很多小企業或者不規范的企業中存在的問題，就是需求可能是完全由產品經理來定，不會經過需求的審核流程。這是會出現產品經理提的合理性需求，開發不愿意做，老板也不愿意做，但需求的確是真實合理的，此時怎么辦。

一、試圖說服老板；二、老板說服不了，就放棄。

碰到這種情況，沒必要去埋怨老板和開發傻逼，因為有些東西實在是你控制不了的，產品經理一定要明確這一點。

2、KANO模型

評估需求還有一個重要方法——KANO模型。

KANO模型.png

這個模型對應到我們在第1節第3小節講到的各類需求。

使用KANO模型最簡單的方法就是考慮每個模塊或需求， 對它所屬的類型進行討論。 我們可以設計一套問卷， 對用戶進行問卷調查。

KANO建議通過對一個功能問兩個問題來確定分類。 一個問題是： 如果產品中有這個功能， 用戶會覺得如何？ 另一個問題是：如果功能不存在， 用戶又覺得如何？

對每個問題采用5點度量方式進行回答： A表示我喜歡這樣； B表示我期望這樣； C表示我沒有意見； D表示我可以忍受這樣； E表示我討厭這樣。

經過訪談后， 根據歸類矩陣， 將問題進行歸類來確定需求的類型， 如圖所示。

KANO模型需求歸類矩陣.png

注： M代表Must-have， 是基本型需求； L代表Linear， 是期望型需求； E代表Exciter， 是興奮型需求； R代表Reverse， 是相反的需求； Q代表Questionable， 是可疑的結果； I代表Indifferent， 是無關緊要的。

通過上述的矩陣分析， 可以得出： 哪些是用戶需求表達時自相矛盾的； 哪些是用戶自己都不確定的； 哪些是無關緊要、 可有可無的； 哪些是必須要有的； 哪些是期望有的； 哪些是自己都沒有想到， 但用戶喜歡的（ 即興奮型需求）。

具體的評估方法就是對應基本型需求的功能必須要做， 不能在這方面失分； 對應期望型需求的功能選擇性做， 提高其質量， 力爭超過競爭對手； 對應興奮型需求的功能選擇1或2個必須做， 讓用戶尖叫。

Kano模型的優勢和不足

結合過往的資料和自己的心得，認為在調研中，Kano模型有以下幾個優勢：

• Kano模型可以細致全面的挖掘功能的特質
• Kano模型可以幫助業務方在工作中排優先級，輔助項目排期;
• Kano模型可以幫助人們擺脫“誤以為‘沒有抱怨’等于用戶滿意”的想法。

同樣，Kano模型也有它的不足：

• Kano問卷通常較長，而且從正反兩面詢問，可能會導致用戶感覺重復，并引情緒上的波動，若用戶受到影響沒有認真作答，則會引起數據質量的下降。
• Kano問卷在針對產品屬性進行測試時，部分屬性也許并不是很好理解。
• Kano模型類似于一種定性歸類的方法，以頻數來判斷每個測試屬性的歸類，這種情況下，可能會出屬性歸類結果表中，同一屬性出現了不同歸類欄頻數相等或近似的情況。

由于KANO 模型存在這些不足，在運用KANO模型分析數據的時候就要注重數據收集前期的準備工作。比如在問卷設計時，把問卷盡量設計得清晰易懂、語言盡量簡單具體，避免語意產生歧義。同時，可以在在問卷中加入簡短且明顯的提示或說明，方便用戶順利填答。

3、一些特殊情況的需求評估

3.1 偽測試

偽測試指的是先不實現功能， 只提供一個按鈕鏈接或文字鏈接或圖片入口， 用戶點擊之后提示此功能正在建設當中。 根據用戶的點擊率數據情況來決定是否實現該功能。

偽測試在什么情況下比較適用呢？

如果產品團隊和研發團隊雙方爭執激烈， 誰也說服不了誰， 需要拿出能讓團隊彼此信服的證據，這個時候就可以采用這種方法。

但是， 必須注意的是， 先在產品的忠實用戶中進行灰度測試， 看點擊率情況怎么樣再做決定是否該做。

具體的評估方法就是測試用戶中有超過40%的用戶點擊或使用了， 則表明值得做。

3.2 A/B測試

AB測試比較有趣，是相對成熟的團隊，有一定用戶基礎的團隊使用的一種方法。

A/B測試的基本思想：

• 同時提供多個方案并行測試。
• 不同方案之間只存在一個變量， 排除其他干擾因素。
• 以某種標準判定結果優劣， 篩出最優方案。

3.3 新產品上線

新產品未上線時候的需求特點：沒有運營數據支撐、需求一大堆。

在產品研發初期，還會遇到一些非用戶需求，例如：后臺編輯的方便性、基于產品自身的數據反饋等。

所以其實產品初期更重要的是形成產品的框架架構，即基本需求要打造完成。

3.4 免費型產品已經上線

免費型產品的分類：全免費、部分免費、限時免費。

因為免費，免費產品都能相對獲得更多的用戶運營數據，也就是說產品經理除了通過KNAO模型或者其它方式獲得需求篩選甄別排序依據外，還可以通過真實的運營數據來分析用戶的實際需求。

我們可以通過數據公式來計算用戶的期望型需求和魅力型需求：

用戶需求重要性=用戶使用率（有多少用戶用過）*功能或者內容平均使用次數（經常用還是偶爾用）*類別重要性權重（次功能的重要性，通過專家團隊來評估）

3.5 需求有前置/后置條件

對于一些串行的產品需求，例如：A之后才能是B，B之后才能使C。那么按照需求重要排序則是 A>B>C。

4、小結

還是那句話，諸行無常。今天的興奮需求也許明天就是基本需求，今天的基本需求通過改進也許就成了明天的興奮需求。大家，可以思考一下那些需求以前是興奮需求現在變成了基本需求。

在產品的生命周期中，應該做好基礎需求，發現期望需求，創造興奮需求。爭取在產品上線的時候，就應該有一些期望和興奮需求，這樣才能在短時間里面讓用戶發現產品的價值。

注意，對于一些拿捏的很準的需求，就請忘記KANO模型吧。產品經理一定要學會靈活處理問題，很多時候可以對需求進行多重考量，而不是僅僅是套用一種方法。

產品經理對需求排序的能力，會影響到整個產品的進度以及開發人員，所以，產品經理一定要對需求排序心中有數，胸有成竹，說出道理，讓大家明白，這樣大家才能信服你，更好的與你展開合作。

有些東西說清了是什么和為什么之后，怎么做的問題就很清晰了，所以之后我會盡可能多說是什么和為什么，怎么做的問題我只會簡要說明一下方法論。

四、需求評審

一個產品的開發過程會經過很多次評審，大概的順序基本是：

BRD/MRD評審→PRD/需求評審→交互設計稿評審→視覺設計稿評審→開發需求評審→測試用例評審→運營規劃評審→閉環循環

其中每個環節的評審所對應的人員都是不同的，每個環節可能都不止評審一次。

BRD/MRD評審基本上會是產品經理和老板或高層一起評審，不僅包括需求的評審，還會有對產品戰略、運營規劃等方面的評審。

PRD評審是一個多方參與的工作，涉及到老板（最好叫上他哈）、開發、設計、測試、運營等。一般我們在做出比較大粒度的PRD之后就會做一次評審，以便盡早發現問題。

交互設計稿評審是在PRD評審之后，由交互設計師根據產品需求進行設計，參與方為：交互設計師、產品經理等。

視覺設計稿評審是由UI設計師根據產品需求和交互設計稿進行設計，參與方為：UI設計師、產品經理、交互設計師等。

開發需求評審是開發接到產品需求后，將產品需求轉化為開發需求，一般是在研發人員內部進行評審，當然產品經理也可以參與。我的建議是最好參與進來。

測試用例評審，俗稱TC評審，是測試人員根據產品需求對每一個需求寫測試用例，測試會根據測試用例進行測試工作。此階段的參與方為：測試、開發、產品。

運營規劃評審是由運營人員產出運營規劃后對規劃進行的評審，參與方為：運營、產品、老板等。

對于由產品經理主導的評審會議，我們要注意以下問題：

開會前要注意幾點：

• 開會前，最好能有一份會議議程給大家，然后大家提前熟悉一下，讓大家帶著問題來開會。
• 或者，開會的時候，先請大家過一遍內容等。
• 再或者，是開會開始的時候，產品經理先定一個基調，講一下背景等等。

開會過程中要鼓勵大家多提問題：

• 注意只要與會人員能放開提問題就是好事兒，這樣能打消團隊成員的疑慮。
• 也可以把沒有想明白的東西提出來大家一起討論

這里面涉及一個團隊決策的問題，需要我們需注意：

在做團隊討論時，產品經理的思路很有可能會被淹沒在團隊決策中，產品變得四不像，這非?？简灝a品經理的拿捏以及決策能力和定力。

因為，團隊討論很有可能是每個參與者會“略微”站在自己的維度考慮問題，例如技術研發人員可能會考慮工作量，市場人員可能會考慮銷售指標等，他們會選擇對他們有利的方式，但不一定對產品有利。

因此，我們雖然提倡團隊討論，但決策還有要由我們自己來做。

五、需求管理

1、需求管理池

這里提供一個簡易模板。

任何一個環節delay，都會導致整個項目的delay，因此，我們需要時刻關注一些時間和進度性質的字段，把控項目進展。

2、需求變更

幾乎很少有從頭到尾都不變更需求的產品，產品經理對于需求變更的控制也是貫穿到產品始終的。

很多需求變更都是通過口頭溝通的，但是我們最好要做好書面記錄（甩鍋必備）。

這里也提供一個簡易模板。

小結

到這里，我們對需求分析與管理的講解就算完成了。原稿大概是2萬字，但有太多廢話，所以刪減到了現在9千字左右的精華版本。

需求分析的方法論不止以上這些，但我們日常工作常用的基本就是本文所講的了，我上面所提到的很多細節都是非常需要大家注意的。

本來打算把MRD和PRD也放在這里的，但這樣篇幅太長了，因此我把這些放在下一篇講。