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

產品需求文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔，如果你已經能可以撰寫需求文檔，那么你現在需要看看本文，在會撰寫的基礎上能夠將產品需求文檔撰寫的更深入。

一、簡述

撰寫結構與開發思維，是在產品需求文檔基礎上，需進一步提升的核心基本功。而這個基本功，決定著能否輸出高度模塊化的產品需求文檔。

但是，許多的新入行的產品新人，對產品需求文檔認識，局限在：“套個模板、添加個前置、后置條件、流程圖”等認知，便能輸出一份嚴謹的產品需求文檔。事實上，這些都只是些浮于表層的事物！對于模板“是否擁有前置條件、后置條件”這些模塊結構，對于產生優質的產品需求文檔，其實并不是核心的決定因素。

糾結于產品模板，會導致新人誤入形式，遠離本質。這種場景下，很難將產品需求文檔撰寫嚴謹，最終必然導致內容空泛。我們對產品需求文檔最終達到的效果，進行TAG概括：

• 推理嚴謹
• 邏輯合理
• 描述細致
• 場景清晰

在進階版篇章中，我們從產品需求文檔模板的框架中跳出來，在高一層的維度中，從“方法論”的角度展示。

根據案例：產品需求文檔A與產品需求文檔B，基于撰寫結構與開發思維，如何實現“嚴謹、合理、細致、清晰”效果，進行案例分析。

二、撰寫結構

撰寫結構，就是基于被撰寫的產品功能模塊，有規劃的進行內容組織。且將組織的內容清晰的描述出來，而內容組織并不局限在使用某個產品需求文檔的模板中，只需要擁有個人“方法”，將產品功能描繪清晰即可。但，它須堅持一些原則：

• 符合瀏覽對象瀏覽信息流的習慣，被組織的內容權重主次清晰，并起到引導作用。
• 內容組織緊湊，功能模塊內容結構劃分清晰，區分明顯。
• 結構化的撰寫方式，以結構化的形式展示數據流、業務流、頁面布局邏輯。
• 嚴謹的是與否判斷。

產品需求文檔A

產品需求文檔A，在描繪需求時，采用的是“功能名稱-需求說明（內容描述）-原型圖”形式作為撰寫結構，進行文檔撰寫，描述不夠深入導致整體較為空洞，體現在：

• 頁面布局：缺乏1、2級層級關系，用戶瀏覽信息時，缺乏主次。需要查看參與者個人進行信息區分，隊內容層級篩選。
• 整體排序：排序不符合查看參與瀏覽信息方式，不能起到引導用戶有節奏地進行產品功能內容傳遞。
• 模塊結構：內容結構單一，在“需求說明”上，無法系統化地進行產品功能細節描寫，頁面的數據流、邏輯關系無法清晰的表達。
• 撰寫結構：文檔描述口語化嚴重，缺乏結構化語言，思維零碎，無法引導查看參與者思維進行文檔價值傳遞。

基于上述原因，產品需求文檔A，對于產品功能涉及的“字段、操作邏輯、數據流、排序規則….等，都無清晰的表達出來。

產品需求文檔B

采用豎并列式的結構進行文檔撰寫，整體顯的緊湊，內容豐富，主要體現在：

完整的文檔模塊

產品需求文檔B，文檔模塊，圍繞產品功能的數據流與邏輯關系展開搭建，框架模塊較為清晰。從產品功能名稱介入，從“用例圖、前置條件、后置條件、功能概述”的角度，將產品功能大的框架明確。

產品框架的基礎上，進行產品功能模塊細化，繪制出：“字段列表、表單、操作、交互、算法模型….”，而描述的模塊與結構化的思維，將產品功能主次區分開，將細節進一步深入描述。如進行產品功能規劃：“從主業務流切入，將核心流程打通?！焙笈_：邏輯業務流，前臺：選購支付流（流程不通，轉化率必然很低）。

規范的內容排序

嚴謹的功能模塊，結合內容主次排序，如何符合參與角色瀏覽文檔的習慣，便顯的非常重要。產品需求文檔A，在文檔排序上，使用：“功能名稱-功能說明-原型圖”，這種描述邏輯是：

查看參與者，需要先看需求說明，才進入查看原型圖，這種查看文檔的交互方式，是有問題。

對 于文檔傳遞信息而言，第一步是進行整體的產品功能概念的價值灌輸，從原型圖了解大體的邏輯與數據，讓參與對象可以在功能上對整體模塊進行了解。在這個基礎 上，才進入細節描述，這個過程中才結合原型圖，逐漸將功能細節撰寫排序。這樣利于后續交接方與提出方、研發方，在查看文檔時，最短的時間熟悉產品功能的大 體邏輯。

而產品需求文檔B，在內容排序上，采用“功能名稱-原型圖-整體業務框-功能說明”，這種描述的邏輯是：

了解功能，了解答題的功能內容-了解整體業務框架-進入細節了解，這種查看文檔的交互方式，符合上述方法論，并且從淺往深引導查看參與者由淺至深的深入了解文檔整體內容。

嚴謹的細節撰寫

在整體框架的基礎上，撰寫的更深入。一方面，需要對行業業務知識進行積累；另一方面，對于所把握的產品功能的使用業務場景理解透徹。

在 產品需求文檔A中，每個字段、操作邏輯、判斷條件、業務場景無嚴謹的說明，所描繪的內容僅局限于不清晰的頁面布局與不清晰的提取數據記錄。而產品需求文檔 B，采用格式化的形式進行文檔撰寫，在格式化的框架下，細致頁面布局的字段與涉及業務場景、判斷條件都能很好的進行描述。

而細節描述，盡量精確至每個字段。若所設計的字段與當前業務字段符合，請備注為當前功能不變，開發成熟的模塊僅需要插進去。

但 業務場景，必須想清晰，如：在某款特賣產品中，新增”瀏覽記錄”功能點，常規用戶進行歷史瀏覽記錄查看時，超過90%的瀏覽的記錄時“無法進行購買超 過”，這是影響用戶體驗，印象流量轉化率。若后續在“本場景”下新增個性化推薦功能點，也顯的有些不搭調，這個場景邏輯是：我看個人歷史記錄-沒有了-推 薦其它商品，那我干嘛還看我的歷史瀏覽記錄？若針對于活動熱度這種特殊場景，但是瀏覽記錄又是一個常規功能。而事實上，這是非常典型的沒將功能點各個業務 場景清晰的梳理清楚：

1. 特賣商品擁有檔期屬性，若干天就需要對商品進行下架。
2. 大量的用戶非每天都會在本產品進行新商品瀏覽。（若是電商PM查看本文檔，請查看貴平臺后臺的BI分析報表，查詢一下日用戶活躍度（DAU）的環比下降幅度，與用戶平均查看商品數）

可理解的描述結構

產品需求文檔A整體是缺乏結構的，而產品需求文檔B是在結構化的框架下進行撰寫。而描述結構圍繞著產品功能或字段，圍繞著“我是誰，我從那么來，我要那里去”，整體便非常清晰。

撰 寫結構，是產品需求文檔非常核心的組成部份，在模塊化、排序、細節、結構等層面上。一方面，從整體上解決產品需求文檔A存在PRD撰寫的問題。另一方面， 將發散的思維收窄，聚焦至解決一個產品功能的業務問題上，包括字段數、業務邏輯、涉及的變量算法… ….清晰的描繪出來。

讓PM把握產品功能整體，完整的的對價值實現上與下進行傳遞，并滿足本章節提出的“撰寫結構原則”條件。

三、開發思維

開發思維，是一種線性思維；在邏輯的世界里，只有“是與否”。是，則開始。否，則結束或進入下一個開始。
它們就像完美的整體，將產品從頂層戰略至功能細節，體驗在產品每個使用場景中（用戶使用體驗）（具體的用戶體驗，我們將從后續的篇章進行描述，這里不進行詳細描寫）。

正如在《倒爺教你寫產品需求文檔（基礎篇）》中，計算機表達的是數據流與邏輯操作，那么開發思維，便是通過“是與否”，將產品細節，從數據流、操作邏輯關系的角度。描述出來；主要體現在兩個方面：

數據流

在 協助層與基礎層之間，通過“數據控制”與“數據傳送”兩個動作，實現數據的倉儲與傳送。那么，前臺主要是進行取值（數據提取），后臺主要是數據發布與管 理；而PM，需對所負責業務，對系統擁有哪些數據，與數據是如何控制擁有足夠的把握。只要后臺擁有產品功能模塊數據，在不影響前臺性能的前提下，在時間條 件充足下，基本上可以實現。

隨著平臺業務的增長，平臺需從開始由于“低門檻”讓參與度提高的策略，擺脫前期策略導致的信息數據匱乏。后期需逐漸逐漸通過運營的手段，將前后臺的業務數據補齊，支撐后期進行數據結構化分析，實現數據智能精準化運營。而數據流，必然少不了。

邏輯關系

機器的行為，是通過程序語言來實現。你需要輸入某個指令，它才會去執行某個任務。在處理多個任務的時候，便需要對多個指令進行判斷執行。而在前后臺業務時， 需要PM對每個業務狀態場景有深入的認識，才能基于判斷邏輯與觸發條件足夠的把控，將所負責的業務場景打通；（在這點上，若不是只做操作功能點的PM，可 以用戶產品功能架構，將個人所負責產品功能，從數據發布、管理、提取、倉促、分析，進行產品功能框架搭建）

總而言之數據流與邏輯關系相互結合，能讓PM在撰寫產品需求文檔時，讓用戶使用場景與計算機邏輯緊密結合，設計出符合用戶體驗的產品，結合業務場景進行功能取舍，設計出符合平臺戰略或用戶體驗的產品功能點，提高了對應的轉化率與實現業務(GMV）增長。

四、綜述

撰寫結構與開發思維，是撰寫產品需求文檔非常核心的組成部分。是在模板或者樣式的基礎上，輸出優質嚴謹的文檔內容。在業務層面，與開發與業務方更嚴謹的進行良性溝通。而這些正是進階版的核心所在，這個基礎上，你可以根據實際的產品功能請看，進行PRD撰寫與設計！

同時，將PM從發散思維的產物收窄至邏輯思維的產物，大大提高了PM入門門檻，提高了專業度。

五、附語

對于產品需求文檔是否需要某類樣式與格式？具體的樣式與格式，可根據團隊、項目實際流程與平臺業務性質進行撰寫結構進行設計，畢竟商業社會是以團隊的形式進行作戰。

但， 作為個人，是否需要進行訓練。倒爺001無法給你明確的答案，因為那是你自己的事。但是，從PRD角度，撰寫完整的框架，能對你個人的產品框架思維得到訓 練。并且，文檔是否高要求，其實也是你的事，至于開發看不看那是開發的事。出了問題，背鍋的也是你的事?？偛荒茏寽y試背吧？

大道至簡，簡難而繁易。處理一個功能點的框架思維與處理一個產品的框架思維是一樣的。經過嚴謹的訓練，能讓框架思維得到提升，而初始框架搭建是否靠譜，也決定了產品后續的迭代生長。

六、拋個話題

如果上帝無法預測與控制宇宙的每個細節，在我們所能理解的所認知思維中，對我們存在認知進行設計，并存有大量以下的現象，如：

• 50%的人類是畸形人
• 50% 的天氣是自然災害
• 女性的占比率<=1%

那么，你認為Ta是一位偉大的創造者？

相關閱讀：

剛入行的產品新人，你其實可以寫一份合格產品需求文檔

作者：倒爺，微信：ftl_keen。

本文由 @倒爺 原創發布于人人都是產品經理。未經許可，禁止轉載。