寫PRD并不是產(chǎn)品經(jīng)理的全部工作，但卻是不可少的一部分，一份可讀性的PRD對一個項目團隊來說是至關(guān)重要的。

突發(fā)事件

昨天編輯了一篇純邏輯修改的文檔，交付開發(fā)后，開發(fā)方向偏離，后臺大量訂單數(shù)據(jù)出錯出錯。

我立馬叫停開發(fā)人員，交流之后，發(fā)現(xiàn)開發(fā)人員錯誤理解了PRD文檔。開發(fā)人員在閱讀文檔的時候直接看掉了兩個字。

后來我自己回去閱讀的時候也看錯了，說明我文檔是不易讀。所以一方面叫開發(fā)人員停下來修復(fù)數(shù)據(jù)出錯的地方，一方面重新整理文檔。

下面我就介紹一下我在梳理文檔過程中發(fā)現(xiàn)的幾個坑。

第一坑——名詞交流混亂

這是昨天文檔中最大的問題，因為后臺是管理訂單的，所以會有大量的時間結(jié)點，但是目前只有兩個時間結(jié)點有自己的專屬名字。其他的時間結(jié)點的叫法都是今天一個樣，明天一個樣。

所以我在寫文檔的時候就按照自己的叫發(fā)來寫文檔，其中就有一系列相似名稱的時間結(jié)點叫做“服務(wù)時間”、“次服務(wù)時間”、“官方服務(wù)時間”，技術(shù)同學(xué)在開發(fā)的時候，直接把“官方服務(wù)時間”的“官方”二字看掉了。

看錯后就直接對“服務(wù)時間”的先關(guān)內(nèi)容進行大刀闊斧的修改，所以就導(dǎo)致后臺訂單數(shù)據(jù)錯亂。于是乎經(jīng)過交流，終于重新定名“服務(wù)時間”、“訂單時間”、“官方時間”。

關(guān)鍵詞命名的注意點：

1. 整個團隊要將關(guān)鍵詞進行統(tǒng)一，最好創(chuàng)建規(guī)范性名詞解釋列表；
2. 關(guān)鍵詞命名時，同一個模塊、流程中的詞語里邊相同字的使用不要超過50%；
3. 還有產(chǎn)品設(shè)計各個環(huán)節(jié)中，關(guān)鍵詞的一致性，也是需要注意的。

第二坑——專業(yè)名稱重復(fù)出現(xiàn)

昨天在寫文檔的時候，為了使每一個名詞都能精確的定位到每個點上，所以每一個名詞都使用專業(yè)名稱來表示，全篇PRD專業(yè)名稱橫飛。由于昨天寫的文檔是屬于純邏輯性的文檔，所以大量在專業(yè)名稱充斥的情況下，整篇文章的可讀性極差。

專業(yè)名稱使用注意：

1. 同一句話中，能使用代詞來代指句子中的專業(yè)名稱的時候，盡量使用代詞表示，因為代詞更口語化，也更容易讓人理解。
2. 如果使用代詞會讓整句話產(chǎn)生歧義，那就一定不要使用代詞；
3. 使用代詞可以增加可讀性，使用專業(yè)名稱可以增加準確性，所以只有在恰到好處的地方進行敲到好處的表達，才能把文檔的易讀性和準確性最大化。

第三坑——行文邏輯不清晰

在寫開發(fā)文檔的時候，憑著直覺來寫文檔，在寫之前并沒有梳理清楚其中的邏輯，以至于最后寫出來地文檔邏輯混亂，各個板塊互相穿插。

在撰寫文檔前，首先自己要清楚整個功能的流程，這個肯定是毋庸置疑的。但是，我們在寫文檔的時候，可能就沒有這么在意行文的邏輯，全憑自覺來撰寫。

所以在寫文檔的時候，不僅僅需要理清整個產(chǎn)品、功能的邏輯，還需要為整篇文章的結(jié)構(gòu)和行為邏輯進行提前的思考，不然產(chǎn)出的文檔可讀性也很差。

第四坑——詳細得臃腫

在寫PRD時，為了想一次性把問題說清楚，讓程序員能一次性把文檔理解透。所以會把一個問題解釋得很詳細，從而使得文檔變得很臃腫。

這不是認真，這其實是一種懶惰，因為想用文檔砸給程序員，讓他們自己去理解產(chǎn)品，不想和程序員進行過多的交流和文檔解釋。

其實在實際工作中，我發(fā)現(xiàn)有就算你寫得再詳細，如果不進行口頭介紹，程序員想把如此臃腫的文檔理解清楚也非常不容易。所以，如果能用流程圖來表述，就不需要長篇累述；如果能先進行產(chǎn)品大致的介紹，讓大家先理解整個思路，就不需要文字上過于累贅的表述。

產(chǎn)品文檔應(yīng)該做到“考慮全面，邏輯清晰，語言精練”

第五坑——文檔排版不易讀

原來才開始寫文檔的時候，完全不知道什么排版，在無數(shù)次打磨自己的格式后，開始對排版有了一點自己的理解。

如果說排版有什么技巧，我想可能是這幾個：

1. 以功能劃分大板塊，大板塊標題醒目。
2. 把大板塊簡單拆分，并用小標題區(qū)分。
3. 用點號羅列觀點，不要寫成一大段。

對于文檔排版，統(tǒng)一文字格式后，做好以上幾點就能確保文檔基本整潔和可讀性。但是排版是個長期打磨和鍛煉的事情，必須要經(jīng)常鍛煉，才能有一套自己的合理的排版風格。

第六坑——重點內(nèi)容不突出

重點加得非常隨意，就會造成兩個結(jié)果，重點不突出和重點不夠重點。
所以，文檔中應(yīng)該標記重點，但也要注意：

1. 重點最好為重要的動詞、轉(zhuǎn)折詞、新名詞和關(guān)鍵邏輯判定詞等。
2. 重點內(nèi)容不在于多，更在于精，滿篇重點則是沒有重點。

第七坑——不用程序員喜歡的形式寫文檔

最后，特別重要的一點，也是不可不說的一點，那就是使用程序員容易理解的、喜歡的方式來寫文檔。

1. 程序員更喜歡看到能用公式來展現(xiàn)各個數(shù)據(jù)或者信息之間的關(guān)系；
2. 了解程序員編程的時候常用的邏輯，多以這種邏輯術(shù)語來寫文檔，這樣程序員就更能理解；
3. 多用分句，別用連句，一個分句表達一個意思就可以了。
4. 能用配流程圖的，千萬別只寫文字。

作者：譚宇恒

來源：http://www.jianshu.com/u/a43d456a3674

本文由 @譚宇恒 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。