通過前面三篇文章講了從市場需求到功能的過程，接下來講講如何把功能落地。

在寫這篇文章之前，我對自己加的幾個產品群做了簡單的調研，以下是部分調研截屏：

我匯總了一下圖中調研輸出產物，大概有以下幾種：

1. 需求文檔
2. 原型圖
3. 操作手冊
4. 流程圖
5. PPT

各位PM也可以嘗試列一下自己工作中輸出物，看看有那些。接下里進入文章正題，話不多說上圖：

• 準備開發階段：產品還未開始開發，處于剛定完需求階段，這個時候產品經理事情比較多，需要輸出大量文檔。
• 開發完成階段：產品開發完成，進入測試階段，產品同樣需要輸出相關產物。

前后端產物的差別

接下來我們分別來看看前后端分別的產物差別：

前端產物

通用產物

通用產物：這種產物，是前后端都需要用到的，不好定義具體屬于哪一類。

后端產物

看了上面列出來的輸出產物，會感慨產品經理怎么會有這么多的輸出產物。接下來我們一個一個的去講解，每一個產物的作用。

項目過程性文檔

需求列表

這個產物在上一票文章需求分析的時候已經全面講解過了，只是這篇文章專門講輸出產物，所以再提了一下。

這個地方提幾個建議：

1. 需求的描述一定要準確；
2. 原型圖與需求列表必須能對應的上；
3. 任何需求的變更，需求列表也需要同步的變更；
4. 前后端的需求相關連的注意說明。

受眾對象：領導、研發leader、開發人員。

原型圖

這個是基本上很多執行崗產品人都會輸出的產物，這個也沒有什么可說的，只是針對這個原型圖有幾點建議：

1. 制作速度要快，因為原型圖只是把需求變成界面功能的demo展示，演示過程中肯定會有按鈕位置擺放的不滿意、頁面布局的不滿意，各種需要修改的地方，所以制作的速度快了，就可以有更多的時間去修改，這樣才不會耽誤項目的進度。
2. 原型圖不要上色，上了色會對設計師進行高保真設計產生影響。
3. 不必過度的設計原型圖的動效，最多就做到頁面邏輯的跳轉關系。
4. 布局結果的清晰，設計師能清晰的明白看懂你的圖。

受眾對象：測試、設計師、前端開發。

需求文檔

這個是基本上很多產品人都會輸出的產物，但是名稱都是這個名稱，但是內容的格式，千奇百怪；可以說是一個公司一種格式。但是這個也沒有一個標準的格式，網上一搜一大堆什么需求文檔（PRD）模板。

針對需求文檔有個建議：

需求文檔只有合適的，沒有標準的。不用太去在意這個文檔的模板，用BAT的需求文檔，也不一定適合你們公司的產品流程。

要明白這個文檔，只是產品開發的一個過程文檔，它的作用是描述清楚功能的細節說明，和注意事項。只要文檔，開發和測試人員看起來清晰明了，能輕松的看懂產品經理需要表達什么，這才是最重要的。

受眾對象：測試人員、開發人員。

功能結構圖

功能結構圖就是按照功能的從屬關系畫成的圖表，圖中的每一個框都稱為一個功能模塊。功能模塊可以根據具體情況分的大一點或小一點，對其中每項功能還可以繼續分解為第三層、第四層……甚至更多的功能。

實際操作中注意事項：

1. 前后端分開列結構圖
2. 有些細節的備注
3. 模塊層級關系清晰

受眾對象：領導。

push模板-前端

這個主要用于給用戶端推送一些固定的軟件內推送，比如：電商某某的優惠劵到期了，發貨提醒等等！

提醒事項：

1. 注意抒寫的格式、標題。
2. 注意哪些是取動態數據的，抒寫清楚，比如：下面的我舉例的備注。
3. 如果類型有多重，需要分別說明。

圖為我自己隨便制作的一個push模板，這是一個很簡單的模板，需要根據自己公司的實際情況輸出站內信模板格式。

受眾對象：開發人員。

數據導出模板-后臺

這個文檔的作用是規范后端的資料下載格式規范，需要從后端下載出那些字段、字段格式、下載文件名稱等等。

提醒事項：

1. 注意抒寫的格式，建議使用excel表格，因為使用word格式的不好管理，迭代記錄。
2. 注意一些字段的名稱歧義，例如：時間，很多后臺都會記錄多個時間，比如訂單創建時間、訂單支付時間、訂單支付完成時間等等，需要明確的指出是導出的是哪個時間。

這是數據導出模板的是我自己做的一個，內容的話由于與公司敏感信息相關，所以打碼。注意一下，如果模板還有其他的說明，可以在“文件名稱”后增加一欄：備注。

受眾對象：后臺開發人員。

權限文檔-后臺

做過后臺的都知道，一般后臺都會分角色登錄，不同的角色權限不一樣，能在后臺進行的操作也不一樣，輸出的這份文檔主要是制定出各個角色對應的功能權限、數據權限。

注意事項：

1. 確定平臺基本角色：超級管理員、管理員、運營部、產品部等等；
2. 支持自定義角色；
3. 特殊權限需要在旁邊加上備注，不能下放。

受眾對象：后臺開發人員。

通用產物-校驗規則

這個文檔作用是整個產品（前后端）信息錄入過程中填寫不規范提示性文案的統一規則，在錄入信息的過程中常見的一些例子（部分）：

1. 輸入框默認顯示什么？
2. 輸入錯誤：提示什么？
3. 不輸入：提示什么？
4. 密碼錯誤提示什么？
5. ……

針對這個輸入信息校驗，簡單分享一下，校驗分為前端校驗與后端校驗；前后端校驗的邏輯是不同的，這點有部分產品人員容易忽視。

下面我用最常見的登錄頁面來簡單說明一下：

這下應該很容易前后端的校驗了。

受眾對象：前后端開發人員。

通用產物-短信模板

在特定的一些業務場景發送相同的短信通知用戶，但是有個前提是，必須錄入了手機號才能發送，它和push的區別就在于，站內信是只要下載這款產品就能發送push信息通知，而發送短信必須是有手機號。

方法：

1. 梳理業務流程，梳理出哪些場景是需要發送短信的節點；
2. 梳理短信文案時；注意短信的內容的主次，核心表達的內容是什么，輔助信息是什么等等；
3. 并整理出文檔；word/ excel格式都可以。

受眾對象：后臺開發人員。

培訓文檔

操作手冊/功能指引（B端產品）

操作手冊是詳細描述產品的功能、用戶操作流程，使用戶了解到如何使用該軟件。這點就不多講了，就清楚產品是怎么使用是講的，一些注意事項，這個不知道怎么寫的，找百度。

受眾對象：用戶。

培訓PPT

產品上線，需要對公司內部的其他部門人員進行產品培訓，一般參與培訓的部門指：運營部、市場部、客服部等等。

哪些這個PPT應該怎么去做了（站在目標人群的角度去制作）：

• 運營部：知道產品如何操作，業務流程應該怎么操作；
• 市場部：需要做的產品的一些主要賣點；
• 客服部：需要做的產品如何操作，有哪些注意事項，等等；

這樣應該知道內部培訓PPT怎么做了。

受眾對象：內部運營部、市場部、客服部等。

結尾

產物輸出只是項目開發中的一部分，如何讓項目如期保質保量落地，請期待下一篇：項目跟進去的白與黑。

相關閱讀

實戰第一步：市場調研

實戰第二步：如何做一份有針對性的競品分析

實戰第三步：從需求池到確認需求的全過程

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

題圖來自Unsplash，基于CC0協議