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

產品需求文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔，其作用就是“對MRD中的內容進行指標化和技術化”，這個文檔的質量好壞直接影響到研發部門是否能夠明確產品的功能和性能。

一、簡述

產品需求文檔是產品人員非常核心的基本功！是協調研發、測試、UED、業務非常重要的重要工具。但是，往往很多新入行的PM與互聯網領域的PM，產出的文檔往往不盡人意，主要體現在：

• 缺乏邏輯，語言啰嗦不精練；
• 通俗的用詞過多，整體顯的不專業；
• 無法將字段的數據結構、邏輯關系清晰的表達出來；
• 缺乏開發思維；

而出現這種原因在于：

• 新人入職，沒有經過嚴謹的文檔撰寫、流程設計訓練；
• 大多數的PM非研發出身，對前后臺的業務邏輯、數據結構了解不清晰；
• 分工細，版本迭代迅速，對功能點理解不夠透徹；

完善的產品需求文檔，不但利于PM對所承接的功能進行有效的管控，將業務邏輯梳理清晰，對分解的功能點，進行協調測試、研發、設計、運營同時開展工作；

模塊化的功能點（倒爺當年做的一個功能）

雖然，不同的公司擁有不同的產品需求文檔模板！但，不論模板格式如何，文檔的本質在于：“有效的將功能清晰的表達出來，并且能支撐后續的業務交接與版本迭代參考，對上與下進行價值傳遞。”并且，隨著平臺業務的發展，歸檔、倉儲起來的業務文檔，便是極其有價值的知識庫，里面匯總了各個時期里PM、研發、測試、項目經理、設計….對業務是如何進行思考，對文檔研究的本身，側面也反應了企業是如何將戰略進行細節落實。

而，“業務描述、功能描述、其它需求”是組成產品需求文檔非常重要的模塊；本篇章，將以通用版的角度，對這些模塊行介紹；

二、業務描述

任何的業務或需求，都有業務提出方，業務提出是相關的業務部門或產品經理自身。

業務來源的本質，便是希望通過這個業務解決那些實際的問題，達到提升某些轉化率或某些目的；業務描述清晰的表達出來即可，不需要多復雜，但常規包括：

• 業務背景
• 產品功能概述
• 產品前景分析
• 產品功能整體流程
• 產品邏輯關系
• 面向對象
• 應用對象
• 名詞解釋
• 參考文檔

上述的這些層面，以通用版的角度，將產品的價值傳遞給研發方與業務方，實現之間有效的銜接。

為什么，我們需要進行業務、功能、概述這些偏宏觀不實際的描述呢？這樣不是很麻煩，且浪費時間？

我們要知道，每新增或刪除一個功能，狹義來看也沒啥大不了。但站在宏觀的角度去看，功能研發是需要耗資企業運營成本。如果處理不完善，浪費運營成本同時，甚至影響整個用戶體驗與開發規則。

身為產品人員在未傳達產品的業務價值前提條件下，便強勢驅動研發人員進入開發階段，這是錯誤的！我要是研發，我也會拍死這位PM。那么業務描述的本質便很清晰了，便將業務價值，傳遞給團隊成員。

另一方面，非常多的企業，內部的項目流程是不完善的，且并非每一位研發人員都是善類。產品經理往往需要兼備著項目經理的職責，推動著項目實現研發上線。在這種情況下，如果業務價值描述不清晰，功能在開發與上線后出現問題，這個鍋注定是要背的。

BTW，這些我就不都說了，自己工作中慢慢積累！

下面，我對組成業務描述的組成元素進行描述：

業務背景描述：

這里，你必須將業務提出方描寫出來，并且細致到業務方為什么將這個需求提出來！為什么？一方面，你要告訴研發人員，你為什么設計這個產品或功能，這個需求從來源到設計是有原因的。另一方面，拉上相關業務部門，你至少不是一個人在戰斗。

產品功能描述：

對當前功能進行概述，所設計的產品或功能的功能模塊，新增、完善、優化那些產品功能；

產品前景描述：

本產品或功能，希望對那些轉化率指標或實現那些目的；

產品的整體流程：

Visio、Axure（Axure畫的流程圖好丑）。

通過而言，簡單的需求將主業務流與邏輯關系流表達出來便可以；但涉及復雜的業務，便將產品或功能涉及的主要流程繪制出來；而流程目的，主要是清晰的將前后臺的邏輯關系與數據結構表達出來；一方面方便開發理解業務與數據流，另一方面也方便產品人員梳理自身需求的業務邏輯；利于后續與研發進行溝通。

具體的流程數量，根據業務的復雜程度決定，一般只需要將核心的流程繪制出來便可；

• 前臺：主要是交互、數據流程；
• 后臺：主要是業務邏輯判斷、數據流；

前后臺的流程湊在一起，能清晰的看到前后臺的模塊之間，是如何進行耦合的，數據儲存、提取、處理、分析。

功能框架：

Mindjet Minmanager、Xmind畫的框架圖好丑。

框架圖的意義在于，能讓查看或了解業務的人，全方位的了解功能之間的功能點的邏輯關系。同時，一份優秀的框架圖，能讓PM站在全局的基本面上，對個人所負責的產品進行全局的規劃，對前后臺的功能進行把握，達到支撐平臺業務。

• 產品架構：對前后臺的各個系統與管理模塊的邏輯關系，一般是對業務極其熟悉的業務構架師與資深的產品總監搭建，里面涉及每個接口如何進行對接耦合。
• 功能架構：所負責的產品或功能的前后臺功能的邏輯關系，簡單點的就是一個產品或功能的前后臺，大一點就是一個系統涉及的功能點之間的耦合。
• 功能框架：功能點所涉及的邏輯關系。
• 功能結構：功能點所涉及的邏輯關系。

而“架構、框架、結構”區分在于，所負責的業務究竟有多大。但不論如何，它們的表現的原理是一致的。將分解的功能點，之間是如何聯系的功能結構關系清晰、簡練的表達即可。

關于架構，包含“功能分解、面向用戶”就夠用了。若再深入，可將分為：“應用對象、BI分析（BI需求也寫上去）、系統集成….”。后續可根據BI數據，對產品進行版本迭代與優化。

面向對象

表達產品或功能主要是為那類用戶服務的。將面向用戶是誰，擁有哪些權限清晰的表達出來即可，對個人進行功能設計也有很大的幫助。

應用對象

本功能需要在那些應用端或版本進行上線，清晰的描繪出來，方便后續進行業務交接。

名詞解釋

將本次文檔涉及一些奇葩的明詞進行解釋，這點很重要！有些PM喜歡將一些非常簡單的內容包裝成非常牛逼，讓人看起來很難懂，而事實上也就做哪些一件簡單事，但是看的人會很痛苦：看PRD時會想：“這玩意，究竟想表達什么。

參考文檔

將所做的本次功能，所參考的那些文檔，附屬上來；目的的在于，方便后續的業務方、研發方進行查看。

三、功能描述

功能描述能否描寫清晰，描寫清晰，開發找茬都不怕了。如何才能完整的對功能點進行描述呢？圍繞三個點“功能是誰？功能來自哪里？功能要到哪里去？

同時，功能需求主要分為核心功能、其它功能。不論是核心功能還是其它功能，都可以由以下元素構成：

• 功能名稱
• 面向用戶
• 用例圖（Axure、mocking（適合移動端進行敏捷性開發）)
• 前置條件
• 后置條件
• 功能簡述
• 詳情描述

而具體的功能描述內容，則根據業務（功能點）的復雜程度，進行篩選描寫?？梢匀珜?，也可以不全寫。但務必記住：不論何種方式，目的在于將業務價值完整、清晰、有條理的傳遞給查看文檔的參與角色。

功能名稱（我是誰）

本功能在系統里的命名。

面向用戶

本功能的使用對象。（在前臺，功能的參與者是少數的；但后臺與企業級應用里，功能的參與者是多個的）

用例圖

表達功能在表現層的邏輯圖；可以是傳統意義上的用例圖，或者是簡化版的原型圖、流程圖；

前置條件（我來自哪里）

使用該功能的前提、邏輯關系說明；公司大了后，每個開發都只寫個人所負責的業務，所以一定要將每個模塊來源都清清楚楚的表達出來，方便開發之間的銜接。

后置條件（我要到那里去）

使用該功能后，對業務、數據功能，產生的影響與結果；

功能簡述

描寫本功能需要實現的商業價值或目的；

詳情描述

將功能”我怎么來，我怎么去“清清楚楚的表達出來。變成計算機邏輯便是，頁面布局、操作邏輯進行詳細的說明。常規而言：

• 前臺：主要是字段、交互邏輯組成；
• 后臺：主要是判斷邏輯、列表表單、查詢條件、交互邏輯組成；

四、其它功能

其它功能目的在于，功能描述針對于本次產品功能的核心業務，而其它功能針對于觸發或需要其它功能變動的業務。功能描述清晰的讓開發了解核心，而其它功能便讓開發清晰的了解非核心。

而其它功能，主要由以下內容組成

其他接口

對其它系統產生“字段、業務流程”進行說明；本次產品或業務，對前后臺那些非主流程模塊產生影響；

系統風險評估

當前設計的功能存在哪些缺陷、注意事項與后期的功能拓展如何解決這些問題；

其它需求

對一些非核心的功能點進行詳情描述。如：一些需過濾的關鍵字、新增某個欄目字段。

五、綜述

通過上述內容，能以通用版的形式，清晰的將所負責產品與功能表達出來，而業務描述、功能描述、其它功能。是產品需求文檔重要的組成部份，將產品需求較為全面、有效的描述出來。

同時，能訓練PM邏輯思維，提升文字表達能力、業務理解能力，從整體上讓PM在需求管理上，明顯更加專業，所負責功能的邏輯關系、數據流的來與去都能很好的把控。

六、附語

不論是什么格式，倒爺堅持一個觀點，適合團隊才是好的模板。當前很多的公司在進行MVP迭代的時候會使用Axure+內容描述的形式。雖然，這種形式，是很難將邏輯關系表達清晰，同時會有非常多的思維漏洞。在進行文檔歸檔時，也很難對根據關鍵字進行檢索。但，確實挺適合進行MVP迭代，出現問題修改起來也方便，這種方式比較適合項目流程完善的企業平臺使用。

而在敏捷性開發匯總，倒爺習慣流程圖+功能框架（功能點）+Axure（原型圖繪制），從核心的業務流開始，逐漸迭代至功能完善，這個過程也將文檔補齊。

但有些公司會在EXCEL里進行需求文檔撰寫，進行版本管理（這個也不錯）。

但，作為新人，需要記住：你能寫復雜的東西，簡單的東西也能能寫；但當然一開始只寫簡單的東西，那你一輩子只能做簡單的東西。

大道至簡，簡難而繁易；經歷過復雜的訓練與要求，才能簡化再簡化。

作者：倒爺，微信：ftl_keen。

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