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

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