網(wǎng)絡中，已有太多關于PRD撰寫方法的文章了，包括我自己也曾分享過一個技巧，但是，你知道為什么要寫需求文檔嗎？

文檔我們可能寫過很多了，但是有沒有發(fā)現(xiàn)他的重要性呢？或者說，在實際工作過程中，除了評審以外，是不是就沒有什么時候用到了？

我還是強調(diào)這個觀念：10年后的現(xiàn)在，產(chǎn)品經(jīng)理已經(jīng)從探索階段逐漸發(fā)展到規(guī)模階段并且正在向標準化發(fā)展。

最早對于PRD文檔的定義，在于需求評審，以及對需求的表達。但這對于現(xiàn)在來講是不夠的（如果僅僅將需求文檔當做是表達，或者是評審的載體，那您仔細閱讀本文的內(nèi)容吧，或許對你有所啟發(fā)）。

我們一起來看看，需求文檔在這些地方產(chǎn)生的影響。

產(chǎn)品技能的熟練度

對于app、HTML5、web的產(chǎn)品而言，我們的功能很大程度是受限于編程語言的，所有的功能都包含在我們基本不會觸及到的編碼邊界內(nèi)。

這個是我親身經(jīng)歷的一個示例：一個編碼邊界值在android平臺里，能夠調(diào)用的方法不能超過65536個；一旦超過后，就會無法編譯，并且提示你錯誤信息。

這意味著什么呢？ 這意味著：并不存在真正意義上的“創(chuàng)造”，我們所謂的“創(chuàng)造”產(chǎn)品，都是基于已有規(guī)則內(nèi)的“應用”。

你覺得不同平臺之間的手機號碼注冊以及第三方登陸，會有什么不一樣的嗎？其實大家都是一樣的，我們都是基于一定條件下，對規(guī)則、對邏輯的應用。

既然是“應用”，就會出現(xiàn)熟練度的問題。

你有沒有發(fā)現(xiàn)大量功能的背后，是存在“類型”的，相同“類型”的功能，他的需求文檔總是驚人的相似，你需要做的，也許只是調(diào)整“參數(shù)”。

我們拿個人資料來看看吧，看看他們都是什么樣的功能類型。

微信的個人資料，設計的很是巧妙，他將預覽和編輯分離了，這對我們?nèi)ダ斫膺@個命題很有幫助。

我會這樣來寫他們的需求文檔：

點擊類的功能，不僅僅適用于個人資料，在我們的信息流頁面，基本上都是點擊類的功能，你要做的是將需求描述后面的跳轉頁面地址更換成正確的地址，就足夠了。

我們往往會先繪制原型圖，再對比原型圖進行需求文檔的撰寫，這是為了減少調(diào)整的幅度，也是為了需求的完整度，要知道很多功能隨著原型圖的改變而改變。

當你在看著原型圖時，能否立即反應出這個頁面都是什么“類型”的功能，這種“類型”的功能，通常都會有哪些“功能點”？

這是我們對產(chǎn)品技能掌握的熟練度。

我需要向你再次強調(diào)一件事實，就目前市面上大部分的產(chǎn)品而言，我們的需求文檔是相同的！你未來要做的一款新的產(chǎn)品， 他的需求文檔也和你現(xiàn)在正在做的產(chǎn)品，是相同的，你所需要的，僅僅是將已有的需求文檔，重新排列，組合。

這正如我告知你的：我們只是對規(guī)則的“應用”， 并不曾真的創(chuàng)造“規(guī)則”。

減少不必要的思考時間

從自私的角度來講，需求文檔大概是你能夠為自己做的最偷懶的事情吧，但也是你最應該做的事情。

現(xiàn)在，我在設計一個信息流時，我大概需要5分鐘來寫這個頁面的需求文檔吧？而且我可以肯定的告訴你，這份文檔會很完整，包括錯誤機制，數(shù)據(jù)獲取機制等等。保守估計，這會有40個需求點，你需要多少時間呢？

我能做到這點的原因很簡單，我對需求非常熟悉，熟悉到我只需要從我以前的需求庫中copy出來，做微小的調(diào)整就可以了。

當你擁有了一個需求庫，這個庫里保存了你一直精心維護的需求文檔，并且你平?？臻e時會將他們做整理，分類，讓他們更像一個庫而不是文檔這會是什么感覺嗎？

這將會為你減少非常多的工作時間，如果每一個版本的研發(fā)周期是3周， 你在需求文檔上花的時間應該會在2天以上，并且這還會容易遺漏需求。

有沒有發(fā)現(xiàn)，我們大部分的時間是在做重復的事情嗎？ 不斷的重復的寫著“點擊跳轉xxx”“字符長度xx位”。

難道你沒想過有什么樣的辦法，把這些重復的，又占據(jù)了你很多時間的工作處理一下嗎？當你開始建立需求庫時，當你開始去經(jīng)營自己的需求庫時，就像經(jīng)營一個只為你服務的“產(chǎn)品”時，你應該很快就能從這樣的狀況里解放出來了。

你也不需要每一次寫需求文檔，都再去思考、擔心有沒有遺漏的，這樣的參數(shù)合不合理。這是因為：他已經(jīng)被使用過了，因為這是在你曾經(jīng)的項目過程中，就如此使用了；如果有問題， 那也一定在文檔里進行過修改了。

如果你對需求文檔足夠的重視，他將會在你未來的時間，也許是一年，也許是半年，開始回報給你。

減少團隊時間耗損

需求文檔節(jié)省的不僅僅是自己的時間，好的需求文檔還會為整個團隊帶來可觀的時間節(jié)省。

對于QA而言，是需要產(chǎn)出test case，這和我們產(chǎn)出需求文檔時一樣的，不一樣的地方在于，如果你的需求文檔不夠詳細，那么QA同學將會把我們的工作重新做一遍，并且這里面的時間耗損將是1+1>2的狀況。

這是因為在QA按照你的粗糙的需求文檔編寫測試用例時，會反復找你溝通，確認需求，因為沒有明確的需求表達，QA同學無法界定程序實現(xiàn)的正確，或者錯誤。

對于研發(fā)而言，你有沒有發(fā)現(xiàn) Android 和IOS在同一個功能上用了不同的實現(xiàn)方法，我曾經(jīng)遇到過。

在我們的需求文檔里，沒有提及首頁在數(shù)據(jù)請求后，需要將內(nèi)容緩存下來，當然，文檔里，也沒有提到“不緩存”，于是我們的IOS 沒有緩存數(shù)據(jù)，而android 緩存了，最后的結果，無論是緩存還是不緩存，都有一端需要調(diào)整。

你的需求文檔，能夠最大限度的解決研發(fā)過程的漏做，錯做，自定義需求三種惡劣情況的產(chǎn)生，從而減少研發(fā)同學的編程耗時。

數(shù)據(jù)分析

我已經(jīng)和你提及了需求文檔將會為你還有你的團隊，減少許多不必要的時間耗損，相應的等同于提高了整個項目組的產(chǎn)能， 這只需要你重視自己的需求文檔。

我還會為你介紹一個原因，數(shù)據(jù)分析，這將幫助你成長。

我們這里提到的數(shù)據(jù)分析，實際上需要你對數(shù)據(jù)足夠敏感，具備數(shù)據(jù)驅動的一些思維。

你在實際工作中，會反復經(jīng)歷評審，研發(fā)，評審，研發(fā)的循環(huán)，如果是這樣，你一定會經(jīng)歷另外一件事情：“需求被拒絕”。

需求被拒絕的原因有很多，諸如上層不通過，研發(fā)拒絕等等，當你把這些被拒絕的需求單獨拿出來進行分析時，你會不會發(fā)現(xiàn)里面的“共性”呢？

而這些共性，則會加強你對需求的掌控力，讓你知道什么是“可以實現(xiàn)”，什么是“無法實現(xiàn)”。

冒昧問一下， 產(chǎn)品新人，和產(chǎn)品老司機的明顯差異不是正好包含：知道什么能做，也正好知道什么不能做嗎？

最后，我希望你真的能夠重視你的需求文檔，建立好自己的需求庫，這好比研發(fā)人員手里的代碼一樣，他將會成為你個人價值的一部分。

#專欄作家#

枯葉，微信公眾號，枯葉咖啡館，人人都是產(chǎn)品經(jīng)理專欄作家。擅長社交，社區(qū)，細分群體挖掘。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。