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

什么是好的產品文檔？好的產品具備如何的特質？怎么樣才能寫出優秀的產品文檔？本文將就此作出解答。

好的產品文檔

不同的公司對產品文檔的要求不用，差別也會很大。

在大公司，可能改一個小的功能都要經過BRD——MRD——PRD的流程，文檔統一流程化；而在創業公司，可能產品文檔只需要產品原型搭配上產品邏輯以及相關功能細節。

我們不能評判形式的好壞，在不同的項目使用最適合的文檔形式才是最重要的。

什么是好的產品文檔呢？往往不能給出一個明確的定義，我覺得只要能夠順暢推動項目前進，在產品開發和測試過程中能夠大幅度減少工程師和產品經理反復溝通的文檔，就是優秀的產品文檔。

想達到只提供一份產品文檔而完全不需要溝通，這也是不現實的，畢竟在產品的研發過程中會出現很多讓我們前期想不到的細節。

“大幅度減少工程師和產品經理反復溝通”只是作為檢驗產品文檔優劣的一個校驗標準。其實，產品文檔的作用就是為了高效地傳遞產品經理對產品功能的描述的。

基于上述的校驗標準，好的產品文檔應該具備以下的幾個特質：

• 產品邏輯要清晰且流暢。產品文檔的內容要前后一致，邏輯通暢，這也是最基本的。如果產品的大邏輯有硬傷，是沒有辦法進行研發的。同時，要秉承先整體后局部的原則，先要從全局去定義整體的產品邏輯，再去逐步分解細節，這樣研發人員才可以順暢的開展研發工作。
• 避免產品功能的疏漏。一個產品功能牽連的信息和邏輯越多就越會產生考慮不周全的情況，研發人員會在寫代碼的過程中就會產生問題了。所以在描述產品功能時，要考慮到所有的情況，比如會不會對其他模塊產生影響？異常流程的描述，邊界情況等。
• 文檔的可讀性要強。能用圖描述的一定嫌麻煩用文字，多用流程圖、用例圖、時序圖等去描述你的產品。在涉及到很細節的交互時，最好將相關功能做出高保真原型圖供研發人員參考。這些圖能比文字更好地傳達設計思想。

好文檔背后的邏輯

上面討論了好的產品文檔應該具備的特質，那么如何做才能促使一個好文檔的誕生呢？這背后往往會涉及到一些邏輯，好的產品文檔就是基于這些邏輯呈現出來的。

產品業務流程的邏輯

產品的業務流程始終在支撐著整個產品，產品的最終交付也是要基于業務流程去實現的。

業務流程指的是實現產品所提供的功能或服務的具體流程步驟。有很多的產品都有很多的功能，用戶使用這一個功能往往會涉及到很多的步驟，這背后的業務邏輯/流程是我們要梳理清晰的。

這里可以借用編程的兩種維度去分析業務流程的邏輯：面向過程和面向對象。

面向過程：

面向過程是指，要完成一個功能，中間會涉及到很多的操作步驟，而在這些操作步驟中要整理出健全的操作流程，邏輯要清晰并且不要有遺漏。

比如，在電商產品中，用戶要實現下單的功能，此時會涉及到的大流程包括：瀏覽商品——查看商品詳情——加入購物車——進入結算中心——結算——產生訂單，這只是涉及到的大的操作步驟，其中還會涉及到：編輯/刪除購物車中的商品、商品庫存的判斷、優惠券的編輯/刪除/狀態判斷、第三方支付平臺的對接、第三方支付訂單數據的返回、訂單狀態的更改等等。

在這里，我們一定要用流程圖去繪制整體的流程，有必要時要加入泳道、角色等關鍵信息，直觀地展示出在哪里要處理那些信息等關鍵要素。

面向對象：

產品中的對象是對具有完整生命周期的一類的描述，比如，飛機大戰游戲中的飛機是一個類，敵機是一個類。一個對象的生命周期就表示一次完整功能的使用。這個對象一定是要具有生命周期的。比如訂單，從生成到完成中間會有很多的狀態，每一個狀態都會涉及到哪些操作？哪些流程？都要用狀態圖或流程題來描述。

信息架構的邏輯

具有復雜度的產品，清晰定義它的信息架構是十分重要的。

如果不去清晰劃分其結構，使用者的分工就無法開展，相關的功能也就無法定義。

比如涉及用戶端和企業端的產品，普通用戶和企業用戶都在產品上工作，所以必須要清晰劃分產品的信息架構，提供清晰的責任分工和協作流程。

在規劃產品的信息架構時，可以采用先拆解再整合的邏輯。

拆解：

拆解就是要把產品涉及到的所有功能枚舉出來，拆分成相對獨立的一個個模塊。

比如，我之前負責的一款創客類用戶和企業類用戶共同使用的產品，就要針對創客用戶端和企業用戶端分別拆分出對應的所有功能模塊。

整合：

接下來，我們就要把已經拆解好的功能予以整合。

根據不同用戶端的功能，將瑣碎的功能點整合到一個個的模塊中去，比如個人中心模塊、登錄注冊模塊、充值模塊、VIP專區模塊、軟件模塊等。

有了整合后的信息架構，我們就對不同類型用戶的產品結構一目了然了。未來如果迭代功能，就可以在相對應的模塊中為功能找到對應的位置。

任何產品在處理信息架構時，都可以采用類似的“拆解——整合”的方法，為產品整理出對應的模塊劃分。

產品功能的邏輯

對于產品的功能邏輯，我們在描述一個功能點的方案時，有時無論多么謹慎也會出現有遺漏的地方。所以，我們在描述產品的一個功能點的方案時，一定要捋清邏輯，把涉及到的所有情況/內容都要有條理且完整的描述清楚。

比如，我在之前負責的一款項目中，會涉及到管理員端變更用戶端數據后顯示的情況，而且會涉及不同的顯示類型，我采用的就是用表格的形式澄清所有的情況：

采用這種方法，對于研發人員來說，這就是具體的、清晰的。針對不同的類型，不同的情況去處理就好了。

在進行產品功能的描述時，可以從以下幾方面去實施：

• 要完整，避免疏漏。要枚舉出全部涉及到的情況、異常流程，并且要根據這些情況去分別詳述功能內容。如果相關的情況較多并且也比較復雜，就可以采用表格的形式去展示。
• 描述文案要明確。在描述功能時，描述文案一定要符合產品前期做好的定位，同一類的名詞要統一，這樣才能有助于提升溝通效率。比如，產品啟動會上，高層已經明確產品內出現的素材文件統一叫“作品”，在研發過程中，我發現產品后臺對素材的叫法還是“商品”，這就會對運營同學造成困擾。
• 要考慮到所有影響的面。產品的功能越多，就越可能牽一發而動全身。產品功能的改動，往往會牽扯到其他功能點的同時變動，哪怕只是一個小小的變動。還是以我之前負責的產品為例，用戶端在兌換的方式上做了一些功能的調整，涉及到了部分頁面的調整。都已經重新發布上線了，才發現新手幫助內的文案及截圖還沒有做調整，我急忙登錄后臺，做了更改。好在產品的用戶量小，沒有造成多大問題。所以 ，在調整一項功能時，最好事先將可能影響到的功能或模塊，全部羅列出來，事后反復核對。
• 最好加入功能背景的描述。加入功能的背景的描述以及要達到的目的，可以讓團隊成員清晰了解需求發生的背景可，也更利于團隊理解產品。

最后

產品的文檔沒有統一的模板標準，公司里能提供既有的模板固然是好的，可以有助于公司的文檔管理。

如果沒有模板，用一頁原型+邏輯描述能清晰說明功能也是可以的。最重要的還是團隊之間的協作方式，文檔的終極作用還是要能夠大幅度減少工程師和產品經理的反復溝通，增強彼此的工作效率。

#專欄作家#

流年，人人都是產品經理專欄作家?；ヂ摼W產品設計師，4年互聯網產品設計經驗。擅長用戶體驗設計，喜歡鉆研需求功能背后的技術實現方式；在成為綜合型產品設計師的道路上不斷努力前進！

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

題圖來自Unsplash，基于CC0協議