文檔的撰寫與合格交付一直是困擾在許多產(chǎn)品經(jīng)理心中的一個(gè)難題。為了解決這個(gè)難題，筆者收集了開發(fā)、測(cè)試、設(shè)計(jì)人員多方意見，總結(jié)出這一份文檔交付原則。

眾所周知，需求文檔的撰寫與交付是每位產(chǎn)品經(jīng)理工作中必備的技能，而在筆者寫下這套文檔交付原則之前，筆者所在的產(chǎn)品團(tuán)隊(duì)正面臨著需求文檔混亂、格式不統(tǒng)一、不具備參考性等眾多問題。

筆者在收集了多位開發(fā)、測(cè)試、設(shè)計(jì)人員的意見后，綜合了一些較為優(yōu)秀的PRD需求文檔，最終寫下了這篇文檔交付原則。目前也已經(jīng)成功投入使用，它不僅僅能告訴你如何寫一份需求文檔，也能告訴你文檔在進(jìn)入設(shè)計(jì)、開發(fā)流程前你需要做哪些準(zhǔn)備工作，衷心的希望這篇原則能給讀者們以啟迪！

一、文檔交付流程

文檔從最開始的需求分析到真正以文本格式投入使用往往需要經(jīng)歷以下幾個(gè)階段——即：需求分析→原型設(shè)計(jì)→文檔撰寫→內(nèi)部評(píng)審→外部評(píng)審。

這也是當(dāng)今主流互聯(lián)網(wǎng)公司大多采用的流程，筆者在本文中會(huì)主要介紹：原型設(shè)計(jì)、文檔撰寫、內(nèi)部評(píng)審三個(gè)方面。

二、原型設(shè)計(jì)

原型繪畫是產(chǎn)品經(jīng)理的基礎(chǔ)技能，但現(xiàn)在許多產(chǎn)品經(jīng)理都認(rèn)為繪畫原型沒那么重要，所以草草了事。

但實(shí)際上，一份好的原型不僅能幫助設(shè)計(jì)和后端開發(fā)較好的理解你的意圖，也能增進(jìn)團(tuán)隊(duì)之間的和諧。在筆者的產(chǎn)品工作中，設(shè)計(jì)人員不止一次因?yàn)槟玫揭恍┎灰?guī)范的原型設(shè)計(jì)向筆者抱怨。那么，一份讓大家都滿意的原型應(yīng)該滿足哪些要求呢？

筆者認(rèn)為主要是以下四點(diǎn)：

• 可點(diǎn)擊的頁(yè)面跳轉(zhuǎn)或頁(yè)面流程圖
• 清晰且與文檔對(duì)應(yīng)的框架結(jié)構(gòu)
• 美觀且較易于理解的設(shè)計(jì)草圖
• 簡(jiǎn)單、規(guī)范、統(tǒng)一的必要文字說明

“可點(diǎn)擊的頁(yè)面跳轉(zhuǎn)或頁(yè)面流程圖”：能夠幫開發(fā)更好的理解功能流程，也更利于產(chǎn)品經(jīng)理在內(nèi)審時(shí)對(duì)自己做的功能進(jìn)行介紹，而且這通過Axure的“屏幕快照”功能可以非常輕松的實(shí)現(xiàn)。

“清晰且與文檔對(duì)應(yīng)的框架結(jié)構(gòu)”：要求PRD需求文檔功能模塊的名稱要與原型文檔里的名稱對(duì)應(yīng)。

“美觀且較易于理解的設(shè)計(jì)草圖”：要求產(chǎn)品經(jīng)理繪畫的原型要至少保證可用性——即有原型且原型交互符合規(guī)范。筆者曾遇到過有產(chǎn)品經(jīng)理在原型設(shè)計(jì)中將Web端交互放到了移動(dòng)端，甚至直接給設(shè)計(jì)人員Web端原型，讓設(shè)計(jì)人員做一份移動(dòng)端設(shè)計(jì)稿的情況。

(移動(dòng)端原型錯(cuò)誤的交互設(shè)計(jì))
此時(shí)的設(shè)計(jì)人員：“到底你是產(chǎn)品，還是我是產(chǎn)品？？？”

“簡(jiǎn)單、規(guī)范、統(tǒng)一的必要文字說明”：因?yàn)橛行┕δ茳c(diǎn)描述在文本中表現(xiàn)可能不夠清晰，所以直接在原型上給予標(biāo)注，這部分要盡量克制。

三、文檔撰寫

1. 我們?yōu)槭裁匆獙懳臋n？

文檔的撰寫目的，筆者認(rèn)為主要有以下四點(diǎn)：

• 幫助產(chǎn)品經(jīng)理梳理思路、流程及細(xì)節(jié)，完善產(chǎn)品。
• 減少設(shè)計(jì)、開發(fā)、測(cè)試過程中反復(fù)溝通造成的時(shí)間浪費(fèi)和進(jìn)度延誤。
• 增強(qiáng)用戶意識(shí)及程序思維。
• 反向通過完整的PRD、原型對(duì)產(chǎn)品進(jìn)行驗(yàn)收及質(zhì)量評(píng)價(jià)。

以上的一、三、四點(diǎn)都比較好理解，主要是為了完善產(chǎn)品經(jīng)理的產(chǎn)品思維、減少出錯(cuò)。而第二點(diǎn)可能有很多人會(huì)疑惑，做產(chǎn)品本來就需要我們反復(fù)的去跟開發(fā)、設(shè)計(jì)、測(cè)試進(jìn)行溝通，為什么還要減少呢？

這主要是因?yàn)椋寒a(chǎn)品經(jīng)理與他們之間的許多溝通本來是可以不發(fā)生的。

例如：一個(gè)Button的字段，你在文檔里沒有描述清晰，那么開發(fā)就會(huì)過來找你問，如果沒有問你直接照著他的想法做了。最后方向和你想的不一樣，那就悲劇了，要接著溝通怎么改了。

所以，對(duì)于一個(gè)產(chǎn)品經(jīng)理，最好的狀態(tài)是當(dāng)你完成了某個(gè)項(xiàng)目的V1.0版本時(shí)，你就應(yīng)該立刻著手準(zhǔn)備V1.1版本的迭代與更新了，而不是接著和團(tuán)隊(duì)的其他成員在V1.0版本上扯皮。

請(qǐng)務(wù)必記?。骸?strong>產(chǎn)品經(jīng)理是帶著團(tuán)隊(duì)跑，不是和團(tuán)隊(duì)一起跑?！?/strong>

2. 優(yōu)秀文檔應(yīng)具有哪些特性？

筆者認(rèn)為，優(yōu)秀的文檔主要具有以下特性：

• 邏輯性：內(nèi)容有層次，描述可遞進(jìn)，文檔中的結(jié)論要有客觀事實(shí)來說明。
• 敏捷性：文檔的內(nèi)容要盡可能精簡(jiǎn)，切勿長(zhǎng)篇大論。
• 完整性：在保證文檔內(nèi)容精簡(jiǎn)的同時(shí)，也不能缺三少四，重要的模塊不能丟。
• 可讀性：盡量避免使用二義性的語(yǔ)句，這容易造成使用人員曲解你的想法。
• 規(guī)范性：每份文檔盡量保證格式相同或類似，減少使用人員的適應(yīng)成本。
• 一致性：在需求分析模塊的劃分和命名上與原型文檔保持一致。

3. 優(yōu)秀文檔應(yīng)該包含哪些模塊？

上文提到：一個(gè)好的需求文檔應(yīng)該做到完整性——即包含所有的重要模塊，不能缺三少四。

那么又有哪些模塊是重要的呢？

筆者在仔細(xì)分析了團(tuán)隊(duì)正在做的產(chǎn)品業(yè)務(wù)后，總結(jié)了優(yōu)秀文檔所需要包含的23個(gè)重要模塊，其中有11個(gè)模塊是必備的。

筆者相信，這也同樣適用于大部分其他產(chǎn)品的業(yè)務(wù)。

筆者簡(jiǎn)單解釋一下，上圖中各個(gè)模塊應(yīng)包含的內(nèi)容和存在意義。

（1）版本修訂記錄(必備)：主要包含現(xiàn)有版本的版本號(hào)、主要更改內(nèi)容、更改原因等，它在產(chǎn)品出現(xiàn)問題，追根溯源時(shí)可以起到巨大作用。同時(shí)，也便于使用人員梳理邏輯。

（2）產(chǎn)品目標(biāo)（必備）：可以是功能或者產(chǎn)品上線后想要達(dá)到的效果。

（4）需求方及背景（必備）：簡(jiǎn)述需求產(chǎn)生背景以及原因，需求面向哪些人群？一定要有事實(shí)或者數(shù)據(jù)作為佐證，開發(fā)吐槽產(chǎn)品經(jīng)理亂提需求也不是一天兩天了。

（5）預(yù)估收益（必備）：最好能用數(shù)字量化產(chǎn)品或功能開發(fā)產(chǎn)生的收益，也就是ROI，對(duì)收益的正確評(píng)判也是產(chǎn)品經(jīng)理的一項(xiàng)重要能力。這里舉個(gè)例子，如“優(yōu)化公司內(nèi)部系統(tǒng)某流程，預(yù)計(jì)耗時(shí)13人天，完成后預(yù)計(jì)可以為公司其他部門每年節(jié)省35人天”。這樣的描述，清晰且可信。

（6）風(fēng)險(xiǎn)描述：簡(jiǎn)要概述產(chǎn)品或功能開發(fā)過程中可能會(huì)遇到的內(nèi)部風(fēng)險(xiǎn)和外部風(fēng)險(xiǎn)，例如：新項(xiàng)目遷移可能遇到未知問題，這就是內(nèi)部風(fēng)險(xiǎn)。前端開發(fā)缺人，項(xiàng)目撞車，這就屬于外部風(fēng)險(xiǎn)。

（7）目標(biāo)用戶（必備）：簡(jiǎn)要描述一下產(chǎn)品或功能上線后服務(wù)的人群，有群體特征的最好也寫上。

（8）使用場(chǎng)景：簡(jiǎn)要描述一下產(chǎn)品或功能上線后使用的場(chǎng)景。

（9）參與人員（必備）：記錄產(chǎn)品或功能從孵化到上線過程中負(fù)責(zé)的工作人員，這樣的好處是某個(gè)環(huán)節(jié)一旦出了問題，可以快速的定位到相關(guān)的負(fù)責(zé)人，提高效率，特別是翻看歷史記錄的時(shí)候。

（10）項(xiàng)目周期：主要是方便使用人員進(jìn)行時(shí)間規(guī)劃，同時(shí)可用于進(jìn)行項(xiàng)目管理，如果所在團(tuán)隊(duì)項(xiàng)目的時(shí)間管理已經(jīng)足夠好，那么這個(gè)模塊可以不寫。

（11）名詞解釋：對(duì)使用人員可能不了解的名詞進(jìn)行注釋。

（12）功能流程（必備）：這是PRD需求文檔里最重要的一個(gè)模塊，所以在保持簡(jiǎn)潔的同時(shí)要做到盡可能的詳細(xì)。

流程圖的作用不必多說，邏輯清晰的流程圖可以幫助使用者快速的理清業(yè)務(wù)邏輯，提高效率，減少出錯(cuò)。而在“交互流程”中，我建議產(chǎn)品經(jīng)理可以直接用Axure生成的HTML網(wǎng)址進(jìn)行表示，方便且快捷。

接下來是“頁(yè)面及彈窗”，這部分對(duì)前端開發(fā)意義很大，能有效的避免漏掉某些重要頁(yè)面。

最后便是“功能及說明”，這部分主要對(duì)產(chǎn)品的每個(gè)功能進(jìn)行詳盡的描述。

以Web端的一個(gè)頁(yè)面舉例，我們需要介紹這個(gè)頁(yè)面的操作路徑，頁(yè)面上的操作形式，數(shù)據(jù)的來源，額外的說明等。

具體的示例，筆者在下面用圖片展示：

（13）權(quán)限&角色：簡(jiǎn)要描述一下使用這個(gè)產(chǎn)品或功能的不同特征人群的權(quán)限，舉個(gè)例子，企業(yè)做一個(gè)自己的日?qǐng)?bào)系統(tǒng)，老板和員工的使用權(quán)限肯定是不一樣的。

（14）性能需求：簡(jiǎn)要描述一下產(chǎn)品對(duì)性能的要求，如QPS、請(qǐng)求訪問時(shí)長(zhǎng)等。

（15）營(yíng)銷&運(yùn)營(yíng)需求：這部分主要是面向C端產(chǎn)品，寫出方向性就可以，是與運(yùn)營(yíng)聯(lián)動(dòng)的一個(gè)模塊。

（16）安全需求：不同產(chǎn)品或功能對(duì)于安全的要求往往不盡相同，例如“支付功能”的安全需求比大多其他功能都要高，這個(gè)模塊建議寫上產(chǎn)品或功能安全等級(jí)的高低，應(yīng)該做好哪些預(yù)防。

（17）法務(wù)需求：主要是專利著作權(quán)、版權(quán)等可能遇到的法務(wù)風(fēng)險(xiǎn)，大多產(chǎn)品或功能不存在這個(gè)問題。

（18）異常情況（必備）：簡(jiǎn)要描述一下用戶使用產(chǎn)品或功能時(shí)可能碰到的異常情況，例如突然斷網(wǎng)等。

（19）測(cè)試要點(diǎn)（必備）：這部分非常重要，產(chǎn)品經(jīng)理需要在這個(gè)模塊介紹產(chǎn)品或功能在上線前有哪些重點(diǎn)功能是需要反復(fù)測(cè)試的，有哪些異常邏輯是需要注意的。因?yàn)闇y(cè)試人員在一些細(xì)節(jié)的把控上可能沒有產(chǎn)品經(jīng)理來的仔細(xì)，如果一些重要的點(diǎn)沒能被測(cè)試到就直接Pass，在后續(xù)的開發(fā)中就可能會(huì)惹上大麻煩（回爐重造等），從而導(dǎo)致項(xiàng)目延期。

（20）數(shù)據(jù)埋點(diǎn)及統(tǒng)計(jì)需求：寫清楚應(yīng)該在產(chǎn)品中的哪些維度進(jìn)行數(shù)據(jù)埋點(diǎn)，和與之對(duì)應(yīng)的統(tǒng)計(jì)需求。

（21）上線前準(zhǔn)備（必備）：分點(diǎn)敘述上線前需要完成那些事件，例如把Bug狀態(tài)都變?yōu)椤耙呀鉀Q”。

（22）上線后工作（必備）：大多數(shù)產(chǎn)品或功能不是上線就結(jié)束了，往往需要后續(xù)的跟進(jìn)，例如進(jìn)行回歸測(cè)試，對(duì)用戶進(jìn)行意見調(diào)研、實(shí)際收益評(píng)估等。

（23）設(shè)計(jì)規(guī)范：針對(duì)有交互原則的團(tuán)隊(duì)。

（24）補(bǔ)充說明：其他不屬于以上22個(gè)模塊的解釋描述。

四、需求評(píng)審

1. 評(píng)審的主要流程

• 自評(píng)清單，自評(píng)通過再內(nèi)審。
• 內(nèi)審評(píng)價(jià)，內(nèi)審?fù)ㄟ^再外審。
• 外審評(píng)價(jià)，外審?fù)ㄟ^進(jìn)入開發(fā)。

2. 如何做好內(nèi)審？

內(nèi)審是評(píng)審的第一步，如果沒有卡好內(nèi)審這門關(guān)卡，隨意的讓項(xiàng)目通過，會(huì)導(dǎo)致外審時(shí)項(xiàng)目出現(xiàn)諸多紕漏，浪費(fèi)團(tuán)隊(duì)其他人員的時(shí)間，所以內(nèi)審一定要足夠謹(jǐn)慎。

針對(duì)內(nèi)審，筆者總結(jié)了六條原則：

1. 至少應(yīng)有3人參與內(nèi)審；
2. 內(nèi)審必須邀請(qǐng)項(xiàng)目管理者參與；
3. 要提前給定好內(nèi)審預(yù)計(jì)所需要的時(shí)間；
4. 基礎(chǔ)測(cè)試一旦沒有通過，內(nèi)審必須當(dāng)即中斷；
5. 評(píng)審結(jié)束后，相關(guān)人員應(yīng)該在幕后形成相關(guān)的結(jié)論；
6. 每次內(nèi)審需做內(nèi)審會(huì)議紀(jì)要，紀(jì)要包括內(nèi)審的結(jié)論和問題。

這六條原則應(yīng)該都是比較通俗易懂的，但關(guān)于基礎(chǔ)測(cè)試，筆者要額外解釋一下：所謂基礎(chǔ)測(cè)試其實(shí)就是需求或功能流程，如果在內(nèi)審當(dāng)中，因?yàn)楫a(chǎn)品經(jīng)理個(gè)人的靈光乍現(xiàn)或者是他人異議發(fā)現(xiàn)原定流程中有一段已經(jīng)完全行不通了，那此時(shí)的內(nèi)審也就沒有意義了。產(chǎn)品經(jīng)理應(yīng)立刻停止內(nèi)審，回去重新思考并修改流程，但如果僅僅是某一個(gè)節(jié)點(diǎn)需要修改，影響較小，則可以繼續(xù)進(jìn)行。

3. 評(píng)審需要符合那些標(biāo)準(zhǔn)？

• 合理性：成本、收益、用戶、痛點(diǎn)、風(fēng)險(xiǎn)等評(píng)估要合理。
• 完整性：角色是否完整、狀態(tài)是否完整、功能是否完整。
• 可行性：技術(shù)的可行性，是否觸碰到已知邊界。
• 一致性：保持相同的視覺風(fēng)格、交互方式和情感傳達(dá)。
• 邏輯性：流程是否清晰便于其他人理解。
• 準(zhǔn)確性：字段、數(shù)據(jù)源、數(shù)據(jù)計(jì)算方式、異常狀態(tài)等。
• 易用性：用戶使用成本是否足夠低，路徑足夠簡(jiǎn)潔。
• 復(fù)用性：是否考慮復(fù)用已有產(chǎn)品、框架、設(shè)計(jì)。
• 創(chuàng)新性：是否能夠盡可能發(fā)揮創(chuàng)新的能力。

以上標(biāo)準(zhǔn)既適用于內(nèi)審，也適用于外審。

總結(jié)

文檔的撰寫與合格交付一直是困擾在許多產(chǎn)品經(jīng)理心中的一個(gè)難題?，F(xiàn)在許多的人都建議直接用Axure來同時(shí)進(jìn)行原型與PRD文檔的制作，這種方式的確非常節(jié)省時(shí)間，但要注意這個(gè)時(shí)間只是節(jié)省了寫文檔的時(shí)間，在接下來的設(shè)計(jì)、開發(fā)、測(cè)試過程中，由于前期文檔內(nèi)容不夠詳盡，耗費(fèi)的時(shí)間實(shí)際上是大幅度增加了。

在筆者寫下這篇原則之前，所在團(tuán)隊(duì)也是采取Axure原型和文檔一起做的模式，但實(shí)行起來效果并不好——前端、測(cè)試、設(shè)計(jì)飽受這種不規(guī)范文檔之苦。所以，依舊建議大家用文字表達(dá)。

這套原則因?yàn)槭堑谝话妫夜P者作為一個(gè)實(shí)習(xí)生還沒有太多的產(chǎn)品工作經(jīng)歷，所以在部分模塊細(xì)節(jié)上可能仍然有許多疏漏。特別的，可能因?yàn)閺氖碌臉I(yè)務(wù)相關(guān)，這套原則不能完全的適用于其他團(tuán)隊(duì)產(chǎn)品的工作模式，不過筆者相信它依舊能給你們以啟發(fā)。

至于這套原則的下一步，筆者目前所考慮的是協(xié)同文檔，WIKI、石墨等等，如果大家有好的建議或者是看法，也歡迎在評(píng)論中提出，筆者都會(huì)認(rèn)真聆聽并虛心接受，謝謝！

本文由 @天下 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議