本文摘自PM圈子網—PM牛人聚集地(www.pmleader.cn)轉載請註明來源

先問幾個問題，大家覺得寫文件是一件必要的事嗎？你喜歡寫文件嗎？？你寫的文件程式猿和測試會看嗎？？

假如你自己能獨立設計和開發一個產品，你甚至根本就不需要寫文件。文件的存在很大程度是因為團隊協作需要進行資訊傳遞。但負責傳遞資訊的文件會存在幾個問題，資訊傳遞會有損失。

存在寫文件的成本。

存在閱讀理解成本。

而在一個變化萬千的網際網路行業裡，大家應該知道有一種絕望叫做，當你還在寫文件的時候，別人已經在收集使用者反饋了。

關於資訊傳遞在知乎我找到一個圖表，大概表達的是“溝通成效和溝通渠道的關係”，我們可以發現右上角面對面交流的效率是最高的，左下角用紙來交流效率最低。

當今的世界是敏捷開發的天下。傳統開發過程中，人們通過交付文件來獲得價值。但這樣做的結果僅僅是撰寫了產品的附加件而已，對於產品本身的交付沒有太大的幫助。在經典的敏捷軟體開發宣言中，我們會發現很有名的一句話，工作的軟體高於詳盡的文件，你寫再多的文件也不如用一個哪怕簡陋卻可執行的軟體來闡述明白你的問題。

當然文件也有它存在的必要，比如說它的“記錄”功能，若干個月後，專案換了負責人，他就可以通過這份文件瞭解專案的來龍去脈，從而更好的傳承設計思路。文件也有益於解決紛爭，當傳遞過程中資訊流失太多，事後追究過錯，看一看文件就能找到問題所在。

因此在網際網路行業，無論是大企業還是創業公司，文件有其存在的必要，但這個文件應該是一份輕量且高質量的文件。那麼一份敏捷有效的文件應該遵循怎樣的原則呢？？

最最基本的有兩條：

敏捷性

可讀性

什麼叫敏捷的文件，我的理解就是“精簡易迭代”。

所謂精簡，就是指你的文件只講重點，什麼標題目錄複雜的專業術語統統都先拋掉，只寫當前任務的核心要點。有些需求文件會先講行業和業務背景，還會有名詞解釋的類別，專門有一塊來解釋後文難懂的專業術語，而對於一份敏捷的文件來說，這些細節應該在MRD或者BRD裡說明，不應該在PRD裡廢話。如果程式猿需要了解業務背景知識，當面講給他聽。

所謂易迭代，就是這份文件要有一個易於迭代的形式。一是編寫人員不應該花費過多的時間去注意排版和規範，思考的重心在需求內容。二是要有迭代記錄的區域，需求變更頻繁，變動的原因、時間、提出人、處理情況還是有必要記錄下來的。當然大家可以將這部分統一進PRD的文章開頭，也可以另外用專門的軟體或文件來管理。

關於“敏捷性”還有一個要點要提一提，就是編寫文件的時機。我們要知道，不是先寫文件，才做產品。合理的順序應該是先有產品，需要的時候才寫文件，當然這一點比較難把握，實際操作中大家需要綜合考慮。

接著說可讀性，我的理解也是兩個要點：

形式易讀

考慮閱讀物件

關於形式易讀，其實它會增加編寫人員的寫作成本，但還是有一些很基本的技巧和方法可以快速的達到目標。最起碼，我們要用上設計四原則的前兩個，親密性和對齊，再用簡單的色塊區分開文件的不同要點，就能很大的提高閱讀人員的理解速度，同時不會增加太多的編寫成本。

接著就到了本文浮誇標題的內容了T.T，也就是寫一份考慮閱讀物件尤其是程式猿的文件。寫文件的人其實最怕寫完文件卻沒人看，所有的努力彷彿都被浪費了，而產品需求文件最主要的閱讀人員就是開發工程師和測試工程師。那究竟怎樣的文件才是他們喜聞樂見的呢？？

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

比如說測試最常見的工作方式是什麼，就是撰寫測試用例。測試用例如果簡化一點，我們可以用寫“使用者故事”（user story）的方法來寫。

用使用者故事的方法來編寫需求文件，可以讓我們將注意力放在需求上，而不是解決方法和實施技術上。過早的提及技術實施方案，會降低對需求的注意力。

這裡我上網搜了一下資料，規劃業務需求，可以採用“3W模板”，也就是：

誰（Who）

是什麼（What）

為什麼（Why）

上面的3W實際上就是描述了相關利益者是誰，他們想要什麼，他們為什麼有這種需求。下面舉一例子進行說明：

誰（Who）：使用者

是什麼（What）：希望藉助一個應用程式在不同伺服器間傳輸檔案為什麼（Why）：為了儲存專案資料

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

誰（Who）：消費者/使用者

是什麼（What）：想將歸檔過程數字化

為什麼（Why）：為了增強溝通，提高分享效率

敏捷專案中編寫使用者故事有一個常用模板：作為一名“使用者型別”，我想要“需求”，以便於“原因”。應用到這個例子，就是：作為一名使用者，我想要將歸檔程式數字化，以便於增強溝通、提高分享效率。

多數情況下，需求內容需要更加充實和詳細，這一步要放到後面做，開始不要這樣。使用者故事的方法有時會因過於簡短、不斷重複而受到批評。這裡我們必須明白：需求文件不是散文或詩歌，應該清晰、簡明地描述使用者需求；需求文件的重點也在於此，不要管形式多變或內容是否重複這樣的問題。

然後作為一個不太懂技術的產品，我瞭解到開發中最常用的一個軟體設計框架叫做MVC框架。

它的運作規則我還在學習，但它給我編寫需求文件提供了一個重要的指導意義，就是在開發的思維裡，使用者的輸入行為、後端規則和前端互動是獨立出來的，我們在撰寫文件時是不是也可以按照這種思維方法來區分內容。對此我設計了一個需求文件的模板，歡迎大家提出參考意見啊，這個文件還有很多缺陷，歡迎大家提出修改意見和我交流哦。