国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

講到PRD，有兩種不同的意見：有的人認為PRD十分關鍵，能夠體現(xiàn)出產(chǎn)品方案、設計思路；而有的人則認為PRD無用，價值小。對此筆者認為：我們應該結合公司、業(yè)務、產(chǎn)品等去自定義PRD，發(fā)揮它的最大價值。

一、寫作緣由

PRD、原型可以說是產(chǎn)品經(jīng)理工作中最常見、最高頻的交付物了。但是最近與許多同事的交流中卻發(fā)現(xiàn)，很多產(chǎn)品人員、開發(fā)人員都對需求文檔抱有一種輕視、鄙夷的態(tài)度，產(chǎn)品經(jīng)理對于需求文檔敷衍了事，開發(fā)更是看都不看。加之一些不知從何處來的言論鼓吹，“一個好的產(chǎn)品經(jīng)理絕對不等同于寫文檔、畫原型”“寫文檔就是搬磚”，PRD更加成為了一個尷尬的存在。

然而事實并非如此。

對于產(chǎn)品經(jīng)理個人而言，需求文檔是產(chǎn)品方案、設計思路、實現(xiàn)思路的綜合體現(xiàn)和結果輸出，不管是使用可交互原型、手繪原型還是文字描述，產(chǎn)品經(jīng)理總是需要這樣一個載體來表達自己的思維結晶。

對于團隊配合而言，隨著分工越來越細化以及員工流動性的增加，需求文檔轉而擔負起了聯(lián)絡產(chǎn)品、開發(fā)、測試以及新老員工的溝通工具。

對于公司或者業(yè)務這個抽象實體而言，需求文檔是其業(yè)務發(fā)展、變革的沉淀……

上面講到需求文檔存在的價值，不過我們也應該看到，圍繞著目標或者第一性，需求文檔可能只是交付產(chǎn)品或用戶價值的工具，我們確實應當結合公司、業(yè)務、產(chǎn)品的具體情況去自定義“需求文檔”，而不是直接生搬硬套。

下文所述，是基于我個人不到一年的產(chǎn)品工作以及PRD寫作經(jīng)驗。我相信隨著經(jīng)驗的不斷積累，還會不斷生發(fā)出新的認知來，屆時通過比較，我也能感知到自己的成長，在這里也歡迎大家與我共同探討。

二、重新定義需求文檔

1. 面向人群與寫作目標

需求文檔的使用人群主要包括產(chǎn)品經(jīng)理、開發(fā)、測試。對于產(chǎn)品產(chǎn)品經(jīng)理而言，使用并撰寫需求文檔應當可以幫助：

1. 細化產(chǎn)品方案
2. 輸出文字版的產(chǎn)品實現(xiàn)方案
3. 幫助整理思路、發(fā)現(xiàn)不足、促進溝通
4. 用于對內對外的溝通展示

對于開發(fā)和測試而言，需求文檔應當可以幫助其了解業(yè)務、功能、成功標準，從而更好的進行開發(fā)和測試。

因而寫作PRD的過程，可以視為一個梳理產(chǎn)品思路、細化產(chǎn)品方案、細化技術方案的迭代的過程，而最終的PRD可以作為產(chǎn)品的藍圖、實施方案以及溝通工具。

2. 寫作思維

下面總結了在PRD寫作中我認為比較重要的幾種思維模型：

（1）目標思維

首先最頂層的思維應當是“目標思維”，通過思考這些問題找到寫作目標：這份文檔給誰看？他們想看哪些信息？他們會以何種方式看？我應該以什么樣的形式、內容來寫才能更好的幫助讀者？

我寫作的常見目標可能是這樣的：

1. 通過需求文檔梳理整個產(chǎn)品設計思路，并簡要的傳達給項目成員。
2. 通過需求文檔，將產(chǎn)品方案細化為文字版的解決方案，這個文字版方案應當涵蓋所有開發(fā)細節(jié)，以便開發(fā)可以快速展開工作而無需多次找我溝通確認。
3. 需求文檔應該有良好的組織結構，便于以后加入新的文檔。
4. 跟隨敏捷與迭代的原則，需求文檔也應是敏捷并且不斷迭代的。
5. 需求文檔應當及時記錄和告知變更。

（2）基本的邏輯思維

產(chǎn)品文檔的各個組成模塊，應當具備合理的邏輯關系，而不是雜亂地鋪在文檔里。

例如，可以首先描寫和論證用戶需求；然后簡要敘述為了解決需求，選擇了怎樣的產(chǎn)品方案或業(yè)務模型；隨后列出為了實現(xiàn)業(yè)務模型需要鋪設的產(chǎn)品功能點；進一步的，通過功能流程圖，將功能點進一步細化為一個個頁面路徑和頁面元素；最后還要有對于頁面元素的詳細描述。

可以看到，這樣的需求文檔是邏輯清晰、有說服力的，出現(xiàn)問題也很容易定位到具體環(huán)節(jié)。

（3）微言大義

對語言文字有所敬畏，語言文字作為溝通工具，是非常容易造成歧義的，要想準確地將自己的思路想法傳達給別人是一件非常難的事情。需求文檔在文字表達上應該力求簡潔、清晰、無歧義，多試著以讀者的角度去審視自己的文字表達，相信你會發(fā)現(xiàn)很多問題。

（4）產(chǎn)品思維

我個人將PRD的寫作過程看作對產(chǎn)品思路的梳理和記錄。這個產(chǎn)品思路或許并沒有唯一正確答案，我個人的思路可以概括為：

（1）自上而下，基本遵循目標-概要性產(chǎn)品解決方案–詳細解決方案（對于常見的2C互聯(lián)網(wǎng)產(chǎn)品，這個詳細解決方案可能包括從功能結構到頁面視覺的一系列工作）

（2）由內而外，主要用于對現(xiàn)有功能的優(yōu)化，基本遵循可用-易用-好用的迭代原則。

因而實際工作中，我的寫作思路一般也遵循上述原則，對于新功能通常按照目標-概要方案-詳細方案去寫；對于功能優(yōu)化，結合現(xiàn)有使用場景和痛點，去提出優(yōu)化方案。

（5）技術思維

產(chǎn)品思維比較偏重于分析決策和提出面向用戶或商業(yè)的解決方案，而技術主要考慮如何去實現(xiàn)這個解決方案，以及這個解決方案對既有技術框架的影響有多大。

實際上，一個好的解決方案絕不僅僅只考慮用戶或商業(yè)，技術實現(xiàn)也是必須考量的要素。技術將解決方案落實并決定項目的資源和成本，技術方案的好壞也會直接決定用戶的使用體驗，甚至有些時候技術實現(xiàn)可以驅動商業(yè)和用戶需求的變革。

產(chǎn)品經(jīng)理缺失技術思維，就會很容易將自己沒完成的任務無意識的甩鍋給開發(fā)，實際工作中開發(fā)經(jīng)常跑來找產(chǎn)品溝通需求細節(jié)也是源于此。

以一個簡單的例子來說明：

技術層面，用戶在登錄注冊后，可以本地緩存賬號信息，從而下次訪問應用時無需手動進行登錄操作。如果產(chǎn)品經(jīng)理不懂這個緩存技術，在PRD中就會缺失相應描述，開發(fā)人員無法明確是否要做這樣一個自動登錄的功能，就只能拍腦袋決定了。

再舉一個登錄注冊相關的例子：

網(wǎng)站登錄注冊需要考慮是否限制用戶多賬號登錄的問題，網(wǎng)站運行在瀏覽器上，瀏覽器在緩存用戶信息的時候是按域存儲的；如果網(wǎng)站允許多賬號登錄，在不加以設計的情況下，這些同時登錄的賬號會出現(xiàn)數(shù)據(jù)混亂的情況。因而必須在產(chǎn)品設計之初就從需求上定義是否需要多賬號登錄，進而才能由開發(fā)給出一個完善的多賬號數(shù)據(jù)存儲或請求方案。

現(xiàn)實工作中，產(chǎn)品經(jīng)理可能無法達到技術人員的水平，解決之道可以是自己多學習、和技術多去溝通產(chǎn)品方案；還可以通過制定設計&開發(fā)規(guī)范，讓產(chǎn)品、設計、技術可以協(xié)同工作(類似于ant design，定義了一套常用的設計開發(fā)規(guī)范，產(chǎn)品設計和開發(fā)都可以基于共同規(guī)范去開展，而不用重復造輪子)。

在我最初的認知中，產(chǎn)品經(jīng)理應該盡量去定義一套足夠詳盡的解決方案，而開發(fā)人員、設計人員只需根據(jù)PRD去進行自己的工作。

在對設計、開發(fā)有了一定的了解后，我認為，單靠產(chǎn)品經(jīng)理一人之力去輸出詳盡的解決方案是不太可能的（除非產(chǎn)品經(jīng)理既懂得產(chǎn)品設計、又懂得技術、還懂得交互設計和視覺設計等）。一個真正優(yōu)秀的產(chǎn)品方案應該由產(chǎn)品人員、開發(fā)人員、設計人員、測試人員通力合作，這些人員不是上下游關系、規(guī)劃與執(zhí)行關系，而是一種能力互補的關系，這些人員的才能共同造就一個優(yōu)秀的產(chǎn)品。

另一方面，在不斷的配合中，產(chǎn)品、設計、開發(fā)應該嘗試去將常用功能封裝成一個設計&開發(fā)框架，在以后的工作中可以直接沿用或改動現(xiàn)有框架，提高工作與溝通效率。

三、PRD結構

下面簡要介紹我個人常常使用的PRD的基本結構：

1. 需求

也是產(chǎn)品方案要達到的目標，需求可能是用戶需求（即以用戶價值為導向），也可能是業(yè)務需求（即以商業(yè)價值為導向），后面的產(chǎn)品方案細節(jié)，最終都是為了達到這一目標。

在PRD中闡述項目的目標，有助于激發(fā)團隊成員的動機，從而在目標上達成一致。

2. 設計模型

面向需求或目標，提出解決方案或設計模型，可以以泳道圖、流程圖等可視化的方式或者文字表達的方式描述主要的業(yè)務邏輯、產(chǎn)品架構。

3. 功能列表

根據(jù)設計模型，將用戶需求、業(yè)務需求轉換為大大小小的產(chǎn)品功能模塊或非功能性要求，闡述這些模塊間的業(yè)務關聯(lián)、數(shù)據(jù)關聯(lián)，對于功能進行優(yōu)先級分析和版本規(guī)劃。

4. 功能流程

針對每一個功能模塊，圍繞著功能目標，設計功能流程。如圍繞著用戶賬號登錄這一目標，設計登錄注冊的流程。這里要注意：

根據(jù)功能模塊的特性，使用不同種類的流程圖，比如泳道圖、時序圖、狀態(tài)圖。

突出主流程、弱化分支流程、以文字表達異常流程，將三者區(qū)隔開來。

（產(chǎn)品設計應當優(yōu)先考慮引導用戶走向主流程，次之考慮對于用戶的分支行為作出一定約束，最后還要考慮整個環(huán)境系統(tǒng)可能出現(xiàn)的異常。對于用戶、設計人員、開發(fā)人員而言，這三者的作用和優(yōu)先級都是不同的）。

5. 頁面設計與頁面元素

頁面設計是對功能流程的進一步細化，許多的頁面元素串聯(lián)起來，引導用戶走完整個功能流程并達成目標。根據(jù)功能流程圖，考慮以最少的頁面和最清晰有效的頁面布局實現(xiàn)功能。

6. 頁面詳細說明

對于頁面之間的邏輯和每一個頁面元素進行必要的說明。

頁面元素包括信息和控件等，在說明信息時，需要對信息的展示效果、信息來源、信息的計算規(guī)則、信息的刷新規(guī)則等進行說明；對于控件，以輸入性控件為例，對控件類型、控件樣式、控件交互、輸入限制、輸入校驗等屬性進行說明。

個人覺得，頁面詳細說明是開發(fā)和測試最終要參考的部分，也是產(chǎn)品經(jīng)理最容易有遺漏的地方，因為這里會涉及很多細節(jié)；對于這里的寫作也是爭議最多的，是否要寫得足夠詳盡？我只能說，對此要具體情況具體分析，如果團隊已經(jīng)有了成熟的配合模式和規(guī)范，這里自然可以簡化；但是我想每個產(chǎn)品經(jīng)理都應該具備寫一份詳盡文檔的能力。

那么怎樣才能避免遺漏細節(jié)呢？

我個人覺得，還是要有技術思維。換位思考如果你是開發(fā)，你需要知道哪些必要因素才能開工。

對此，個人認為最快的學習途徑不是看別人怎么寫需求文檔，而是讀一些技術的書，真正明白當一個開發(fā)在寫代碼時是在做什么。

以網(wǎng)頁表單為例，前端需要通過html和CSS來定義表單的結構和樣式，通過javascript執(zhí)行一些輸入限制和校驗，通過AJAX和服務端通信，發(fā)送POST請求將用戶輸入的一些字段信息上報；服務端需要編寫程序對請求進行處理并在處理完成后發(fā)送響應給前端。

因而從前端的角度出發(fā)，PRD里應當包含頁面控件樣式的描述、控件交互的描述、輸入限制的描述、數(shù)據(jù)上報的描述等；從后端的角度出發(fā)，PRD里應該包含有數(shù)據(jù)上報的描述。

7. 全局說明

一些各個頁面都有的功能點、交互模式、設計樣式，或者一些通用的異常控制，可以放在全局說明里。

四、總結

在PM的日常工作中，對于PRD有了一些認知上的升級，在這里進行了初步總結。主要講述了：

（1）PRD寫作的目的和價值

（2）PRD寫作中應該具備的思維模式

（3）PRD的常見結構

此文雖以PRD為主要話題，但實質上重在對產(chǎn)品經(jīng)理邏輯與理性思維的體察。誠如很多大佬說的，產(chǎn)品經(jīng)理需要有一秒內變?yōu)榘装V的能力；但個人認為，除了直覺與感性，良好的邏輯思維與理性亦是產(chǎn)品人必不可少的。

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

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