PRD七坑:沒有可讀性的PRD都是耍流氓
寫PRD并不是產品經理的全部工作,但卻是不可少的一部分,一份可讀性的PRD對一個項目團隊來說是至關重要的。
突發事件
昨天編輯了一篇純邏輯修改的文檔,交付開發后,開發方向偏離,后臺大量訂單數據出錯出錯。
我立馬叫停開發人員,交流之后,發現開發人員錯誤理解了PRD文檔。開發人員在閱讀文檔的時候直接看掉了兩個字。
后來我自己回去閱讀的時候也看錯了,說明我文檔是不易讀。所以一方面叫開發人員停下來修復數據出錯的地方,一方面重新整理文檔。
下面我就介紹一下我在梳理文檔過程中發現的幾個坑。
第一坑——名詞交流混亂
這是昨天文檔中最大的問題,因為后臺是管理訂單的,所以會有大量的時間結點,但是目前只有兩個時間結點有自己的專屬名字。其他的時間結點的叫法都是今天一個樣,明天一個樣。
所以我在寫文檔的時候就按照自己的叫發來寫文檔,其中就有一系列相似名稱的時間結點叫做“服務時間”、“次服務時間”、“官方服務時間”,技術同學在開發的時候,直接把“官方服務時間”的“官方”二字看掉了。
看錯后就直接對“服務時間”的先關內容進行大刀闊斧的修改,所以就導致后臺訂單數據錯亂。于是乎經過交流,終于重新定名“服務時間”、“訂單時間”、“官方時間”。
關鍵詞命名的注意點:
- 整個團隊要將關鍵詞進行統一,最好創建規范性名詞解釋列表;
- 關鍵詞命名時,同一個模塊、流程中的詞語里邊相同字的使用不要超過50%;
- 還有產品設計各個環節中,關鍵詞的一致性,也是需要注意的。
第二坑——專業名稱重復出現
昨天在寫文檔的時候,為了使每一個名詞都能精確的定位到每個點上,所以每一個名詞都使用專業名稱來表示,全篇PRD專業名稱橫飛。由于昨天寫的文檔是屬于純邏輯性的文檔,所以大量在專業名稱充斥的情況下,整篇文章的可讀性極差。
專業名稱使用注意:
- 同一句話中,能使用代詞來代指句子中的專業名稱的時候,盡量使用代詞表示,因為代詞更口語化,也更容易讓人理解。
- 如果使用代詞會讓整句話產生歧義,那就一定不要使用代詞;
- 使用代詞可以增加可讀性,使用專業名稱可以增加準確性,所以只有在恰到好處的地方進行敲到好處的表達,才能把文檔的易讀性和準確性最大化。
第三坑——行文邏輯不清晰
在寫開發文檔的時候,憑著直覺來寫文檔,在寫之前并沒有梳理清楚其中的邏輯,以至于最后寫出來地文檔邏輯混亂,各個板塊互相穿插。
在撰寫文檔前,首先自己要清楚整個功能的流程,這個肯定是毋庸置疑的。但是,我們在寫文檔的時候,可能就沒有這么在意行文的邏輯,全憑自覺來撰寫。
所以在寫文檔的時候,不僅僅需要理清整個產品、功能的邏輯,還需要為整篇文章的結構和行為邏輯進行提前的思考,不然產出的文檔可讀性也很差。
第四坑——詳細得臃腫
在寫PRD時,為了想一次性把問題說清楚,讓程序員能一次性把文檔理解透。所以會把一個問題解釋得很詳細,從而使得文檔變得很臃腫。
這不是認真,這其實是一種懶惰,因為想用文檔砸給程序員,讓他們自己去理解產品,不想和程序員進行過多的交流和文檔解釋。
其實在實際工作中,我發現有就算你寫得再詳細,如果不進行口頭介紹,程序員想把如此臃腫的文檔理解清楚也非常不容易。所以,如果能用流程圖來表述,就不需要長篇累述;如果能先進行產品大致的介紹,讓大家先理解整個思路,就不需要文字上過于累贅的表述。
產品文檔應該做到“考慮全面,邏輯清晰,語言精練”
第五坑——文檔排版不易讀
原來才開始寫文檔的時候,完全不知道什么排版,在無數次打磨自己的格式后,開始對排版有了一點自己的理解。
如果說排版有什么技巧,我想可能是這幾個:
- 以功能劃分大板塊,大板塊標題醒目。
- 把大板塊簡單拆分,并用小標題區分。
- 用點號羅列觀點,不要寫成一大段。
對于文檔排版,統一文字格式后,做好以上幾點就能確保文檔基本整潔和可讀性。但是排版是個長期打磨和鍛煉的事情,必須要經常鍛煉,才能有一套自己的合理的排版風格。
第六坑——重點內容不突出
重點加得非常隨意,就會造成兩個結果,重點不突出和重點不夠重點。
所以,文檔中應該標記重點,但也要注意:
- 重點最好為重要的動詞、轉折詞、新名詞和關鍵邏輯判定詞等。
- 重點內容不在于多,更在于精,滿篇重點則是沒有重點。
第七坑——不用程序員喜歡的形式寫文檔
最后,特別重要的一點,也是不可不說的一點,那就是使用程序員容易理解的、喜歡的方式來寫文檔。
- 程序員更喜歡看到能用公式來展現各個數據或者信息之間的關系;
- 了解程序員編程的時候常用的邏輯,多以這種邏輯術語來寫文檔,這樣程序員就更能理解;
- 多用分句,別用連句,一個分句表達一個意思就可以了。
- 能用配流程圖的,千萬別只寫文字。
作者:譚宇恒
來源:http://www.jianshu.com/u/a43d456a3674
本文由 @譚宇恒 授權發布于人人都是產品經理,未經作者許可,禁止轉載。
字不如表,表不如圖
還有一點 寫完文字描述 檢查一遍有沒有錯別字
尤其是 第七坑——不用程序員喜歡的形式寫文檔 這種大標題錯誤
不是用Axure寫PRD嗎?
最好的產品PDR,永遠存在PM的思路里。閱讀PDR的最高效方式,就是隨便問PM,對方都可以思路清晰的對答如流。
prd不是pdr
啪啪打臉
你逗我笑
來自運營的prd吐槽
這內容條理??……誠懇建議作者讀一下《金字塔原理》學習一下邏輯表達的方法。
來來來,把你認為清楚地呈現出來
標題吸引人,內容就不說了。。。
你們上線前都不測試么?
本篇文章可讀性就不是很高吧,錯別字還不少。能用圖別用字,咋全是字
哈哈哈經典
收藏
個人感覺,帶有交互的產品原型對開發人員來說更容易掌控。當然,開發文檔肯定也是必要的,一來輔助開發人員核對細節,二來可以作為產品的記錄備份,用作版本迭代以及產品交付等。不過,我們的開發人員,現在基本上也不會去讀繁雜的文檔了。。
能用圖就不用文字,說的太對了
能用圖說明的,堅決不用文檔。開發人員理解圖片的能力比看文強很多。
理解圖片的能力比看文強很多。其實這是全人類的共同點。
學習了
你們開發人員真不錯,還會去讀文檔。
哈哈哈,莫名想笑
確實不錯