實戰第四步：新專案之十大輸出產物
零基礎學產品，BAT產品總監帶，2天線下集訓+1年線上課程，全面掌握優秀產品經理必備技能。 ofollow,noindex">瞭解詳情
釋放雙眼，帶上耳機，聽聽看~！
00:00
00:00
通過前面三篇文章講了從市場需求到功能的過程，接下來講講如何把功能落地。
在寫這篇文章之前，我對自己加的幾個產品群做了簡單的調研，以下是部分調研截圖：
我彙總了一下圖中調研輸出產物，大概有以下幾種：
- 需求文件
- 原型圖
- 操作手冊
- 流程圖
- PPT
各位PM也可以嘗試列一下自己工作中輸出物，看看有那些。接下里進入文章正題，話不多說上圖：
- 準備開發階段：產品還未開始開發，處於剛定完需求階段，這個時候產品經理事情比較多，需要輸出大量文件。
- 開發完成階段：產品開發完成，進入測試階段，產品同樣需要輸出相關產物。
前後端產物的差別
接下來我們分別來看看前後端分別的產物差別：
前端產物
通用產物
通用產物：這種產物，是前後端都需要用到的，不好定義具體屬於哪一類。
後端產物
看了上面列出來的輸出產物，會感慨產品經理怎麼會有這麼多的輸出產物。接下來我們一個一個的去講解，每一個產物的作用。
專案過程性文件
需求列表
這個產物在上一票文章需求分析的時候已經全面講解過了，只是這篇文章專門講輸出產物，所以再提了一下。
這個地方提幾個建議：
- 需求的描述一定要準確；
- 原型圖與需求列表必須能對應的上；
- 任何需求的變更，需求列表也需要同步的變更；
- 前後端的需求相關連的注意說明。
受眾物件：領導、研發leader、開發人員。
原型圖
這個是基本上很多執行崗產品人都會輸出的產物，這個也沒有什麼可說的，只是針對這個原型圖有幾點建議：
- 製作速度要快，因為原型圖只是把需求變成介面功能的demo展示，演示過程中肯定會有按鈕位置擺放的不滿意、頁面佈局的不滿意，各種需要修改的地方，所以製作的速度快了，就可以有更多的時間去修改，這樣才不會耽誤專案的進度。
- 原型圖不要上色，上了色會對設計師進行高保真設計產生影響。
- 不必過度的設計原型圖的動效，最多就做到頁面邏輯的跳轉關係。
- 佈局結果的清晰，設計師能清晰的明白看懂你的圖。
受眾物件：測試、設計師、前端開發。
需求文件
這個是基本上很多產品人都會輸出的產物，但是名稱都是這個名稱，但是內容的格式，千奇百怪；可以說是一個公司一種格式。但是這個也沒有一個標準的格式，網上一搜一大堆什麼需求文件（PRD）模板。
針對需求文件有個建議：
需求文件只有合適的，沒有標準的。不用太去在意這個文件的模板，用BAT的需求文件，也不一定適合你們公司的產品流程。
要明白這個文件，只是產品開發的一個過程文件，它的作用是描述清楚功能的細節說明，和注意事項。只要文件，開發和測試人員看起來清晰明瞭，能輕鬆的看懂產品經理需要表達什麼，這才是最重要的。
受眾物件：測試人員、開發人員。
功能結構圖
功能結構圖就是按照功能的從屬關係畫成的圖表，圖中的每一個框都稱為一個功能模組。功能模組可以根據具體情況分的大一點或小一點，對其中每項功能還可以繼續分解為第三層、第四層……甚至更多的功能。
實際操作中注意事項：
- 前後端分開列結構圖
- 有些細節的備註
- 模組層級關係清晰
受眾物件：領導。
push模板-前端
這個主要用於給使用者端推送一些固定的軟體內推送，比如：電商某某的優惠劵到期了，發貨提醒等等！
提醒事項：
- 注意抒寫的格式、標題。
- 注意哪些是取動態資料的，抒寫清楚，比如：下面的我舉例的備註。
- 如果型別有多重，需要分別說明。
圖為我自己隨便製作的一個push模板，這是一個很簡單的模板，需要根據自己公司的實際情況輸出站內信模板格式。
受眾物件：開發人員。
資料匯出模板-後臺
這個文件的作用是規範後端的資料下載格式規範，需要從後端下載出那些欄位、欄位格式、下載檔名稱等等。
提醒事項：
- 注意抒寫的格式，建議使用excel表格，因為使用word格式的不好管理，迭代記錄。
- 注意一些欄位的名稱歧義，例如：時間，很多後臺都會記錄多個時間，比如訂單建立時間、訂單支付時間、訂單支付完成時間等等，需要明確的指出是匯出的是哪個時間。
這是資料匯出模板的是我自己做的一個，內容的話由於與公司敏感資訊相關，所以打碼。注意一下，如果模板還有其他的說明，可以在“檔名稱”後增加一欄：備註。
受眾物件：後臺開發人員。
許可權文件-後臺
做過後臺的都知道，一般後臺都會分角色登入，不同的角色許可權不一樣，能在後臺進行的操作也不一樣，輸出的這份文件主要是制定出各個角色對應的功能許可權、資料許可權。
注意事項：
- 確定平臺基本角色：超級管理員、管理員、運營部、產品部等等；
- 支援自定義角色；
- 特殊許可權需要在旁邊加上備註，不能下放。
受眾物件：後臺開發人員。
通用產物-校驗規則
這個文件作用是整個產品（前後端）資訊錄入過程中填寫不規範提示性文案的統一規則，在錄入資訊的過程中常見的一些例子（部分）：
- 輸入框預設顯示什麼？
- 輸入錯誤：提示什麼？
- 不輸入：提示什麼？
- 密碼錯誤提示什麼？
- ……
針對這個輸入資訊校驗，簡單分享一下，校驗分為前端校驗與後端校驗；前後端校驗的邏輯是不同的，這點有部分產品人員容易忽視。
下面我用最常見的登入頁面來簡單說明一下：
這下應該很容易前後端的校驗了。
受眾物件：前後端開發人員。
通用產物-簡訊模板
在特定的一些業務場景傳送相同的簡訊通知使用者，但是有個前提是，必須錄入了手機號才能傳送，它和push的區別就在於，站內信是隻要下載這款產品就能傳送push資訊通知，而傳送簡訊必須是有手機號。
方法：
- 梳理業務流程，梳理出哪些場景是需要傳送簡訊的節點；
- 梳理簡訊文案時；注意簡訊的內容的主次，核心表達的內容是什麼，輔助資訊是什麼等等；
- 並整理出文件；word/ excel格式都可以。
受眾物件：後臺開發人員。
培訓文件
操作手冊/功能指引（B端產品）
操作手冊是詳細描述產品的功能、使用者操作流程，使使用者瞭解到如何使用該軟體。這點就不多講了，就清楚產品是怎麼使用是講的，一些注意事項，這個不知道怎麼寫的，找百度。
受眾物件：使用者。
培訓PPT
產品上線，需要對公司內部的其他部門人員進行產品培訓，一般參與培訓的部門指：運營部、市場部、客服部等等。
哪些這個PPT應該怎麼去做了（站在目標人群的角度去製作）：
- 運營部：知道產品如何操作，業務流程應該怎麼操作；
- 市場部：需要做的產品的一些主要賣點；
- 客服部：需要做的產品如何操作，有哪些注意事項，等等；
這樣應該知道內部培訓PPT怎麼做了。
受眾物件：內部運營部、市場部、客服部等。
結尾
產物輸出只是專案開發中的一部分，如何讓專案如期保質保量落地，請期待下一篇：專案跟進去的白與黑。
相關閱讀
本文由 @微丶笑 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
