什么是好的產(chǎn)品文檔？好的產(chǎn)品具備如何的特質(zhì)？怎么樣才能寫出優(yōu)秀的產(chǎn)品文檔？本文將就此作出解答。
好的產(chǎn)品文檔
不同的公司對(duì)產(chǎn)品文檔的要求不用，差別也會(huì)很大。 在大公司，可能改一個(gè)小的功能都要經(jīng)過(guò)BRD——MRD——PRD的流程，文檔統(tǒng)一流程化；而在創(chuàng)業(yè)公司，可能產(chǎn)品文檔只需要產(chǎn)品原型搭配上產(chǎn)品邏輯以及相關(guān)功能細(xì)節(jié)。 我們不能評(píng)判形式的好壞，在不同的項(xiàng)目使用最適合的文檔形式才是最重要的。 什么是好的產(chǎn)品文檔呢？往往不能給出一個(gè)明確的定義，我覺(jué)得只要能夠順暢推動(dòng)項(xiàng)目前進(jìn)，在產(chǎn)品開(kāi)發(fā)和測(cè)試過(guò)程中能夠大幅度減少工程師和產(chǎn)品經(jīng)理反復(fù)溝通的文檔，就是優(yōu)秀的產(chǎn)品文檔。 想達(dá)到只提供一份產(chǎn)品文檔而完全不需要溝通，這也是不現(xiàn)實(shí)的，畢竟在產(chǎn)品的研發(fā)過(guò)程中會(huì)出現(xiàn)很多讓我們前期想不到的細(xì)節(jié)。 “大幅度減少工程師和產(chǎn)品經(jīng)理反復(fù)溝通”只是作為檢驗(yàn)產(chǎn)品文檔優(yōu)劣的一個(gè)校驗(yàn)標(biāo)準(zhǔn)。其實(shí)，產(chǎn)品文檔的作用就是為了高效地傳遞產(chǎn)品經(jīng)理對(duì)產(chǎn)品功能的描述的。 基于上述的校驗(yàn)標(biāo)準(zhǔn)，好的產(chǎn)品文檔應(yīng)該具備以下的幾個(gè)特質(zhì)：- 產(chǎn)品邏輯要清晰且流暢。產(chǎn)品文檔的內(nèi)容要前后一致，邏輯通暢，這也是最基本的。如果產(chǎn)品的大邏輯有硬傷，是沒(méi)有辦法進(jìn)行研發(fā)的。同時(shí)，要秉承先整體后局部的原則，先要從全局去定義整體的產(chǎn)品邏輯，再去逐步分解細(xì)節(jié)，這樣研發(fā)人員才可以順暢的開(kāi)展研發(fā)工作。
- 避免產(chǎn)品功能的疏漏。一個(gè)產(chǎn)品功能牽連的信息和邏輯越多就越會(huì)產(chǎn)生考慮不周全的情況，研發(fā)人員會(huì)在寫代碼的過(guò)程中就會(huì)產(chǎn)生問(wèn)題了。所以在描述產(chǎn)品功能時(shí)，要考慮到所有的情況，比如會(huì)不會(huì)對(duì)其他模塊產(chǎn)生影響？異常流程的描述，邊界情況等。
- 文檔的可讀性要強(qiáng)。能用圖描述的一定嫌麻煩用文字，多用流程圖、用例圖、時(shí)序圖等去描述你的產(chǎn)品。在涉及到很細(xì)節(jié)的交互時(shí)，最好將相關(guān)功能做出高保真原型圖供研發(fā)人員參考。這些圖能比文字更好地傳達(dá)設(shè)計(jì)思想。
好文檔背后的邏輯
上面討論了好的產(chǎn)品文檔應(yīng)該具備的特質(zhì)，那么如何做才能促使一個(gè)好文檔的誕生呢？這背后往往會(huì)涉及到一些邏輯，好的產(chǎn)品文檔就是基于這些邏輯呈現(xiàn)出來(lái)的。產(chǎn)品業(yè)務(wù)流程的邏輯
產(chǎn)品的業(yè)務(wù)流程始終在支撐著整個(gè)產(chǎn)品，產(chǎn)品的最終交付也是要基于業(yè)務(wù)流程去實(shí)現(xiàn)的。 業(yè)務(wù)流程指的是實(shí)現(xiàn)產(chǎn)品所提供的功能或服務(wù)的具體流程步驟。有很多的產(chǎn)品都有很多的功能，用戶使用這一個(gè)功能往往會(huì)涉及到很多的步驟，這背后的業(yè)務(wù)邏輯/流程是我們要梳理清晰的。 這里可以借用編程的兩種維度去分析業(yè)務(wù)流程的邏輯：面向過(guò)程和面向?qū)ο蟆? 面向過(guò)程： 面向過(guò)程是指，要完成一個(gè)功能，中間會(huì)涉及到很多的操作步驟，而在這些操作步驟中要整理出健全的操作流程，邏輯要清晰并且不要有遺漏。 比如，在電商產(chǎn)品中，用戶要實(shí)現(xiàn)下單的功能，此時(shí)會(huì)涉及到的大流程包括：瀏覽商品——查看商品詳情——加入購(gòu)物車——進(jìn)入結(jié)算中心——結(jié)算——產(chǎn)生訂單，這只是涉及到的大的操作步驟，其中還會(huì)涉及到：編輯/刪除購(gòu)物車中的商品、商品庫(kù)存的判斷、優(yōu)惠券的編輯/刪除/狀態(tài)判斷、第三方支付平臺(tái)的對(duì)接、第三方支付訂單數(shù)據(jù)的返回、訂單狀態(tài)的更改等等。 在這里，我們一定要用流程圖去繪制整體的流程，有必要時(shí)要加入泳道、角色等關(guān)鍵信息，直觀地展示出在哪里要處理那些信息等關(guān)鍵要素。 面向?qū)ο螅?/strong> 產(chǎn)品中的對(duì)象是對(duì)具有完整生命周期的一類的描述，比如，飛機(jī)大戰(zhàn)游戲中的飛機(jī)是一個(gè)類，敵機(jī)是一個(gè)類。一個(gè)對(duì)象的生命周期就表示一次完整功能的使用。這個(gè)對(duì)象一定是要具有生命周期的。比如訂單，從生成到完成中間會(huì)有很多的狀態(tài)，每一個(gè)狀態(tài)都會(huì)涉及到哪些操作？哪些流程？都要用狀態(tài)圖或流程題來(lái)描述。信息架構(gòu)的邏輯
具有復(fù)雜度的產(chǎn)品，清晰定義它的信息架構(gòu)是十分重要的。 如果不去清晰劃分其結(jié)構(gòu)，使用者的分工就無(wú)法開(kāi)展，相關(guān)的功能也就無(wú)法定義。 比如涉及用戶端和企業(yè)端的產(chǎn)品，普通用戶和企業(yè)用戶都在產(chǎn)品上工作，所以必須要清晰劃分產(chǎn)品的信息架構(gòu)，提供清晰的責(zé)任分工和協(xié)作流程。 在規(guī)劃產(chǎn)品的信息架構(gòu)時(shí)，可以采用先拆解再整合的邏輯。 拆解： 拆解就是要把產(chǎn)品涉及到的所有功能枚舉出來(lái)，拆分成相對(duì)獨(dú)立的一個(gè)個(gè)模塊。 比如，我之前負(fù)責(zé)的一款創(chuàng)客類用戶和企業(yè)類用戶共同使用的產(chǎn)品，就要針對(duì)創(chuàng)客用戶端和企業(yè)用戶端分別拆分出對(duì)應(yīng)的所有功能模塊。 整合： 接下來(lái)，我們就要把已經(jīng)拆解好的功能予以整合。 根據(jù)不同用戶端的功能，將瑣碎的功能點(diǎn)整合到一個(gè)個(gè)的模塊中去，比如個(gè)人中心模塊、登錄注冊(cè)模塊、充值模塊、VIP專區(qū)模塊、軟件模塊等。 有了整合后的信息架構(gòu)，我們就對(duì)不同類型用戶的產(chǎn)品結(jié)構(gòu)一目了然了。未來(lái)如果迭代功能，就可以在相對(duì)應(yīng)的模塊中為功能找到對(duì)應(yīng)的位置。
任何產(chǎn)品在處理信息架構(gòu)時(shí)，都可以采用類似的“拆解——整合”的方法，為產(chǎn)品整理出對(duì)應(yīng)的模塊劃分。
產(chǎn)品功能的邏輯
對(duì)于產(chǎn)品的功能邏輯，我們?cè)诿枋鲆粋€(gè)功能點(diǎn)的方案時(shí)，有時(shí)無(wú)論多么謹(jǐn)慎也會(huì)出現(xiàn)有遺漏的地方。所以，我們?cè)诿枋霎a(chǎn)品的一個(gè)功能點(diǎn)的方案時(shí)，一定要捋清邏輯，把涉及到的所有情況/內(nèi)容都要有條理且完整的描述清楚。 比如，我在之前負(fù)責(zé)的一款項(xiàng)目中，會(huì)涉及到管理員端變更用戶端數(shù)據(jù)后顯示的情況，而且會(huì)涉及不同的顯示類型，我采用的就是用表格的形式澄清所有的情況：
采用這種方法，對(duì)于研發(fā)人員來(lái)說(shuō)，這就是具體的、清晰的。針對(duì)不同的類型，不同的情況去處理就好了。
在進(jìn)行產(chǎn)品功能的描述時(shí)，可以從以下幾方面去實(shí)施：
- 要完整，避免疏漏。要枚舉出全部涉及到的情況、異常流程，并且要根據(jù)這些情況去分別詳述功能內(nèi)容。如果相關(guān)的情況較多并且也比較復(fù)雜，就可以采用表格的形式去展示。
- 描述文案要明確。在描述功能時(shí)，描述文案一定要符合產(chǎn)品前期做好的定位，同一類的名詞要統(tǒng)一，這樣才能有助于提升溝通效率。比如，產(chǎn)品啟動(dòng)會(huì)上，高層已經(jīng)明確產(chǎn)品內(nèi)出現(xiàn)的素材文件統(tǒng)一叫“作品”，在研發(fā)過(guò)程中，我發(fā)現(xiàn)產(chǎn)品后臺(tái)對(duì)素材的叫法還是“商品”，這就會(huì)對(duì)運(yùn)營(yíng)同學(xué)造成困擾。
- 要考慮到所有影響的面。產(chǎn)品的功能越多，就越可能牽一發(fā)而動(dòng)全身。產(chǎn)品功能的改動(dòng)，往往會(huì)牽扯到其他功能點(diǎn)的同時(shí)變動(dòng)，哪怕只是一個(gè)小小的變動(dòng)。還是以我之前負(fù)責(zé)的產(chǎn)品為例，用戶端在兌換的方式上做了一些功能的調(diào)整，涉及到了部分頁(yè)面的調(diào)整。都已經(jīng)重新發(fā)布上線了，才發(fā)現(xiàn)新手幫助內(nèi)的文案及截圖還沒(méi)有做調(diào)整，我急忙登錄后臺(tái)，做了更改。好在產(chǎn)品的用戶量小，沒(méi)有造成多大問(wèn)題。所以 ，在調(diào)整一項(xiàng)功能時(shí)，最好事先將可能影響到的功能或模塊，全部羅列出來(lái)，事后反復(fù)核對(duì)。
- 最好加入功能背景的描述。加入功能的背景的描述以及要達(dá)到的目的，可以讓團(tuán)隊(duì)成員清晰了解需求發(fā)生的背景可，也更利于團(tuán)隊(duì)理解產(chǎn)品。
最后
產(chǎn)品的文檔沒(méi)有統(tǒng)一的模板標(biāo)準(zhǔn)，公司里能提供既有的模板固然是好的，可以有助于公司的文檔管理。 如果沒(méi)有模板，用一頁(yè)原型+邏輯描述能清晰說(shuō)明功能也是可以的。最重要的還是團(tuán)隊(duì)之間的協(xié)作方式，文檔的終極作用還是要能夠大幅度減少工程師和產(chǎn)品經(jīng)理的反復(fù)溝通，增強(qiáng)彼此的工作效率。愛(ài)盈利-運(yùn)營(yíng)小咖秀(www.jza6.com) 始終堅(jiān)持研究分享移動(dòng)互聯(lián)網(wǎng)App運(yùn)營(yíng)推廣經(jīng)驗(yàn)、策略、全案、渠道等純干貨知識(shí)內(nèi)容；是廣大App運(yùn)營(yíng)從業(yè)者的知識(shí)啟蒙、成長(zhǎng)指導(dǎo)、進(jìn)階學(xué)習(xí)的集聚平臺(tái)；
想了解更多移動(dòng)互聯(lián)網(wǎng)干貨知識(shí)，請(qǐng)關(guān)注微信公眾號(hào)運(yùn)營(yíng)小咖秀（ID: yunyingshow）
【轉(zhuǎn)載說(shuō)明】 若上述素材出現(xiàn)侵權(quán)，請(qǐng)及時(shí)聯(lián)系我們刪除及進(jìn)行處理：[email protected]
