中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

你是否有過因為PRD文檔寫得不夠好，而被開發(fā)懟的經(jīng)歷呢？這里一份詳細的PRD文檔寫作說明，get這份說明，你的開發(fā)過程將會很順利。接下來，就讓筆者為我們講述如何寫好一份PRD文檔吧。

產(chǎn)品和開發(fā)之間的矛盾人盡皆知，其中一個核心問題就是：PRD寫得不夠好，于是開發(fā)過程非常不順，導(dǎo)致產(chǎn)品和開發(fā)不斷撕逼。

當時剛做產(chǎn)品經(jīng)理時，也為此頗為煩惱。雖然大學時學過C++和Java，但對技術(shù)的理解有限，當時還難以寫出合格的PRD。

緊接著，我就和很多產(chǎn)品新人一樣——到網(wǎng)上到處搜PRD該如何寫，搜了一堆模板、一堆文章。

但緊接著我們會發(fā)現(xiàn)：并沒有人給出一個足夠?qū)嵱玫腜RD詳細說明，讓我們能直接在工作中應(yīng)用，并能保證開發(fā)過程順暢。

到了現(xiàn)在，我終于能給出一份比較實用的PRD詳細說明了。果然打是親，罵是愛，感謝那些曾經(jīng)懟過自己的開發(fā)們。

有了這份PRD文檔寫作詳細說明后，有什么效果？

• 一位開發(fā)評價：按照你上次的PRD文檔，以后就不是開發(fā)懟你，而是你懟開發(fā)了。
• 一位測試評價：我感覺PRD文檔寫成這樣，以后就不用需求講解了（“需求講解”特指開發(fā)之前的講解，便于開發(fā)熟悉需求）。
• 一位面試官評價：你是我面試過的產(chǎn)品經(jīng)理中，一個難得的合格的產(chǎn)品經(jīng)理，你要感謝那些懟過你的開發(fā)們。

確實如此，只要每次都按照這份詳細說明來寫PRD，開發(fā)過程就很順暢。而如果有不順暢的地方，往往是忽略了詳細說明中的部分內(nèi)容。

那么這份詳細說明是怎么來的？

很簡單：不斷地被開發(fā)懟。

在被開發(fā)懟了將近1年后，在接觸了6個開發(fā)團隊后，我收集了足夠多的開發(fā)懟我的注意點，以及過程中的不斷完善，梳理出了這份詳細說明。從此之后，一切就變得很順暢。

下面就來具體講解：

一、基本注意點

1. 不同團隊需要不同的PRD

PRD是給開發(fā)、測試看的，本質(zhì)上也是一個產(chǎn)品，產(chǎn)品的用戶就是開發(fā)和測試。

因此，一個最基本的原則是：根據(jù)不同團隊的具體需求，給出不同的PRD。

是的，PRD也不是一招鮮吃遍天。當你接觸的團隊足夠多，你會發(fā)現(xiàn)不同團隊對PRD的要求有很大差異：

• 有的團隊需要非常詳細的說明——一般是比較成熟穩(wěn)定的開發(fā)團隊。
• 有的團隊只需要原型圖足夠準確，需求描述部分很少——這就需要在開發(fā)過程中不斷溝通。
• 有的團隊注重你對需求的深入理解，而不是PRD本身的描述是否足夠詳細——一般是創(chuàng)業(yè)團隊。

所以，PRD到底要寫到什么程度，最基本的原則就是：看團隊的具體需求。

2. 一些注意點

另外，還有一些注意點：

• 這份PRD詳細說明主要針對業(yè)務(wù)類產(chǎn)品。因為這份說明來自實際工作經(jīng)驗，筆者沒做過AI、大數(shù)據(jù)、區(qū)塊鏈等高新技術(shù)產(chǎn)品，更多的是業(yè)務(wù)類產(chǎn)品。
• 這份PRD詳細說明非常詳細，但不代表你的PRD就要這么詳細。如上面所說，不同團隊需要不同的PRD。但你的PRD可以比較簡略，所以，對功能的思考上要考慮到這份詳細說明中的內(nèi)容，以避免開發(fā)過程的不順暢。
• 這份PRD詳細說明只針對功能的技術(shù)可行性，不針對需求的合理性——這是PRD的核心目的，需求的合理性可在其他階段考慮。

二、PRD文檔寫作詳細說明

先說明一下：一些基本的PRD模塊我們就不說了——比如：「歷史版本修改記錄」、「需求背景說明」這些人盡皆知的部分。

我們只講PRD最核心的部分——對各個功能應(yīng)該如何描述才足夠準確、詳細。

至于其他模塊，我們在文末放一個鏈接，大家自行下載即可，看一眼就懂了。

1. 取值規(guī)則

取值規(guī)則：產(chǎn)品前端/客戶端的字段取的是對應(yīng)的什么字段。

我們以「人人都是產(chǎn)品經(jīng)理」APP首頁為例：

比如：下圖的banner部分，取值規(guī)則就是這些banner的圖和標題取自哪里？

一般來說，banner部分的圖和標題都在后臺配置，因此你就可以寫成：

banner圖片：取值后臺字段XX。

banner標題：取值后臺字段YY。

PS：建議寫出后臺的具體字段，否則時間長了，字段就亂了，下次你想知道前后端的對應(yīng)關(guān)系時，還得找開發(fā)查半天。

當然 ，取值的來源可以不是后臺某字段，比如：

• 前端用戶操作的數(shù)據(jù)——比如用戶點贊次數(shù)。
• 某幾個字段綜合計算后的結(jié)果。
• 符合特定條件的某字段——比如取值后臺字段 [狀態(tài)] 的值為”顯示”的字段XX。
• ……

這些在實際工作中會有變化，核心是得想清楚前端/客戶端的字段，其取值的對應(yīng)字段是什么。

2. 顯示規(guī)則

顯示規(guī)則：與顯示相關(guān)的規(guī)則。

以下圖banner部分為例，顯示規(guī)則要考慮：

• 取值數(shù)據(jù)為空時如何處理：例如banner的圖片對應(yīng)的后臺字段為空，此時如何顯示？
• 顯示數(shù)量：banner的圖片要顯示幾張？超出數(shù)量限制時如何處理？banner的標題要顯示多少字？超出數(shù)量限制時如何處理？
• 顯示格式：比如標題是靠左還是居中還是靠右？如果是數(shù)字，比如時間，是要顯示成12小時制還是24小時制？
• 排序規(guī)則：banner的圖片顯示的先后順序如何排序？是按照后臺的某個字段排序？還是按照其他規(guī)則排序？

3. 交互規(guī)則

交互規(guī)則：將對應(yīng)的交互設(shè)計描述出來。

比如下圖的banner部分，至少要考慮：

• 自動輪播的時間間隔。
• 左右滑動時的交互效果。
• 點擊后的交互效果——比如點擊后進入XX頁面。

4. 默認規(guī)則

對一些默認情況的說明。

• 默認的取值規(guī)則：默認取值xx，當xx為空則取值yy。
• 默認的顯示規(guī)則：默認顯示xx，當….則顯示yy。
• 默認的交互規(guī)則：導(dǎo)航欄，默認選中某個標簽——比如上圖的首頁部分，底部TAB默認選中的是「閱讀」，頂部導(dǎo)航欄默認選中的是「文章」。
• 其他的默認情況說明。

5. 邊界情況

對各種邊界情況的考量，防止出現(xiàn)異常。

比如：

取值規(guī)則：被取值字段為空時如何取值？

顯示規(guī)則：

當沒有內(nèi)容時，如何處理？——當前頁面沒有任何內(nèi)容時顯示什么頁面？當前字段沒有任何內(nèi)容時顯示什么內(nèi)容？

當數(shù)量巨大時，如何處理？——列表顯示數(shù)量過大時可能影響性能，要與開發(fā)協(xié)商處理措施。

時間顯示格式——如顯示時間區(qū)間格式：若開始時間和結(jié)束時間為同一天，那么，是否只顯示一個時間即可？

交互規(guī)則：

• 操作次數(shù)限制：是否要限制？如要限制，限制多少次？達到上限后如何提醒？比如，輸入密碼錯誤達到上限后，就要凍結(jié)一段時間。
• 輸入內(nèi)容限制：是否要限制？如要限制，限制多少次？達到上限后如何提醒？比如，輸入手機號碼限制11位數(shù)字，超過后如何處理？
• 返回按鈕：若上一個頁面為空，則返回哪里？
• 提示：提示多久消失？比如toast提示，是否3s后消失？
• 編輯：是否可編輯？涉及到編輯時，要描述清楚編輯成功后的交互。比如保存后是否要刷新頁面。
• ……

異常情況：出現(xiàn)異常時如何處理？

1. 當沒有網(wǎng)絡(luò)/網(wǎng)絡(luò)異常時，顯示什么？
2. 當服務(wù)器忙時，顯示什么？
3. 當產(chǎn)品下架/頁面被刪除等時，顯示什么？
4. 被惡意評論、惡意刷分等時，顯示什么？

幾個不同狀態(tài)的綜合考慮：

• 登錄/未登錄：例如，未登錄狀態(tài)下不能點贊。
• 有權(quán)限/無權(quán)限：例如，無權(quán)限時是否顯示？交互如何？
• ……

版本兼容考量——如果是APP，不同版本之間的兼容需要考慮，web端一般不需要考慮這塊。

以上是PRD要考慮的核心部分，是站在開發(fā)角度的考量。

當然，由于例子有限，以上內(nèi)容并不完整（如下方列舉了一部分），所以整理一個思維導(dǎo)圖下載鏈接，大家參照即可。

• 比如：APP端、小程序端、web端各有不同，各自有各自的注意點。
• 比如：流程上的注意點，如需為設(shè)計考慮，可以標注清楚這個版本涉及的更改內(nèi)容，這樣設(shè)計就能更快地知道自己該設(shè)計哪些地方；還應(yīng)該給出可復(fù)制的文案，否則設(shè)計得自己輸入對應(yīng)內(nèi)容等等。
• 比如：與線上功能一致的，盡量沿用線上已有的功能，這樣便于開發(fā)，可降低開發(fā)成本。此時最好還說清楚線上功能所在的位置，便于開發(fā)找到對應(yīng)的功能。
• 對于關(guān)聯(lián)性較強的數(shù)據(jù)，開發(fā)難度往往更大，此時應(yīng)更多地考慮性能。
• 如果更改頻率低，寫死比在后臺添加更好。
• 可以把通用的功能全部收集起來放在一個文檔中，這樣后續(xù)用到對應(yīng)功能時，可以直接給出鏈接，讓開發(fā)看之前的文檔描述即可。
• ……

PRD文檔寫作詳細說明、PRD模板：

鏈接：https://pan.baidu.com/s/1tVhJ6A6On3TFE0lGHO3-TQ

提取碼：smu7

#專欄作家#

萬能的船長，公眾號：PMWang，人人都是產(chǎn)品經(jīng)理專欄作家。一個做產(chǎn)品的人。

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

題圖來自Unsplash, 基于CC0協(xié)議