PRD七坑:沒有可讀性的PRD都是耍流氓

23 評論 43541 瀏覽 218 收藏 8 分鐘

寫PRD并不是產品經理的全部工作,但卻是不可少的一部分,一份可讀性的PRD對一個項目團隊來說是至關重要的。

突發事件

昨天編輯了一篇純邏輯修改的文檔,交付開發后,開發方向偏離,后臺大量訂單數據出錯出錯。

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

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

下面我就介紹一下我在梳理文檔過程中發現的幾個坑。

第一坑——名詞交流混亂

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

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

看錯后就直接對“服務時間”的先關內容進行大刀闊斧的修改,所以就導致后臺訂單數據錯亂。于是乎經過交流,終于重新定名“服務時間”、“訂單時間”、“官方時間”。

關鍵詞命名的注意點:

  1. 整個團隊要將關鍵詞進行統一,最好創建規范性名詞解釋列表;
  2. 關鍵詞命名時,同一個模塊、流程中的詞語里邊相同字的使用不要超過50%;
  3. 還有產品設計各個環節中,關鍵詞的一致性,也是需要注意的。

第二坑——專業名稱重復出現

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

專業名稱使用注意:

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

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

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

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

所以在寫文檔的時候,不僅僅需要理清整個產品、功能的邏輯,還需要為整篇文章的結構和行為邏輯進行提前的思考,不然產出的文檔可讀性也很差。

第四坑——詳細得臃腫

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

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

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

產品文檔應該做到“考慮全面,邏輯清晰,語言精練”

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

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

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

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

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

第六坑——重點內容不突出

重點加得非常隨意,就會造成兩個結果,重點不突出和重點不夠重點。
所以,文檔中應該標記重點,但也要注意:

  1. 重點最好為重要的動詞、轉折詞、新名詞和關鍵邏輯判定詞等。
  2. 重點內容不在于多,更在于精,滿篇重點則是沒有重點。

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

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

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

 

作者:譚宇恒

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

本文由 @譚宇恒 授權發布于人人都是產品經理,未經作者許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 字不如表,表不如圖

    來自北京 回復
  2. 還有一點 寫完文字描述 檢查一遍有沒有錯別字
    尤其是 第七坑——不用程序員喜歡的形式寫文檔 這種大標題錯誤

    來自北京 回復
  3. 不是用Axure寫PRD嗎?

    回復
  4. 最好的產品PDR,永遠存在PM的思路里。閱讀PDR的最高效方式,就是隨便問PM,對方都可以思路清晰的對答如流。

    來自上海 回復
    1. prd不是pdr

      來自廣東 回復
    2. 啪啪打臉

      來自上海 回復
    3. 你逗我笑

      來自河北 回復
  5. 來自運營的prd吐槽

    來自北京 回復
  6. 這內容條理??……誠懇建議作者讀一下《金字塔原理》學習一下邏輯表達的方法。

    來自北京 回復
  7. 來來來,把你認為清楚地呈現出來

    來自廣東 回復
  8. 標題吸引人,內容就不說了。。。

    來自重慶 回復
  9. 你們上線前都不測試么?

    來自北京 回復
  10. 本篇文章可讀性就不是很高吧,錯別字還不少。能用圖別用字,咋全是字

    來自北京 回復
    1. 哈哈哈經典

      來自北京 回復
  11. 收藏

    來自四川 回復
  12. 個人感覺,帶有交互的產品原型對開發人員來說更容易掌控。當然,開發文檔肯定也是必要的,一來輔助開發人員核對細節,二來可以作為產品的記錄備份,用作版本迭代以及產品交付等。不過,我們的開發人員,現在基本上也不會去讀繁雜的文檔了。。

    來自北京 回復
  13. 能用圖就不用文字,說的太對了

    來自山東 回復
  14. 能用圖說明的,堅決不用文檔。開發人員理解圖片的能力比看文強很多。

    回復
    1. 理解圖片的能力比看文強很多。其實這是全人類的共同點。

      來自浙江 回復
  15. 學習了

    回復
  16. 你們開發人員真不錯,還會去讀文檔。

    來自上海 回復
    1. 哈哈哈,莫名想笑

      來自廣東 回復
    2. 確實不錯

      來自廣東 回復