需求文檔是產品經理最重要的產出物，它的撰寫占據了許多產品經理50%以上的工作精力。然而在實際工作中，依然會存在著諸多問題，這是什么原因呢？應該如何解決？本文作者對此進行了分析，一起來看一下吧。

需求文檔是產品經理最重要的產出物，沒有之一。許多產品經理在實際工作中，需求文檔的撰寫占據了 50% 以上的工作精力，即使投入很多精力，需求文檔依舊存在諸多問題。如：

1. 需求理解不清晰，掙扎在開發人員提出各種問題和重新溝通確認。
2. 解決方案沒有形成閉環，缺少異常流程，重復返工需求文檔；
3. 追求高保真原型，大量時間和精力花費在原型設計和交互，后期修改原型的成本高。
4. ……

出現這些問題的核心原因，是產品經理把需求文檔當成一份開發交付文檔，而不是當成「信息傳遞工具」，重點不在交付，而在于信息傳遞。

01 煩人的信息差

產品研發的信息傳遞，指需求方，實施方為了解決需求，進行需求和解決方案的信息傳遞過程。

需求文檔，是承接產品信息的工具，最核心作用，是實現需求方，實施方的信息統一，減少因為信息傳遞問題，帶來的「產品無法解決需求」 的情況。

信息傳遞面臨核心問題的是：「信息差」。

信息傳遞本質是信息編碼再解碼的過程，需求方將想要傳遞的信息通過媒介進行編碼輸出，傳遞給接受者，接受者再解析理解信息的過程。

原始信息在傳遞環節會存在不同程度的損耗，導致需求方和接受方在信息上存在的理解差距的情況，我們稱之為「信息差」。

導致出現信息差的原因很多，例如：

1. 需求方沒有清晰表達能力（編碼問題）；
2. 文本溝通，沒有選擇溝通效率更好面對面溝通（通道/媒介問題）；
3. 接受者對接受的信息理解出錯（解碼問題）；
4. ……

信息傳遞必定存在信息差，產品研發又存在「多人溝通」的常態化現象：

1. 需求方，人數不定，通常為老板，用戶，產品經理等；
2. 產品經理，一般情況 1 人；
3. 技術方，人數不定，通常為前端，后端，測試等。

「信息差」+「多人溝通」形成雙喇叭型結構的信息傳遞模式，在橫向傳輸上，拉長信息傳遞鏈。

即需求方編碼 → 通道傳遞 → 產品經理解碼 → 產品經理再編碼 → 通道傳遞 → 技術方解碼。

傳遞每個環節按 20% 的信息損失，至少有 70% 的信息在傳遞過程中被損失。

類似綜藝節目的傳話游戲，幾個人站成一排，每個人都聽不到前一個人說的話，只能通過前一個人的口型和肢體語言，猜測對方說的是什么，然后再傳話給下個人。

一般到第三個人時，傳遞的信息和原來要傳的信息是天差地別的。

縱向傳輸上，產品經理即接收多個需求方的信息，也向多個技術方傳遞信息。

一方面，多個需求方存在著多個需求，需求方往往傳遞自己認為可行的解決方案，不擅于闡述自己遇到的問題或真實需求。

產品經理需要花費大量精力辨別每個信息傳遞背后的真實需求，一旦有所疏忽，容易誤解用戶真實需求，掉入「用戶說啥，實現啥」的陷阱，投入開發成本，但沒有解決用戶實際需求。

另一方面，產品經理要向多名開發人員傳遞思考后需求和解決方案，開發人員側重于解決方案的實現可行性和成本，很少主動理解需求方的真實需求，主動與產品經理，需求方同步信息，減少信息差。

每個開發人員對信息的理解程度不同，理解需求和方案容易出現誤差，開發過程中，容易出現以下問題：

1. 開發環節，開發人員之間理解差異導致方案差異，例如：前后端人員理解不一致，導致接口缺失，無法聯調；
2. 測試環節，開發人員完成功能與測試人員測試用例不相符；
3. 驗收環節，開發功能與產品經理預期不一致，產品功能無法滿足需求。

出現上述問題，產品經理不得不重復溝通需求，花費大量時間促使所有開發人員達成信息統一。

02 標準化需求文檔

需求文檔是對產品開發的信息傳遞問題的解決方案，好的需求文檔是能讓所有人統一認知，從而提高開發效率的利器。

需求文檔的好壞受限于產品經理能力和經驗，高水平的產品經理屬于小比例人群，所以我們不要求每個產品經理輸出高質量的需求文檔。

但，隨著崗位和行業深入發展，產品經理的工作出現標準化趨勢，意味著我們可以輸出「標準化需求文檔」，保證需求文檔的下限，統一上下游對需求認知，減少信息傳遞過程的損耗。

標準化需求文檔包含 3 個部分：文檔結構化，繪制標準化，功能描述標準化。

1. 文檔結構化

按照產品經理的工作流程，我們將需求文檔的作業流程分為 4 項內容：「需求介紹」，「解決方案」，「修訂記錄」，「其他事項」。

各項內容都有各個細項，會在后續章節進行講解，不再贅述。

2. 繪制標準化

繪制標準化，核心掌握是流程圖的繪制標準化和低保真原型快速輸出。

產品經理在流程圖上經常犯 2 個問題：

一是多數產品經理為非科班入行，很少掌握流程圖的規范，容易繪制錯誤規范的流程圖，被開發人員按正確規范誤解。

產品經理不需要掌握流程圖所有繪制規范，只需要掌握 10 個常用簡單繪制規范即可。

二是不考慮異常流程，異常流程分為 3 大類：

1. 全局型異常流程，指在系統全局都會出現的異常流程；
2. 功能型異常流程，指在功能操作和規則上出現的異常流程；
3. 業務型異常流程，指正常業務過程中，發生不符合預期的業務流程。

不同類型異常流程應用，我們會在后續「流程圖篇」進行講解。

產品經理在原型繪制上避免追求高保真原型和原型交互設計，需求文檔的核心是傳遞需求信息，只要能達到目的，低保真原型和無交互設計都可以。

相仿原型和交互設計精細度越高，意味著我們投入原型設計的時間越多，理解和傳遞需求時間越少，本末倒置。

如何在極短的時間內輸出一份低保真原型，我們會在后續「原型篇」進行講解。

3. 功能描述標準化

功能描述是產品經理碼字最多的地方，也是開發人員理解和落地功能點開發的根據。

開發人員在功能點出現理解誤差的主要原因，是功能描述不標準，即遺漏功能點。

我們以信息流「下滑加載」為例，用戶通過「下滑加載」功能獲取信息，我們怎么寫這個功能點？

A. 用戶可以在頁面頂部向下滑動觸發加載功能，每次加載獲取下一頁的內容，加載失敗時，toast 文字提示：「加載失敗~」。

作為對比，我們看另一份功能描述 B：

1. 觸發方式：在內容列表頂部，用戶通過從上向下手勢觸發滑動觸發，滑動區域超過 1/6 屏幕生效，滑動過程顯示滑動進度 icon，具體樣式和動效以 UI 為主。
2. 加載內容數量：每次加載，均可獲取 50 條內容。
3. 加載內容規則：將下一頁未加載的內容，按照內容的與用戶算法匹配值排序，展示匹配值最大發布的內容。
4. 網絡異常處理：網絡異常狀況下，執行加載功能后，Toast 提示「網絡異常，請更換網絡后再試」，并顯示加載前的內容。
5. 網絡異常：無網絡，弱網絡，均視為網絡異常。
6. 請求超時：若服務器5秒內未返回數據，Toast 提示用戶「服務器忙，請稍后再試」，并顯示加載前的內容。
7. 內容數量不足：加載時，若下一頁內容超過 0 條，但小于 50 條，則返回所有的內容。
8. 下一頁無內容：加載時，若下一頁內容數量為0，則Toast 提示「無最新內容，我們再加急生產中……」。
9. 非正常加載：若是非正常加載，僅視為一次加載，加載過程中，Toast 提示用戶「馬上出現你想要的內容」。
10. 非正常加載定義：監控用戶加載頻率，兩次加載的間隔時間低于1秒，即視為非正常加載。

通過 A 與 B 兩段功能描述，我們清楚看到 A 遺漏 8 點功能點，還有 1 點功能描述不清晰，這意味著開發和測試人員就一個功能，得和產品經理溝通 9 次以上。

功能描述標準化的最大好處，是減少產品經理和開發人員的信息差，減少反復溝通確認，讓開發人員更多時間專注在功能落地。

功能描述如何標準化，在后續「功能描述篇」進行詳細闡述。

03 最后的話

在文章最后，我們總結全篇核心內容：

1. 需求文檔的本質是：需求方，產品經理，開發人員之間需求和解決方案的「信息傳遞工具」。
2. 產品開發主要溝通問題，是「信息差」+「多人溝通」導致信息不同步，容易做出無用產品。
3. 高需求文檔水平的方式是標準化，指「文檔結構化」，「繪制標準化」，「功能描述標準化」。

后續的想法，希望通過 5-6 篇闡述需求文檔的文章，幫助大家減少一點時間在需求文檔和溝通上，

然后，2023 年多一點時間讓自我成長。