PRD需求文檔如何寫？掌握它的底層邏輯你就會了

PRD需求文檔如何寫？掌握它的底層邏輯你就會了編輯導讀：一份好的需求文檔往往是項目成功的先決條件，對一個產(chǎn)品經(jīng)理或項目經(jīng)理來說就顯得尤為重要。但在實際工作中，很多產(chǎn)品經(jīng)理都一昧追求所謂標準的需求文檔，不去思考為什么這樣寫，寫這些的意義是什么。本文作者從需求文檔的目的出發(fā)，對其底層邏輯進行了深入分析探討，希望能夠給你帶來一定的啟發(fā)。01產(chǎn)品經(jīng)理的事兒，怎能算抄年前寫了《需求文檔：沒有標準、只有溝通》這片關(guān)于需求文檔的內(nèi)容，但是說實話更多的是感受而非思考，這次主要是學習底層邏輯，通過底層邏輯真正的思考需求文檔這東西；需求文檔是我們工作中接觸最多，寫的最多，花樣最多的文檔，沒有之一。為什么說沒有之一，首先說說他的展現(xiàn)形態(tài)。有ppt版、word版（文檔）、excel版、axuer版、墨刀版、幕布版等豐富的展現(xiàn)形式。其次內(nèi)容上需求文檔還要分c端、b端、g端，最后還有可能根據(jù)交付人不同而進行不同的調(diào)整。所以說需求文檔是寫的最多，花樣最多的文檔。所以就在這樣的前提下，寫需求文檔似乎就成了許多產(chǎn)品經(jīng)理們老大難的問題。獨自寫需求文檔時發(fā)現(xiàn)不了問題，一旦遇到要與其他人協(xié)同，需要交付給他們需求文檔，這時心態(tài)立馬就到“爆炸邊緣”了。各種問題都涌現(xiàn)，我的結(jié)構(gòu)對不對？該這樣寫嗎？需求文檔該如何寫？等等問題就出來了。在這里插一句表揚，表揚咱們產(chǎn)品經(jīng)理的優(yōu)點，就是不懂就百度。所以每當大家遇見困難，都能自覺帶著各自的疑問去百度，尋找解決方案。但我們又常因為百度出五花八門的答案，又一臉懵逼，最后只能懵懵逼逼的跟著這些“答案”抄“作業(yè)”把需求文檔寫完。最后本以為寫完就ok了，又發(fā)現(xiàn)這次寫的需求文檔又和上次的不一樣。emmm….都是我寫的為什么不一樣？我是不是我查的姿勢沒對啊。面對這樣的情況我們只能是越查越頭疼，于是乎，算了直接找個模版或者是別人的需求文檔套一下，不一樣就不一樣吧。至此，我們走上了模版流產(chǎn)品經(jīng)理，在這個流派中我們原則是，遇事不決，模版庫學，模版不夠，百度來湊。我只想說，這樣不對（很有天賦），這樣是學不到東西的（你已經(jīng)入門了）。哈哈，其實產(chǎn)品經(jīng)理的職責就有解決問題，如果你能用這些方式解決了問題，這就是一個好方法，這是不容置疑的事。但是我們需要通過表層看他們的底層邏輯才行，這樣我們才能升級。02透過需求文檔的表層看他的底層在大部分咱們搜索需求文檔時，咱們得到的答案一般如下：傳達產(chǎn)品開發(fā)需求（我不管，我就是要，按照我的邏輯可以搞定。）保證各部門溝通有理有據(jù)（這是誰的鍋，別亂丟）產(chǎn)品質(zhì)量控制有具體標準（小老弟你看，你當初自己確認沒問題，你現(xiàn)在…..）便于交接工作（來，老弟我走后，這口鍋你要拿穩(wěn)了）等等（產(chǎn)品經(jīng)理在外，要學會保護自己…）這些內(nèi)容其實我們只需要簡單的搜一搜就都知道了。但卻存在一個致命問題，那就是每次借鑒完畢后，過段時間就忘了，又不知道該如何學，又需要重新打開百度或是自己的模版庫去借鑒。長此以往，對于我們來說，我們確實收獲了快速解決問題的能力，但是卻丟失了產(chǎn)品經(jīng)理最重要的東西，探索，挖掘問題的思維和能力。不說本末倒置，但確實對我們不利。因此，我們需要學會在現(xiàn)有答案中去挖掘答案深層次的底層邏輯，在了解事物底層邏輯之后，就會發(fā)現(xiàn)事物的變化都遵循著底層邏輯，例如：能量守恒，萬有引力。面對底層邏輯，我們理解起來會存在一定的困難，但底層邏輯就好比一個公司的愿景，它將是這個公司前進方向和價值體現(xiàn)，只有我們需要不停的逼迫自己去思考，不停的杠自己，最終提煉出它的底層邏輯，那時咱們將會通向羅馬。用樹來比喻，我們直視樹時，眼里多數(shù)只關(guān)注這樹的樹葉，當我們刻意觀察時，能看見樹的樹枝。如果我們聚焦目光再次觀察，咱們會想到它的樹干。到這里時大部分人就停下思考，說出樹干上長樹枝，樹枝上長樹葉，所以樹干是影響樹生在的原因。但是我們都知道這不是真正準確的事實，樹還有樹根，我們還需要用工具挖開腳下的泥土，發(fā)現(xiàn)這棵樹的樹根，在才是真正的底層。為什么樹根是底層？，而樹干不是？樹干壞死了這個樹也不沒了嗎？這里會忽視一個問題，樹干枯萎了，不代表這個樹沒了，只要樹根健全，那么這這顆樹的樹干就算枯萎了，也會枯樹發(fā)芽的情況。如果樹根壞死了，那么這顆樹再怎么的高大，健壯，對于這顆樹來說死亡是一定的事。所以觀察一棵樹不要光看“樹葉”、“樹枝”、“樹干”，我們還要去挖掘它的“樹根”來看。03解決方案是客觀存在的，不要隨意主觀使用事物的發(fā)展是非線性的，都會經(jīng)歷一個個起伏，但事物發(fā)展也都遵循它的底層邏輯。就像一個樹，就算這顆樹長得如何奇怪，但樹一定是向上生長的。如果你要質(zhì)疑，說有些樹是斜著或是橫著生長的。我只想說，那是因為你看待這顆樹的角度不對，如果你關(guān)注的是它離開地面的位置，就會發(fā)現(xiàn)他們始終是向上生長的。在很多寫需求文檔相關(guān)內(nèi)容的文章中，多數(shù)文章都會提及讓大家按照文章中的需求文檔標準來寫。讓大家誤以為跟著文章中的規(guī)范和標準來就沒有問題，隨即大家也就根據(jù)文章中的需求文檔規(guī)范和標準來依葫蘆畫瓢了。至于為什么這樣寫？這樣寫的用處是什么？等問題就不去考慮，潛意識認為文章里的標準就是標準，跟著寫就對了。但是這樣完全是誤會大部分作者的想法，這類作者更多是想體現(xiàn)他們寫需求文檔的思路，希望大家可以相互探討，尋求進步。而不是直接炒一炒就ok的事情。比如下面我提供的這個需求文檔規(guī)范：使用說明修訂記錄版本記錄版本說明全局規(guī)范功能列表角色列表權(quán)限列表框架圖流程圖原型圖非功能需求人員安排特別說明大家覺得如何？看著在這份需求文檔規(guī)范，可能會有人覺得很細致，很好，想要直接使用，問有沒有模版等。但是我在這里提醒大家需要注意，有經(jīng)驗的產(chǎn)品經(jīng)理是不會太過隨意的使用其他人的需求文檔。而是根據(jù)公司、項目、人員等配置來靈活的調(diào)整需求模塊。直接使用會存在很多弊端，如整個項目就三個人，還需要使用說明嗎？這個產(chǎn)品就做個計算功能，以后再也不迭代的，需要修訂、版本記錄嗎？這產(chǎn)品就一個頁面，那需要角色和權(quán)限列表嗎？帶入這樣的場景會發(fā)現(xiàn)，似乎需求文檔中很多模塊都不需要。但是有時候就是只有2個人的產(chǎn)品也還需要復雜的需求文檔，那么到底什么時候用什么樣的需求文檔到底依據(jù)的是什么？我想說是底層邏輯。04底層邏輯需要先找相同之處大部分產(chǎn)品常說的底層邏輯指的是業(yè)務(wù)邏輯，數(shù)據(jù)邏輯等邏輯流程。而我想說的底層邏輯是事物各自遵循的規(guī)則。例如：萬有引力、能量守恒等。因為這樣我們看待問題的時候就可以更加的貼切本質(zhì)，從思路上打開新的天窗。借用劉潤老師的話：底層邏輯就是揭開表面不同看到背后的相同，找到變化后沒變的東西。在這層沒找到共同之處，再往下挖掘。在這句話中揭露底層邏輯的一個本質(zhì)之一。不同的表面都背后的相同。帶入需求文檔中，我們可以看見每一個模塊都是不同的，雖然他們都不相同，但他們遵循的底層邏輯一定是相同的。這時我們需要思考每個模塊來找尋他們的不同之處和相似之處。使用說明：需要我們準確說明該文檔涉及的范圍，做一定的范圍指導（不是所有的東西我都管ok？)，說明能給誰看，不能給誰看（傻子們不要亂傳出去），并且解釋文檔中一些專業(yè)名詞，避免出現(xiàn)認知差異，還需要對文檔中的一些名稱進行定義說明，比如，名詞：我去年買了個表；含義：去年我去買了一塊手表；歧義：我去你xxx；修訂記錄：告知查閱人每一次編輯負責人是誰，避免找不對人（那個傻子修改了我的原型？憑什么修改為的原型？腦子是不是有?。涗浢看涡薷膬?nèi)容，方便回檔，讓每一次修改都變的有憑有據(jù)，更加的謹慎，而不是“我想….、我覺得…..”（嘴強王者）版本記錄：清晰讓所有人了解當前線上版本和線下版本情況，了解每個版本的負責人是誰，針對版本問題可以統(tǒng)一的進行反饋（指定誰是這次的背鍋俠）版本說明：我們在什么情況下，遇見了什么問題，那我們這次用什么方法解決了這個問題。幫助其他人快速了解版本情況。全局規(guī)范：告知所有人我們遵循的規(guī)則是什么，要如何避免文檔內(nèi)容參差不齊而溝通困難。功能列表：記錄我們會涉及哪些平臺，有什么樣的模塊和功能。對于一些功能我們有什么特別的要求和限制。以及最后我們大概的開發(fā)周期是多久。角色列表：告知我們整個系統(tǒng)內(nèi)涉及的角色有好多個，能不能創(chuàng)建角色？每個角色他們能做什么事情。權(quán)限列表：枚舉出我們系統(tǒng)中可以使用的權(quán)限有多少，可以讓使用者快速了解哪些能做哪些不能做。框架圖：快速掌握產(chǎn)品的整體框架流程圖：展示各個細節(jié)上的業(yè)務(wù)邏輯以及數(shù)據(jù)邏輯，明確每個產(chǎn)品模塊是如何運作或協(xié)同的。原型圖：將抽象的功能具現(xiàn)化，變成可視化頁面，讓大家了解我們做的產(chǎn)品是什么樣子的。非功能需求：清晰表述特別的要求，如性能要求（負載均衡、響應(yīng)時間）、安全要求（防火墻、非對稱加密）、復用要求（模塊化低耦合高內(nèi)聚）等。人員安排：指明每個模塊、每一個時期誰是負責人，當出現(xiàn)問題之后，可以及時聯(lián)系干系人，提高效率。特別說明：將產(chǎn)品中涉及風險和需要注意的地方進行表述，避免大家觸及風險，造成不必要的損失。呼，寫了這么多，那么咱們思考下，他們的相同的地方是什么？似乎每個模塊的使用場景中都存在兩個或以上的角色，都是交代、說明一些事實。這些事實，要么讓你避免什么問題，要么是讓你遵循規(guī)則或是指導你出現(xiàn)問題后應(yīng)該及時找誰處理等。從這些角度開來需求文檔的底層邏輯看起來是溝通。用需求文檔代替我們需要面對面溝通問題。使用需求文檔減少我們溝通時間，提升了我們的效率（不用面對面去溝通，省下來的時間去做其他的工作）。我們換個角度，現(xiàn)在我們大多數(shù)使用敏捷開發(fā)的方式進行產(chǎn)品開發(fā)，在敏捷開發(fā)中我們很少看到十分詳細的需求文檔，更多都是一個簡單的原型就進行開發(fā)，甚至有時沒有實體文檔，就一句話、一個白板畫就進行開發(fā)，并且還能夠在短時間內(nèi)完成上線。面對這樣的情況，不管是一句話還是就一個原型他們都是需求文檔，但說需求文檔的底層是溝通，就顯得十分牽強，因為日常交流也是溝通啊，所以說一句話就是需求文檔？這樣的后果就是強行上升到哲學的問題，我們下面在繼續(xù)思考。我們再從其他方向入手，從它們的形態(tài)開始思考，為什么會存在那么多ppt、word、excel等形態(tài)的需求文檔。他們的相同的地方是什么。和其他使用ppt、word、excel等工具的內(nèi)容又有什么相同的地方？根據(jù)這樣的思路我發(fā)現(xiàn)其實他們都只是一種承載的工具而已，我們甚至可以用紙筆來寫，用腦子來記。所以拋開這些工具，我們的目的只是在于記錄。記錄需求文檔的使用說明，記錄產(chǎn)品原型的樣子，記錄規(guī)范，記錄負責人等等，所以需求文檔的底層邏輯之一就是記錄。但是這里體現(xiàn)出一個問題。在敏捷開發(fā)中似乎也不存在記錄啊，老板開頭一句話我們就直接干、我們開發(fā)的時候也沒有文檔來記錄，大家都是直接面對面溝通開發(fā)。在這些真實的場景下，需求文檔的底層邏輯又不成立了。我只想說對于這些只是形式上的記錄，不能因為沒有實體文檔記錄而說沒有需求文檔。但確實這樣看來光一個記錄并不能代表需求文檔的底層邏輯，那么還需要另外的東西。05相同屬性+不同差=底層邏輯（本質(zhì)定義）柏拉圖有個小故事，柏拉圖曾說人是二足無毛的動物。然后第歐根尼就帶了一只拔光羽毛的雞到講學的地方，說：「這就是柏拉圖的『人』」。同時亞里士多德說：「人是理性的動物」。在兩位大佬的話我們可以發(fā)現(xiàn)，我們除了相同的屬性，還需要一個他們不同的地方。需求文檔和其他用相似工具記錄的內(nèi)容來講，他們的相似之處在于記錄，用不用等形式記錄內(nèi)容，那他們不同之處是什么？是工作，需求文檔是記錄工作的內(nèi)容？我看不是，工作中也有很多需要記錄的問題，所以不是所有的文檔叫需求文檔。記錄需求，需求文檔是記錄需求的內(nèi)容？我看也不覺得準確，因為除了需求，需求文檔中還記錄很多東西，如說明、限制、人員、修改記錄等，最后再三思考，我暫時認為，需求文檔的底層邏輯是（我下定義了）記錄有歧義的內(nèi)容（交流正確的內(nèi)容）。為什么？記錄這個我們不再說了，這個是內(nèi)容的底層邏輯，所有內(nèi)容都需要我們進行記錄（交流），不管是線上，線下還是腦子里面，都是需要我們記錄（交流）的，這就是他們共同的屬性。那為什么是有歧義的內(nèi)容了，是因為我將他們帶入了日常開發(fā)的場景中，很多時候不是所有的內(nèi)容都需要進行文檔記錄，我們可以采取口頭溝通的形式就能達到效果，所以并不是全都需要文檔記錄。那么是在什么情況下才需要記錄了？那就是預防事故（預防背鍋）。不管是文檔說明，功能列表，原型樣式還是業(yè)務(wù)邏輯，我們都會去記錄、去做可視化的頁面還有詳細的標注，那是因為我們怕出現(xiàn)意外。這里的意外是指因為每個人認知不同，看待問題的方向不同，而造成大家按照自己的想法來進行工作。例如短信驗證碼是多少問的問題，運營覺得4位簡單，研發(fā)覺得8位安全，而產(chǎn)品經(jīng)理覺得6位即可，即相對安全也方便快速記憶。像這樣有歧義（需要確認）的地方我們將進行記錄（交流），以便后續(xù)做的時候都按照這個來。所以需求文檔的底層邏輯上：記錄有歧義的內(nèi)容（交流正確的內(nèi)容）06通過底層邏輯思考需求文檔的表面