需求文檔是產(chǎn)品經(jīng)理最重要的產(chǎn)出物，它的撰寫(xiě)占據(jù)了許多產(chǎn)品經(jīng)理50%以上的工作精力。然而在實(shí)際工作中，依然會(huì)存在著諸多問(wèn)題，這是什么原因呢？應(yīng)該如何解決？本文作者對(duì)此進(jìn)行了分析，一起來(lái)看一下吧。

需求文檔是產(chǎn)品經(jīng)理最重要的產(chǎn)出物，沒(méi)有之一。許多產(chǎn)品經(jīng)理在實(shí)際工作中，需求文檔的撰寫(xiě)占據(jù)了 50% 以上的工作精力，即使投入很多精力，需求文檔依舊存在諸多問(wèn)題。如：

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

出現(xiàn)這些問(wèn)題的核心原因，是產(chǎn)品經(jīng)理把需求文檔當(dāng)成一份開(kāi)發(fā)交付文檔，而不是當(dāng)成「信息傳遞工具」，重點(diǎn)不在交付，而在于信息傳遞。

01 煩人的信息差

產(chǎn)品研發(fā)的信息傳遞，指需求方，實(shí)施方為了解決需求，進(jìn)行需求和解決方案的信息傳遞過(guò)程。

需求文檔，是承接產(chǎn)品信息的工具，最核心作用，是實(shí)現(xiàn)需求方，實(shí)施方的信息統(tǒng)一，減少因?yàn)樾畔鬟f問(wèn)題，帶來(lái)的「產(chǎn)品無(wú)法解決需求」 的情況。

信息傳遞面臨核心問(wèn)題的是：「信息差」。

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

原始信息在傳遞環(huán)節(jié)會(huì)存在不同程度的損耗，導(dǎo)致需求方和接受方在信息上存在的理解差距的情況，我們稱之為「信息差」。

導(dǎo)致出現(xiàn)信息差的原因很多，例如：

1. 需求方?jīng)]有清晰表達(dá)能力（編碼問(wèn)題）；
2. 文本溝通，沒(méi)有選擇溝通效率更好面對(duì)面溝通（通道/媒介問(wèn)題）；
3. 接受者對(duì)接受的信息理解出錯(cuò)（解碼問(wèn)題）；
4. ……

信息傳遞必定存在信息差，產(chǎn)品研發(fā)又存在「多人溝通」的常態(tài)化現(xiàn)象：

1. 需求方，人數(shù)不定，通常為老板，用戶，產(chǎn)品經(jīng)理等；
2. 產(chǎn)品經(jīng)理，一般情況 1 人；
3. 技術(shù)方，人數(shù)不定，通常為前端，后端，測(cè)試等。

「信息差」+「多人溝通」形成雙喇叭型結(jié)構(gòu)的信息傳遞模式，在橫向傳輸上，拉長(zhǎng)信息傳遞鏈。

即需求方編碼 → 通道傳遞 → 產(chǎn)品經(jīng)理解碼 → 產(chǎn)品經(jīng)理再編碼 → 通道傳遞 → 技術(shù)方解碼。

傳遞每個(gè)環(huán)節(jié)按 20% 的信息損失，至少有 70% 的信息在傳遞過(guò)程中被損失。

類似綜藝節(jié)目的傳話游戲，幾個(gè)人站成一排，每個(gè)人都聽(tīng)不到前一個(gè)人說(shuō)的話，只能通過(guò)前一個(gè)人的口型和肢體語(yǔ)言，猜測(cè)對(duì)方說(shuō)的是什么，然后再傳話給下個(gè)人。

一般到第三個(gè)人時(shí)，傳遞的信息和原來(lái)要傳的信息是天差地別的。

縱向傳輸上，產(chǎn)品經(jīng)理即接收多個(gè)需求方的信息，也向多個(gè)技術(shù)方傳遞信息。

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

產(chǎn)品經(jīng)理需要花費(fèi)大量精力辨別每個(gè)信息傳遞背后的真實(shí)需求，一旦有所疏忽，容易誤解用戶真實(shí)需求，掉入「用戶說(shuō)啥，實(shí)現(xiàn)啥」的陷阱，投入開(kāi)發(fā)成本，但沒(méi)有解決用戶實(shí)際需求。

另一方面，產(chǎn)品經(jīng)理要向多名開(kāi)發(fā)人員傳遞思考后需求和解決方案，開(kāi)發(fā)人員側(cè)重于解決方案的實(shí)現(xiàn)可行性和成本，很少主動(dòng)理解需求方的真實(shí)需求，主動(dòng)與產(chǎn)品經(jīng)理，需求方同步信息，減少信息差。

每個(gè)開(kāi)發(fā)人員對(duì)信息的理解程度不同，理解需求和方案容易出現(xiàn)誤差，開(kāi)發(fā)過(guò)程中，容易出現(xiàn)以下問(wèn)題：

1. 開(kāi)發(fā)環(huán)節(jié)，開(kāi)發(fā)人員之間理解差異導(dǎo)致方案差異，例如：前后端人員理解不一致，導(dǎo)致接口缺失，無(wú)法聯(lián)調(diào)；
2. 測(cè)試環(huán)節(jié)，開(kāi)發(fā)人員完成功能與測(cè)試人員測(cè)試用例不相符；
3. 驗(yàn)收環(huán)節(jié)，開(kāi)發(fā)功能與產(chǎn)品經(jīng)理預(yù)期不一致，產(chǎn)品功能無(wú)法滿足需求。

出現(xiàn)上述問(wèn)題，產(chǎn)品經(jīng)理不得不重復(fù)溝通需求，花費(fèi)大量時(shí)間促使所有開(kāi)發(fā)人員達(dá)成信息統(tǒng)一。

02 標(biāo)準(zhǔn)化需求文檔

需求文檔是對(duì)產(chǎn)品開(kāi)發(fā)的信息傳遞問(wèn)題的解決方案，好的需求文檔是能讓所有人統(tǒng)一認(rèn)知，從而提高開(kāi)發(fā)效率的利器。

需求文檔的好壞受限于產(chǎn)品經(jīng)理能力和經(jīng)驗(yàn)，高水平的產(chǎn)品經(jīng)理屬于小比例人群，所以我們不要求每個(gè)產(chǎn)品經(jīng)理輸出高質(zhì)量的需求文檔。

但，隨著崗位和行業(yè)深入發(fā)展，產(chǎn)品經(jīng)理的工作出現(xiàn)標(biāo)準(zhǔn)化趨勢(shì)，意味著我們可以輸出「標(biāo)準(zhǔn)化需求文檔」，保證需求文檔的下限，統(tǒng)一上下游對(duì)需求認(rèn)知，減少信息傳遞過(guò)程的損耗。

標(biāo)準(zhǔn)化需求文檔包含 3 個(gè)部分：文檔結(jié)構(gòu)化，繪制標(biāo)準(zhǔn)化，功能描述標(biāo)準(zhǔn)化。

1. 文檔結(jié)構(gòu)化

按照產(chǎn)品經(jīng)理的工作流程，我們將需求文檔的作業(yè)流程分為 4 項(xiàng)內(nèi)容：「需求介紹」，「解決方案」，「修訂記錄」，「其他事項(xiàng)」。

各項(xiàng)內(nèi)容都有各個(gè)細(xì)項(xiàng)，會(huì)在后續(xù)章節(jié)進(jìn)行講解，不再贅述。

2. 繪制標(biāo)準(zhǔn)化

繪制標(biāo)準(zhǔn)化，核心掌握是流程圖的繪制標(biāo)準(zhǔn)化和低保真原型快速輸出。

產(chǎn)品經(jīng)理在流程圖上經(jīng)常犯 2 個(gè)問(wèn)題：

一是多數(shù)產(chǎn)品經(jīng)理為非科班入行，很少掌握流程圖的規(guī)范，容易繪制錯(cuò)誤規(guī)范的流程圖，被開(kāi)發(fā)人員按正確規(guī)范誤解。

產(chǎn)品經(jīng)理不需要掌握流程圖所有繪制規(guī)范，只需要掌握 10 個(gè)常用簡(jiǎn)單繪制規(guī)范即可。

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

1. 全局型異常流程，指在系統(tǒng)全局都會(huì)出現(xiàn)的異常流程；
2. 功能型異常流程，指在功能操作和規(guī)則上出現(xiàn)的異常流程；
3. 業(yè)務(wù)型異常流程，指正常業(yè)務(wù)過(guò)程中，發(fā)生不符合預(yù)期的業(yè)務(wù)流程。

不同類型異常流程應(yīng)用，我們會(huì)在后續(xù)「流程圖篇」進(jìn)行講解。

產(chǎn)品經(jīng)理在原型繪制上避免追求高保真原型和原型交互設(shè)計(jì)，需求文檔的核心是傳遞需求信息，只要能達(dá)到目的，低保真原型和無(wú)交互設(shè)計(jì)都可以。

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

如何在極短的時(shí)間內(nèi)輸出一份低保真原型，我們會(huì)在后續(xù)「原型篇」進(jìn)行講解。

3. 功能描述標(biāo)準(zhǔn)化

功能描述是產(chǎn)品經(jīng)理碼字最多的地方，也是開(kāi)發(fā)人員理解和落地功能點(diǎn)開(kāi)發(fā)的根據(jù)。

開(kāi)發(fā)人員在功能點(diǎn)出現(xiàn)理解誤差的主要原因，是功能描述不標(biāo)準(zhǔn)，即遺漏功能點(diǎn)。

我們以信息流「下滑加載」為例，用戶通過(guò)「下滑加載」功能獲取信息，我們?cè)趺磳?xiě)這個(gè)功能點(diǎn)？

A. 用戶可以在頁(yè)面頂部向下滑動(dòng)觸發(fā)加載功能，每次加載獲取下一頁(yè)的內(nèi)容，加載失敗時(shí)，toast 文字提示：「加載失敗~」。

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

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

通過(guò) A 與 B 兩段功能描述，我們清楚看到 A 遺漏 8 點(diǎn)功能點(diǎn)，還有 1 點(diǎn)功能描述不清晰，這意味著開(kāi)發(fā)和測(cè)試人員就一個(gè)功能，得和產(chǎn)品經(jīng)理溝通 9 次以上。

功能描述標(biāo)準(zhǔn)化的最大好處，是減少產(chǎn)品經(jīng)理和開(kāi)發(fā)人員的信息差，減少反復(fù)溝通確認(rèn)，讓開(kāi)發(fā)人員更多時(shí)間專注在功能落地。

功能描述如何標(biāo)準(zhǔn)化，在后續(xù)「功能描述篇」進(jìn)行詳細(xì)闡述。

03 最后的話

在文章最后，我們總結(jié)全篇核心內(nèi)容：

1. 需求文檔的本質(zhì)是：需求方，產(chǎn)品經(jīng)理，開(kāi)發(fā)人員之間需求和解決方案的「信息傳遞工具」。
2. 產(chǎn)品開(kāi)發(fā)主要溝通問(wèn)題，是「信息差」+「多人溝通」導(dǎo)致信息不同步，容易做出無(wú)用產(chǎn)品。
3. 高需求文檔水平的方式是標(biāo)準(zhǔn)化，指「文檔結(jié)構(gòu)化」，「繪制標(biāo)準(zhǔn)化」，「功能描述標(biāo)準(zhǔn)化」。

后續(xù)的想法，希望通過(guò) 5-6 篇闡述需求文檔的文章，幫助大家減少一點(diǎn)時(shí)間在需求文檔和溝通上，

然后，2023 年多一點(diǎn)時(shí)間讓自我成長(zhǎng)。