先問幾個(gè)問題，大家覺得寫文檔是一件必要的事嗎？你喜歡寫文檔嗎？？你寫的文檔程序猿和測(cè)試會(huì)看嗎？？

假如你自己能獨(dú)立設(shè)計(jì)和開發(fā)一個(gè)產(chǎn)品，你甚至根本就不需要寫文檔。文檔的存在很大程度是因?yàn)閳F(tuán)隊(duì)協(xié)作需要進(jìn)行信息傳遞。但負(fù)責(zé)傳遞信息的文檔會(huì)存在幾個(gè)問題，

1. 信息傳遞會(huì)有損失。
2. 存在寫文檔的成本。
3. 存在閱讀理解成本。

而在一個(gè)變化萬千的互聯(lián)網(wǎng)行業(yè)里，大家應(yīng)該知道有一種絕望叫做，當(dāng)你還在寫文檔的時(shí)候，別人已經(jīng)在收集用戶反饋了。

關(guān)于信息傳遞在知乎我找到一個(gè)圖表，大概表達(dá)的是“溝通成效和溝通渠道的關(guān)系”，

我們可以發(fā)現(xiàn)右上角面對(duì)面交流的效率是最高的，左下角用紙來交流效率最低。

當(dāng)今的世界是敏捷開發(fā)的天下。傳統(tǒng)開發(fā)過程中，人們通過交付文檔來獲得價(jià)值。但這樣做的結(jié)果僅僅是撰寫了產(chǎn)品的附加件而已，對(duì)于產(chǎn)品本身的交付沒有太大的幫助。在經(jīng)典的敏捷軟件開發(fā)宣言中，

我們會(huì)發(fā)現(xiàn)很有名的一句話，

工作的軟件高于詳盡的文檔，你寫再多的文檔也不如用一個(gè)哪怕簡(jiǎn)陋卻可運(yùn)行的軟件來闡述明白你的問題。

當(dāng)然文檔也有它存在的必要，比如說它的“記錄”功能，若干個(gè)月后，項(xiàng)目換了負(fù)責(zé)人，他就可以通過這份文檔了解項(xiàng)目的來龍去脈，從而更好的傳承設(shè)計(jì)思路。文檔也有益于解決紛爭(zhēng)，當(dāng)傳遞過程中信息流失太多，事后追究過錯(cuò)，看一看文檔就能找到問題所在。

因此在互聯(lián)網(wǎng)行業(yè)，無論是大企業(yè)還是創(chuàng)業(yè)公司，文檔有其存在的必要，但這個(gè)文檔應(yīng)該是一份輕量且高質(zhì)量的文檔。那么一份敏捷有效的文檔應(yīng)該遵循怎樣的原則呢？？

最最基本的有兩條：

1. 敏捷性

2. 可讀性

什么叫敏捷的文檔，我的理解就是“精簡(jiǎn)易迭代”。

所謂精簡(jiǎn)，就是指你的文檔只講重點(diǎn)，什么標(biāo)題目錄復(fù)雜的專業(yè)術(shù)語統(tǒng)統(tǒng)都先拋掉，只寫當(dāng)前任務(wù)的核心要點(diǎn)。有些需求文檔會(huì)先講行業(yè)和業(yè)務(wù)背景，還會(huì)有名詞解釋的類別，專門有一塊來解釋后文難懂的專業(yè)術(shù)語，

而對(duì)于一份敏捷的文檔來說，這些細(xì)節(jié)應(yīng)該在MRD或者BRD里說明，不應(yīng)該在PRD里廢話。如果程序猿需要了解業(yè)務(wù)背景知識(shí)，當(dāng)面講給他聽。

所謂易迭代，就是這份文檔要有一個(gè)易于迭代的形式。

一是編寫人員不應(yīng)該花費(fèi)過多的時(shí)間去注意排版和規(guī)范，思考的重心在需求內(nèi)容。

二是要有迭代記錄的區(qū)域，需求變更頻繁，變動(dòng)的原因、時(shí)間、提出人、處理情況還是有必要記錄下來的。

當(dāng)然大家可以將這部分統(tǒng)一進(jìn)PRD的文章開頭，也可以另外用專門的軟件或文檔來管理。

關(guān)于“敏捷性”還有一個(gè)要點(diǎn)要提一提，就是編寫文檔的時(shí)機(jī)。我們要知道，不是先寫文檔，才做產(chǎn)品。合理的順序應(yīng)該是先有產(chǎn)品，需要的時(shí)候才寫文檔，當(dāng)然這一點(diǎn)比較難把握，實(shí)際操作中大家需要綜合考慮。

接著說可讀性，我的理解也是兩個(gè)要點(diǎn)：

1. 形式易讀

2. 考慮閱讀對(duì)象

關(guān)于形式易讀，其實(shí)它會(huì)增加編寫人員的寫作成本，但還是有一些很基本的技巧和方法可以快速的達(dá)到目標(biāo)。最起碼，我們要用上設(shè)計(jì)四原則的前兩個(gè)，親密性和對(duì)齊，

再用簡(jiǎn)單的色塊區(qū)分開文檔的不同要點(diǎn)，就能很大的提高閱讀人員的理解速度，同時(shí)不會(huì)增加太多的編寫成本。

接著就到了本文浮夸標(biāo)題的內(nèi)容了T.T，也就是寫一份考慮閱讀對(duì)象尤其是程序猿的文檔。寫文檔的人其實(shí)最怕寫完文檔卻沒人看，所有的努力仿佛都被浪費(fèi)了，而產(chǎn)品需求文檔最主要的閱讀人員就是開發(fā)工程師和測(cè)試工程師。那究竟怎樣的文檔才是他們喜聞樂見的呢？？

我的想法是寫一份符合程序猿思維模式和工作方法的文檔。

比如說測(cè)試最常見的工作方式是什么，就是撰寫測(cè)試用例。測(cè)試用例如果簡(jiǎn)化一點(diǎn)，我們可以用寫“用戶故事”（user story）的方法來寫

用用戶故事的方法來編寫需求文檔，可以讓我們將注意力放在需求上，而不是解決方法和實(shí)施技術(shù)上。過早的提及技術(shù)實(shí)施方案，會(huì)降低對(duì)需求的注意力。? ??這里我上網(wǎng)搜了一下資料，規(guī)劃業(yè)務(wù)需求，可以采用“3W模板”，也就是：

– 誰（Who）

– 是什么（What）

– 為什么（Why）

上面的3W實(shí)際上就是描述了相關(guān)利益者是誰，他們想要什么，他們?yōu)槭裁从羞@種需求。下面舉一例子進(jìn)行說明：

– 誰（Who）：用戶

– 是什么（What）：希望借助一個(gè)應(yīng)用程序在不同服務(wù)器間傳輸文件

– 為什么（Why）：為了存儲(chǔ)項(xiàng)目數(shù)據(jù)

為了更加接近“用戶故事”，我們可以改寫為：

– 誰（Who）：消費(fèi)者/用戶

– 是什么（What）：想將歸檔過程數(shù)字化

– 為什么（Why）：為了增強(qiáng)溝通，提高分享效率

敏捷項(xiàng)目中編寫用戶故事有一個(gè)常用模板：作為一名“用戶類型”，我想要“需求”，以便于“原因”。

應(yīng)用到這個(gè)例子，就是：作為一名用戶，我想要將歸檔程序數(shù)字化，以便于增強(qiáng)溝通、提高分享效率。? ??多數(shù)情況下，需求內(nèi)容需要更加充實(shí)和詳細(xì)，這一步要放到后面做，開始不要這樣。

用戶故事的方法有時(shí)會(huì)因過于簡(jiǎn)短、不斷重復(fù)而受到批評(píng)。這里我們必須明白：需求文檔不是散文或詩歌，應(yīng)該清晰、簡(jiǎn)明地描述用戶需求；需求文檔的重點(diǎn)也在于此，不要管形式多變或內(nèi)容是否重復(fù)這樣的問題。

然后作為一個(gè)不太懂技術(shù)的產(chǎn)品，我了解到開發(fā)中最常用的一個(gè)軟件設(shè)計(jì)框架叫做MVC框架，

它的運(yùn)作規(guī)則我還在學(xué)習(xí)，但它給我編寫需求文檔提供了一個(gè)重要的指導(dǎo)意義，就是在開發(fā)的思維里，用戶的輸入行為、后端規(guī)則和前端交互是獨(dú)立出來的，我們?cè)谧珜懳臋n時(shí)是不是也可以按照這種思維方法來區(qū)分內(nèi)容。對(duì)此我設(shè)計(jì)了一個(gè)需求文檔的模板，歡迎大家提出參考意見啊，

這個(gè)文檔還有很多缺陷，歡迎大家提出修改意見和我交流哦。

#專欄作家#

烏木，公眾號(hào)：wumuwizard，人人都是產(chǎn)品經(jīng)理專欄作家，簡(jiǎn)書@烏木。喜歡搖滾和吉他，喜歡騎自行車，喜歡用Sketch，自學(xué)編程中，對(duì)交互比較敢興趣。希望做個(gè)全面又有夢(mèng)想的產(chǎn)品人，夢(mèng)想是做一款自己喜歡用戶也喜歡的產(chǎn)品。

本文系作者授權(quán)發(fā)布，未經(jīng)許可，不得轉(zhuǎn)載。