產(chǎn)品需求文檔-沒有標準,只有溝通

1、產(chǎn)品需求文檔：沒有標準，只有溝通這次寫這個其實也算是有感而發(fā)，起因是一個產(chǎn)品朋友小李向我吐梢，他在 一個創(chuàng)業(yè)團隊，公司正在從探索期向成長期度過。原來的測試工作都是小李和研 發(fā)相互協(xié)同的，也就是他們各自客串下測試。后面公司慢慢向成長期過度，員工 從10個演變成了 50多號人，其他城市也有分公司，加起來快 100號人，研發(fā)人 員也就從2人變成了近10人。因為業(yè)務(wù)發(fā)展迅速，要全力負責業(yè)務(wù)線上的事情， 就招了個測試。之后便是他們找我吐梢的原因。小李給我說，測試來的第一周，給了他第一個任務(wù)，就是熟悉業(yè)務(wù)，了解公 司當前的運營模式，以及基本功能。隨后便帶著他去見了每一個部門相關(guān)對接人， 甚至帶到兄弟部門去

2、認識下部門的領(lǐng)導。希望后面有問題可以直接有效的溝通， 不然后面公司在擴展下，這種機會就很少了。隨后也帶到了研發(fā)那里，一一介紹， 給研發(fā)表示，這是新來的測試，以后大家就是工作上的一家人我，畫外音就是讓 研發(fā)不要刁難測試。就這樣過了 2周，小李覺得半個月時間基本的業(yè)務(wù)和一些功能應(yīng)該熟悉了， 那么就開始對相關(guān)功能就行上手測試吧。這個時候小李他們的公司也在瘋狂的擴 展，并且還是獲得了融資，這使得小李的工作更忙了。但是小李還是和她約好時 間，進行相關(guān)功能的對接。對接的時候，小李拿著草圖給測試，進行了相關(guān)的講 解。想讓他根據(jù)草圖和上面的文字先進行簡單的測試。但是測試老說，沒有文檔 測試不了。小李說當時他很

3、困惑，雖然當初很多功能都是ide,直接在會議室假設(shè)出來， 但是之后去探索驗證之后，很多都完善到草圖上了。他就直接給他說那些草圖就是就可以直接完成測試。后面測試就直接慰了小李，說你這是草圖，根本就不是 需求文檔。小李就直接說，原來公司處于探索業(yè)務(wù)，變換的很快，都是根據(jù)草圖 來進行研發(fā)的，這個草圖上都有，為什么不能作為測試依據(jù)？那時，兩人爭得不可開交，爭到最后，測試就說她來自己寫一份，說小李根 本不是產(chǎn)品。小李說到這里我也是吃驚了，畢竟都說出這樣的話了。連忙問小李 草圖上有哪些東西，小李表示上面很多是手繪的原型和注釋，以及后續(xù)方向，并 且上面也簡單的寫了公司的業(yè)務(wù)方向以及后期如何做這些內(nèi)容。還因為

4、怕看不懂,專門還整理了，整理之后還給研發(fā)他們看，他們都說沒問題，他也不知道問題出 在哪里。后面我也想了想這個問題，真的是沒有需求文檔而引起的嗎？寫個需求文檔 他的標準是什么？需求文檔的作用工作中，對于產(chǎn)品寫需求文檔還有個很常見的事情就是，我們花了大量的時 間，將產(chǎn)品所有細節(jié)都推敲的完畢，都仔仔細細的寫在了需求文檔上面，甚至寫 完后還反復和研發(fā)、業(yè)務(wù)部門核對了，確保沒有問題之后，交付給了相關(guān)干系人。 結(jié)果他們因為工作安排，時間緊湊要么就沒看，要么就簡單的看了幾眼就放在了 一邊。這個無疑是打擊我們。但是這個好處是十分的明顯：1、后期研發(fā)中出現(xiàn)了什么問題，這個鍋產(chǎn)品肯定不背。為什么？研發(fā)自己 不看文

5、檔，文檔里面寫的清清楚楚，這個地方要這樣處理，是你們自己不根據(jù)文 檔來研發(fā)。2、如果出現(xiàn)了人員的離職或者是新增，那他可以通過需求文檔快速的了解 項目。減少他的熟悉時間。換個角度，不寫需求文檔。那就是我們可以從作出決定，快速的推進至研發(fā) 階段。等于開完會就直接開工，而不需要將所有細節(jié)都寫的清清楚楚。有種說法, 人無完人，事無巨細。但是這個對研發(fā)團隊要求很高，首先團隊必須具備作出決 定的能力，其次大家要有相同的行為準則和職業(yè)素養(yǎng)，這個就體現(xiàn)在相關(guān)代碼規(guī) 范、設(shè)計規(guī)范、原型規(guī)范上。因為如果配合出現(xiàn)了失誤，包括功能和功能之間的 不協(xié)調(diào)，ui配色和尺寸的不統(tǒng)一。那么就直接涼了。寫需求文檔的作用是什么需求

6、文檔的作用主要就是為了保證目標一致性， 讓研發(fā)或是其他配合人員能 夠清晰的了解我們在做什么，了解當下我們需要解決的問題、面對的場景是什么, 對于成功的定義是什么。總結(jié)起來就是只要寫出的東西，弄夠幫助團隊成員，作出正確的結(jié)果的東西, 那就是需求文檔，需求文檔沒有標準，只有溝通。我不希望約束的說，需求文檔這樣寫才對，你那樣寫不對。我認為需求文檔 對于個人來說，想這么寫就這么想，想那樣寫就那樣寫。但是對于工作，還是根 據(jù)公司要求來，畢竟吃飯嘛。但是，不管是寫需求文檔還是說需求文檔，我還是認為包含下面這些信息， 對于團隊，還是個人都還是有很大的好處。1、問題和方案。2、證明問題和方案3、成功的定義4、

7、場景5、功能描述第一：問題和方案人與人之間有著明顯的差異性和共同性，更別說不同職位了。前端、后端、 測試、UI、產(chǎn)品、運營等職位，對于相同的事物和問題都會有著自己的見解和解 決方案，并且因為職業(yè)壁壘原因，常會雞同鴨講，這是最常見的。（工作中例子太多了，產(chǎn)品要增加個功能，直接給研發(fā)說，結(jié)果研發(fā)說沒必 要。這就是很典型的研發(fā)不知道說在什么樣子的背景下，遇見的這個問題。）我們首先要明確這個新增加的功能要解決了什么問題。其中包括了簡要的背景，這個背景可以說一句話，例如，支付成功人數(shù)很低。也可以說相關(guān)的用戶調(diào) 研、市場反饋、數(shù)據(jù)趨勢等，用于證實這個功能或產(chǎn)品是我們團隊要做的。第二：證明問題和方案我們需要

8、證實兩個東西，一個是問題，一個是方案。要給其他人說明這個問 題是真實存在的，而不是我想當然的。因為職業(yè)問題，很多研發(fā)或者是其他的部 門的人都會認為（不絕對哈，但確實有這樣現(xiàn)象），產(chǎn)品是技術(shù)部門的 門面”，吹 拉彈唱”樣樣都會。讓人誤以為產(chǎn)品經(jīng)理是個只會 吹?！钡慕浑H花”。但確實行業(yè) 內(nèi)，包括當初我自己出現(xiàn)過隨隨便便寫個我認為的問題，而沒去證實他，之后草 草丟給研發(fā)。方案，也是同樣的問題，不去窮舉，不去關(guān)注相關(guān)競品的解決方案，也就推 進到研發(fā)階段。我想這也大家都會經(jīng)歷的一個過程。同樣我能夠想象到出，當我們經(jīng)歷多了之后，簡簡單單說一個方案之后，這個方案真的可能是最優(yōu)方案，畢 竟天才和蠢材說出相關(guān)的

9、解決方案，前者是經(jīng)歷過很多失敗的方案之后說的，后 者可能是運氣好，正好說中罷了。叫他說出其中緣由，那就漏底了。第三：成功的定義我們要清晰的告訴其他人，這個功能對于成功的定義是什么。這里的成功有兩個意思，一、成功的研發(fā)出來。二、這個功能推出后取得的 效果。成功的研發(fā)出來這個很好理解，就是還原度，百分之一百的還原出功能。只 有保證這個功能能夠百分之一百的還原，我們才能通過市場、通過用戶去驗證這 個功能或說這個方案是否成功。不然對于團隊和我們來說就是，資源浪費。我們 要將成功進行定義，只有這樣才能得到有效的反饋。不然我們無法確認得到的結(jié) 果，到底是成沒成功。第四：場景場景說產(chǎn)品工作中最重要的東西，自

10、始至終貫穿整個產(chǎn)品的一生。我這里不 在過多闡述，文末我會發(fā)個我使用的場景還原方式。第五：功能描述功能描述包含的了很多東西，如：業(yè)務(wù)、流程、反饋、架構(gòu)等，如果是文檔 的還會包括原型、狀態(tài)、迭代記錄等問題。我們需要讓其他人了解業(yè)務(wù)的流程，讓每一個人清晰的知道，我們的業(yè)務(wù)環(huán) 節(jié)。就像我們說的，如果你們團隊很強大，幾乎人人都是業(yè)務(wù)方面的小能手，那 么你覺得還需要相關(guān)圖嗎？反之，我們?yōu)榱四軌蚯逦谋硎鰳I(yè)務(wù)，不一定要去畫精美的圖來表示，只要能夠理解，寫個 1234都可以我們需要讓其他人了解當前產(chǎn)品的架構(gòu)，不管是信息還是功能，這樣能夠盡 可能的復用，減少開發(fā)成本。不然研發(fā)不清楚，瓜兮兮的跑去寫代碼，結(jié)果要寫

11、 完了發(fā)現(xiàn)，這尼瑪其他模塊有，可以直接調(diào)用或者是改一下就能用。現(xiàn)在寫出來 了還不能用（開發(fā)：代碼耦合度高）只能去改原來的，那么確實是很尷尬。所以 可以告知用戶，這個功能在原產(chǎn)品上是存在的或是已經(jīng)實現(xiàn)過了，因為代碼真的 不像我們說的，這個功能很簡單，隨便加一個字段就行。最后其實小李那些草圖里面的內(nèi)容確實是包含所有需求文檔有的東西，只是相對于所謂的需求文檔，沒成體系罷了。也不是說那個測試的問題，我只是覺得太過 去追求所謂的需求文檔，反而不知道需求文檔的真實目的。雖然標準的文檔在一 定程度上能夠在這些內(nèi)容表述清楚，通過原型具現(xiàn)出來。但是切記，這些還是需 要根據(jù)當前公司文化來，按需輸出。一味追求所謂標準的需求文檔，不去思考為