chinesefreesexvideos高潮,欧美极品少妇性运交,久久久国产一区二区三区,99久久婷婷国产综合精品,成人国产一区二区三区

產(chǎn)品經(jīng)理有一個(gè)必備技能：文檔技能。

輸出的文檔內(nèi)容包含了需求文檔、MRD等等，而需求文檔的撰寫標(biāo)準(zhǔn)，各家公司都有自己的規(guī)范。

所以一個(gè)產(chǎn)品經(jīng)理隨著工作時(shí)間久了，在不同的公司工作，也會(huì)積累不同的標(biāo)準(zhǔn)。對(duì)于沒有標(biāo)準(zhǔn)或規(guī)范的團(tuán)隊(duì)或個(gè)人來說，找到一個(gè)好用的需求文檔模版，也可以提升效率。

下面這份模板時(shí)間過去了6年，但仍然是一個(gè)非常好用的模板。畢竟需求文檔不能做的很細(xì)，會(huì)導(dǎo)致下游產(chǎn)品設(shè)計(jì)、開發(fā)閱讀效率降低，反而不能夠理解需求。

我做產(chǎn)品經(jīng)理工作累計(jì)8年了，也積累了”標(biāo)準(zhǔn)“的PRD文檔。

需求前文檔準(zhǔn)備

需求前我會(huì)將文檔設(shè)置為web版式，字體使用微軟雅黑，標(biāo)題分級(jí)用默認(rèn)等級(jí)，方便進(jìn)行瀏覽和閱讀。

而如果你選擇使用在線文檔，那么就不用設(shè)置。

【W(wǎng)ORD版式】

1.需求概述

需求文檔的第一部分：需求概述

在需求概述中，我首先會(huì)使用一個(gè)表格來羅列當(dāng)前需求是什么、需求的版本、以及需求的完成日期和需求的狀態(tài)。

用于簡(jiǎn)單陳述當(dāng)前的需求狀況，讓閱讀者知道該文檔是做什么、文檔當(dāng)前的狀態(tài)、該需求負(fù)責(zé)人是誰、修訂版本（當(dāng)前文檔的修訂版本，并不是產(chǎn)品迭代版本

需求文檔結(jié)構(gòu)開頭

2.背景概述

背景概述是說明需求出現(xiàn)的背景是什么，是基于什么原因想完成什么。比如下面是社區(qū)論壇UGC功能模塊需求。

3.需求來源

本次需求來源負(fù)責(zé)人：Kevin，部門：產(chǎn)品部

4.關(guān)聯(lián)負(fù)責(zé)人

需求相關(guān)的負(fù)責(zé)人版塊

5.需求執(zhí)行成員

項(xiàng)目成員

需求執(zhí)行成員給出了具體的項(xiàng)目各個(gè)聯(lián)系人。這一點(diǎn)要說明的是，如果團(tuán)隊(duì)沒有以上職位，可以將做這個(gè)項(xiàng)目的人員拉進(jìn)來?？赡躊M會(huì)做UI、UE，類似這樣的情況，也需要填表。

當(dāng)然敏捷開發(fā)的創(chuàng)業(yè)團(tuán)隊(duì)，可能會(huì)當(dāng)面溝通，文檔中存在執(zhí)行成員與否反而不重要，本來人就少，大家都心知肚明啦。

6.項(xiàng)目進(jìn)度

【項(xiàng)目執(zhí)行周期】

每個(gè)公司的研發(fā)流程有一些區(qū)別，比如上面是適用于在產(chǎn)品研發(fā)人員在20人以內(nèi)的團(tuán)隊(duì)，有2次評(píng)審。

需求評(píng)審周期和UI評(píng)審的周期是反復(fù)、漫長(zhǎng)的，并不是將每一次的評(píng)審開會(huì)時(shí)間填上去，而是將相應(yīng)周期。

如：目前評(píng)審處于需求評(píng)審，UI還沒做，那么就屬于開發(fā)需求評(píng)審。

7.更新記錄

這一塊是我認(rèn)為需求文檔中，最為重要的一塊。

文檔更新可能是很簡(jiǎn)單的一句話，但卻是開發(fā)與測(cè)試人員每次最關(guān)注的就是你的更新記錄，他可不想每次都去查找那一小部分更新內(nèi)容。

這個(gè)更新記錄可以在需求評(píng)審后，也可以是開發(fā)中更新，畢竟有一些需求是開會(huì)中不會(huì)遇見的，只有在正在開發(fā)中才會(huì)發(fā)現(xiàn)不合理。

【更新記錄】

這里值得注意的是首先分為4個(gè)屬性

·新增

·刪除

·修改

·新建

新建默認(rèn)為相應(yīng)模塊的首次使用，后期對(duì)于文檔的修改用新增、刪除、修改即可，并且這里需要將修改、新增的地方加入超鏈接，方便開發(fā)進(jìn)行查閱。

這里介紹了產(chǎn)品需求的全體結(jié)構(gòu)，描述順序?yàn)橹鞴δ?mdash;子功能—子功能詳情頁

【需求結(jié)構(gòu)圖】

并且這里建議將每個(gè)頁面超鏈接指向需求文檔后面的功能詳情，方便相應(yīng)人員查看。

鏈接的方式為功能模塊—子功能模塊——詳情頁面，都做可鏈接。

當(dāng)然這樣式比較費(fèi)時(shí)間的，通吃我是只有梳理結(jié)構(gòu)圖，沒有做鏈接形式。

對(duì)象背后的數(shù)據(jù)關(guān)系

通過以用戶的方式來模擬功能模塊流程，將流程涉及的數(shù)據(jù)關(guān)聯(lián)以流程圖展現(xiàn)，當(dāng)然也可以用腦圖，可以方便測(cè)試和開發(fā)人員指導(dǎo)哪一個(gè)數(shù)據(jù)是哪一個(gè)對(duì)象的，在哪一些流程中會(huì)增加或判別什么數(shù)據(jù)。

TIPS：

這一點(diǎn)對(duì)于大功能模塊來說比較常用，但一些小的功能模塊，這一塊可以不梳理，比如很常見的一個(gè)廣告BANNER等小功能模塊，想用的數(shù)據(jù)關(guān)系可以不用展示，與開發(fā)直接溝通好就行。

全局說明指的是在多個(gè)功能、頁面會(huì)存在的相同交互或邏輯，這里分類分為3個(gè)類，如下圖

全局說明中，產(chǎn)品經(jīng)理可以把最基礎(chǔ)的功能全局和交互全局進(jìn)行說明。在所有的功能PRD文檔中，都需要體現(xiàn)，這里我們列舉了比較常見的交互全局、功能全局

·彈層對(duì)話

·加載

·彈層菜單

·搜索

·導(dǎo)航

·表格

·按鈕

·列表

·進(jìn)步器

在這個(gè)功能中會(huì)涉及哪些全局的控件或交互，PM需要將相應(yīng)的全局控件或交互置于文檔中，這里在這次UGC模塊中，有彈層對(duì)話與加載涉及全局，下面是全局的描述。

【UGC模塊中全局彈層】

加載的模塊首先分為以下3種：頁面加載中、內(nèi)容加載中、加載結(jié)果

【加載狀態(tài)】

1.頁面加載中

2.內(nèi)容加載（下拉、松開）

3.頁面加載網(wǎng)絡(luò)正常卻沒數(shù)據(jù)

4.頁面加載網(wǎng)絡(luò)異常

5.頁面加載搜索沒有結(jié)果

全局交互的2種表達(dá)形式

1.頁面間交互

產(chǎn)品經(jīng)理通過全局交互定義頁面間之間的交互，每個(gè)頁面哪些地方可以進(jìn)入，可以退出等。以下我分為單張和多張圖示進(jìn)行展示，頁面間交互應(yīng)該如何說明

【單個(gè)頁面間交互】

【多個(gè)頁面件交互】

2.頁面內(nèi)交互

、

以上為移動(dòng)端內(nèi)的頁面內(nèi)交互，當(dāng)然還有長(zhǎng)安、雙擊等交互，目前以上列舉的是比較常見的一些手勢(shì)

在對(duì)于UGC模塊中，我將相應(yīng)的子功能進(jìn)行羅列，方便設(shè)計(jì)、開發(fā)人員以及測(cè)試人員對(duì)工作量的評(píng)估。

【功能清單】

當(dāng)然值得注意的是可能一個(gè)模塊下有子功能，子功能下面還有子功能，這個(gè)時(shí)候建議方便文檔查看，就以2個(gè)層級(jí)進(jìn)行區(qū)分，在后方描述的時(shí)候進(jìn)行說明。

是以用戶開始，依照用戶的操作，將其流程分為前端和服務(wù)端2類流程，告知相應(yīng)端開發(fā)人員應(yīng)該做什么、不應(yīng)該做什么。

前端是指具體在系統(tǒng)里，PM需要根據(jù)不同的角色將相應(yīng)流程進(jìn)行繪制。

【根據(jù)不同角色泳道圖】

另一個(gè)流程圖就是后端服務(wù)流程，根據(jù)默認(rèn)的用戶流程，將系統(tǒng)APP、后臺(tái)之間的信息交互進(jìn)行記錄，有時(shí)候我們會(huì)用時(shí)序圖進(jìn)行記錄。

根據(jù)前端與服務(wù)端不同處理進(jìn)行分類

PRD文檔中的流程圖，將產(chǎn)品邏輯和用戶使用邏輯描述得清楚，將方便開發(fā)人員以及測(cè)試人員知道如何去進(jìn)行開發(fā)和驗(yàn)收，涉及到數(shù)據(jù)交互的都應(yīng)該在服務(wù)端與

值得注意的是流程圖千萬要清晰、明了，不要彎彎曲曲，混成一團(tuán)。在與產(chǎn)品朋友們交流中

【扭曲成一團(tuán)】

【規(guī)整的流程圖】

到這里就是PRD主要的內(nèi)容部分，我建議將功能的每個(gè)頁面進(jìn)行列舉，比如某一個(gè)功能

【每個(gè)頁面進(jìn)行列舉】

每個(gè)功能的描述，按照功能點(diǎn)進(jìn)行拆解，以此羅列子功能。接下來在文檔中我們需要展現(xiàn)的是三部分內(nèi)容：

【三大部分】

1.頁面需求描述

說明該頁面是干什么的？并且該頁面出現(xiàn)的地方，在什么時(shí)間出現(xiàn)，需要有什么條件要求

2.交互手勢(shì)

上面所說的交互手勢(shì)在這里就可以列舉出來了，當(dāng)前頁面能做什么交互手勢(shì)？哪些手勢(shì)不能做？

【交互手勢(shì)】

該頁面如果只有點(diǎn)擊手勢(shì)，那么即在手勢(shì)下面寫有，并且描述在IOS與安卓那個(gè)版本下有，如果沒有是否需要開發(fā)

3.用例描述

描述點(diǎn)擊相應(yīng)控件或位置，頁面后進(jìn)入到哪一個(gè)頁面，以什么方式（滑動(dòng)？彈出？）

這里以APP里開紅包方式來描述

用例1： 點(diǎn)擊開，頁面左滑進(jìn)入紅包首頁 用例結(jié)束

4.異常情況

異常情況的知曉能夠反映出作為PM的經(jīng)驗(yàn)豐富情況，到底該頁面下那些異常會(huì)出現(xiàn)，你是否能預(yù)知？

PM或許會(huì)將該異常情況統(tǒng)一交給測(cè)試來處理。

異常情況：用戶未登錄，點(diǎn)擊紅包開，頁面左滑進(jìn)入紅包首頁 用例結(jié)束

以上的部分，可以將PRD差不多完成了70%，接下來就是為了后期驗(yàn)證做一些輔助性需求，讓需求更加完整。

數(shù)據(jù)統(tǒng)計(jì)的需求我們也需要在文檔中進(jìn)行填寫，當(dāng)然如果有專門的數(shù)據(jù)部門，我建議PM可以交給數(shù)據(jù)部門完成，PM將其需求過渡給數(shù)據(jù)部門。

當(dāng)然不懂?dāng)?shù)據(jù)的PM肯定不是好PM，為此能夠了解產(chǎn)品哪些地方有數(shù)據(jù)統(tǒng)計(jì)，我還是把相應(yīng)的數(shù)據(jù)要求提交在文檔中。

【數(shù)據(jù)提交模板】

【頁面點(diǎn)擊數(shù)據(jù)模板】

關(guān)于自定義事件LABEL和自定義事件參數(shù)，（圖中時(shí)間改為事件），由開發(fā)人員來定就行了。當(dāng)然如果你是開發(fā)轉(zhuǎn)型的PM，你可以來決定，為了后期的數(shù)據(jù)參數(shù)統(tǒng)計(jì)和分類，建議還是直接交給開發(fā)人員

比如以UGC模塊，以發(fā)帖事件來進(jìn)行說明，該頁面所能進(jìn)行的操作都需要將其規(guī)則化，以事件名稱來確定每個(gè)操作的名稱，可以滿足將其規(guī)則化的目的。

綜上，基本一個(gè)PRD文檔就算完成了，但在工作中一個(gè)功能模塊或一個(gè)版本的迭代往往還需要涉及其他需求，涉及人力、財(cái)務(wù)資源的需求，以及對(duì)于每次評(píng)審或小團(tuán)隊(duì)溝通的記錄。這里我也一并同步出來自己在工作中做的一些需求描述，也可以集中放置于項(xiàng)目文檔或該P(yáng)RD文檔中。

·性能需求

·服務(wù)需求

·營(yíng)銷需求

·安全需求

·法務(wù)需求

·幫助需求

·異常場(chǎng)景

·溝通記錄

·風(fēng)險(xiǎn)描述

1.性能需求

性能需求可以以表格的形式對(duì)相應(yīng)的功能模塊進(jìn)行要求，如紅包點(diǎn)擊彈出的時(shí)間在3S內(nèi)，成功率是99%，并發(fā)數(shù)是20000。

【性能需求】

2.服務(wù)需求

這個(gè)涉及到產(chǎn)品客服，產(chǎn)品人員需要知道要占用客服時(shí)間、相應(yīng)問題解決的方案是什么？每個(gè)問題的優(yōu)先級(jí)是什么？產(chǎn)品需要從客服人員中得到什么信息？這個(gè)需要PM對(duì)當(dāng)前產(chǎn)品數(shù)據(jù)分析，才能更好的對(duì)接資源，總不能要求其他部門把全部資源用在你手上吧。

【服務(wù)需求】

這里首先要說明的是關(guān)于成本建議做一個(gè)標(biāo)準(zhǔn)，如果是按照價(jià)錢就統(tǒng)一為錢；如果為時(shí)間就統(tǒng)一為時(shí)間；預(yù)知服務(wù)頻率需要PM進(jìn)行數(shù)據(jù)分析，給予一個(gè)恰當(dāng)?shù)姆秶?/p>

3.營(yíng)銷需求

營(yíng)銷需求和上方的服務(wù)需求同樣，也是需要產(chǎn)品經(jīng)理進(jìn)行數(shù)據(jù)分析，為達(dá)到目標(biāo)計(jì)劃一個(gè)預(yù)計(jì)營(yíng)銷需求，當(dāng)然其營(yíng)銷的平臺(tái)與方式可以和營(yíng)銷部進(jìn)行策劃溝通。

4.法務(wù)需求

【人力需求】

法務(wù)需求與以上2點(diǎn)需求類似，建議可以合成為一張表格，將分別的需求資源供應(yīng)方分類，這樣可以更快的在一張表中了解該項(xiàng)目的資源消耗情況。

5.財(cái)務(wù)需求

同法務(wù)需求一樣

6.幫助需求

幫助需求可以解釋為FAQ培訓(xùn)，將產(chǎn)品上線后對(duì)于該項(xiàng)目涉及人員和部門進(jìn)行培訓(xùn)，建立相應(yīng)的FAQ，并且對(duì)于活動(dòng)類模塊也需要運(yùn)營(yíng)提供活動(dòng)FAQ。

7.項(xiàng)目風(fēng)險(xiǎn)

【項(xiàng)目風(fēng)險(xiǎn)】

如果是功能模塊迭代可以說明為版本風(fēng)險(xiǎn)，但是對(duì)于產(chǎn)品的迭代中，其需要明確新增、取締的風(fēng)險(xiǎn)，將其可能存在的風(fēng)險(xiǎn)隱患進(jìn)行描述

8.評(píng)審中的溝通會(huì)議記錄

可以參考下面的會(huì)議模板作為需求評(píng)審記錄

【會(huì)議需求記錄】

這樣有了會(huì)議溝通記錄之后，相信產(chǎn)品人能夠減少一些坑或者識(shí)別一些坑，避免一些人冤枉PM說：領(lǐng)這是你之前說的！XX這是你說的！