不只是我自己在用excel，我還推薦朋友使用，在培訓時，我也將excel需求文檔的寫法教給大家，并且將excel版本定義為需求文檔的2.0階段。

這篇大概是我改的次數最多的文章，因為好處實在太多，最開始我從使用特性來分析，然后又從管理來分析，但總覺得不妥，畢竟這些好處并不是絕對的，還要看個人和團隊的升級應用，然后就有了這版 ，絕對肯定一定大概也許可能打死不改的版本。

我決定，寫幾個最基礎的好處，屬于每一位用excel寫需求文檔都會擁抱它的好處。

一、需求可量化

如圖，我們一旦使用excel寫需求文檔，會立即知曉需求數量，圖有14個需中便求點。你還記的上一個版本做了多少個需求嗎？

我們使用excel來攥寫需求文檔，會很明確每個版本的需求量，比如我在上一個版本里總共開發的需求點有240個左右。

不論是word版本又或者是原型圖標注，在這一點上都無法做到與excel相同的效果。（ps.我始終不認為原型圖標注是一種需求文檔的撰寫方法，他應該是表現形式才對）

需求量化以后，我們能做到哪些事情？

將需求量化以后，我們可以輕易得到以上四個信息。

產品輸出：

基本上每位產品經理都能生產需求，但卻無法將這些需求進行均衡，這也是許多創業團隊的PM進入成熟團隊后，很難適應的問題。

每個開發團隊的生產力都是有限的，越是成熟的團隊，周期內開發的需求量越是顯得均衡，比如一個月固定開發量在400-500之間。

當然開發團隊的規模，技術能力，以及需求復雜度，都會影響可開發的需求量。但這些的前提，我們得有能量化下來的需求才行。

需求變更：

需求變更不僅僅是讓開發，測試同學深惡痛絕，也是我們產品從業人員心理的痛。誰不想消滅需求變更呢？畢竟被大家不信任，以及質疑，總不是一件讓人感到高興的事情?？伤坪跷覀兛偸亲霾坏健安蛔兏?，甚至不知道自己的變更算嚴重還是在可接受范圍。

量化以后，這些數據就能成為我們最大的評判工具。

在上個版本一共有40個需求點出現了變更，這個版本變更記錄只有20條，是不是離目標近了點？即使某個版本出現變更較多的時候，比如出現了60個需求點變更，我們也能立即發現問題出在哪個環節，能發現自己對何種類型的需求掌握不足。

開發輸出：

大概是習慣使然，我們一般都會質疑產品的需求遺漏，卻不怎么會留意到功能漏做，一個好的團隊 ，出現功能漏做的可能性比較低，但在團隊初期時，這個問題，可是非常常見的。

我們可以借助規范的方法來避免這個問題，也是寄托于需求可量化的特性，能夠統計到漏做的數量 ，也能關注到哪些需求容易漏做。

這是word乃至原型標注所不能達到的效果：需求可量化

需求量化后就可被統計，而有了統計，就會出現完成率，變更率

這部分就不再展開了，我們來看看除了需求可量化以外，我選擇excel撰寫需求文檔的其他好處。

二、認識功能

這是我強調的另一個概念，對于產品經理而言，這是一個分水嶺：認識功能。其實有許多產品經理認識需求，但卻不認識功能。

這并不是一個值得提倡的趨勢，需求的來源我們可以理解成分析階段的產物，也是一種想法，思考的表現，但卻終要功能來實現。

互聯網產品經理本身有很大的局限性質，我們的想發必須依賴功能才得以實現，而這些功能都受到編程語言的限制，那就表示，功能是有限的。

需求是什么呢？

用戶將內容從A產品里分享到朋友圈里，如果他的微信好友訪問了他分享出去的內容，那在A產品里能夠記錄并通知用戶：你的微信好友xxx ，訪問了你分享的<xxxx>。

這是一個需求，也是我所做過的一個需求，實際的效果非常好，我們不需要將用戶的微信好友轉移到A產品里，就能實現簡單的熟人互動?！?/p>

怎么實現呢？

Word版本的需求文檔，大多是以描述需求為主，就像這個案例一樣，這個描述里有多少個功能，都有哪些功能，我們都是不知道的。

但excel的需求文檔里，如果我們不認識功能，就無法撰寫，excel并不只是將需求點羅列出來而已。

按照列順序，依次是 功能模塊 ，需求點，需求描述， 參數

功能模塊可以有多個需求點，需求點卻只能包含一個功能點。

我們只有認識到什么是排序規則，什么是首次加載，什么又是翻頁，什么是緩存，才能去將這些功能羅列出來，并且對單個功能點進行描述。

我們只有認識到什么是參數，才能在參數列里，將參數的內容獨立出來。這就反過來對我們產生了督促效果。

在撰寫的過程中，會反復思考需求如何實現的，并且向開發詢問，進行技術調研，經過了這一系列的過程，最終寫出來的需求文檔，就會極大的規避遺漏掉的需求，以及會變更的需求。要知道，在我們掌握一個需求的實現方案之前，這份文檔是寫不出來的。

所以，使用excel寫需求文檔的PM ，在相同的一年里，往往能比word版本的PM，具備更多的功能素材，積累更多的關于技術的認識。

這并不需要學習代碼，excel寫需求文檔就能達到這個效果。

三、積累需求庫

當我們進入這個行業后，會逐漸的發現，功能的復用度很高。

我所了解的設計師有一些開源的素材，開發也會有封裝好的SDK，可以直接使用。

產品經理也可以，我們的需求文檔也可以積累下來，也是可以被復用的。

圖中是一個功能模塊的需求文檔，我們會發現很多產品里使用到發布時間的，都會有一些相同的表現結果。那么這部分的需求文檔就可以復用到多個項目中。

隨著這樣的模塊化需求越來越多，我們自身就會積累非常高效的需求庫。怎么做呢？

這只需要我們單獨再建一張EXCEL，將每個版本的需求，按照一定的規律進行集合就好了。

Excel的需求文檔，由于是對功能進行定義，也就是說從功能的角度來寫，這就導致復用性非常高，不牽扯到業務邏輯，需求場景，功能就是功能。

久而久之，就會讓我們發現其實不同的需求所用到的功能很多都是相同的。不論我們做什么樣的項目，圖片還是那個圖片，輸入框還是輸入框。

這時，我們再寫一份需求文檔，大概只需要1-2小時，從我們的需求庫，提取出相應需求就可以了。

需求庫的形成，會有幾個典型好處：

• 對功能的認識可積累下來
• 極高的復用性能
• 逐漸完善需求，減少遺漏

有時候，我們會反復在同一個類型的需求里反相同的錯誤，就拿統計數字來講吧。

統計數字現在經常被使用，像是點贊數，評論數，關注數，粉絲數，照片數，閱讀數等等，非常多的地方使用到了統計數。我們可能在第一次寫統計數字的需求時，會漏掉單位轉換，沒關系，我們將這個遺漏掉的需求，以需求變更的形式，記錄下來。

第二次寫的時候，我們會直接復用這塊的需求，可能還會漏掉四舍五入，同樣的，還是用需求變更的方式記錄下來。

到后續的第三次，第四次，直到我們不需要再補充了，直到不會再因為該類型的需求，增加需求變更記錄了，我們的需求庫就成熟了。后續使用時，直接復用就好，無須再思考了。

這篇文章，我給大家講述了三個選擇使用excel的原因，但就如同我在前文里提及到的，excel的好處實在太多了，甚至還有很大的挖據空間，等待大家的發現。

枯葉講需求

今天來說說前端的“判斷”邏輯。

判斷邏輯是指在指定結果里，選擇某一個結果進行展示。

每個結果，都會有一個唯一的原因。

以關注按鈕而言，后端會告訴前端該用戶是否已關注對方，0表示 已關注，1表示未關注，前端就判斷這個參數是0還是1。如果是0的話，就顯示已關注按鈕，或者隱藏關注按鈕；如果是1的話，就顯示關注按鈕。

判斷條件的結果可能有多個，但一定是有限的，而且是一對一的。比如有四種結果，那就是在四種結果中間進行判斷。

#專欄作家#

枯葉，近6年經驗的產品經理，人人都是產品經理專欄作家。擅長社交，社區，細分群體挖掘。微信公眾號：枯葉咖啡館。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。