一、需求文檔的反思

????????學(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)對不對？該這樣寫嗎？需求文檔該如何寫？等等問題就出來了。

? ? ? ? 很多時(shí)候，當(dāng)我們遇到不懂的，都喜歡去百度尋求答案，但是通常百度給出的答案都是五花八門的，無法區(qū)分好壞，甚至都無法判斷是否是自己真正需要的。這時(shí)候，我們往往都只能選擇一個(gè)通用的需求模板，照著抄把需求文檔寫完。長久以往，我們會(huì)發(fā)現(xiàn)每次寫的需求文檔總是跟上次的不一樣，面對這樣的情況我們只能是越查越頭疼，于是乎，算了直接找個(gè)模版或者是別人的需求文檔套一下，不一樣就不一樣吧。至此，我們走上了模版流產(chǎn)品經(jīng)理，在這個(gè)流派中我們原則是，遇事不決，模版庫學(xué)，模版不夠，百度來湊。

????????我只想說，這樣不對，這樣是學(xué)不到東西的。哈哈，其實(shí)產(chǎn)品經(jīng)理的職責(zé)就有解決問題，如果你能用這些方式解決了問題，這就是一個(gè)好方法，這是不容置疑的事。但是我們需要通過表層看他們的底層邏輯才行，這樣我們才能升級。

二、透過需求文檔的表層看他的底層

????????在大部分咱們搜索需求文檔時(shí)，咱們得到的答案一般如下：

????????傳達(dá)產(chǎn)品開發(fā)需求、保證各部門溝通有理有據(jù)、產(chǎn)品質(zhì)量控制有具體標(biāo)準(zhǔn)、便于交接工作、等等

????????這些內(nèi)容其實(shí)我們只需要簡單的搜一搜就都知道了。但卻存在一個(gè)致命問題，那就是每次借鑒完畢后，過段時(shí)間就忘了，又不知道該如何學(xué)，又需要重新打開百度或是自己的模版庫去借鑒。長此以往，對于我們來說，我們確實(shí)收獲了快速解決問題的能力，但是卻丟失了產(chǎn)品經(jīng)理最重要的東西，探索，挖掘問題的思維和能力。不說本末倒置，但確實(shí)對我們不利。

????????因此，我們需要學(xué)會(huì)在現(xiàn)有答案中去挖掘答案深層次的底層邏輯，在了解事物底層邏輯之后，就會(huì)發(fā)現(xiàn)事物的變化都遵循著底層邏輯，例如：能量守恒，萬有引力。面對底層邏輯，我們理解起來會(huì)存在一定的困難，但底層邏輯就好比一個(gè)公司的愿景，它將是這個(gè)公司前進(jìn)方向和價(jià)值體現(xiàn)，只有我們需要不停的逼迫自己去思考，不停的杠自己，最終提煉出它的底層邏輯，那時(shí)你將會(huì)通向羅馬。

三、解決方案是客觀存在的，不要隨意主觀使用

????????事物的發(fā)展是非線性的，都會(huì)經(jīng)歷一個(gè)個(gè)起伏，但事物發(fā)展也都遵循它的底層邏輯。就像一個(gè)樹，就算這顆樹長得如何奇怪，但樹一定是向上生長的。如果你要質(zhì)疑，說有些樹是斜著或是橫著生長的。我只想說，那是因?yàn)槟憧创@顆樹的角度不對，如果你關(guān)注的是它離開地面的位置，就會(huì)發(fā)現(xiàn)他們始終是向上生長的。

????????在很多寫需求文檔相關(guān)內(nèi)容的文章中，多數(shù)文章都會(huì)提及讓大家按照文章中的需求文檔標(biāo)準(zhǔn)來寫。讓大家誤以為跟著文章中的規(guī)范和標(biāo)準(zhǔn)來就沒有問題，隨即大家也就根據(jù)文章中的需求文檔規(guī)范和標(biāo)準(zhǔn)來依葫蘆畫瓢了。至于為什么這樣寫？這樣寫的用處是什么？等問題就不去考慮，潛意識認(rèn)為文章里的標(biāo)準(zhǔn)就是標(biāo)準(zhǔn)，跟著寫就對了。

????????但是這樣完全是誤會(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è)頁面，那需要角色和權(quán)限列表嗎？

????????帶入這樣的場景會(huì)發(fā)現(xiàn)，似乎需求文檔中很多模塊都不需要。但是有時(shí)候就是只有2個(gè)人的產(chǎn)品也還需要復(fù)雜的需求文檔，那么到底什么時(shí)候用什么樣的需求文檔到底依據(jù)的是什么？我想說是底層邏輯。

四、底層邏輯需要先找相同之處

????????大部分產(chǎn)品常說的底層邏輯指的是業(yè)務(wù)邏輯，數(shù)據(jù)邏輯等邏輯流程。而我想說的底層邏輯是事物各自遵循的規(guī)則。例如：萬有引力、能量守恒等。因?yàn)檫@樣我們看待問題的時(shí)候就可以更加的貼切本質(zhì)，從思路上打開新的天窗。

????????借用劉潤老師的話：底層邏輯就是揭開表面不同看到背后的相同，找到變化后沒變的東西。在這層沒找到共同之處，再往下挖掘。在這句話中揭露底層邏輯的一個(gè)本質(zhì)之一。不同的表面都背后的相同。

????????帶入需求文檔中，我們可以看見每一個(gè)模塊都是不同的，雖然他們都不相同，但他們遵循的底層邏輯一定是相同的。這時(shí)我們需要思考每個(gè)模塊來找尋他們的不同之處和相似之處。

? ? ? ?1、使用說明：需要我們準(zhǔn)確說明該文檔涉及的范圍，做一定的范圍指導(dǎo)，并且解釋文檔中一些專業(yè)名詞，避免出現(xiàn)認(rèn)知差異，還需要對文檔中的一些名稱進(jìn)行定義說明；

? ? ? ?2、修訂記錄：告知查閱人每一次編輯負(fù)責(zé)人是誰，避免找不對人，記錄每次修改內(nèi)容，方便回檔，讓每一次修改都變的有憑有據(jù)，更加的謹(jǐn)慎，而不是“我想…. 、我覺得…..”；

????????3、版本記錄：清晰讓所有人了解當(dāng)前線上版本和線下版本情況，了解每個(gè)版本的負(fù)責(zé)人是誰，針對版本問題可以統(tǒng)一的進(jìn)行反饋

????????4、版本說明：我們在什么情況下，遇見了什么問題，那我們這次用什么方法 解決了這個(gè)問題。幫助其他人快速了解版本情況。/

????????5、全局規(guī)范：告知所有人我們遵循的規(guī)則是什么，要如何避免文檔內(nèi)容參差不齊而溝通困難。

????????6、功能列表：記錄我們會(huì)涉及哪些平臺，有什么樣的模塊和功能。對于一些功能我們有什么特別的要求和限制。以及最后我們大概的開發(fā)周期是多久。/6角色列表：告知我們整個(gè)系統(tǒng)內(nèi)涉及的角色有好多個(gè)，能不能創(chuàng)建角色？每個(gè)角色他們能做什么事情。

????????7、權(quán)限列表：枚舉出我們系統(tǒng)中可以使用的權(quán)限有多少，可以讓使用者快速了解哪些能做哪些不能做。

????????8、框架圖：快速掌握產(chǎn)品的整體框架流程圖：展示各個(gè)細(xì)節(jié)上的業(yè)務(wù)邏輯以及數(shù)據(jù)邏輯，明確每個(gè)產(chǎn)品模塊是如何運(yùn)作或協(xié)同的。

????????9、原型圖：將抽象的功能具現(xiàn)化，變成可視化頁面，讓大家了解我們做的產(chǎn)品是什么樣子的。

????????10、非功能需求：清晰表述特別的要求，如性能要求（負(fù)載均衡、響應(yīng)時(shí)間）、安全要求（防火墻、非對稱加密）、復(fù)用要求（模塊化低耦合高內(nèi)聚）等。

????????11、人員安排：指明每個(gè)模塊、每一個(gè)時(shí)期誰是負(fù)責(zé)人，當(dāng)出現(xiàn)問題之后，可以及時(shí)聯(lián)系干系人，提高效率。

????????12、特別說明：將產(chǎn)品中涉及風(fēng)險(xiǎn)和需要注意的地方進(jìn)行表述，避免大家觸及風(fēng)險(xiǎn)，造成不必要的損失。

????????思考下，他們的相同的地方是什么？似乎每個(gè)模塊的使用場景中都存在兩個(gè)或以上的角色，都是交代、說明一些事實(shí)。這些事實(shí)，要么讓你避免什么問題，要么是讓你遵循規(guī)則或是指導(dǎo)你出現(xiàn)問題后應(yīng)該及時(shí)找誰處理等。?????????

????????從這些角度開來需求文檔的底層邏輯看起來是溝通。用需求文檔代替我們需要面對面溝通問題。使用需求文檔減少我們溝通時(shí)間，提升了我們的效率（不用面對面去溝通，省下來的時(shí)間去做其他的工作）。

????????我們換個(gè)角度，現(xiàn)在我們大多數(shù)使用敏捷開發(fā)的方式進(jìn)行產(chǎn)品開發(fā)，在敏捷開發(fā)中我們很少看到十分詳細(xì)的需求文檔，更多都是一個(gè)簡單的原型就進(jìn)行開發(fā)，甚至有時(shí)沒有實(shí)體文檔，就一句話、一個(gè)白板畫就進(jìn)行開發(fā)，并且還能夠在短時(shí)間內(nèi)完成上線。

????????面對這樣的情況，不管是一句話還是就一個(gè)原型他們都是需求文檔，但說需求文檔的底層是溝通，就顯得十分牽強(qiáng)，因?yàn)槿粘＝涣饕彩菧贤ò。哉f一句話就是需求文檔？這樣的后果就是強(qiáng)行上升到哲學(xué)的問題，我們下面在繼續(xù)思考。

????????我們再從其他方向入手，從它們的形態(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í)候也沒有文檔來記錄，大家都是直接面對面溝通開發(fā)。在這些真實(shí)的場景下，需求文檔的底層邏輯又不成立了。

????????我只想說對于這些只是形式上的記錄，不能因?yàn)闆]有實(shí)體文檔記錄而說沒有需求文檔。但確實(shí)這樣看來光一個(gè)記錄并不能代表需求文檔的底層邏輯，那么還需要另外的東西。

五、相同屬性+不同差=底層邏輯（本質(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ā)的場景中，很多時(shí)候不是所有的內(nèi)容都需要進(jìn)行文檔記錄，我們可以采取口頭溝通的形式就能達(dá)到效果，所以并不是全都需要文檔記錄。那么是在什么情況下才需要記錄了？那就是預(yù)防事故。

????????不管是文檔說明，功能列表，原型樣式還是業(yè)務(wù)邏輯，我們都會(huì)去記錄、去做可視化的頁面還有詳細(xì)的標(biāo)注，那是因?yàn)槲覀兣鲁霈F(xiàn)意外。這里的意外是指因?yàn)槊總€(gè)人認(rèn)知不同，看待問題的方向不同，而造成大家按照自己的想法來進(jìn)行工作。

????????例如短信驗(yàn)證碼是多少問的問題，運(yùn)營覺得4位簡單，研發(fā)覺得8位安全，而產(chǎn)品經(jīng)理覺得6位即可，即相對安全也方便快速記憶。像這樣有歧義（需要確認(rèn)）的地方我們將進(jìn)行記錄（交流），以便后續(xù)做的時(shí)候都按照這個(gè)來。

所以需求文檔的底層邏輯上：記錄有歧義的內(nèi)容（交流正確的內(nèi)容）

六、通過底層邏輯思考需求文檔的表面

????????在知道需求文檔的底層邏輯是記錄有歧義的內(nèi)容后，我們就可以很好的思考那些模塊是我們需要的，那些是不需要的。

?以理解需求文檔的底層邏輯后，面對豐富的需求文檔模版我們是不是有了更好的選擇？