產(chǎn)品經(jīng)理在工作時，所必須要必備的技能之一——文檔撰寫能力，要如何整理出一份完整的產(chǎn)品文檔呢？下面這篇是筆者分享的關于此的內(nèi)容，大家一起往下看看。

一、撰寫有根有據(jù)的產(chǎn)品文檔

文檔撰寫能力是產(chǎn)品經(jīng)理必須具備的最基本的能力之一。在工作中，產(chǎn)品要輸出各種類型的文檔，如BRD商業(yè)需求文檔，MRD市場需求文檔，PRD產(chǎn)品需求文檔，產(chǎn)品體驗/分析文檔跟競品分析分檔等等。寫作的本質(zhì)是要把自己的思路，想法，IDEA形成文字，以文字的方式表達出來，然后讓閱讀對象閱讀并理解文檔里面的內(nèi)容。這才是一個文檔的完整過程。所以如何才能出一份，合格，優(yōu)良的產(chǎn)品文檔呢？

寫文檔也是有一定的技巧，套路，除了公司發(fā)你那一個標準的模板，本人總結(jié)了以下3步曲：

1. 確定范圍

當要寫一個產(chǎn)品文檔之前，首先要定好文檔的范圍，通常要明確以下幾點：

1. 文檔標題：要定位清晰，內(nèi)容明確，還要加上迭代的版本號
2. 文檔目的：用清晰簡潔的語言描述文檔的目的跟用途
3. 文檔歸屬，閱讀對象
4. 創(chuàng)建時間/更新時間
5. 其它補充

2. 選模板

除了上面提到的文檔類型，還有用戶調(diào)研報告，行業(yè)分析報告等等，公司的模板不一定能很好的表達自己的IDEA，可以選擇合適自己的模板，最好是在自己的日常工作中做好積累。

3. 守規(guī)范

規(guī)劃化是產(chǎn)品經(jīng)理在職業(yè)成長過程中需要具備的一項基本職業(yè)素養(yǎng)。小到文檔撰寫，原型設計的規(guī)范，大到用戶調(diào)研，需求分析以及產(chǎn)品設計，都有一定的規(guī)定可以遵循，這樣往往能事半功倍。

4. 命名規(guī)范

例如：SCRM系統(tǒng)產(chǎn)品需求文檔V10.0，這樣通用標準的格式來命名，就可以準確的表達文檔的定位和類型。也不容易引起歧義。

什么是B端产品经理？和C端产品经理有什么区别？

B端产品经理中的B是Business，商业的意思，B端产品经理首先就要理解这个职位的重要性，要设计出更适合这个项目需求的产品方案，B最终产品经理在日常工作中...

查看详情 >

5. 表達規(guī)范

要注意文字表達的規(guī)范，盡量結(jié)構(gòu)化的語言闡述，用行業(yè)術語表達，而不是口語化，隨意的想到什么就說什么，這樣會表現(xiàn)得很不專業(yè)，很業(yè)余，沒有意思做產(chǎn)品應有的嚴謹與專業(yè)精神。

6. 版本迭代的規(guī)范

文檔不單單是寫給自己，領導看的，還會寫給開發(fā)、測試、運營等整條產(chǎn)品線，做好迭代的規(guī)范才會減少溝通的誤會，引起不必要的內(nèi)耗，也是對其他同事的尊重。

二、繪制思維清晰的流程圖

畫得好的流程圖，可以很好的體現(xiàn)業(yè)務邏輯和產(chǎn)品邏輯；相反，畫歪了，就是無形中增加團隊的理解成本跟內(nèi)耗，還會影響產(chǎn)品的個人形象，對于下一次的產(chǎn)品評審溝通等都會起到減分作用。

當面對復雜的業(yè)務流程和流轉(zhuǎn)邏輯時，語言描述和文字描述，往往沒有流程圖表達的清晰和簡潔，一張清晰簡明的流程圖不僅能更好的描述業(yè)務邏輯，還能查漏補缺。避免功能流程上、邏輯上出現(xiàn)遺漏，確保流程的完整性。流程圖在溝通的過程中思路更加清晰，邏輯更加清楚，有助于程序邏輯的實現(xiàn)和有效解決實際問題。

1. 按表達的主體劃分

1. 業(yè)務流程圖：描述的主體是業(yè)務邏輯。
2. 數(shù)據(jù)流程圖：描述的主體是數(shù)據(jù)流。
3. 程序流程圖：描述的主體是軟件程序的操作流程。
4. 系統(tǒng)流程圖： 同時體現(xiàn)系統(tǒng)的操作流程和數(shù)據(jù)流。

2. 按表現(xiàn)形式劃分

• 一般流程圖：不區(qū)分角色在其中的穿插，只關注業(yè)務、功能本身的閉環(huán)。
• 泳道流程圖：業(yè)務、功能在多個角色之前穿插交互、流轉(zhuǎn)。

3. 按復雜程度劃分

• 基本流程圖：只描述流程的關鍵節(jié)點，忽略細節(jié)闡述。
• 完整流程圖：詳細的畫出整體流程的每一個環(huán)節(jié)。

三、繪制產(chǎn)品原型圖

原型設計在整個產(chǎn)品方案的輸出流程中處于很重要的位置，有這承上啟下的作用。進行原型設計之前，需求描述相對比較抽象，原型設計的過程就是將抽象的需求描述轉(zhuǎn)化成為具象的產(chǎn)品方案的過程，之后再配合PRD和流程圖對原型圖中的功能邏輯、交互邏輯及視覺邏輯進行描述和說明。

原型圖的最大優(yōu)點在于，它可以有效的避免重要的元素被忽略，將需求邏輯可視化，促進整個團隊間的理解。

四、功能結(jié)構(gòu)圖、信息架構(gòu)圖、產(chǎn)品結(jié)構(gòu)圖

對比各種產(chǎn)品輸出物（文檔、原型、流程圖）可以看出，產(chǎn)品結(jié)構(gòu)圖的形式最簡單，其實也就是一個思維導圖，簡稱腦圖，但其復雜程度，涉及的范圍，抽象程度都是最高的，對產(chǎn)品整體的把握能力，思維能力也是最高的。

在進行產(chǎn)品設計時，首先應該產(chǎn)出的是產(chǎn)品結(jié)構(gòu)圖，思考這張圖如何畫的過程，就是幫助你梳理產(chǎn)品設計思路以及確定產(chǎn)品形態(tài)的過程。

其次，產(chǎn)品上線之后，無論是進行內(nèi)部的宣講還是對外的推廣，都需要使用高度抽象，簡潔易懂的載體來介紹產(chǎn)品的整個情況，推廣信息不可能用繁雜的頁面和文字去描述，因此，產(chǎn)品結(jié)構(gòu)圖就是介紹整個產(chǎn)品的理念，功能和設計的最好媒介。

常見的產(chǎn)品結(jié)構(gòu)圖有功能結(jié)構(gòu)圖，信息架構(gòu)圖，產(chǎn)品結(jié)構(gòu)圖，業(yè)務架構(gòu)圖，混合結(jié)構(gòu)圖等等。

主要有以下4個步驟：

1. 確定對象：確定業(yè)務對象。
2. 拆解架構(gòu)：化整為零，拆分各個功能。
3. 挖掘關系：理清個功能之間的干系，并列，父子，支撐，輔助等等。
4. 輸出表達：逆向思維查漏補缺。

五、如何更好的研究和分析用戶

1. 問卷調(diào)研

問卷調(diào)研是用戶調(diào)研過程中應用最廣泛的形式之一，其中最重要的環(huán)節(jié)是設計調(diào)研問卷。問卷設計主要包括：合理性，一般性、邏輯性、明確性、非誘導性、便于理解分析等。

2. 用戶訪談

1）訪談時，訪談者要去適應被訪談者，不要讓被訪談者適應自己。

2）提問不要帶有主觀的誘導性。

3）讓被訪談者說出自己的真正需求，而不是他自己想出的解決方案。

3. 構(gòu)建用戶畫像

1）戰(zhàn)略角度：用戶畫像做好，可以幫助企業(yè)進行市場洞察，預估市場規(guī)模，制定階段性目標，指導重大決策，提升ROI投資回報率。

2）產(chǎn)品角度：可以對用戶進行人群細分，確定產(chǎn)品的核心人群，從而更加準確的做產(chǎn)品定位并優(yōu)化產(chǎn)品功能。

3）數(shù)據(jù)分析的角度：有助于建立數(shù)據(jù)資產(chǎn)，挖掘數(shù)據(jù)的價值，是數(shù)據(jù)分析更加準確，可以進行數(shù)據(jù)交易，促進數(shù)據(jù)流通。

六、管理需求的的方法

1. 挖掘用戶的真實需求

所以的產(chǎn)品的誕生都是基于用戶的需求設計出來的，但用戶往往只會提出眼前的，表面上的訴求，而真正的，本質(zhì)上的需求用戶往往沒有有意識的深思考，不考慮需求的實現(xiàn)前提到底是充分條件，還是必要條件等等。

2. 評估需求的價值

用戶只考慮當下的問題，但是產(chǎn)品往往要考慮用戶維度，研發(fā)維度，商業(yè)維度等等，都是要綜合量化產(chǎn)品的ROI，所以必須要有清晰的價值認識。

3. 評估需求的優(yōu)先級

價值權重，緊急程度，實現(xiàn)的難以程度，上級的指示，先后順序等等。

4. 開好產(chǎn)品的需求評審會

5. 需求池的應用

6. 父需求與子需求的平衡

7. 需求研發(fā)過程中的進度跟進

8. 需求上線后的項目復盤

七、設計優(yōu)秀的產(chǎn)品

1. 構(gòu)建自己的產(chǎn)品設計模型庫

工作中會經(jīng)常遇到一些通用的產(chǎn)品設計方案，這些方案同時具備可遷移性和可復用性，作用于具體的行業(yè)和業(yè)務，只有數(shù)據(jù)上的不同，基于這些獨立的模塊，需要構(gòu)建出自己的產(chǎn)品設計知識地圖，自己的產(chǎn)品設計模型。

2. 交互設計自查表

3. 產(chǎn)品的完整性與業(yè)務的閉環(huán)

4. 產(chǎn)品的高內(nèi)聚與低耦合

保證產(chǎn)品單一功能模塊具備相對豐富的功能，且各模塊之間足夠獨立，一個模塊的改動對其他模塊影響不大，例如在RBAC模型中，賬戶管理，角色管理，權限管理三大模塊就具有高內(nèi)聚低耦合的特性，具體體現(xiàn)在賬戶管理模塊的變更，角色管理模塊的變更，權限管理模塊的變更，三者相互獨立，互不影響。

又如在電商體系的產(chǎn)品設計中，下單流程通常涉及商品模塊，用戶模塊和訂單模塊，在電商管理后臺中，這三大模塊都是完整的功能模塊，呈現(xiàn)出高內(nèi)聚低耦合的特性，這三大模塊都支持各自的增刪查改，都不會對其他模塊造成影響，卻共同支撐整用戶的整個下單操作流程。

5. 產(chǎn)品交互的7大定律

1）菲茨定律：指點到達一個目標的時間，與設備當前的位置，和目標的距離，和 目標的寬度有關。

2）希克定律：一個人面臨的選擇越多，需要做決定的時間就越長。

3）7+-2法則：人類大腦在最好的狀態(tài)下能記住5~9項信息后，后面還有就會容易出錯。

4）接近法則：如果2個或多個對象離得很近時，人的潛意識會認為他們是相關的。

5）防錯原則：我們不可能消除差錯，但是可以人為的發(fā)現(xiàn)并糾正差錯，最大限度避免損失。

6）復雜守恒定律：每一個過程都有其固有的復雜度，存在其臨界點，超過這個點就沒辦法簡化了，只能將復雜從一個地方轉(zhuǎn)移到另一個地方。

7）奧卡姆剃刀原則：如無必要，勿增實體，簡單即有限原則。

6. 雅各布·尼爾森10大交互原則

7. 輸出一份完整的產(chǎn)品分析報告

8. 產(chǎn)品用戶體驗的定義與思考

八、怎么進行數(shù)據(jù)分析

數(shù)據(jù)通?？梢苑譃榻Y(jié)構(gòu)性數(shù)據(jù)和非結(jié)構(gòu)性數(shù)據(jù)，結(jié)構(gòu)化數(shù)據(jù)是指可以按一定的規(guī)則可以格式化存儲的業(yè)務數(shù)據(jù)或用戶基礎數(shù)據(jù)，這些數(shù)據(jù)通常存儲在關系型的數(shù)據(jù)庫中，而非結(jié)構(gòu)型數(shù)據(jù)通常是指那些非格式化處理的數(shù)據(jù)，如用戶的評論數(shù)據(jù)，這些數(shù)據(jù)通常存儲在非關系型的數(shù)據(jù)庫中。

數(shù)據(jù)分析是指用適當?shù)慕y(tǒng)計分析方法對收集起來的大量數(shù)據(jù)進行分析，從中提取出有用的數(shù)據(jù)及形成結(jié)論的過程。數(shù)據(jù)分析通常分為描述性數(shù)據(jù)分析、探索性數(shù)據(jù)分析和驗證性數(shù)據(jù)分析。其中描述性分析是指側(cè)重于對現(xiàn)有的數(shù)據(jù)進行事實或結(jié)論的陳述。探索性分析側(cè)重于在數(shù)據(jù)之中發(fā)現(xiàn)新的特指，驗證性分析側(cè)重于對已有的假設驗證或證偽。

完整的數(shù)據(jù)分析過程分為：

1. 明確目標
2. 獲取數(shù)據(jù)
3. 處理數(shù)據(jù)
4. 展現(xiàn)數(shù)據(jù)
5. 分析數(shù)據(jù)
6. 輸出報告

在數(shù)據(jù)分析過程中，指標是指衡量事物發(fā)展程度的單位或方法，通過需要經(jīng)過計算或統(tǒng)計才能得到，比如PV、UV；維度是指事物本身所帶有的某種特征或?qū)傩?，抑或是一種描述事物的角度，如性別，時間，年齡，收入等。

九、如何做項目管理

瀑布模型將軟件生命周期劃分為需求分析、方案設計、實施/編碼、測試/評估、運維這5個基本活動，并且規(guī)定了它們自上而下，相互銜接的固定順序，如同瀑布流水，逐級下落。

物極必反，實現(xiàn)需求的目標的明確，研發(fā)流程的規(guī)范以及項目流程的嚴格控制，也犧牲了對需求變動響應的靈活性。導致在項目各個階段之間極少的反饋。只有在結(jié)束的后期才看到結(jié)果，如果最終結(jié)果與用戶的期望不一致，則會產(chǎn)生巨大的返工成本。瀑布模型的致命缺點就是不能用戶需求的變化。

敏捷是一種應對快速變化的需求的軟件開發(fā)能力。敏捷不僅強調(diào)技術人員與產(chǎn)品及客戶之間的緊密協(xié)助，還重視面對面的溝通，認為這比書面文檔溝通更加有效，同時要求頻繁交付新的軟件版本并且不斷的反饋。更注重軟件開發(fā)過程中人的作用。

十、總結(jié)

以上，只是總結(jié)的一些方法，最重要的是產(chǎn)品在日常的工作中不斷的實踐，思考和應用，舉一反三，不斷的自我革新，相信都能成為一個優(yōu)秀的產(chǎn)品經(jīng)理。