一、簡(jiǎn)述
產(chǎn)品需求文檔是產(chǎn)品人員非常核心的基本功！是協(xié)調(diào)研發(fā)、測(cè)試、UED、業(yè)務(wù)非常重要的重要工具。
?但是，往往很多新入行的PM與互聯(lián)網(wǎng)領(lǐng)域的PM，產(chǎn)出的文檔往往不盡人意，主要體現(xiàn)在：
·缺乏邏輯，語(yǔ)言啰嗦不精練；
·通俗的用詞過多，整體顯的不專業(yè)；
·無法將字段的數(shù)據(jù)結(jié)構(gòu)、邏輯關(guān)系清晰的表達(dá)出來；
·缺乏開發(fā)思維；
而出現(xiàn)這種原因在于：
·新人入職，沒有經(jīng)過嚴(yán)謹(jǐn)?shù)奈臋n撰寫、流程設(shè)計(jì)訓(xùn)練；
·大多數(shù)的PM非研發(fā)出身，對(duì)前后臺(tái)的業(yè)務(wù)邏輯、數(shù)據(jù)結(jié)構(gòu)了解不清晰；
·分工細(xì)，版本迭代迅速，對(duì)功能點(diǎn)理解不夠透徹；
完善的產(chǎn)品需求文檔，不但利于PM對(duì)所承接的功能進(jìn)行有效的管控，將業(yè)務(wù)邏輯梳理清晰，對(duì)分解的功能點(diǎn)，進(jìn)行協(xié)調(diào)測(cè)試、研發(fā)、設(shè)計(jì)、運(yùn)營(yíng)同時(shí)開展工作；
雖然，不同的公司擁有不同的產(chǎn)品需求文檔模板！但，不論模板格式如何，文檔的本質(zhì)在于：“有效的將功能清晰的表達(dá)出來，并且能支撐后續(xù)的業(yè)務(wù)交接與版本迭代參考，對(duì)上與下進(jìn)行價(jià)值傳遞。"并且，隨著平臺(tái)業(yè)務(wù)的發(fā)展，歸檔、倉(cāng)儲(chǔ)起來的業(yè)務(wù)文檔，便是極其有價(jià)值的知識(shí)庫(kù)，里面匯總了各個(gè)時(shí)期里PM、研發(fā)、測(cè)試、項(xiàng)目經(jīng)理、設(shè)計(jì)….對(duì)業(yè)務(wù)是如何進(jìn)行思考，對(duì)文檔研究的本身，側(cè)面也反應(yīng)了企業(yè)是如何將戰(zhàn)略進(jìn)行細(xì)節(jié)落實(shí)。
而，“業(yè)務(wù)描述、功能描述、其它需求”是組成產(chǎn)品需求文檔非常重要的模塊；本篇章，將以通用版的角度，對(duì)這些模塊行介紹；
二、業(yè)務(wù)描述
任何的業(yè)務(wù)或需求，都有業(yè)務(wù)提出方，業(yè)務(wù)提出是相關(guān)的業(yè)務(wù)部門或產(chǎn)品經(jīng)理自身。
業(yè)務(wù)來源的本質(zhì)，便是希望通過這個(gè)業(yè)務(wù)解決那些實(shí)際的問題，達(dá)到提升某些轉(zhuǎn)化率或某些目的；業(yè)務(wù)描述清晰的表達(dá)出來即可，不需要多復(fù)雜，但常規(guī)包括：
·業(yè)務(wù)背景
·產(chǎn)品功能概述
·產(chǎn)品前景分析
·產(chǎn)品功能整體流程
·產(chǎn)品邏輯關(guān)系
·面向?qū)ο?/b>
·應(yīng)用對(duì)象
·名詞解釋
·參考文檔
上述的這些層面，以通用版的角度，將產(chǎn)品的價(jià)值傳遞給研發(fā)方與業(yè)務(wù)方，實(shí)現(xiàn)之間有效的銜接；
為什么，我們需要進(jìn)行業(yè)務(wù)、功能、概述這些偏宏觀不實(shí)際的描述呢？這樣不是很麻煩，且浪費(fèi)時(shí)間？
我們要知道，每新增或刪除一個(gè)功能，狹義來看也沒啥不打了。但站在宏觀的角度去看，功能研發(fā)是需要耗資企業(yè)運(yùn)營(yíng)成本。如果處理不完善，浪費(fèi)運(yùn)營(yíng)成本同時(shí)，甚至影響整個(gè)用戶體驗(yàn)與開發(fā)規(guī)則。
身為產(chǎn)品人員在未傳達(dá)產(chǎn)品的業(yè)務(wù)價(jià)值前提條件下，便強(qiáng)勢(shì)驅(qū)動(dòng)研發(fā)人員進(jìn)入開發(fā)階段，這是錯(cuò)誤的！我要是研發(fā)，我也會(huì)拍死這位PM。那么業(yè)務(wù)描述的本質(zhì)便很清晰了，便將業(yè)務(wù)價(jià)值，傳遞給團(tuán)隊(duì)成員。
另一方面，非常多的企業(yè)，內(nèi)部的項(xiàng)目流程是不完善的，且并非每一位研發(fā)人員都是善類。產(chǎn)品經(jīng)理往往需要兼?zhèn)渲?xiàng)目經(jīng)理的職責(zé)，推動(dòng)著項(xiàng)目實(shí)現(xiàn)研發(fā)上線。在這種情況下，如果業(yè)務(wù)價(jià)值描述不清晰，功能在開發(fā)與上線后出現(xiàn)問題，這個(gè)鍋?zhàn)⒍ㄊ且车摹?/p>
BTW，這些我就不都說了，自己工作中慢慢積累！
下面，我對(duì)組成業(yè)務(wù)描述的組成元素進(jìn)行描述：
·業(yè)務(wù)背景描述：
這里，你必須將業(yè)務(wù)提出方描寫出來，并且細(xì)致到業(yè)務(wù)方為什么將這個(gè)需求提出來！為什么？一方面，你要告訴研發(fā)人員，你為什么設(shè)計(jì)這個(gè)產(chǎn)品或功能，這個(gè)需求從來源到設(shè)計(jì)是有原因的。另一方面，拉上相關(guān)業(yè)務(wù)部門，你至少不是一個(gè)人在戰(zhàn)斗。
·產(chǎn)品功能描述：
對(duì)當(dāng)前功能進(jìn)行概述，所設(shè)計(jì)的產(chǎn)品或功能的功能模塊，新增、完善、優(yōu)化那些產(chǎn)品功能；
·產(chǎn)品前景描述：
本產(chǎn)品或功能，希望對(duì)那些轉(zhuǎn)化率指標(biāo)或?qū)崿F(xiàn)那些目的；
·產(chǎn)品的整體流程：（Visio、Axure（Axure畫的流程圖好丑））
通過而言，簡(jiǎn)單的需求將主業(yè)務(wù)流與邏輯關(guān)系流表達(dá)出來便可以；但涉及復(fù)雜的業(yè)務(wù)，便將產(chǎn)品或功能涉及的主要流程繪制出來；而流程目的，主要是清晰的將前后臺(tái)的邏輯關(guān)系與數(shù)據(jù)結(jié)構(gòu)表達(dá)出來；一方面方便開發(fā)理解業(yè)務(wù)與數(shù)據(jù)流，另一方面也方便產(chǎn)品人員梳理自身需求的業(yè)務(wù)邏輯；利于后續(xù)與研發(fā)進(jìn)行溝通。
具體的流程數(shù)量，根據(jù)業(yè)務(wù)的復(fù)雜程度決定，一般只需要將核心的流程繪制出來便可；
前臺(tái)，主要是交互、數(shù)據(jù)流程；
后臺(tái)，主要是業(yè)務(wù)邏輯判斷、數(shù)據(jù)流；
前后臺(tái)的流程湊在一起，能清晰的看到前后臺(tái)的模塊之間，是如何進(jìn)行耦合的，數(shù)據(jù)儲(chǔ)存、提取、處理、分析。
·功能框架：（Mindjet Minmanager、Xmind畫的框架圖好丑）
框架圖的意義在于，能讓查看或了解業(yè)務(wù)的人，全方位的了解功能之間的功能點(diǎn)的邏輯關(guān)系。同時(shí)，一份優(yōu)秀的框架圖，能讓PM站在全局的基本面上，對(duì)個(gè)人所負(fù)責(zé)的產(chǎn)品進(jìn)行全局的規(guī)劃，對(duì)前后臺(tái)的功能進(jìn)行把握，達(dá)到支撐平臺(tái)業(yè)務(wù)。
產(chǎn)品架構(gòu)：對(duì)前后臺(tái)的各個(gè)系統(tǒng)與管理模塊的邏輯關(guān)系，一般是對(duì)業(yè)務(wù)極其熟悉的業(yè)務(wù)構(gòu)架師與資深的產(chǎn)品總監(jiān)搭建，里面涉及每個(gè)接口如何進(jìn)行對(duì)接耦合。
功能架構(gòu)：所負(fù)責(zé)的產(chǎn)品或功能的前后臺(tái)功能的邏輯關(guān)系，簡(jiǎn)單點(diǎn)的就是一個(gè)產(chǎn)品或功能的前后臺(tái)，大一點(diǎn)就是一個(gè)系統(tǒng)涉及的功能點(diǎn)之間的耦合。
功能框架：功能點(diǎn)所涉及的邏輯關(guān)系。
功能結(jié)構(gòu)：功能點(diǎn)所涉及的邏輯關(guān)系。
而“架構(gòu)、框架、結(jié)構(gòu)”區(qū)分在于，所負(fù)責(zé)的業(yè)務(wù)究竟有多大。但不論如何，它們的表現(xiàn)的原理是一致的。將分解的功能點(diǎn)，之間是如何聯(lián)系的功能結(jié)構(gòu)關(guān)系清晰、簡(jiǎn)練的表達(dá)即可。
關(guān)于架構(gòu)，包含“功能分解、面向用戶”就夠用了。若再深入，可將分為：“應(yīng)用對(duì)象、BI分析（BI需求也寫上去）、系統(tǒng)集成….”。后續(xù)可根據(jù)BI數(shù)據(jù)，對(duì)產(chǎn)品進(jìn)行版本迭代與優(yōu)化。
·面向?qū)ο?/b>
表達(dá)產(chǎn)品或功能主要是為那類用戶服務(wù)的。將面向用戶是誰(shuí)，擁有哪些權(quán)限清晰的表達(dá)出來即可，對(duì)個(gè)人進(jìn)行功能設(shè)計(jì)也有很大的幫助。
·應(yīng)用對(duì)象
本功能需要在那些應(yīng)用端或版本進(jìn)行上線，清晰的描繪出來，方便后續(xù)進(jìn)行業(yè)務(wù)交接。
·名詞解釋
將本次文檔涉及一些奇葩的明詞進(jìn)行解釋，這點(diǎn)很重要！有些PM喜歡將一些非常簡(jiǎn)單的內(nèi)容包裝成非常牛逼，讓人看起來很難懂，而事實(shí)上也就做哪些一件簡(jiǎn)單事，但是看的人會(huì)很痛苦：看PRD時(shí)會(huì)想：“這玩意，究竟想表達(dá)什么。
·參考文檔
將所做的本次功能，所參考的那些文檔，附屬上來；目的的在于，方便后續(xù)的業(yè)務(wù)方、研發(fā)方進(jìn)行查看。
三、功能描述
功能描述能否描寫清晰，描寫清晰，開發(fā)找茬都不怕了。如何才能完整的對(duì)功能點(diǎn)進(jìn)行描述呢？圍繞三個(gè)點(diǎn)“功能是誰(shuí)？功能來自哪里？功能要到哪里去？
同時(shí)，功能需求主要分為核心功能、其它功能。不論是核心功能還是其它功能，都可以由以下元素構(gòu)成：
·功能名稱
·面向用戶
·用例圖（Axure、mocking（適合移動(dòng)端進(jìn)行敏捷性開發(fā)）)
·前置條件
·后置條件
·功能簡(jiǎn)述
·詳情描述
而具體的功能描述內(nèi)容，則根據(jù)業(yè)務(wù)（功能點(diǎn)）的復(fù)雜程度，進(jìn)行篩選描寫?？梢匀珜懀部梢圆蝗珜?。但務(wù)必記?。翰徽摵畏N方式，目的在于將業(yè)務(wù)價(jià)值完整、清晰、有條理的傳遞給查看文檔的參與角色。
·功能名稱（我是誰(shuí)）
本功能在系統(tǒng)里的命名。
·面向用戶
本功能的使用對(duì)象。（在前臺(tái)，功能的參與者是少數(shù)的；但后臺(tái)與企業(yè)級(jí)應(yīng)用里，功能的參與者是多個(gè)的）
·用例圖
表達(dá)功能在表現(xiàn)層的邏輯圖；可以是傳統(tǒng)意義上的用例圖，或者是簡(jiǎn)化版的原型圖、流程圖；
·前置條件（我來自哪里）
使用該功能的前提、邏輯關(guān)系說明；公司大了后，每個(gè)開發(fā)都只寫個(gè)人所負(fù)責(zé)的業(yè)務(wù)，所以一定要將每個(gè)模塊來源都清清楚楚的表達(dá)出來，方便開發(fā)之間的銜接。
·后置條件（我要到那里去）
使用該功能后，對(duì)業(yè)務(wù)、數(shù)據(jù)功能，產(chǎn)生的影響與結(jié)果；
·功能簡(jiǎn)述
描寫本功能需要實(shí)現(xiàn)的商業(yè)價(jià)值或目的；
·詳情描述
將功能”我怎么來，我怎么去“清清楚楚的表達(dá)出來。變成計(jì)算機(jī)邏輯便是，頁(yè)面布局、操作邏輯進(jìn)行詳細(xì)的說明。常規(guī)而言：
前臺(tái)：主要是字段、交互邏輯組成；
后臺(tái)：主要是判斷邏輯、列表表單、查詢條件、交互邏輯組成；
四、其它功能
其它功能目的在于，功能描述針對(duì)于本次產(chǎn)品功能的核心業(yè)務(wù)，而其它功能針對(duì)于觸發(fā)或需要其它功能變動(dòng)的業(yè)務(wù)。功能描述清晰的讓開發(fā)了解核心，而其它功能便讓開發(fā)清晰的了解非核心。
而其它功能，主要由以下內(nèi)容組成
·其他接口
對(duì)其它系統(tǒng)產(chǎn)生“字段、業(yè)務(wù)流程”進(jìn)行說明；本次產(chǎn)品或業(yè)務(wù)，對(duì)前后臺(tái)那些非主流程模塊產(chǎn)生影響；
·系統(tǒng)風(fēng)險(xiǎn)評(píng)估
當(dāng)前設(shè)計(jì)的功能存在哪些缺陷、注意事項(xiàng)與后期的功能拓展如何解決這些問題；
·其它需求
對(duì)一些非核心的功能點(diǎn)進(jìn)行詳情描述。如：一些需過濾的關(guān)鍵字、新增某個(gè)欄目字段。
五、綜述
通過上述內(nèi)容，能以通用版的形式，清晰的將所負(fù)責(zé)產(chǎn)品與功能表達(dá)出來，而業(yè)務(wù)描述、功能描述、其它功能。是產(chǎn)品需求文檔重要的組成部份，將產(chǎn)品需求較為全面、有效的描述出來。
同時(shí)，能訓(xùn)練PM邏輯思維，提升文字表達(dá)能力、業(yè)務(wù)理解能力，從整體上讓PM在需求管理上，明顯更加專業(yè)，所負(fù)責(zé)功能的邏輯關(guān)系、數(shù)據(jù)流的來與去都能很好的把控。
六、附語(yǔ)
不論是什么格式，倒?fàn)攬?jiān)持一個(gè)觀點(diǎn)，適合團(tuán)隊(duì)才是好的模板。當(dāng)前很多的公司在進(jìn)行MVP迭代的時(shí)候會(huì)使用Axure+內(nèi)容描述的形式。雖然，這種形式，是很難將邏輯關(guān)系表達(dá)清晰，同時(shí)會(huì)有非常多的思維漏洞。在進(jìn)行文檔歸檔時(shí)，也很難對(duì)根據(jù)關(guān)鍵字進(jìn)行檢索。但，確實(shí)挺適合進(jìn)行MVP迭代，出現(xiàn)問題修改起來也方便，這種方式比較適合項(xiàng)目流程完善的企業(yè)平臺(tái)使用。
而在敏捷性開發(fā)匯總，倒?fàn)斄?xí)慣流程圖+功能框架（功能點(diǎn)）+Axure（原型圖繪制），從核心的業(yè)務(wù)流開始，逐漸迭代至功能完善，這個(gè)過程也將文檔補(bǔ)齊。
但有些公司會(huì)在EXCEL里進(jìn)行需求文檔撰寫，進(jìn)行版本管理。（這個(gè)也不錯(cuò)）
但，作為新人，需要記住：你能寫復(fù)雜的東西，簡(jiǎn)單的東西也能能寫；但當(dāng)然一開始只寫簡(jiǎn)單的東西，那你一輩子只能做簡(jiǎn)單的東西；
大道至簡(jiǎn)，簡(jiǎn)難而繁易；經(jīng)歷過復(fù)雜的訓(xùn)練與要求，才能簡(jiǎn)化再簡(jiǎn)化；
想要倒?fàn)斢H手繪制的《產(chǎn)品需求文檔》模板，請(qǐng)?zhí)砑拥範(fàn)斘⑿牛⑿潘阉髻~號(hào)：“ftl_keen”便可。添加微信時(shí)，請(qǐng)備注“PRD”。
