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

一、簡述

產(chǎn)品需求文檔是產(chǎn)品人員非常核心的基本功！是協(xié)調(diào)研發(fā)、測試、UED、業(yè)務(wù)非常重要的重要工具。但是，往往很多新入行的PM與互聯(lián)網(wǎng)領(lǐng)域的PM，產(chǎn)出的文檔往往不盡人意，主要體現(xiàn)在：

• 缺乏邏輯，語言啰嗦不精練；
• 通俗的用詞過多，整體顯的不專業(yè)；
• 無法將字段的數(shù)據(jù)結(jié)構(gòu)、邏輯關(guān)系清晰的表達出來；
• 缺乏開發(fā)思維；

而出現(xiàn)這種原因在于：

• 新人入職，沒有經(jīng)過嚴謹?shù)奈臋n撰寫、流程設(shè)計訓練；
• 大多數(shù)的PM非研發(fā)出身，對前后臺的業(yè)務(wù)邏輯、數(shù)據(jù)結(jié)構(gòu)了解不清晰；
• 分工細，版本迭代迅速，對功能點理解不夠透徹；

完善的產(chǎn)品需求文檔，不但利于PM對所承接的功能進行有效的管控，將業(yè)務(wù)邏輯梳理清晰，對分解的功能點，進行協(xié)調(diào)測試、研發(fā)、設(shè)計、運營同時開展工作；

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

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

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

二、業(yè)務(wù)描述

任何的業(yè)務(wù)或需求，都有業(yè)務(wù)提出方，業(yè)務(wù)提出是相關(guān)的業(yè)務(wù)部門或產(chǎn)品經(jīng)理自身。

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

• 業(yè)務(wù)背景
• 產(chǎn)品功能概述
• 產(chǎn)品前景分析
• 產(chǎn)品功能整體流程
• 產(chǎn)品邏輯關(guān)系
• 面向?qū)ο?/li>
• 應(yīng)用對象
• 名詞解釋
• 參考文檔

上述的這些層面，以通用版的角度，將產(chǎn)品的價值傳遞給研發(fā)方與業(yè)務(wù)方，實現(xiàn)之間有效的銜接。

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

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

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

另一方面，非常多的企業(yè)，內(nèi)部的項目流程是不完善的，且并非每一位研發(fā)人員都是善類。產(chǎn)品經(jīng)理往往需要兼?zhèn)渲椖拷?jīng)理的職責，推動著項目實現(xiàn)研發(fā)上線。在這種情況下，如果業(yè)務(wù)價值描述不清晰，功能在開發(fā)與上線后出現(xiàn)問題，這個鍋注定是要背的。

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

下面，我對組成業(yè)務(wù)描述的組成元素進行描述：

業(yè)務(wù)背景描述：

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

產(chǎn)品功能描述：

對當前功能進行概述，所設(shè)計的產(chǎn)品或功能的功能模塊，新增、完善、優(yōu)化那些產(chǎn)品功能；

產(chǎn)品前景描述：

本產(chǎn)品或功能，希望對那些轉(zhuǎn)化率指標或?qū)崿F(xiàn)那些目的；

產(chǎn)品的整體流程：

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

通過而言，簡單的需求將主業(yè)務(wù)流與邏輯關(guān)系流表達出來便可以；但涉及復雜的業(yè)務(wù)，便將產(chǎn)品或功能涉及的主要流程繪制出來；而流程目的，主要是清晰的將前后臺的邏輯關(guān)系與數(shù)據(jù)結(jié)構(gòu)表達出來；一方面方便開發(fā)理解業(yè)務(wù)與數(shù)據(jù)流，另一方面也方便產(chǎn)品人員梳理自身需求的業(yè)務(wù)邏輯；利于后續(xù)與研發(fā)進行溝通。

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

• 前臺：主要是交互、數(shù)據(jù)流程；
• 后臺：主要是業(yè)務(wù)邏輯判斷、數(shù)據(jù)流；

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

功能框架：

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

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

• 產(chǎn)品架構(gòu)：對前后臺的各個系統(tǒng)與管理模塊的邏輯關(guān)系，一般是對業(yè)務(wù)極其熟悉的業(yè)務(wù)構(gòu)架師與資深的產(chǎn)品總監(jiān)搭建，里面涉及每個接口如何進行對接耦合。
• 功能架構(gòu)：所負責的產(chǎn)品或功能的前后臺功能的邏輯關(guān)系，簡單點的就是一個產(chǎn)品或功能的前后臺，大一點就是一個系統(tǒng)涉及的功能點之間的耦合。
• 功能框架：功能點所涉及的邏輯關(guān)系。
• 功能結(jié)構(gòu)：功能點所涉及的邏輯關(guān)系。

而“架構(gòu)、框架、結(jié)構(gòu)”區(qū)分在于，所負責的業(yè)務(wù)究竟有多大。但不論如何，它們的表現(xiàn)的原理是一致的。將分解的功能點，之間是如何聯(lián)系的功能結(jié)構(gòu)關(guān)系清晰、簡練的表達即可。

關(guān)于架構(gòu)，包含“功能分解、面向用戶”就夠用了。若再深入，可將分為：“應(yīng)用對象、BI分析（BI需求也寫上去）、系統(tǒng)集成….”。后續(xù)可根據(jù)BI數(shù)據(jù)，對產(chǎn)品進行版本迭代與優(yōu)化。

面向?qū)ο?/strong>