人類高質量需求文檔怎麼寫?超級厲害的產品經理都在用藍湖超級文檔

適合人羣:0-5 歲產品經理、“野路子”產品人、期望系統性學習產品方法的人羣

你將得到:

1、寫需求文檔和口頭交流到底哪個更適合我?

2、爲什麼我的文檔總有人說看不懂?

3、需求文檔“好”的標準是什麼?

4、評審會上總因爲邏輯漏洞被研發追問,如何能避免這種尷尬?

5、大廠是怎麼寫需求文檔的,他們的思考方式是什麼?

閱讀時間:🥤 喝完一杯奶茶的時間


我們這邊不寫需求文檔,研發也沒耐心看,只看原型和設計圖。 — by. 產品經理

我覺得文檔讀起來太累,你直接給我講一遍吧。— by. 研發工程師

這個功能之前的邏輯是什麼來着?我也忘了,你查查代碼吧?— by. 產品經理

產品邏輯漏洞特別多,需求很粗糙,邏輯都是我們補充的。—by. 測試工程師

這些問題在大部分產研團隊中都存在,團隊成員間的信任感也因此逐漸降低。但在我調研的產品、研發同學中有一個有趣的現象:他們會因爲產品價值不明確、邏輯不清晰吵得不可開交從而浪費大量時間,但與此同時又一致認爲寫需求文檔價值不大,原型旁邊標註邏輯是產品交付需求更高效的方式

所以,真的是這樣嗎?

首先,我們需要明確一個問題:爲什麼要寫需求文檔每當我拋出這個問題,高票回答中都會出現這個答案:需求文檔只是形式,把產品邏輯和研發對清楚也能達到一樣效果。但實際上這樣理解問題的人,往往只看到了表象而沒有深刻理解需求文檔的底層邏輯。

使用什麼樣的工具,決定你的思維方式。”你當然可以在原型旁邊標註詳細的邏輯,甚至口頭對研發說明邏輯。但這些都是不夠體系化的表達方式,如果長時間使用這種方法,你的思考方式是無法得到結構化的訓練。說不清這個需求的價值,不會從產品 5 要素去思考問題,最終呈現出的表象就是研發口中的“產品拍腦袋想的需求”。可能你會覺得這麼說並不尊重,但事實確實如此。

需求文檔是讓你深思熟慮後產出的信息無損地流轉在工作中各個角色間的媒介。

接下來,我們看看“需求文檔”需要擁有哪些要素,才能幫助產品經理們增加高質量思考,輸出完備準確的信息。

🍎 “需求文檔需要是結構化的”

在寫需求文檔前,需要找一份優質的模板大綱。好的模板大綱是結構化的,能讓我們更全面的思考問題,保障文檔輸出的最低水平。(我在下方章節提供了一套優質的需求文檔模板並進行了詳細說明。)

“結構是骨、現象是皮。”在思考需求問題時不要被表象迷惑,應更深挖其本質。我曾經做過一個關於引導的需求,整體邏輯是:通過用戶的行爲,觸發引導提示。當時需求圍繞着:用戶點擊 A 出現引導 a,點擊 B 出現引導 b 去描述。現在回憶起來,這種描述就是按照現象去描述的並沒有抓住本質。這套邏輯的本質是一套觸發器的邏輯,存在入參和出參,入參不同導致現象不同,所以研發只要開發這套觸發器即可。

☝️ “需求文檔是需要經得起挑戰的”

你可以在需求中添加和刪減任何模塊,但要經得起他人挑戰。例如:背景信息是否需要寫?寫或者不寫會帶來什麼樣的利弊?增加這部分信息是讓你的需求更加完備易懂了,還是更加冗餘了?閱讀者會這部分信息是否感興趣?等等。

如果以上問題都想清楚了,那你的文檔經得起任何 challenge。

🍭 “需求文檔是需要爲你的讀者而寫的”

我們經常遇到新上的功能要給研發、運營、客戶支持甚至是老闆等角色進行產品宣講。一些產品經理會拿着同一份文檔、重複同一套語言邏輯,格式化的講解,但實際上往往會看到聽衆一臉茫然的表情,長此以往這種宣講會大家也都不想參加了。這並不是聽衆的理解能力問題而是針對不同人羣我們需要從不同的視角去闡述他們最關心的問題。

例如,給老闆宣講新功能的時候,他重點關心的是這個功能給公司帶來什麼樣的收益?成本如何?上線後效果怎麼樣?而非功能怎麼使用,細節邏輯是什麼。但如果是給客戶支持進行宣講,那麼反而是功能如何使用,用戶遇到問題怎麼處理更加重要。

所以在需求文檔中,我往往會加上 QA 這個模板,模擬聽衆可能會遇到的問題並逐一解釋。這種方法起碼能節省你 40% 以上的開會時間。

🍸 “需求文檔是需要注入感情的”

這部分就是相對高級的要求了,實現起來也確實比較困難。我曾經給運營宣講需求的時候發現,明明這個需求他們也很關心,但是宣講過程中他們表現的心不在焉,似乎聽不進去只想快點下班。

實際上問題在於產品經理把需求當做功能點講解了。人類天性是喜歡聽故事的,每一個需求本身都是一個故事:在什麼樣的場景,一幫什麼樣的人,遇到了什麼樣的問題,其他人是怎麼解決的,我們又是如何解決的。

如果你擅長講故事,擅長把人們帶入場景中產生共情,那你就能寫好一份需求文檔

那麼,應該如何寫一篇高質量的需求文檔呢?我曾有幸和字節跳動產品專家交流過這個問題,他將需求思考方法抽象總結出一份模板,目前這份模板不僅他的團隊在用,我也使用至今,有效的幫我結構化了思維方式。

這份模板(請見下圖)一共分爲 10 部分。無論大小需求,除了第 10 部分 i18N(即是否有國際化需求)可能部分公司不涉及,剩下的內容都有填寫的必要性。當你深入思考每一部分並明確描述邏輯,你會發現需求的溝通成本降低了。養成寫需求文檔的習慣,產品輸出的邏輯漏洞會越來越少,功能規劃也會變得井井有條。

除此之外,我還收集了日常工作中優秀的產研先進方法。如果看完這篇文章你對寫需求文檔有了新的認識並且希望落實在自己的工作中,就請來藍湖超級文檔中的模板中心看看我爲你準備的內容吧。

藍湖是一款產研協作工具,我們致力於提高整個產研工作效率。在藍湖,不僅有本文所提及的需求文檔模板和最佳案例,更有各個大廠(如美團、阿里、字節等公司)實際在用的方法論。例如:敏捷項目管理、用戶畫像、產品能力模型、UX審覈清單、接口文檔模板、產研思考模型等大量優質模板和案例。

獲取更多產研先進方法步驟如下:

1️⃣ 電腦端搜索“藍湖”進入官網,或者輸入網址 www.lanhuapp.com 進行註冊

2️⃣ 註冊後選擇超級文檔,點擊「新建文檔」就能查看我爲你準備的全部產研先進方法以及真實案例了

3️⃣ 你可以嘗試選擇任意模板進行創建或者在超級文檔中寫筆記、撰寫產研相關文檔、甚至是管理項目

4️⃣ 另外,你還可以將文檔分享給其他小夥伴進行閱讀以及共同管理項目

🌸  期待我的分享能對你有所幫助,更期待我們能在藍湖相遇。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章