中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

我還是強調這個觀念：10年后的現在，產品經理已經從探索階段逐漸發展到規模階段并且正在向標準化發展。

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

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

產品技能的熟練度

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

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

這意味著什么呢？ 這意味著：并不存在真正意義上的“創造”，我們所謂的“創造”產品，都是基于已有規則內的“應用”。

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

既然是“應用”，就會出現熟練度的問題。

你有沒有發現大量功能的背后，是存在“類型”的，相同“類型”的功能，他的需求文檔總是驚人的相似，你需要做的，也許只是調整“參數”。

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

微信的個人資料，設計的很是巧妙，他將預覽和編輯分離了，這對我們去理解這個命題很有幫助。

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

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

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

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

這是我們對產品技能掌握的熟練度。

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

這正如我告知你的：我們只是對規則的“應用”， 并不曾真的創造“規則”。

減少不必要的思考時間

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

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

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

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

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

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

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

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

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

減少團隊時間耗損

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

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

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

對于研發而言，你有沒有發現 Android 和IOS在同一個功能上用了不同的實現方法，我曾經遇到過。

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

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

數據分析

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

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

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

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

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

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

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

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

#專欄作家#

枯葉，微信公眾號，枯葉咖啡館，人人都是產品經理專欄作家。擅長社交，社區，細分群體挖掘。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。