編輯導語：需求文檔的撰寫有助于產品經理更好地理清思路，協助后續項目業務的分析復盤，與此同時，也可以讓團隊人員更好地理解業務需求，推動項目進行。那么，B端產品經理如何撰寫出讓開發測試都能理解且認可的需求文檔？本文作者做了總結，一起來看一下。

一、客觀場景

據調研，開發測試非常反感以下類型的B端產品經理：

• 業務流程都整不明白，還是開發幫其捋出來的；
• 講完一個需求，讓開發花幾天或幾周時間梳理其不明確的邏輯點；
• 已經到了敲代碼階段了，還在多次改需求；
• 寫的需求來自拍腦袋而不是客觀業務背景；
• 需求文檔讓測試根本不知道怎樣寫測試用例。

這些問題的解決辦法除了用人情交際手段、扯皮解決，還可以從嚴于律己的角度出發，踏踏實實寫好PRD文檔，寫出能征服開發、測試的PRD文檔，然后宣講需求的時候按照文檔寫的順序宣講就行。

“怎么寫PRD文檔”這常常是培訓機構做的事情，主要給那些將要做產品經理的新人同學看，我講的是“怎樣寫出征服開發測試的B端PRD文檔”，主要寫給已經做B端產品經理2年以上的同學看，目的是讓B端產品經理能通過PRD文檔表達實力、提升能力、征服開發，從而提高產研協作效率和豎立產品經理威嚴。

二、開發測試的訴求

那么到底怎樣才能寫出征服開發測試的B端PRD文檔 ？

首先就得分析開發測試通過PRD文檔到底想知道什么、也就是其需求是什么，然后有效地滿足他們的需求，最后在宣講需求的時候用通俗易懂的話講清楚、讓聽眾聽明白。那么開發測試到底通過PRD文檔主要想知道什么呢？

1. 前端開發

• 哪些增刪改查頁面要做；
• 每一個界面交互邏輯；
• 哪些節點要請求后端哪些接口；
• 為何要做這個需求。

2. 后端開發

• 核心和具體功能的業務流程是什么；
• 前端的哪些交互需要調用我的什么接口；
• 涉及到哪些表，表之間的數據流向是什么、表結構怎樣設計；
• 需要其它后端開發配合我聯調什么接口；
• 為何要做這個需求。

3. 測試

要寫哪些明確的用例。

三、八招征服

那么到底怎樣寫PRD文檔，才能滿足開發測試上面的這些需求呢？

經過6年的ERP、供應鏈相關產品設計實戰，我總結出了“八招”，讀者在使用這八招時需要實事求是一切從實際出發，畢竟難度很大。為了讓讀者理解起來不那么枯燥，我把這8招分開闡述，且配了相關案例。

1. 更新標記

無論是創建一個全新的大需求，還是在已有需求中增刪改需求都要有標記，這樣就可追溯需求。如果不這樣做，有時產品經理自己就會發現之前的邏輯是什么不知道，特別是前任產品離職后如果不交接清楚，你接收后會一臉懵。

我說的標記是只在文檔內容中要有標記，這樣開發測試只需搜索這個標記就知道了“這個需求”涉及哪些，而不是要全文閱讀。就好像你在監控下面干了什么，都被拍下來了一樣，下面我列舉了2個簡單案例。

1）修改字段名稱

2）修改一段邏輯

2. 業務場景

要寫清楚業務上遇到什么了問題，然后你的產品方案是要解決這個問題的，不然開發測試不知道你為何要做這個需求。還要寫清楚這個問題是怎樣來的，是來自實際業務、還是誰拍腦袋的，這樣開發測試就知道了需求的真實性。

如果你還有空的話，可以寫下分析這個問題的過程、以及解決這個問題的多種方案，這樣開發測試就能身臨其境地知道了這個需求的來龍去脈。

3. 方案概述

寫完業務場景就要寫方案概述，主要就是用產品語言概述上面的問題是怎樣解決的，這個需求涉及到哪些業務模塊、涉及到哪些核心邏輯。

這樣宣講需求時開發憑此就可判斷是否與自己有關系了，就不會出現“某開發參加需求評審個把小時卻發現自己不需要做啥，然后耽誤了敲代碼的時間搞的晚上又要加班”。而且開發主管也可以根據這個方案概述就能判斷出來需要給什么樣的開發資源、開發周期。

4. 業務流程

寫完方案概述開發測試只知道要干什么，但是具體怎樣做是不知道的，這時就要開始寫業務流程，最好用泳道圖寫清楚各種判斷邏輯、涉及的用戶角色、業務模塊等。后端開發看這個的時候，腦子里就會想數據流向、需要哪些接口、用哪張表。

業務流程就好像是開車時使用的地圖導航、就好像是打仗時制定的路線圖，對于B端產品經理來說“無論多么復雜的業務都可以用流程圖表達出來”是基本的能力，這里我就不放按案例圖片了。對于開發來說非常反感的一種B端產品經理就是“一個需求竟然畫不清楚、說不清楚流程”。

5. 前端交互

只有業務流程來表達一件事情的解決過程還是有些抽象，所以此時要用原型頁面來形象表達，這塊UI和前端會重點看需要做哪些增刪改查頁面、哪些交互，后端也會思考需要封裝哪些接口給前端調用。

注意這里不是簡單用原型工具畫幾個頁面把鏈接拋給開發就行，而是要按一定的格式（條件、動作、頁面、結果）寫出每一個交互、每一個字段，具體可看下面案例。

有一種產品經理是非常讓開發測試反感的，就是“需求的輸出方式就是一個原型文件，點開后發現就基本的列表頁、新增編輯頁、詳情頁，其它邏輯靠猜”。

以我這樣的方式寫前端交互有個弊端就是比較花時間，最大的優勢就是可以不漏掉每一個交互邏輯、每一個字段，下面我只是舉了2個非常簡單的例子。

1）列表頁中的每一個字段名稱、排序要寫出來，以免遺漏

2）新增、編輯頁中的每一個交互，用“條件、動作、頁面、結果”這一格式表達

6. 表結構

這塊目前市面上90%以上的B端產品經理都不會寫，因為籠統地覺得這是開發的事情。如果產品經理能把這個需求需要設計哪些表、需要哪些字段、以及每個字段的相關信息都寫出來，那么開發設計表結構的時候就可以借鑒、確認，這樣開發真的會非常佩服你。

這塊的基礎就是產品經理要懂sql的基本查詢語句，如果懂了真的是如虎添翼，寫需求的時候能更加從開發的角度考慮問題了。以下案例中的每一列名稱的使用，需要有一定數據庫功底的產品經理才能掌握。

7. 數據流向

從哪個表取數據插入或更新到哪個表，用什么樣的入參去請求哪個接口返回出什么樣的值，這個開發是非常關心的。

開發敲的代碼操縱的就是表，也就是說在開發眼中功能的本質就是數據的流向，而數據流向的載體是表和接口，數據流向是業務流程的技術理解。這塊需要有一定數據庫和接口功底的B端產品經理才寫得出來。

8. 評審問題

在產品宣講或開發過程中，開發提的一些重要問題的答案這里要記錄下來，這樣就方便其它開發看，也更能明確需求。特別是產品文檔中沒寫的邏輯，在評審時開發發現了然后經過討論后定下來了，就更加要寫到這上面來了。

這塊其實是對需求文檔的一個查漏補缺，如果不記錄那么也許過一段時間又會忘記這些重要邏輯，記錄采取這樣的格式就行“提出人、提出時間、問題、答案”。

四、總結

到了這里就寫完了，這八招是對B端產品經理的高嚴格、高標準，所以在實際應用過程中需要一切從實際出發，畢竟通過口述需求、原型文件、一個PPT、簡單寫一段文字、甚至畫個草圖給開發，開發也是能把需求實現的。

產品經理寫的文檔就相當于是自己的藝術作品，如果你對自己的藝術作品是高標準的，那么我相信假以時日你在開發測試眼中將是一塊金字招牌，都樂于和你合作。

我不會寫一篇虛的文章，每篇文章都是來自多年ERP、供應鏈相關產品經理工作的總結。我不需要任何一個讀者給我鼓掌或者覺得我講的有道理，我需要的是閱讀此文后你能在工作中用得上，這樣就能幫助你更優秀。

作者：產品老兵，公眾號：供應鏈產品老兵

本文由 @供應鏈產品老兵 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。