起點(diǎn)課堂會(huì)員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會(huì)特權(quán)
個(gè)人IP打造特權(quán)
30+門專項(xiàng)技能課
1300+專題課程
12場(chǎng)職場(chǎng)軟技能直播
12場(chǎng)求職輔導(dǎo)直播
12場(chǎng)專業(yè)技能直播
會(huì)員專屬社群
榮耀標(biāo)識(shí)PRD1.0分享：全面通用的移動(dòng)端產(chǎn)品需求文檔
花了大概1年整理出一份全面通用的移動(dòng)端產(chǎn)品需求文檔，包含了我多年產(chǎn)品經(jīng)驗(yàn)以及對(duì)業(yè)務(wù)的理解，對(duì)技術(shù)原理的涉及。命名為浪子PRD1.0，請(qǐng)查看全文后再直達(dá)源網(wǎng)址。
這份PRD雖然內(nèi)容很全面通用，但是還不夠系統(tǒng)結(jié)構(gòu)化。所以才命名為1.0。首先希望對(duì)大家有幫助，其次希望大家給我提建議，然后可以不斷迭代到2.0、3.0……
營(yíng)銷出身，先做運(yùn)營(yíng)，后轉(zhuǎn)產(chǎn)品，一直研究技術(shù)原理。做過B端、C端產(chǎn)品。做過PC client、Web產(chǎn)品、H5 app、原生app、多平臺(tái)產(chǎn)品?，F(xiàn)在做移動(dòng)端社區(qū)電商APP的商城模塊。相信這樣的經(jīng)歷和大家應(yīng)該可以共鳴。
從網(wǎng)上學(xué)到了很多產(chǎn)品文章，最終自己也算是略有心得，所以特此回饋給大家。
先預(yù)覽一下PRD的結(jié)構(gòu)
一、畫原型的步驟
二、PRD撰寫原則
其實(shí)我覺得這個(gè)特別重要，但是偏理論了。
大原則
業(yè)務(wù)優(yōu)先于需求，需求優(yōu)先于功能，功能優(yōu)先于交互，交互優(yōu)先于UI。
PRD的目標(biāo)
旨在對(duì)APP項(xiàng)目的業(yè)務(wù)架構(gòu)&產(chǎn)品流程&功能需求做詳細(xì)的介紹，為產(chǎn)品后續(xù)的需求、設(shè)計(jì)、開發(fā)、測(cè)試、上線提供依據(jù)。
- 向項(xiàng)目組成員(項(xiàng)目經(jīng)理、開發(fā)、測(cè)試、運(yùn)營(yíng))傳達(dá)產(chǎn)品的業(yè)務(wù)信息與需求細(xì)節(jié)。
- 管理需求，進(jìn)行歸檔，為后續(xù)需求迭代與變更提供依據(jù)。
- 實(shí)現(xiàn)項(xiàng)目的規(guī)范化管理。
PRD的撰寫說明
- 只有一種輸出物，在線原型。
- 只用原型傳達(dá)思想和表意，不過度考慮視覺呈現(xiàn)。
- 邏輯確定后不經(jīng)常改動(dòng)，如有必要上線前統(tǒng)一和前端對(duì)照并修改。
- 內(nèi)容文案是否經(jīng)得起推敲，頂部標(biāo)題以及按鈕文案以及各種小提示是否簡(jiǎn)潔清晰。
- 內(nèi)容結(jié)構(gòu)：一級(jí)目錄使用”一”，二級(jí)目錄使用”1″，三級(jí)目錄使用”③”。
- 元件樣式和交互的通用規(guī)則，請(qǐng)寫到全局規(guī)范。其他寫到對(duì)應(yīng)的元件邏輯中。
- 寫的邏輯禁止不確定字樣(也許/可能/maybe/考慮/好像/類似/暫時(shí)/待定/等等/像/真的/？)
- 所有變量統(tǒng)一使用紅色表示并且配上說明，比如滿x元減x元。
- 英文單詞盡量小寫，易識(shí)別。除非是約定俗成的詞語(yǔ)，比如iOS、Android。
- 雙引號(hào)&單引號(hào)&小括號(hào)不使用全角，只有半角。
需求描述原則
- 表述清楚需求的位置是在什么位置，比如”x”頁(yè)面、還是”x”頁(yè)面的”x”元件。
- 需求是新增”x”功能、還是修復(fù)”x”bug、還是優(yōu)化”x”功能。
技術(shù)處理原則
- 某些場(chǎng)景下技術(shù)上可以考慮合并多步操作，以減少客戶端對(duì)于異常情況的判斷。比如確認(rèn)訂單頁(yè)面的保存地址并返回運(yùn)費(fèi)。
- 某些警告框應(yīng)該當(dāng)做頁(yè)面來處理數(shù)據(jù)埋點(diǎn)以及交互，單獨(dú)說明。
- 盡量解耦到每一個(gè)頁(yè)面，每一個(gè)警告框，而不是多個(gè)頁(yè)面之間關(guān)聯(lián)性太強(qiáng)。
PRD的核心模塊
- 頁(yè)面，寫在Axure的Pages中。生成原型后請(qǐng)點(diǎn)擊左側(cè)Pages進(jìn)行查看。
- 交互，寫在Axure的Interaction中。生成原型后請(qǐng)點(diǎn)擊左側(cè)Pages中的鏈接圖標(biāo)進(jìn)行展示和隱藏。
- 邏輯，寫在Axure的Notes中。生成原型后請(qǐng)點(diǎn)擊左側(cè)Notes后查看，或者點(diǎn)擊右側(cè)元件旁邊的圖標(biāo)進(jìn)行查看。
元件的邏輯有5種，具體如下：
- 功能邏輯：詳細(xì)講解該功能的邏輯。
- 交互邏輯：對(duì)頁(yè)面之間的相互跳轉(zhuǎn)進(jìn)行說明。
- 視覺邏輯：對(duì)顏色，對(duì)圖標(biāo)的要求。
- 業(yè)務(wù)邏輯：講一下該功能對(duì)應(yīng)著什么業(yè)務(wù)。
- 技術(shù)邏輯：有些邏輯可能用技術(shù)語(yǔ)言描述更清楚一點(diǎn)，以及對(duì)技術(shù)有特殊的要求。
關(guān)于命名
- 動(dòng)作，狀態(tài)的命名一定要區(qū)分，比如刪除是動(dòng)作，已刪除才是狀態(tài)。
- 動(dòng)作的命名一般是”操作+名詞”，比如修改文章。
- 條件的命名一般是是否怎么樣。
- 功能的命名要么是名詞，比如購(gòu)物車；要么是動(dòng)賓短語(yǔ)，比如確認(rèn)訂單。
其他說明
- PD指產(chǎn)品經(jīng)理，產(chǎn)品設(shè)計(jì)師
- PM指項(xiàng)目經(jīng)理
三、PRD閱讀指南
四、產(chǎn)品工作流程
4.1、發(fā)布原型
4.2、制作H5
4.3、PD到UI
4.4、項(xiàng)目開發(fā)
4.5、處理BUG
所有問題都需要填寫注釋。
- 修復(fù)：簡(jiǎn)要填寫問題原因，并說明如何修復(fù)
- 外部原因：寫清楚來源
- 無法重現(xiàn)：寫大概需要哪些條件
- 問題重復(fù)：填寫重復(fù)問題的bugid
- 功能設(shè)計(jì)如此：把功能邏輯鏈接到這里
- 是問題但不修復(fù)：補(bǔ)充不修復(fù)的理由
- 下版本解決：填寫大概解決時(shí)間，并在解決后指派給提出者驗(yàn)證
4.6、軟件測(cè)試
4.7、UAT測(cè)試
五、PRD全局清單
六、內(nèi)稟原則
內(nèi)稟規(guī)則是什么？指業(yè)務(wù)實(shí)體本身具備的內(nèi)在規(guī)則，并且不受外部以及用例交互的影響。這類規(guī)則應(yīng)該實(shí)現(xiàn)到你的實(shí)體類中，根據(jù)面向?qū)ο蟮姆庋b原則，內(nèi)稟的邏輯一定不要讓它暴露到外部。不論你的業(yè)務(wù)實(shí)體是EntityBean，JavaBean，POJO還是COM+。
操作者是誰(shuí)？程序員
如何獲得？需要對(duì)每個(gè)業(yè)務(wù)實(shí)體的屬性進(jìn)行羅列，并找出它們的規(guī)則。最主要的來源是業(yè)務(wù)執(zhí)行者，需求人員應(yīng)該更多的去與他們交流。
6.1、時(shí)間
日期：yyyy-mm-dd
周幾：周一/周二/周三/周四/周五/周六/周日
時(shí)分：hh:mm
時(shí)分秒：hh:mm:ss
發(fā)布于什么時(shí)間：
- 適用于消息列表/消息詳情/動(dòng)態(tài)列表/視頻列表/直播列表等feed流，詳見下方流程圖
- 當(dāng)前時(shí)間取本機(jī)時(shí)間，有精力的話前端童鞋可加判斷，如果發(fā)現(xiàn)本地時(shí)間和服務(wù)器時(shí)間不一致，需做統(tǒng)一。
其他：
建議服務(wù)端按照時(shí)間戳來存儲(chǔ)，并且格式是yyyy-mm-dd hh:mm:ss
6.2、距離
一、絕對(duì)距離如何顯示
- xm，當(dāng)距離＜1000米，比如356m
- xkm，≥1000米，比如5km
- 最小值是1m，最大值9999+km。
二、地理位置如何顯示
顯示格式”省份城市”，比如江蘇南通，如果取不到顯示”未知”。注意直轄市只顯示”直轄市名稱”。
6.3、賬號(hào)
什么是賬號(hào)？
用戶的唯一身份id
如何處理?yè)尩牵?/strong>
當(dāng)用戶使用手機(jī)a登錄了賬號(hào)，又去用手機(jī)b去同一賬號(hào)，從而形成搶登。
第一個(gè)手機(jī)收到推送，顯示警告框”該賬號(hào)已在其他手機(jī)登錄，如非本人請(qǐng)趕緊登錄然后修改密碼。”和確定按鈕，點(diǎn)擊確定按鈕回到App首頁(yè)并重新加載。
其他
- 身份證號(hào)必須是15或18位
- 手機(jī)號(hào)必須是11位
七、交互規(guī)則
交互規(guī)則是什么？產(chǎn)生于用例場(chǎng)景當(dāng)中，規(guī)定了滿足什么條件后業(yè)務(wù)將如何反應(yīng)。比如當(dāng)提交一份訂單時(shí)，哪些數(shù)據(jù)是必須填寫的，用戶身份是否合法。當(dāng)然也包括一般理解上的業(yè)務(wù)流程流轉(zhuǎn)規(guī)則等，比如金額大于一萬元的訂單被定為VIP訂單進(jìn)入特殊流程等。
交互規(guī)則實(shí)際上還有兩個(gè)是比較特殊的，一個(gè)是前置條件（入口條件），即Actor滿足什么條件才能啟動(dòng)用例；另一個(gè)是后置條件（出口條件），即用例結(jié)束后會(huì)產(chǎn)生哪些后果。通常這部分規(guī)則是復(fù)雜多變不穩(wěn)定，所謂的需求經(jīng)常變更絕大部分來自于此。因此將這些規(guī)則單獨(dú)列出來并給予關(guān)注和管理是很有必要的。同時(shí)這部分規(guī)則通常在系統(tǒng)中以Control類去實(shí)現(xiàn)，MVC模式/SOA架構(gòu)中的BPEL也是如此。既然需求無可避免的要變更，那么將交互規(guī)則單獨(dú)提取出來，并設(shè)計(jì)成為擴(kuò)展性很強(qiáng)的結(jié)構(gòu)就是一種有效的應(yīng)對(duì)手段。
操作者是誰(shuí)？交互設(shè)計(jì)師or產(chǎn)品經(jīng)理
如何獲得？從用例場(chǎng)景而來，每一個(gè)場(chǎng)景，每一個(gè)交互的過程可能都隱含著規(guī)則。需要與客戶多討論。交互規(guī)則最主要的來源是業(yè)務(wù)提出者和業(yè)務(wù)管理者，最好不要去找業(yè)務(wù)執(zhí)行者。
7.1、狀態(tài)切換
7.2、常用輸入字段
7.3、邊界問題
需要處理的異常邊界
異常處理一般來說，PM還是會(huì)非常重視的。比如購(gòu)物車商品減到0需要提醒用戶二次確認(rèn)是否把商品從購(gòu)物車去掉、或者用戶輸入的密碼不符合規(guī)范，需要提醒用戶調(diào)整。這些很多異常情況，PM是需要把自己放空，通過很多非正常交互流程去模擬和梳理的。比如購(gòu)買流程不可逆，此時(shí)用戶想點(diǎn)返回了，哪一步是可以到上一步，哪一步到不了上一步，這些就是交互設(shè)計(jì)的細(xì)節(jié)。
7.4、交互常見十二狀態(tài)
八、全局規(guī)則
全局規(guī)則是什么？通常與所有用例相關(guān)，而不是與特定用例相關(guān)。所以應(yīng)該抽象出來讓系統(tǒng)去負(fù)責(zé)這些特性的實(shí)現(xiàn)。比如Actor要給朋友發(fā)圖片以及在朋友圈發(fā)圖片用例必須獲得相應(yīng)的授權(quán)，或者用戶在系統(tǒng)中的所有操作都要被記錄下來等等。
授權(quán)，事務(wù)，備份等這些全局特性都是由系統(tǒng)框架去實(shí)現(xiàn)的，具體的功能中只是調(diào)用而不再實(shí)現(xiàn)它們。
操作者是誰(shuí)？架構(gòu)師or產(chǎn)品總監(jiān)
如何獲得？很難從用戶處調(diào)研得來，通常這方面是用戶的盲點(diǎn)。主要是由有經(jīng)驗(yàn)的系統(tǒng)分析員，或架構(gòu)師以及客戶方的IT部門，從業(yè)務(wù)特點(diǎn)、應(yīng)用環(huán)境、行業(yè)規(guī)定、法律規(guī)章等等方面去總結(jié)，再求得客戶方的認(rèn)可。
8.1、啟動(dòng)
自動(dòng)刷新的時(shí)間差取決于你們的業(yè)務(wù)本身，但是也需要考慮服務(wù)器的承載問題。
iOS系統(tǒng)有后臺(tái)喚醒自動(dòng)刷新的方法，時(shí)間差由系統(tǒng)決定，僅需RD調(diào)用此方法即可。
Android可以根據(jù)判斷此次打開和上次刷新的時(shí)間差，超過產(chǎn)品設(shè)定的時(shí)間差就自動(dòng)刷新。
說明哪些地方從后臺(tái)切換回前臺(tái)時(shí)需要進(jìn)行數(shù)據(jù)更新。
只列出需要考慮的場(chǎng)景，iOS只有系統(tǒng)級(jí)別的事件處理。當(dāng)APP從在后臺(tái)回到前臺(tái)，請(qǐng)展示上次打開應(yīng)用的快照然后自動(dòng)刷新該頁(yè)面。
以上事件中，刷新當(dāng)前頁(yè)面之前加一個(gè)鉤子，判斷該頁(yè)面是由經(jīng)常更新的模塊或者列表構(gòu)成，具體可咨詢PD。
鉤子的具體解釋最好百度一下，有點(diǎn)像預(yù)先留下伏筆然后通過這個(gè)判斷是否需要回調(diào)刷新頁(yè)面數(shù)據(jù)的事件。
8.2、授權(quán)
8.3、手勢(shì)
8.5、頁(yè)面
8.4、頁(yè)面類型
8.5、啟動(dòng)頁(yè)
8.6、閃屏頁(yè)
8.7、故事板
8.8、主界面
8.9、頁(yè)面狀態(tài)
8.10、頁(yè)面間轉(zhuǎn)場(chǎng)
8.11、頁(yè)面加載類型
8.12、頁(yè)面刷新類型
8.13、圖片
九、非功能性需求
9.1、網(wǎng)絡(luò)需求
處于不穩(wěn)定網(wǎng)絡(luò)狀態(tài)：比如在走動(dòng)中，地鐵火車上
當(dāng)切換網(wǎng)絡(luò)時(shí)：比如有無wifi連接/有無有線網(wǎng)絡(luò)/手機(jī)wifi和有線網(wǎng)絡(luò)互切/飛行模式
視頻播放場(chǎng)景：比較特殊，點(diǎn)擊查看詳情
9.2、數(shù)據(jù)需求
新舊數(shù)據(jù)沖突：
1、重要
- 客服告訴客戶什么時(shí)候數(shù)據(jù)遷移完成，能否接受。
- 用戶主動(dòng)，停止服務(wù)，告訴用戶可以保存到什么時(shí)候，讓用戶自己主動(dòng)備份。
- 用戶被動(dòng)，數(shù)據(jù)遷移到哪里去，給個(gè)能找到數(shù)據(jù)的入口。
2、重要但又不那么必要
- 導(dǎo)出數(shù)據(jù)給到客戶
- 客服和客戶進(jìn)行協(xié)商
- 只要敢就可以沒有
數(shù)據(jù)內(nèi)容過期/刪除/違禁后如何展示/產(chǎn)品售罄下架：
1、內(nèi)容過期
- 告訴用戶過期時(shí)間，比如微信紅包
- 相關(guān)內(nèi)容關(guān)聯(lián)推薦
- 專題類/活動(dòng)類的下次開始什么時(shí)候
2、刪除
手段同內(nèi)容過期
3、違禁后如何展示
告訴用戶我們產(chǎn)品的態(tài)度，違禁原因，保護(hù)產(chǎn)品生態(tài)人人有則，即使用戶之前看過/收藏過，這是原則。
數(shù)據(jù)內(nèi)容展示/更新機(jī)制：
- 冷啟動(dòng)數(shù)據(jù)(極其不常用，不想影響安裝包大小)，打在安裝包里，不變的產(chǎn)品架構(gòu)可以先緩存進(jìn)去
- 需要說明哪些地方需要手動(dòng)刷新？哪些地方需要自動(dòng)刷新？(再次進(jìn)入頁(yè)面時(shí)刷新；設(shè)定一個(gè)時(shí)間值每隔一段時(shí)間刷新)一個(gè)時(shí)間值哪些地方是手動(dòng)+自動(dòng)刷新
- 說明哪些地方從后臺(tái)切換回前臺(tái)時(shí)需要進(jìn)行數(shù)據(jù)更新？
- 需要說明哪些內(nèi)容需要實(shí)時(shí)更新，哪些需要定時(shí)更新？
- 說明數(shù)據(jù)展示部分的處理邏輯，是每次從服務(wù)端請(qǐng)求，還是緩存到本地。
- 用戶更新或者上傳操作時(shí)，是否顯示進(jìn)度。
- 數(shù)據(jù)多維度排序規(guī)則
- 時(shí)間，信息流淚產(chǎn)品，微博/微信
- 流覽/贊/收藏，推薦/搜索常用
數(shù)據(jù)處理：
- 閃退后數(shù)據(jù)是否丟失
- 卸載刪除軟件數(shù)據(jù)如何處理
- 數(shù)據(jù)安全
- 數(shù)據(jù)存儲(chǔ)極限/跨平臺(tái)同步
- 數(shù)據(jù)被移除時(shí)會(huì)發(fā)生的情況
- 數(shù)據(jù)過多或者過少數(shù)據(jù)需求導(dǎo)致布局和UI的改變
- 在不同時(shí)段/不同數(shù)據(jù)權(quán)限數(shù)據(jù)推薦顯示機(jī)制
- 如何處理大量數(shù)據(jù)
- 數(shù)據(jù)同步被打斷
- 數(shù)據(jù)或架構(gòu)更新時(shí)會(huì)造成影響
- 無效數(shù)據(jù)的處理
數(shù)據(jù)版權(quán)：
用的別人數(shù)據(jù)是否有數(shù)據(jù)來源等版權(quán)說明
9.3、性能需求
耗電情況：
不停與服務(wù)器交互數(shù)據(jù)，尤其是首頁(yè)各個(gè)業(yè)務(wù)都想顯示自己的數(shù)據(jù)，產(chǎn)品經(jīng)理要權(quán)衡克制。
流量：
- 不停與服務(wù)器交互數(shù)據(jù)，尤其是首頁(yè)各個(gè)業(yè)務(wù)都想顯示自己的數(shù)據(jù)，產(chǎn)品經(jīng)理要權(quán)衡克制。
- 多用wifi條件下自動(dòng)緩存，設(shè)置上限即可。
- 是否需要提供流量包。
大并發(fā)：
- 整體最大能支持多少人同時(shí)訪問
- 指定功能最大能支持多少人同時(shí)訪問
- 大促活動(dòng)最大能支持多少人同時(shí)訪問
需要考慮：
- 舊功能更新，根據(jù)以往數(shù)據(jù)和增量估算
- 新產(chǎn)品/新功能，O2O根據(jù)線下的量進(jìn)行估算
- 新產(chǎn)品/新功能，給的流量入口的進(jìn)行估算
訪問速度：
訪問速度達(dá)到多少
其他：
前端閱讀頁(yè)面以及列表頁(yè)面，需滾動(dòng)流暢，滾動(dòng)閱讀時(shí)不停頓不卡頓。后臺(tái)數(shù)據(jù)處理能力應(yīng)滿足幾十萬用戶的操作使用。更改與設(shè)置密碼與手機(jī)號(hào)時(shí)，后臺(tái)應(yīng)立即發(fā)出短信。
9.4、安全需求
是否已加固：
APP安裝包是否加固過，是否符合應(yīng)用市場(chǎng)的安全規(guī)則。
是否已混淆代碼：
APP安裝包是否混淆過代碼，以防被競(jìng)品開發(fā)者破解其代碼。
是否符合法規(guī)：
產(chǎn)品需符合網(wǎng)絡(luò)安全部的相關(guān)規(guī)定。
數(shù)據(jù)安全性說明是否完整：
輸人的密碼將不以明文形式進(jìn)行顯示，備份應(yīng)該加密，恢復(fù)數(shù)據(jù)應(yīng)考慮恢復(fù)過程的異常通訊中斷等。
9.5、兼容需求
考慮不同屏幕的兼容性：
原則是根據(jù)主流機(jī)型給出優(yōu)先級(jí)。
考慮不同系統(tǒng)的兼容性：
比如iOS系統(tǒng)中目前主流系統(tǒng)有iOS8、iOS9、iOS10三大類。
Android系統(tǒng)中就更分散了。
考慮是否支持橫豎屏切換：
如果支持，也存在屏幕內(nèi)容兼容問題。
9.6、后臺(tái)需求
接口數(shù)據(jù)：
第3方SDK
內(nèi)部數(shù)據(jù)
Push消息：
什么時(shí)間向什么要push什么內(nèi)容消息等等，一定要考慮服務(wù)器。
自己做，還是采用第3方，比如環(huán)信、極光、融云…
前后端數(shù)據(jù)延遲：
有時(shí)前端功能與后端、服務(wù)器因時(shí)延會(huì)導(dǎo)致進(jìn)度不匹配
客戶端與服務(wù)器交互失?。?/strong>
任務(wù)提交失敗與服務(wù)器通訊失敗
新數(shù)據(jù)覆蓋舊數(shù)據(jù)：
如果涉及到修改底層字段或者表結(jié)構(gòu)，該怎么兼容老版本的客戶端。
9.7、其他需求
短信通道
登錄注冊(cè)/支付狀態(tài)一定要走高速通道，活動(dòng)類可以走低速通道。
支付通道
直接對(duì)接支付寶、微信。還是采用中轉(zhuǎn)的ping++。
郵件服務(wù)
采用自己開發(fā)的，還是第三方的webpower…
分享
點(diǎn)對(duì)點(diǎn)分享和分享到朋友圈文案和圖片顯示。
各種服務(wù)電話
最好在產(chǎn)品里面留一個(gè)用戶聯(lián)系官方的渠道，不管是電話還是郵件還是私信。
十、APP開發(fā)前期準(zhǔn)備
框架生成：
- 制作需求溝通確認(rèn)
- 管理平臺(tái)開戶
- 雙版本APP框架輸出
- APP內(nèi)容架構(gòu)組織
設(shè)計(jì)制作：
- APP界面設(shè)計(jì)
- APP素材收集與加工
- APP圖標(biāo)設(shè)計(jì)
- APP內(nèi)容制作上傳
- 客戶確認(rèn)
測(cè)試調(diào)優(yōu)：
- APP內(nèi)容測(cè)試
- APP性能測(cè)試
- APP功能測(cè)試
- APP視覺測(cè)試
APP發(fā)布：
- APPstore發(fā)布
- 主流安卓市場(chǎng)發(fā)布
- APP下載頁(yè)(web/wap)
- 二維碼生成
- APP應(yīng)用手冊(cè)
- 企業(yè)APP交付
10.1、用戶環(huán)境
10.2、開發(fā)環(huán)境
10.3、單頁(yè)&多頁(yè)H5應(yīng)用
10.4、Web&Mobile區(qū)別
10.5、Native&H5的區(qū)別
十一、版本記錄
11.1、里程碑
11.2、發(fā)布準(zhǔn)備
十二、項(xiàng)目概覽
12.1、使用SDK
12.2、分享APP
12.3、項(xiàng)目數(shù)據(jù)
最后，如果覺得有用，請(qǐng)點(diǎn)贊。如果覺得有問題，請(qǐng)?jiān)u論。查看以上所有內(nèi)容可以點(diǎn)擊我的原型地址http://51prd.com。
作者：浪子，個(gè)人公眾號(hào)langzisay。業(yè)務(wù)型產(chǎn)品經(jīng)理，3年社交+4年電商的工作經(jīng)驗(yàn)。
本文由 @浪子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。
看了大神十幾篇文章，感覺干貨滿滿，想提一點(diǎn)點(diǎn)小建議，能不能先在文章前面整個(gè)目錄？
我收藏了
真是優(yōu)秀
很全面，收藏了~~
洋洋灑灑的，沒多少實(shí)用。就想問那個(gè)產(chǎn)品經(jīng)理培訓(xùn)班出來的？學(xué)費(fèi)多少
產(chǎn)品需要體系化認(rèn)知，方法論支撐
太全面了，方方面面都兼顧，厲害厲害
太牛了大神
浪子大大，目前的公司PD都不需要畫圓形圖，直接由策劃出設(shè)計(jì)稿，這正常么？
經(jīng)歷很豐富
大神，跪求rp資源，麻煩發(fā)我郵箱reenee_2008@163.com 謝謝。
需求方案在進(jìn)入開發(fā)后，有要調(diào)整的地方，要怎么讓相關(guān)人員知曉呢？
文檔寫的好贊。不過有個(gè)問題請(qǐng)教：
1、這么完整的文檔的撰寫需要多長(zhǎng)時(shí)間呢？
2、實(shí)際工作中，項(xiàng)目開發(fā)時(shí)間緊迫，文檔完整后再溝通不現(xiàn)實(shí)，那您是如果保證文檔完整又與開發(fā)人員溝通的呢？
大神，能否求個(gè)rp資源，發(fā)我郵箱可以不，834673470@qq.com，謝謝啦，給您遞茶
大神，跪求rp資源，麻煩發(fā)我郵箱yyxqwddx@126.com 謝謝。
文檔寫的這么好，可是自己的網(wǎng)站做的那么爛
開發(fā)前期沒有足夠的時(shí)間完善文檔時(shí)，哪些可以后期補(bǔ)充？但對(duì)開發(fā)影響不大
不知現(xiàn)在求RP還來不來的及，791557100@qq.com，希望大佬能看到我這條小白的評(píng)論，給大佬遞茶！
干貨，相當(dāng)齊全！
真的詳細(xì)，求分享 boatdcy@qq.com
長(zhǎng)見識(shí)了，本人產(chǎn)品小白，受益多多。
感謝！
感恩，大神
新手上路必備神器
在處理Bug 階段分產(chǎn)品開發(fā)人員和項(xiàng)目開發(fā)人員。這兩種開發(fā)人員分工有什么不同呢？ 產(chǎn)品問題和項(xiàng)目問題有什么區(qū)別呢？
很全面的總結(jié)，很多地方值得借鑒。有個(gè)問題，產(chǎn)品工作流程中的第一步需求溝通的產(chǎn)出物之一產(chǎn)品手繪草案是什么？手繪原型草稿拍照？
就是產(chǎn)品草稿。
大神?。。。〈笊袢a(chǎn)品思維，涵蓋產(chǎn)品、技術(shù)、交互知識(shí)，太系統(tǒng)了！
一點(diǎn)都不虛
很受用
你好，想問一下“閱讀指南”里，色號(hào)后面的A、B、C、D、E、F是什么意思呢？謝謝
只是區(qū)分幾種不同的用色。
太厲害了