都是写需求，高手和菜鸟为何差别这么大？
同樣是寫需求，為什么有的人能一次過，而有的人改了又改，甚至還要推倒重來？
同樣是寫需求，為什么有的人考慮全面，而有的人丟三落四，直到評審的時候被懟得體無完膚？
同樣是寫需求，為什么有的人簡單易懂，而有的人長篇大論，大家卻看不懂？
這種情況在我們工作中經常會看到，優秀的需求文檔和拙劣的需求文檔，就像產品經理的臉面。
那么，怎么才能寫出一份漂亮的需求文檔，結合這幾年的工作總結，和大家聊一聊
一、準確理解需求，才能有的放矢
寫需求的大忌之一，就是自嗨。
很多自嗨型選手，自傲型的，會覺得自己的理解才是最完美的，用戶提的需求或者場景，都是欠考慮的。
他們不屑去找用戶求證，也不會使用簡單的方案先驗證需求，而是完美主義的妄想一步到位，他們信奉喬幫主的一句話：用戶并不知道自己需要的是什么，直到我們拿出自己的產品，他們就發現這是我想要的。
自卑型的，他們不愿意找用戶，害怕找用戶求證。因為擔心自己沒有理解用戶的需求，會被其他人看不起，懷疑自己的能力。
所以即使不理解，也不愿意找用戶求證，但是又要交差，最后就只能按照自己的理解硬著頭皮上。
不能準確理解業務場景，就敢寫需求的，最后都會成為烈士。理解了需求是1，后面所有的文檔，開發和測試都建立在這個1上，沒有1，后面再多的0也白搭。
準確理解需求，其實就是要理解需求背后的使用場景，可以使用常用的5W1H框架。
what：用戶的問題和需求是什么？
when：用戶什么時候會遇到這樣的問題?
why：用戶為什么會遇到這樣的問題？
where：用戶一般在什么地方遇到這樣的問題:
who：遇到這個問題的用戶是誰？用戶群體有什么特征？
how：用戶當前是怎么解決這個問題的？
比如我最近負責的產品，有一個預警的需求，主要是針對平臺的異常數據進行預警。
預警一般就分為三步：預警的數據從哪來？預警的規則如何設置？產生預警后以怎樣的形式發送給誰？
前兩步我跟用戶（公司的業務方）都對的比較清楚。而在第三步通知上，我就犯了理所當然的錯誤，陷入了自己的想象中。
我的想法是，產生預警的消息通知因為需要根據模板來配置的，這就有點類似于微信消息通知，都有固定的模板。
所以我想當然的認為，我們也只能通過設置幾個固定的模板，然后根據產生預警的內容往模板里面填充信息。
但實際用戶的需求并不是這樣，固定的模板不能滿足用戶的需求，用戶不僅需要預警消息，還需要自定義通知哪些信息給哪些用戶。
所以最終的后果就是定好的開發計劃需要重新制定，需求需要重新評審。好在還沒有進入開發，只是耽誤了2天的時間。如果是在驗收的時候發現這個問題，那簡直就是災難了。
磨刀不誤砍柴工，前期需求確認越準確，需求的不確定就越小，后期修改和返工的概率就越小。
二、學會制造和使用工具
確認好需求以后，就可以著手開始寫文檔了。
需求文檔本質上是將我們腦子里對需求功能的構想，準確的傳達給設計師、開發和測試同事。
那么，有哪些方法能提高信息的傳達率呢？總結起來，大概有三種方法：
換位思考，站在開發的角度思考問題
既然我們主要是寫給開發同學看的，那么就應該用他們熟悉的思考方式來撰寫需求文檔。
什么是開發的思維方式呢？答案是函數思維。所有的函數都由三部分組成：輸入—方法—輸出。針對某一功能，用戶的輸入是什么？經過什么樣的方法或流程？最終輸出是什么？
例如，登錄功能，用戶輸入賬號和密碼，點擊登錄按鈕，這過程經過了哪些？
輸入：用戶的賬號、密碼；
方法或流程：請求后臺用戶賬號表，校驗用戶賬號和密碼；
輸出：返回登錄結果，登錄成功跳轉到首頁，登錄失敗則返回失敗的原因。
因此，功能的詳細需求描述，應該包括：
要寫清楚功能的輸入是什么？輸入的參數有哪些？是否是必填，參數的字段類型是怎樣的？
調用什么樣的方法或流程
輸出是什么
異常情況有哪些，如何處理？
其中，調用的方法或流程，我們可以使用流程圖來對功能的數據在各個系統之間的流轉做出精確的刻畫。如果涉及到多個角色或系統，可以使用泳道圖來進行描述。
異常情況的梳理，后面會具體講到。
學會使用動態面板
字不如表，表不如圖。將我們腦子里對需求和功能的構思用原型圖的方式展示出來，這是最直觀的方式。
對語言的理解，由于各自的理解水平、閱歷經驗等不同，一千個讀者就有一千個哈姆雷特。
用原型圖畫出來的保真圖，能夠清晰的告訴大家，我們最終想要實現的效果，頁面自己的跳轉是怎樣的？同時在我們繪制原型圖時，也是我們對需求的進一步梳理。
搭建專屬的高保真組件庫
寫需求的顏值和效率如何兼顧？怎樣又快又美觀的完成需求文檔？答案是高保真組件庫。
這里的組件庫，不是市面上流傳的那些通用的組件庫，而是專屬于我們所負責產品的組件庫。
通用組件庫因為是通用的，所以每次我們使用這些組件庫時，都還需要對這些組件進行一些個性化改造。
所以為了進一步提高我們的效率，可以在這些通用組件庫的基礎上，進一步個性化為自己所負責產品的組件庫。
組件庫搭建成功以后，寫需求就真的是搭積木一樣了，不僅美觀而且效率很高。
通用組件庫可以在antidesign上下載一份。當然，如果你有一位交互設計大佬，也可以求她幫你做一份，就看你的本事了~
如果是自己來設計組件庫，可以參考制作PPT的一些基本設計原則，這些都是相通的。
這里簡單介紹下美國著名設計師Roibin Williams提出了四個關于設計的基本原則：
重復，作品中的一些元素可以在整個設計中重復出現，可能是某種圖案、顏色、文字、空間關系等，重復促成統一；例如一些重復組件的樣式和設計，彈窗、提示、輸入框等
對齊，任何元素都不能在頁面上隨意安排，每一項都應當與頁面上的內容存在某種聯系。頁面上的組件都應該才有某種方式對齊，組件與組件間的間距也要一樣。
對比是為作品增加視覺效果的最有效途徑之一，同時也能清晰地起到區分作用。例如：標題、正文、說明注釋等字體的大小應該有層次感，相同類型的文字格式，包括字體大小，加粗/傾斜，顏色等都應該保持一致
親密性原則是指，將相關項組織在一起而使他們之間產生凝聚力，因為物理位置的接近意味著存在關聯。文字建議使用冷色調，文字顏色和背景色要對比明顯，例如黑底白字，藍底白字，白底黑字等。只有一些特殊的信息使用鮮艷的顏色的提示，例如報警、注意、異常情況等
三、增刪查改顯算傳，盡量做到MECE
我們寫需求的時候總是會遇到考慮不周全的情況。
首先要說明的是，切忌不要完美主義，沒有人總是一次就能把所有因素都考慮在內。
關于需求的完整度，我們盡力即可，而且這其實是非常吃經驗的事，我們可以在工作過程中多總結。
MECE雖然做起來很難，但是做得好的話，它其實是一件令人上癮的事情。那種算盡一切的感覺真的很棒。
尤其是在需求評審，研發、測試等同學問什么問題，你都能回答出來的時候，不僅會給人一種專業的感覺，而且自己也會獲得一種極大的成就感。
給大家分享一些寫需求時，可以提高需求完整度的“7字真言”：增刪查改顯算傳。
增就是新增，刪就是刪除，查就是查詢，改就是修改，增刪查改是形影不離的四兄弟。
所以在設計功能的時候，有其中之一，你就要考慮其他三個有沒有漏掉。
當然，還是要根據業務實事求是。例如有的系統對刪除比較敏感，有的低權限的用戶只能新增，不能刪除，也是有可能的。
顯就是顯示，以怎樣的形式呈現給用戶。列表，還是圖形，彈窗還是新的頁面，文字展示不完怎么辦？數據太多是否需要翻頁？數值數據使用哪種格式？最終，還是要根據具體的業務來。
算就是計算，常見的就是功能的某些字段的值是如何計算得來的？最常見的就是數據埋點，數據的來源，指標的計算方式等
傳就是傳值，該功能前后端的數據交互是怎樣的，中間的數據流轉涉及到哪些系統。例如支付功能，就至少涉及用戶賬號系統，錢包系統，第三方支付系統等。
除了這些，還有寫需求經常會犯的一個錯誤，就是只考慮正常流程，不考慮異常流程。
其實對于異常流程考慮得是否完整，才是對一個PM的專業度的考驗。
常見的一些異常，供大家參考：
當功能有限制時，就需要考慮兩頭的極端情況，例如活動是有時間限制的，就需要考慮用戶在參加活動時，剛好超過時間限制，此時該如何處理？
輸入框，支持哪些字符，中文，英文，數字。如果支持特殊符號，具體支持哪些符號，這些都需要提前定義好。輸入框的長度限制，最大最小支持多少字符，輸入時超過最大長度怎么辦？字段字符太長展示不完怎么辦？
批量導入文件，文件支持哪些格式？文件大小有哪些限制？是否一次性支持多個文件導入？如果支持多個文件導入，有個別文件格式不正確或大小超出限制怎么辦？文件的內容不符合要求怎么辦？
有權限限制，正常情況下操作權限范圍內的功能沒問題，但是在操作過程中，如果沒有權限了，此時該怎么處理？如果對同一個頁面，有多個用戶擁有編輯權限，那么同時編輯的時候，如何處理？
定時任務型功能，例如預警任務，預警任務的運行頻次是怎樣的？是否允許重復發送預警？預警消息發送失敗了怎么辦？定時任務啟動失敗怎么辦？
頁面沒數據時該怎么展示？這個是比較容易被遺忘的點，很多頁面的缺省頁都是需要設計師設計的，因為放一個空白頁面太不友好了，不知道是正在加載，還是沒網，還是出bug了。
網絡異常如何處理？網絡弱的情況如何處理？（APP比較常見）
異常情況，其實可以多跟測試同學聊聊，他們才是真正的專家~
如果能把以上7字箴言和常見的異常情況都考慮清楚，可以說就是一個合格的需求文檔了，更進一步，就需要從整體上進行設計，當前的設計要為后續的迭代和完善做好鋪墊。
這個比較吃經驗，我們在工作的過程中可以多總結，針對一些常見的功能復盤他們的迭代路徑。
這樣積累下去，以后一看到類似的需求，就能做到胸有成竹了。
四、追根溯源，舉一反三
如果是新需求，要舉一反三。簡單來說，就是在細化需求的時候，要把和這個需求相關的其他功能點都考慮在內。
我做這個需求會影響到哪些功能模塊，需要哪些功能模塊配合？
舉個我做過的APP的例子來說，為方便理解，先交代下背景：
我們的APP里有代駕和打車兩項技能，打車已有，代駕需要新增。
打車和代駕都是屬于先享受服務，然后再支付的類型。那么，為了防止白嫖，我們采取的是先凍結部分用戶在APP賬戶內的金額。
原來只有打車的話，那么凍結金額就只有打車的，現在增加了代駕，也需要凍結金額。
那么，在寫代駕訂單邏輯的時候，就需要考慮到這部分凍結金額的邏輯，該如何處理，才能不影響打車。
凍結金額就需要從原來的只有打車，變成需要區分為打車和代駕。其實不止這些，代駕還涉及到訂單后臺，賬單系統和錢包系統的修改，都要考慮到。
如果你沒考慮到打車這個已有功能，就會讓別人對你的專業能力產生質疑，三番幾次就會失去開發的信任。
所以，我們在完善需求的時候，不僅要關注當前的需求，還要抬頭看看四周，與這個需求有關的還有哪些其他的系統，這些系統要相應做哪些修改，都要考慮周全。
如果是功能優化，那么不僅需要考慮與其他功能的關系，還要考慮與自身的關系。
簡單來說，就是要考慮以前數據，功能和交互的兼容性。我在做后臺的時候，吃了很多次虧。
還是舉個我自己的例子。
最近我們對賬單進行了升級，原來的賬單數據非常簡單，就是對賬單數據的簡單羅列，沒有篩選功能。
在賬單升級后，數據結構發生了改變，增加了可按照業務類型（打車和代駕），支付時間和支付方式三個維度進行篩選。
當時我做的時候，沒有考慮到一個重要的因素，就是要對以前的賬單數據做兼容，導致賬單升級以后，只能看到升級以后的數據。
這樣就只能后面再補需求進行處理。雖然這沒有造成很大的影響，但是如果是后續處理不了了，那就是真的大麻煩了。
所以，我們在迭代需求的時候，一定要考慮這個需求的來龍去脈，注意對這個需求以前的數據，交互方式等進行兼容。
五、注意考慮相關方，尤其是B端
相關方，簡單來說就是跟你做這個項目或者需求有任意聯系的人。比如說你負責的是某業務后臺的搭建項目，那么相關的人就至少有：
你的領導，該業務負責人，該業務核心人員（實際使用你后臺干活的），開發人員，測試人員，設計人員。
如何識別這些相關方呢？可以從是否參與項目與所受影響兩個維度來區分。也可以按照相關方類型來區分。
比如：上游供應商，下游客戶，中間有老板，領導，開發團隊，測試團隊，設計團隊，運營團隊，業務團隊等。
將相關方識別出來之后，我們就知道哪些相關方是需要我們重點關注，哪些相關方是無關緊要的。
畢竟我們的精力是有限的，我們必須把80%的精力用在關鍵的20%的人身上，才能保證效率最大化。否則面面俱到只會把自己累死，吃力且不討好。
最后，雖然我們總說不要成為功能或者需求經理，但是過硬的寫需求的能力，是決定我們底線的關鍵，只有基礎夯實，才能建起高樓大廈~
最后也歡迎有問題的小伙伴加微信：chanpin628?溝通交流。
此外我們的官方網站也上線了，每日分享高質量的文章、原型素材和行業報告，小伙伴可自行前往索取，支持搜索，需要的小伙伴可點擊底部的閱讀原文直接查看，或者復制網址：www.dadaghp.com?打開。
更多干貨可關注微信公眾號：產品劉
想學習更多關于產品、職場、心理、認知等干貨，可長按右邊二維碼，關注我們。
··················END··················
RECOMMEND
推薦閱讀
分享一個產品經理轉正述職報告
面試題，你還去過哪些公司面試？
手把手教你做產品經理1.0
有這些特征的公司一般都要996
點擊“閱讀原文”
查看更多干貨
總結
以上是生活随笔為你收集整理的都是写需求，高手和菜鸟为何差别这么大？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 在windows上实现多个java jd
- 下一篇： 完全理解NIO Selector