無論是互聯(lián)網(wǎng)產(chǎn)品還是產(chǎn)品項目，所有這一切的開端都始于需求分析，一份好的需求文檔往往是項目成功的先決條件，對一個產(chǎn)品經(jīng)理或項目經(jīng)理來說就顯得尤為重要。但是，同樣是寫需求，不同的人寫出來效果卻截然不同。相比產(chǎn)品菜鳥，高手究竟在哪些方面表現(xiàn)得更為突出呢？

• 同樣是寫需求，為什么有的人能一次過，而有的人改了又改，甚至還要推倒重來？
• 同樣是寫需求，為什么有的人考慮全面，而有的人丟三落四，直到評審的時候被懟得體無完膚？
• 同樣是寫需求，為什么有的人簡單易懂，而有的人長篇大論，大家卻看不懂？

這種情況在我們工作中經(jīng)常會看到，優(yōu)秀的需求文檔和拙劣的需求文檔，就像產(chǎn)品經(jīng)理的臉面。

那么，怎么才能寫出一份漂亮的需求文檔，結(jié)合這幾年的工作總結(jié)，和大家聊一聊

一、準確理解需求，才能有的放矢

寫需求的大忌之一，就是自嗨。

很多自嗨型選手，自傲型的，會覺得自己的理解才是最完美的，用戶提的需求或者場景，都是欠考慮的。

他們不屑去找用戶求證，也不會使用簡單的方案先驗證需求，而是完美主義的妄想一步到位，他們信奉喬幫主的一句話：用戶并不知道自己需要的是什么，直到我們拿出自己的產(chǎn)品，他們就發(fā)現(xiàn)這是我想要的。

自卑型的，他們不愿意找用戶，害怕找用戶求證。因為擔心自己沒有理解用戶的需求，會被其他人看不起，懷疑自己的能力。

所以即使不理解，也不愿意找用戶求證，但是又要交差，最后就只能按照自己的理解硬著頭皮上。

不能準確理解業(yè)務(wù)場景，就敢寫需求的，最后都會成為烈士。理解了需求是1，后面所有的文檔，開發(fā)和測試都建立在這個1上，沒有1，后面再多的0也白搭。

準確理解需求，其實就是要理解需求背后的使用場景，可以使用常用的5W1H框架。

• what：用戶的問題和需求是什么？
• when：用戶什么時候會遇到這樣的問題?
• why：用戶為什么會遇到這樣的問題？
• where：用戶一般在什么地方遇到這樣的問題:
• who：遇到這個問題的用戶是誰？用戶群體有什么特征？
• how：用戶當前是怎么解決這個問題的？

比如我最近負責的產(chǎn)品，有一個預(yù)警的需求，主要是針對平臺的異常數(shù)據(jù)進行預(yù)警。

預(yù)警一般就分為三步：預(yù)警的數(shù)據(jù)從哪來？預(yù)警的規(guī)則如何設(shè)置？產(chǎn)生預(yù)警后以怎樣的形式發(fā)送給誰？

前兩步我跟用戶（公司的業(yè)務(wù)方）都對的比較清楚。而在第三步通知上，我就犯了理所當然的錯誤，陷入了自己的想象中。

我的想法是，產(chǎn)生預(yù)警的消息通知因為需要根據(jù)模板來配置的，這就有點類似于微信消息通知，都有固定的模板。

所以我想當然的認為，我們也只能通過設(shè)置幾個固定的模板，然后根據(jù)產(chǎn)生預(yù)警的內(nèi)容往模板里面填充信息。

但實際用戶的需求并不是這樣，固定的模板不能滿足用戶的需求，用戶不僅需要預(yù)警消息，還需要自定義通知哪些信息給哪些用戶。

所以最終的后果就是定好的開發(fā)計劃需要重新制定，需求需要重新評審。好在還沒有進入開發(fā)，只是耽誤了2天的時間。如果是在驗收的時候發(fā)現(xiàn)這個問題，那簡直就是災(zāi)難了。

磨刀不誤砍柴工，前期需求確認越準確，需求的不確定就越小，后期修改和返工的概率就越小。

二、學(xué)會制造和使用工具

確認好需求以后，就可以著手開始寫文檔了。

需求文檔本質(zhì)上是將我們腦子里對需求功能的構(gòu)想，準確的傳達給設(shè)計師、開發(fā)和測試同事。

那么，有哪些方法能提高信息的傳達率呢？總結(jié)起來，大概有三種方法：

第一，換位思考，站在開發(fā)的角度思考問題

既然我們主要是寫給開發(fā)同學(xué)看的，那么就應(yīng)該用他們熟悉的思考方式來撰寫需求文檔。

什么是開發(fā)的思維方式呢？答案是函數(shù)思維。所有的函數(shù)都由三部分組成：輸入—方法—輸出。針對某一功能，用戶的輸入是什么？經(jīng)過什么樣的方法或流程？最終輸出是什么？

例如，登錄功能，用戶輸入賬號和密碼，點擊登錄按鈕，這過程經(jīng)過了哪些？

• 輸入：用戶的賬號、密碼；
• 方法或流程：請求后臺用戶賬號表，校驗用戶賬號和密碼；
• 輸出：返回登錄結(jié)果，登錄成功跳轉(zhuǎn)到首頁，登錄失敗則返回失敗的原因。

因此，功能的詳細需求描述，應(yīng)該包括：

1. 要寫清楚功能的輸入是什么？輸入的參數(shù)有哪些？是否是必填，參數(shù)的字段類型是怎樣的？
2. 調(diào)用什么樣的方法或流程
3. 輸出是什么
4. 異常情況有哪些，如何處理？

其中，調(diào)用的方法或流程，我們可以使用流程圖來對功能的數(shù)據(jù)在各個系統(tǒng)之間的流轉(zhuǎn)做出精確的刻畫。如果涉及到多個角色或系統(tǒng)，可以使用泳道圖來進行描述。

異常情況的梳理，后面會具體講到。

第二，學(xué)會使用動態(tài)面板

字不如表，表不如圖。將我們腦子里對需求和功能的構(gòu)思用原型圖的方式展示出來，這是最直觀的方式。

對語言的理解，由于各自的理解水平、閱歷經(jīng)驗等不同，一千個讀者就有一千個哈姆雷特。

用原型圖畫出來的保真圖，能夠清晰的告訴大家，我們最終想要實現(xiàn)的效果，頁面自己的跳轉(zhuǎn)是怎樣的？同時在我們繪制原型圖時，也是我們對需求的進一步梳理。

第三，搭建專屬的高保真組件庫

寫需求的顏值和效率如何兼顧？怎樣又快又美觀的完成需求文檔？答案是高保真組件庫。

這里的組件庫，不是市面上流傳的那些通用的組件庫，而是專屬于我們所負責產(chǎn)品的組件庫。

通用組件庫因為是通用的，所以每次我們使用這些組件庫時，都還需要對這些組件進行一些個性化改造。

所以為了進一步提高我們的效率，可以在這些通用組件庫的基礎(chǔ)上，進一步個性化為自己所負責產(chǎn)品的組件庫。

組件庫搭建成功以后，寫需求就真的是搭積木一樣了，不僅美觀而且效率很高。

通用組件庫可以在antidesign上下載一份。當然，如果你有一位交互設(shè)計大佬，也可以求她幫你做一份，就看你的本事了~

如果是自己來設(shè)計組件庫，可以參考制作PPT的一些基本設(shè)計原則，這些都是相通的。

這里簡單介紹下美國著名設(shè)計師Roibin Williams提出了四個關(guān)于設(shè)計的基本原則：

1. 重復(fù)，作品中的一些元素可以在整個設(shè)計中重復(fù)出現(xiàn)，可能是某種圖案、顏色、文字、空間關(guān)系等，重復(fù)促成統(tǒng)一；例如一些重復(fù)組件的樣式和設(shè)計，彈窗、提示、輸入框等
2. 對齊，任何元素都不能在頁面上隨意安排，每一項都應(yīng)當與頁面上的內(nèi)容存在某種聯(lián)系。頁面上的組件都應(yīng)該才有某種方式對齊，組件與組件見的間距也要一樣。
3. 對比是為作品增加視覺效果的最有效途徑之一，同時也能清晰地起到區(qū)分作用。例如：標題、正文、說明注釋等字體的大小應(yīng)該有層次感，相同類型的文字格式，包括字體大小，加粗/傾斜，顏色等都應(yīng)該保持一致
4. 親密性原則是指，將相關(guān)項組織在一起而使他們之間產(chǎn)生凝聚力，因為物理位置的接近意味著存在關(guān)聯(lián)。文字建議使用冷色調(diào)，文字顏色和背景色要對比明顯，例如黑底白字，藍底白字，白底黑子等。只有一些特殊的信息使用鮮艷的提示，例如報警、注意、異常情況等

三、增刪查改顯算傳，盡量做到MECE

我們寫需求的時候總是會遇到考慮不周全的情況。

首先要說明的是，切忌不要完美主義，沒有人總是一次就能把所有因素都考慮在內(nèi)。

關(guān)于需求的完整度，我們盡力即可，而且這其實是非常吃經(jīng)驗的事，我們可以在工作過程中多總結(jié)。

MECE雖然做起來很難，但是做得好的話，它其實是一件令人上癮的事情。那種算盡一切的感覺真的很棒。

尤其是在需求評審，研發(fā)、測試等同學(xué)問什么問題，你都能回答出來的時候，不僅會給人一種專業(yè)的感覺，而且自己也會獲得一種極大的成就感。

給大家分享一些寫需求時，可以提高需求完整度的“7字真言”：增刪查改顯算傳。

增就是新增，刪就是刪除，查就是查詢，改就是修改，增刪查改是形影不離的四兄弟。

所以在設(shè)計功能的時候，有其中之一，你就要考慮其他三個有沒有漏掉。

當然，還是要根據(jù)業(yè)務(wù)實事求是。例如有的系統(tǒng)對刪除比較敏感，有的低權(quán)限的用戶只能新增，不能刪除，也是有可能的。

顯就是顯示，以怎樣的形式呈現(xiàn)給用戶。列表，還是圖形，彈窗還是新的頁面，文字展示不完怎么辦？數(shù)據(jù)太多是否需要翻頁？數(shù)值數(shù)據(jù)使用哪種格式？最終，還是要根據(jù)具體的業(yè)務(wù)來。

算就是計算，常見的就是功能的某些字段的值是如何計算得來的？最常見的就是數(shù)據(jù)埋點，數(shù)據(jù)的來源，指標的計算方式等

傳就是傳值，該功能前后端的數(shù)據(jù)交互是怎樣的，中間的數(shù)據(jù)流轉(zhuǎn)涉及到哪些系統(tǒng)。例如支付功能，就至少涉及用戶賬號系統(tǒng)，錢包系統(tǒng)，第三方支付系統(tǒng)等。

除了這些，還有寫需求經(jīng)常會犯的一個錯誤，就是只考慮正常流程，不考慮異常流程。

其實對于異常流程考慮得是否完整，才是對一個PM的專業(yè)度的考驗。

常見的一些異常，供大家參考：

1. 當功能有限制時，就需要考慮兩頭的極端情況，例如活動是有時間限制的，就需要考慮用戶在參加活動時，剛好超過時間限制，此時該如何處理？
2. 輸入框，支持哪些字符，中文，英文，數(shù)字。如果支持特殊符號，具體支持哪些符號，這些都需要提前定義好。輸入框的長度限制，最大最小支持多少字符，輸入時超過最大長度怎么辦？字段字符太長展示不完怎么辦？
3. 批量導(dǎo)入文件，文件支持哪些格式？文件大小有哪些限制？是否一次性支持多個文件導(dǎo)入？如果支持多個文件導(dǎo)入，有個別文件格式不正確或大小超出限制怎么辦？文件的內(nèi)容不符合要求怎么辦？
4. 有權(quán)限限制，正常情況下操作權(quán)限范圍內(nèi)的功能沒問題，但是在操作過程中，如果沒有權(quán)限了，此時該怎么處理？如果對同一個頁面，有多個用戶擁有編輯權(quán)限，那么同時編輯的時候，如何處理？
5. 定時任務(wù)型功能，例如預(yù)警任務(wù)，預(yù)警任務(wù)的運行頻次是怎樣的？是否允許重復(fù)發(fā)送預(yù)警？預(yù)警消息發(fā)送失敗了怎么辦？定時任務(wù)啟動失敗怎么辦？
6. 頁面沒數(shù)據(jù)時該怎么展示？這個是比較容易被遺忘的點，很多頁面的缺省頁都是需要設(shè)計師設(shè)計的，因為放一個空白頁面太不友好了，不知道是正在加載，還是沒網(wǎng)，還是出bug了。
7. 網(wǎng)絡(luò)異常如何處理？網(wǎng)絡(luò)弱的情況如何處理？（APP比較常見）

異常情況，其實可以多跟測試同學(xué)聊聊，他們才是真正的專家~

如果能把以上7字真言和常見的異常情況都考慮清楚，可以說就是一個合格的需求文檔了，更進一步，就需要從整體上進行設(shè)計，當前的設(shè)計要為后續(xù)的迭代和完善做好鋪墊。

這個比較吃經(jīng)驗，我們在工作的過程中可以多總結(jié)，針對一些常見的功能復(fù)盤他們的迭代路徑。

這樣積累下去，以后一看到類似的需求，就能做到胸有成竹了。

四、追根溯源，舉一反三

如果是新需求，要舉一反三。簡單來說，就是在細化需求的時候，要把和這個需求相關(guān)的其他功能點都考慮在內(nèi)。

我做這個需求會影響到哪些功能模塊，需要哪些功能模塊配合？

舉個我做過的APP的例子來說，為方便理解，先交代下背景：

我們的APP里有代駕和打車兩項技能，打車已有，代駕需要新增。

打車和代駕都是屬于先享受服務(wù)，然后再支付的類型。那么，為了防止白嫖，我們采取的是先凍結(jié)部分用戶在APP賬戶內(nèi)的金額。

原來只有打車的話，那么凍結(jié)金額就只有打車的，現(xiàn)在增加了代駕，也需要凍結(jié)金額。

那么，在寫代駕訂單邏輯的時候，就需要考慮到這部分凍結(jié)金額的邏輯，該如何處理，才能不影響打車。

凍結(jié)金額就需要從原來的只有打車，變成需要區(qū)分為打車和代駕。其實不止這些，代駕還涉及到訂單后臺，賬單系統(tǒng)和錢包系統(tǒng)的修改，都要考慮到。

如果你沒考慮到打車這個已有功能，就會讓別人對你的專業(yè)能力產(chǎn)生質(zhì)疑，三番幾次就會失去開發(fā)的信任。

所以，我們在完善需求的時候，不僅要關(guān)注當前的需求，還要抬頭看看四周，與這個需求有關(guān)的還有哪些其他的系統(tǒng)，這些系統(tǒng)要相應(yīng)做哪些修改，都要考慮周全。

如果是功能優(yōu)化，那么不僅需要考慮與其他功能的關(guān)系，還要考慮與自身的關(guān)系。

簡單來說，就是要考慮以前數(shù)據(jù)，功能和交互的兼容性。我在做后臺的時候，吃了很多次虧。

還是舉個我自己的例子。

最近我們對賬單進行了升級，原來的賬單數(shù)據(jù)非常簡單，就是對賬單數(shù)據(jù)的簡單羅列，沒有篩選功能。

在賬單升級后，數(shù)據(jù)結(jié)構(gòu)發(fā)生了改變，增加了可按照業(yè)務(wù)類型（打車和代駕），支付時間和支付方式三個維度進行篩選。

當時我做的時候，沒有考慮到一個重要的因素，就是要對以前的賬單數(shù)據(jù)做兼容，導(dǎo)致賬單升級以后，只能看到升級以后的數(shù)據(jù)。

這樣就只能后面再補需求進行處理。雖然這沒有造成很大的影響，但是如果是后續(xù)處理不了了，那就是真的大麻煩了。

所以，我們在迭代需求的時候，一定要考慮這個需求的來龍去脈，注意對這個需求以前的數(shù)據(jù)，交互方式等進行兼容。

五、注意考慮相關(guān)方，尤其是B端

相關(guān)方，簡單來說就是跟你做這個項目或者需求有任意聯(lián)系的人。比如說你負責的是某業(yè)務(wù)后臺的搭建項目，那么相關(guān)的人就至少有：

你的領(lǐng)導(dǎo)，該業(yè)務(wù)負責人，該業(yè)務(wù)核心人員（實際使用你后臺干活的），開發(fā)人員，測試人員，設(shè)計人員。

如何識別這些相關(guān)方呢？可以從是否參與項目與所受影響兩個維度來區(qū)分。也可以按照相關(guān)方類型來區(qū)分。

比如：上游供應(yīng)商，下游客戶，中間有老板，領(lǐng)導(dǎo)，開發(fā)團隊，測試團隊，設(shè)計團隊，運營團隊，業(yè)務(wù)團隊等。

將相關(guān)方識別出來之后，我們就知道哪些相關(guān)方是需要我們重點關(guān)注，哪些相關(guān)方是無關(guān)緊要的。

畢竟我們的精力是有限的，我們必須把80%的精力用在關(guān)鍵的20%的人身上，才能保證效率最大化。否則面面俱到只會把自己累死，吃力且不討好。

最后，雖然我們總說不要成為功能或者需求經(jīng)理，但是過硬的寫需求的能力，是決定我們底線的關(guān)鍵，只有基礎(chǔ)夯實，才能建起高樓大廈~

本文由 @Jarvan 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議