花了大概1年整理出一份全面通用的移動端產(chǎn)品需求文檔，包含了我多年產(chǎn)品經(jīng)驗以及對業(yè)務(wù)的理解，對技術(shù)原理的涉及。命名為浪子PRD1.0，請查看全文后再直達源網(wǎng)址。

這份PRD雖然內(nèi)容很全面通用，但是還不夠系統(tǒng)結(jié)構(gòu)化。所以才命名為1.0。首先希望對大家有幫助，其次希望大家給我提建議，然后可以不斷迭代到2.0、3.0……

營銷出身，先做運營，后轉(zhuǎn)產(chǎn)品，一直研究技術(shù)原理。做過B端、C端產(chǎn)品。做過PC client、Web產(chǎn)品、H5 app、原生app、多平臺產(chǎn)品?，F(xiàn)在做移動端社區(qū)電商APP的商城模塊。相信這樣的經(jīng)歷和大家應(yīng)該可以共鳴。

從網(wǎng)上學(xué)到了很多產(chǎn)品文章，最終自己也算是略有心得，所以特此回饋給大家。

先預(yù)覽一下PRD的結(jié)構(gòu)

一、畫原型的步驟

二、PRD撰寫原則

其實我覺得這個特別重要，但是偏理論了。

大原則

業(yè)務(wù)優(yōu)先于需求，需求優(yōu)先于功能，功能優(yōu)先于交互，交互優(yōu)先于UI。

PRD的目標

旨在對APP項目的業(yè)務(wù)架構(gòu)&產(chǎn)品流程&功能需求做詳細的介紹，為產(chǎn)品后續(xù)的需求、設(shè)計、開發(fā)、測試、上線提供依據(jù)。

• 向項目組成員(項目經(jīng)理、開發(fā)、測試、運營)傳達產(chǎn)品的業(yè)務(wù)信息與需求細節(jié)。
• 管理需求，進行歸檔，為后續(xù)需求迭代與變更提供依據(jù)。
• 實現(xiàn)項目的規(guī)范化管理。

PRD的撰寫說明

• 只有一種輸出物，在線原型。
• 只用原型傳達思想和表意，不過度考慮視覺呈現(xiàn)。
• 邏輯確定后不經(jīng)常改動，如有必要上線前統(tǒng)一和前端對照并修改。
• 內(nèi)容文案是否經(jīng)得起推敲，頂部標題以及按鈕文案以及各種小提示是否簡潔清晰。
• 內(nèi)容結(jié)構(gòu)：一級目錄使用”一”，二級目錄使用”1″，三級目錄使用”③”。
• 元件樣式和交互的通用規(guī)則，請寫到全局規(guī)范。其他寫到對應(yīng)的元件邏輯中。
• 寫的邏輯禁止不確定字樣(也許/可能/maybe/考慮/好像/類似/暫時/待定/等等/像/真的/？)
• 所有變量統(tǒng)一使用紅色表示并且配上說明，比如滿x元減x元。
• 英文單詞盡量小寫，易識別。除非是約定俗成的詞語，比如iOS、Android。
• 雙引號&單引號&小括號不使用全角，只有半角。

需求描述原則

• 表述清楚需求的位置是在什么位置，比如”x”頁面、還是”x”頁面的”x”元件。
• 需求是新增”x”功能、還是修復(fù)”x”bug、還是優(yōu)化”x”功能。

技術(shù)處理原則

• 某些場景下技術(shù)上可以考慮合并多步操作，以減少客戶端對于異常情況的判斷。比如確認訂單頁面的保存地址并返回運費。
• 某些警告框應(yīng)該當做頁面來處理數(shù)據(jù)埋點以及交互，單獨說明。
• 盡量解耦到每一個頁面，每一個警告框，而不是多個頁面之間關(guān)聯(lián)性太強。

PRD的核心模塊

• 頁面，寫在Axure的Pages中。生成原型后請點擊左側(cè)Pages進行查看。
• 交互，寫在Axure的Interaction中。生成原型后請點擊左側(cè)Pages中的鏈接圖標進行展示和隱藏。
• 邏輯，寫在Axure的Notes中。生成原型后請點擊左側(cè)Notes后查看，或者點擊右側(cè)元件旁邊的圖標進行查看。

元件的邏輯有5種，具體如下：

• 功能邏輯：詳細講解該功能的邏輯。
• 交互邏輯：對頁面之間的相互跳轉(zhuǎn)進行說明。
• 視覺邏輯：對顏色，對圖標的要求。
• 業(yè)務(wù)邏輯：講一下該功能對應(yīng)著什么業(yè)務(wù)。
• 技術(shù)邏輯：有些邏輯可能用技術(shù)語言描述更清楚一點，以及對技術(shù)有特殊的要求。

關(guān)于命名

• 動作，狀態(tài)的命名一定要區(qū)分，比如刪除是動作，已刪除才是狀態(tài)。
• 動作的命名一般是”操作+名詞”，比如修改文章。
• 條件的命名一般是是否怎么樣。
• 功能的命名要么是名詞，比如購物車；要么是動賓短語，比如確認訂單。

其他說明

• PD指產(chǎn)品經(jīng)理，產(chǎn)品設(shè)計師
• PM指項目經(jīng)理

三、PRD閱讀指南

四、產(chǎn)品工作流程

4.1、發(fā)布原型

4.2、制作H5

查看大圖

4.3、PD到UI

4.4、項目開發(fā)

4.5、處理BUG

所有問題都需要填寫注釋。

• 修復(fù)：簡要填寫問題原因，并說明如何修復(fù)
• 外部原因：寫清楚來源
• 無法重現(xiàn)：寫大概需要哪些條件
• 問題重復(fù)：填寫重復(fù)問題的bugid
• 功能設(shè)計如此：把功能邏輯鏈接到這里
• 是問題但不修復(fù)：補充不修復(fù)的理由
• 下版本解決：填寫大概解決時間，并在解決后指派給提出者驗證

4.6、軟件測試

4.7、UAT測試

五、PRD全局清單

六、內(nèi)稟原則

內(nèi)稟規(guī)則是什么？指業(yè)務(wù)實體本身具備的內(nèi)在規(guī)則，并且不受外部以及用例交互的影響。這類規(guī)則應(yīng)該實現(xiàn)到你的實體類中，根據(jù)面向?qū)ο蟮姆庋b原則，內(nèi)稟的邏輯一定不要讓它暴露到外部。不論你的業(yè)務(wù)實體是EntityBean，JavaBean，POJO還是COM+。

操作者是誰？程序員

如何獲得？需要對每個業(yè)務(wù)實體的屬性進行羅列，并找出它們的規(guī)則。最主要的來源是業(yè)務(wù)執(zhí)行者，需求人員應(yīng)該更多的去與他們交流。

6.1、時間

日期：yyyy-mm-dd

周幾：周一/周二/周三/周四/周五/周六/周日

時分：hh:mm

時分秒：hh:mm:ss

發(fā)布于什么時間：

• 適用于消息列表/消息詳情/動態(tài)列表/視頻列表/直播列表等feed流，詳見下方流程圖
• 當前時間取本機時間，有精力的話前端童鞋可加判斷，如果發(fā)現(xiàn)本地時間和服務(wù)器時間不一致，需做統(tǒng)一。

其他：

建議服務(wù)端按照時間戳來存儲，并且格式是yyyy-mm-dd hh:mm:ss

6.2、距離

一、絕對距離如何顯示

• xm，當距離＜1000米，比如356m
• xkm，≥1000米，比如5km
• 最小值是1m，最大值9999+km。

二、地理位置如何顯示

顯示格式”省份城市”，比如江蘇南通，如果取不到顯示”未知”。注意直轄市只顯示”直轄市名稱”。

6.3、賬號

什么是賬號？

用戶的唯一身份id

如何處理搶登？

當用戶使用手機a登錄了賬號，又去用手機b去同一賬號，從而形成搶登。

第一個手機收到推送，顯示警告框”該賬號已在其他手機登錄，如非本人請趕緊登錄然后修改密碼。”和確定按鈕，點擊確定按鈕回到App首頁并重新加載。

其他

• 身份證號必須是15或18位
• 手機號必須是11位

七、交互規(guī)則

交互規(guī)則是什么？產(chǎn)生于用例場景當中，規(guī)定了滿足什么條件后業(yè)務(wù)將如何反應(yīng)。比如當提交一份訂單時，哪些數(shù)據(jù)是必須填寫的，用戶身份是否合法。當然也包括一般理解上的業(yè)務(wù)流程流轉(zhuǎn)規(guī)則等，比如金額大于一萬元的訂單被定為VIP訂單進入特殊流程等。

交互規(guī)則實際上還有兩個是比較特殊的，一個是前置條件（入口條件），即Actor滿足什么條件才能啟動用例；另一個是后置條件（出口條件），即用例結(jié)束后會產(chǎn)生哪些后果。通常這部分規(guī)則是復(fù)雜多變不穩(wěn)定，所謂的需求經(jīng)常變更絕大部分來自于此。因此將這些規(guī)則單獨列出來并給予關(guān)注和管理是很有必要的。同時這部分規(guī)則通常在系統(tǒng)中以Control類去實現(xiàn)，MVC模式/SOA架構(gòu)中的BPEL也是如此。既然需求無可避免的要變更，那么將交互規(guī)則單獨提取出來，并設(shè)計成為擴展性很強的結(jié)構(gòu)就是一種有效的應(yīng)對手段。

操作者是誰？交互設(shè)計師or產(chǎn)品經(jīng)理

如何獲得？從用例場景而來，每一個場景，每一個交互的過程可能都隱含著規(guī)則。需要與客戶多討論。交互規(guī)則最主要的來源是業(yè)務(wù)提出者和業(yè)務(wù)管理者，最好不要去找業(yè)務(wù)執(zhí)行者。

7.1、狀態(tài)切換

7.2、常用輸入字段

7.3、邊界問題

需要處理的異常邊界

異常處理一般來說，PM還是會非常重視的。比如購物車商品減到0需要提醒用戶二次確認是否把商品從購物車去掉、或者用戶輸入的密碼不符合規(guī)范，需要提醒用戶調(diào)整。這些很多異常情況，PM是需要把自己放空，通過很多非正常交互流程去模擬和梳理的。比如購買流程不可逆，此時用戶想點返回了，哪一步是可以到上一步，哪一步到不了上一步，這些就是交互設(shè)計的細節(jié)。

7.4、交互常見十二狀態(tài)

八、全局規(guī)則

全局規(guī)則是什么？通常與所有用例相關(guān)，而不是與特定用例相關(guān)。所以應(yīng)該抽象出來讓系統(tǒng)去負責(zé)這些特性的實現(xiàn)。比如Actor要給朋友發(fā)圖片以及在朋友圈發(fā)圖片用例必須獲得相應(yīng)的授權(quán)，或者用戶在系統(tǒng)中的所有操作都要被記錄下來等等。

授權(quán)，事務(wù)，備份等這些全局特性都是由系統(tǒng)框架去實現(xiàn)的，具體的功能中只是調(diào)用而不再實現(xiàn)它們。

操作者是誰？架構(gòu)師or產(chǎn)品總監(jiān)

如何獲得？很難從用戶處調(diào)研得來，通常這方面是用戶的盲點。主要是由有經(jīng)驗的系統(tǒng)分析員，或架構(gòu)師以及客戶方的IT部門，從業(yè)務(wù)特點、應(yīng)用環(huán)境、行業(yè)規(guī)定、法律規(guī)章等等方面去總結(jié)，再求得客戶方的認可。

8.1、啟動

自動刷新的時間差取決于你們的業(yè)務(wù)本身，但是也需要考慮服務(wù)器的承載問題。

iOS系統(tǒng)有后臺喚醒自動刷新的方法，時間差由系統(tǒng)決定，僅需RD調(diào)用此方法即可。

Android可以根據(jù)判斷此次打開和上次刷新的時間差，超過產(chǎn)品設(shè)定的時間差就自動刷新。

說明哪些地方從后臺切換回前臺時需要進行數(shù)據(jù)更新。

只列出需要考慮的場景，iOS只有系統(tǒng)級別的事件處理。當APP從在后臺回到前臺，請展示上次打開應(yīng)用的快照然后自動刷新該頁面。

以上事件中，刷新當前頁面之前加一個鉤子，判斷該頁面是由經(jīng)常更新的模塊或者列表構(gòu)成，具體可咨詢PD。

鉤子的具體解釋最好百度一下，有點像預(yù)先留下伏筆然后通過這個判斷是否需要回調(diào)刷新頁面數(shù)據(jù)的事件。

8.2、授權(quán)

查看大圖

8.3、手勢

8.5、頁面

8.4、頁面類型

8.5、啟動頁

8.6、閃屏頁

8.7、故事板

8.8、主界面

8.9、頁面狀態(tài)

8.10、頁面間轉(zhuǎn)場

8.11、頁面加載類型

查看大圖

8.12、頁面刷新類型

8.13、圖片

查看大圖

九、非功能性需求

9.1、網(wǎng)絡(luò)需求

處于不穩(wěn)定網(wǎng)絡(luò)狀態(tài)：比如在走動中，地鐵火車上

當切換網(wǎng)絡(luò)時：比如有無wifi連接/有無有線網(wǎng)絡(luò)/手機wifi和有線網(wǎng)絡(luò)互切/飛行模式

視頻播放場景：比較特殊，點擊查看詳情

9.2、數(shù)據(jù)需求

新舊數(shù)據(jù)沖突：

1、重要

• 客服告訴客戶什么時候數(shù)據(jù)遷移完成，能否接受。
• 用戶主動，停止服務(wù)，告訴用戶可以保存到什么時候，讓用戶自己主動備份。
• 用戶被動，數(shù)據(jù)遷移到哪里去，給個能找到數(shù)據(jù)的入口。

2、重要但又不那么必要

• 導(dǎo)出數(shù)據(jù)給到客戶
• 客服和客戶進行協(xié)商
• 只要敢就可以沒有

數(shù)據(jù)內(nèi)容過期/刪除/違禁后如何展示/產(chǎn)品售罄下架：

1、內(nèi)容過期

• 告訴用戶過期時間，比如微信紅包
• 相關(guān)內(nèi)容關(guān)聯(lián)推薦
• 專題類/活動類的下次開始什么時候

2、刪除

手段同內(nèi)容過期

3、違禁后如何展示

告訴用戶我們產(chǎn)品的態(tài)度，違禁原因，保護產(chǎn)品生態(tài)人人有則，即使用戶之前看過/收藏過，這是原則。

數(shù)據(jù)內(nèi)容展示/更新機制：

• 冷啟動數(shù)據(jù)(極其不常用，不想影響安裝包大小)，打在安裝包里，不變的產(chǎn)品架構(gòu)可以先緩存進去
• 需要說明哪些地方需要手動刷新？哪些地方需要自動刷新？(再次進入頁面時刷新；設(shè)定一個時間值每隔一段時間刷新)一個時間值哪些地方是手動+自動刷新
• 說明哪些地方從后臺切換回前臺時需要進行數(shù)據(jù)更新？
• 需要說明哪些內(nèi)容需要實時更新，哪些需要定時更新？
• 說明數(shù)據(jù)展示部分的處理邏輯，是每次從服務(wù)端請求，還是緩存到本地。
• 用戶更新或者上傳操作時，是否顯示進度。
• 數(shù)據(jù)多維度排序規(guī)則
• 時間，信息流淚產(chǎn)品，微博/微信
• 流覽/贊/收藏，推薦/搜索常用

數(shù)據(jù)處理：

• 閃退后數(shù)據(jù)是否丟失
• 卸載刪除軟件數(shù)據(jù)如何處理
• 數(shù)據(jù)安全
• 數(shù)據(jù)存儲極限/跨平臺同步
• 數(shù)據(jù)被移除時會發(fā)生的情況
• 數(shù)據(jù)過多或者過少數(shù)據(jù)需求導(dǎo)致布局和UI的改變
• 在不同時段/不同數(shù)據(jù)權(quán)限數(shù)據(jù)推薦顯示機制
• 如何處理大量數(shù)據(jù)
• 數(shù)據(jù)同步被打斷
• 數(shù)據(jù)或架構(gòu)更新時會造成影響
• 無效數(shù)據(jù)的處理

數(shù)據(jù)版權(quán)：

用的別人數(shù)據(jù)是否有數(shù)據(jù)來源等版權(quán)說明

9.3、性能需求

耗電情況：

不停與服務(wù)器交互數(shù)據(jù)，尤其是首頁各個業(yè)務(wù)都想顯示自己的數(shù)據(jù)，產(chǎn)品經(jīng)理要權(quán)衡克制。

流量：

• 不停與服務(wù)器交互數(shù)據(jù)，尤其是首頁各個業(yè)務(wù)都想顯示自己的數(shù)據(jù)，產(chǎn)品經(jīng)理要權(quán)衡克制。
• 多用wifi條件下自動緩存，設(shè)置上限即可。
• 是否需要提供流量包。

大并發(fā)：

• 整體最大能支持多少人同時訪問
• 指定功能最大能支持多少人同時訪問
• 大促活動最大能支持多少人同時訪問

需要考慮：

• 舊功能更新，根據(jù)以往數(shù)據(jù)和增量估算
• 新產(chǎn)品/新功能，O2O根據(jù)線下的量進行估算
• 新產(chǎn)品/新功能，給的流量入口的進行估算

訪問速度：

訪問速度達到多少

其他：

前端閱讀頁面以及列表頁面，需滾動流暢，滾動閱讀時不停頓不卡頓。后臺數(shù)據(jù)處理能力應(yīng)滿足幾十萬用戶的操作使用。更改與設(shè)置密碼與手機號時，后臺應(yīng)立即發(fā)出短信。

9.4、安全需求

是否已加固：

APP安裝包是否加固過，是否符合應(yīng)用市場的安全規(guī)則。

是否已混淆代碼：

APP安裝包是否混淆過代碼，以防被競品開發(fā)者破解其代碼。

是否符合法規(guī)：

產(chǎn)品需符合網(wǎng)絡(luò)安全部的相關(guān)規(guī)定。

數(shù)據(jù)安全性說明是否完整：

輸人的密碼將不以明文形式進行顯示，備份應(yīng)該加密，恢復(fù)數(shù)據(jù)應(yīng)考慮恢復(fù)過程的異常通訊中斷等。

9.5、兼容需求

考慮不同屏幕的兼容性：

原則是根據(jù)主流機型給出優(yōu)先級。

考慮不同系統(tǒng)的兼容性：

比如iOS系統(tǒng)中目前主流系統(tǒng)有iOS8、iOS9、iOS10三大類。

Android系統(tǒng)中就更分散了。

考慮是否支持橫豎屏切換：

如果支持，也存在屏幕內(nèi)容兼容問題。

9.6、后臺需求

接口數(shù)據(jù)：

第3方SDK

內(nèi)部數(shù)據(jù)

Push消息：

什么時間向什么要push什么內(nèi)容消息等等，一定要考慮服務(wù)器。

自己做，還是采用第3方，比如環(huán)信、極光、融云…

前后端數(shù)據(jù)延遲：

有時前端功能與后端、服務(wù)器因時延會導(dǎo)致進度不匹配

客戶端與服務(wù)器交互失敗：

任務(wù)提交失敗與服務(wù)器通訊失敗

新數(shù)據(jù)覆蓋舊數(shù)據(jù)：

如果涉及到修改底層字段或者表結(jié)構(gòu)，該怎么兼容老版本的客戶端。

9.7、其他需求

短信通道
登錄注冊/支付狀態(tài)一定要走高速通道，活動類可以走低速通道。

支付通道
直接對接支付寶、微信。還是采用中轉(zhuǎn)的ping++。

郵件服務(wù)
采用自己開發(fā)的，還是第三方的webpower…

分享
點對點分享和分享到朋友圈文案和圖片顯示。

各種服務(wù)電話
最好在產(chǎn)品里面留一個用戶聯(lián)系官方的渠道，不管是電話還是郵件還是私信。

十、APP開發(fā)前期準備

框架生成：

• 制作需求溝通確認
• 管理平臺開戶
• 雙版本APP框架輸出
• APP內(nèi)容架構(gòu)組織

設(shè)計制作：

• APP界面設(shè)計
• APP素材收集與加工
• APP圖標設(shè)計
• APP內(nèi)容制作上傳
• 客戶確認

測試調(diào)優(yōu)：

• APP內(nèi)容測試
• APP性能測試
• APP功能測試
• APP視覺測試

APP發(fā)布：

• APPstore發(fā)布
• 主流安卓市場發(fā)布
• APP下載頁(web/wap)
• 二維碼生成
• APP應(yīng)用手冊
• 企業(yè)APP交付

10.1、用戶環(huán)境

10.2、開發(fā)環(huán)境

10.3、單頁&多頁H5應(yīng)用

10.4、Web&Mobile區(qū)別

10.5、Native&H5的區(qū)別

十一、版本記錄

11.1、里程碑

11.2、發(fā)布準備

十二、項目概覽

12.1、使用SDK

12.2、分享APP

12.3、項目數(shù)據(jù)

最后，如果覺得有用，請點贊。如果覺得有問題，請評論。查看以上所有內(nèi)容可以點擊我的原型地址http://51prd.com。

 

作者：浪子，個人公眾號langzisay。業(yè)務(wù)型產(chǎn)品經(jīng)理，3年社交+4年電商的工作經(jīng)驗。

本文由 @浪子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。