本文作者認為一個優(yōu)秀的產(chǎn)品經(jīng)理在寫PRD文檔時要在速度、效率、質(zhì)量三方面都表現(xiàn)出色。

和產(chǎn)品經(jīng)理打一輩子交道的可能不是程序猿，也可能是產(chǎn)品文檔。

產(chǎn)品文檔是產(chǎn)品經(jīng)理設(shè)計思路的輸出表現(xiàn)形式，可以理解為打仗的武器、吃飯的家伙。

如此重要的產(chǎn)品文檔卻也可能成為一個產(chǎn)品經(jīng)理的詬病——技術(shù)對于文檔的可讀性的質(zhì)疑、測試工程師對于細節(jié)場景的疑問等。

那讓我們看看我們怎么才能“站在程序員旁邊說話不腰疼”？

一、 PRD輸出效率

那我們先來聊下現(xiàn)實工作中不同等級的產(chǎn)品經(jīng)理處理文檔的效率吧。

我們根據(jù)出文檔質(zhì)量和速度兩個維度進行效率評估，把文檔能力分為3個等級：

• Level1：PRD輸出速度慢+低質(zhì)量
• Level2：PRD輸出速度快+低質(zhì)量
• Level3：PRD輸出速度快+高質(zhì)量

二、PRD速度能力

現(xiàn)實工作中我們可能會遇到很多異常情況：“加急需求”、“頭腦風(fēng)暴短期敏捷開發(fā)需求”……

簡單地說就是：時間短任務(wù)重?？赡苷w的需求方向和做法都沒有確定，基礎(chǔ)的邏輯框架都沒有搭建時已經(jīng)逼近輸出時間節(jié)點。

這時我們就需要注意提升我們的速度能力——“快”。

當然，并不能說快就不管質(zhì)量。我們在提升速度能力時最低的底線是：保持你之前文檔的質(zhì)量水平的基礎(chǔ)上提升文檔完成速度，這樣的訓(xùn)練提升結(jié)果才是可量化的。

訓(xùn)練思路：減少思考你一定要思考的內(nèi)容。

這句話聽著很奇怪，其實就是把之前你需要用時間去思考的內(nèi)容變成工作經(jīng)驗，變成你的一部分，不需要做額外的思考也可以完成。

簡單的舉個栗子，新手產(chǎn)品經(jīng)理在寫文檔的思考步驟：先寫標題、再寫需求的設(shè)計目的、然后我們詳細描述下需求內(nèi)容（需求內(nèi)容第一條要寫什么呢？第二條要寫什么？）。

你會發(fā)現(xiàn)他的思考路徑很長，什么都要想用不用寫，寫什么。

如果我們心里很清楚一個產(chǎn)品的生成哪些內(nèi)容一定要寫，那我們就不用去浪費時間在想上面，而是直接寫 1、2、3、4，最后看是否又遺漏需要進行補充。

總結(jié)起來：“速度訓(xùn)練”就是把工作中文檔輸出的經(jīng)驗形成方法論，來縮短文檔輸出的路徑，加快文檔輸出速度的刻意訓(xùn)練。

三、PRD質(zhì)量

對于文檔質(zhì)量的定義：什么是一個好的產(chǎn)品文檔？

起碼“程序看的懂，測試不罵你”吧！

這里玩笑歸玩笑，但是一個產(chǎn)品文檔如果寫的好一定會大大減少工作中的溝通成本，提升工作效率與環(huán)境。

文檔質(zhì)量的不僅僅是產(chǎn)品思維的體現(xiàn)，也是產(chǎn)品架構(gòu)、復(fù)用準則、邏輯思維、異常處理以及可讀性體現(xiàn)等。

1. 替程序員著想：“體諒”而不是“妥協(xié)”

體諒

很多時候我們寫好文檔和程序同學(xué)溝通時都會出現(xiàn)這樣的問題：哎呀，這個東西不好搞啊，不是不能搞，就是需要時間長點，要不咱們換個方案？

這種情況如果我們按魯迅先生的性格（我向來不憚以最壞的惡意來揣測國人的）來思考問題的話，那么可能是我們提的需求的實現(xiàn)方式違背了技術(shù)的框架結(jié)構(gòu)，比如：代碼的延用性、可維護性、安全性等。

這種情況下，我們就需要體諒和自我提升，體諒是體諒程序員是在為產(chǎn)品著想；而不是跟你作對才說不好做，我們要理解技術(shù)有技術(shù)的規(guī)則。

你不會全部了然，提升是指要學(xué)會以技術(shù)的思維去思考。

你不一定要會寫代碼，但要了解起碼的代碼運作的機制，這樣可以在和程序溝通之前就篩除掉一部分有實現(xiàn)邏輯問題的方案。

不妥協(xié)

剛才說了體諒，我們先禮后兵，現(xiàn)在我們說不妥協(xié)。

如果產(chǎn)品經(jīng)理認定這個需求對于整個產(chǎn)品的數(shù)據(jù)起著至關(guān)重要的作用，我們絕對不要因為技術(shù)實現(xiàn)問題而妥協(xié)去修改方案，違背最初方案的目的。

無論是什么原因，我們最后的目的是提升產(chǎn)品的數(shù)據(jù)盈利，當然我們也要幫程序同學(xué)想辦法一起解決這件事，我們擁有共同的目標。

2. 邏輯思維清晰，可讀性強：會講故事

考驗產(chǎn)品經(jīng)理語文水平的時間到了，如何讓程序員看了你的文檔就明白：我們的目的是提升A，我們通過B路徑去提升A，我要把B路徑做出來，B路徑由1、2、3、4、5、6、7等構(gòu)成。

清楚明了，知道產(chǎn)品為什么要做這個是很關(guān)鍵的。

只有知道出發(fā)點，他才會順著你的思路去完成；不然極端情況會做出和你設(shè)計的內(nèi)容很像，但和出發(fā)點不同的產(chǎn)品，就像我們大家都會玩的誰是臥底一樣。

3. 細節(jié)以及異常情況不要放過

剛?cè)胄挟a(chǎn)品經(jīng)理的小伙伴可能會發(fā)現(xiàn)：即使仔細完成的文檔程序還是會有問題要問你，還是會有你沒寫到或想不到的地方，往往會問到你懷疑人生，難道程序都比我想的多嗎？

遇到這種情況不需要陷入懷疑自己能力的怪圈，因為產(chǎn)品輸出文檔時更注重的是整體產(chǎn)品的合理性、用戶的體驗和目的達成度；而程序在制作過程中需要了解到每一個細節(jié)，他們寫著寫著寫到你沒說的地方就不知道怎么做了。

作為一個身體力行的實踐者當然要比“紙上談兵的我們”更清楚。

不過這些都是不是產(chǎn)品經(jīng)理放棄追求細節(jié)的理由，如果細節(jié)足夠可以為程序、測試小伙伴節(jié)省非常多的溝通成本，也是提升產(chǎn)品經(jīng)理工作能力的必經(jīng)之路。

這里我們給幾個輸出PRD注重細節(jié)的建議吧。

• 培養(yǎng)文檔輸出時的清晰邏輯，把一定要寫的內(nèi)容銘記于心。
• 文檔概述完成后寫一遍流程圖（流程圖真的非常重要）——畫流程圖可以幫助我們查缺補漏，整個產(chǎn)品的流程實現(xiàn)閉環(huán)，減少場景情況遺漏的情況。
• 異常邊際情況標注：一般產(chǎn)品的設(shè)計中會有很多程序異?；蛘哌呺H設(shè)計的情況出現(xiàn)。比如：如果數(shù)據(jù)配置加載失敗，前端應(yīng)該顯示什么；活動隔日刷新時，用戶正在活動中應(yīng)該怎么都是常見的異常邊際問題；在寫完文檔時，我們要格外注意是否會有這些情況、對這些情況進行梳理和標注。
• 凡事不要懈怠。文檔偷懶一時爽，技術(shù)測試瘋狂找。盡量一次強迫自己一次性把內(nèi)容寫清楚，不要總指望第二次的修改，長此以往對我們的進步?jīng)]有任何幫助。

四、結(jié)語

PRD的輸出速度和質(zhì)量會根據(jù)我們的工作經(jīng)驗的完善逐步提升，希望小伙伴們也不要有太大的壓力。

只要我們把每一次的文檔輸出都當作一次試煉，對文檔保持敬畏，相信一段時間后對于產(chǎn)品文檔的質(zhì)量提升會有奇效。

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

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